Skip to main content
The Partner Program is for companies that operate a sales agent on behalf of other businesses. A useful qualification question is: Do you offer a sales agent that another company uses to sell media? A buyer or seller that only uses an agent does not need to join the Partner Program unless it also offers that agent to other companies. The sales-agent offering belongs to the organization; it is not a third account beside the organization’s Buyer and Seller accounts. Organization administrators can open the Partner page to learn about the program, register an operator, and begin deterministic certification at no cost. Some compatibility APIs still expose this organization-level offering as accountType: PARTNER; clients must not treat that projection as a separate account. Unrelated-client operation requires the canonical operate-agents-for-clients entitlement under accepted paid terms or an explicitly approved, time-bounded beta. Contracted support, delegated debugging, statements, Partner-funded AI, and promotion remain paid-only. The current product also gates public listing with Partner access; the planned Agent marketplace separates baseline truthful visibility from certification and commercial authority, but that marketplace picker is not available in Seller Setup yet. During public signup, choosing Offer a sales agent to other sellers creates the organization and starts sales-agent registration. After email verification, the administrator continues to registration; signup does not request or grant commercial approval to operate the agent for unrelated clients. The organization’s Partner page gives agent operators a place to:
  • earn production certification from current evidence, including the zero-spend creative canary;
  • show buyers the identity and certification status of the production agent revision serving them;
  • inspect connected buyers, active results, source health, errors, latency, incidents, and ownership; and
  • use contracted Partner support for integrations, incidents, and buyer adoption after purchasing the right to operate agents for clients. Self-service certification and confirmed Apostra-defect or security intake remain available without it.
The Apostra Embedded Sales Agent is the reference implementation for explaining the certification journey. It is not represented as certified merely because Apostra operates it: certification is awarded to a specific production revision only after every required assertion is current. The reference card reads its status from the same production-certification registry used for third-party agents. All authenticated organizations can read the customer-safe projection:
The response includes Apostra operator and SALES capability names, the current deployed production version, and its current certification decision. It never returns the image digest, evidence references, connected clients, source health, or private diagnostics. Before a real production artifact is registered, the release is null and the certification status is REGISTERED; the UI does not substitute the version pinned in source control or imply that deployment proves certification.

​
Register your sales agent

An organization administrator can register the provider and sales agent their company operates directly from the Partner page. Registration and deterministic certification are free; paid Partner Program approval is not required to create the technical identity or begin certification. Registering does not expose connected clients, grant operational access, activate a commercial relationship, or award certification. The page creates two durable records:
  • the provider operator, which is the provider name buyers know; and
  • the typed SALES capability, which is the sales agent offered to clients.
Apostra may map a known provider operator and sales capability to your exact organization before your team completes registration. A mapped identity appears as Apostra mapped · unclaimed. It is only an identity map: it does not make the organization a Partner, certify the agent, authorize a client connection, or activate commercial status. A directly authenticated organization administrator can review and claim that mapping from Partner. Claiming preserves the existing operator UID, capability UID, client connections, and history. API clients can perform the same explicit, organization-scoped action:
An administrator cannot claim an operator mapped to a different organization. The original Apostra mapping provenance remains attached after a successful claim. There is one no-extra-login path for owned-and-operated supply. When an inventory Source is explicitly bound to a SALES capability whose provider owner and Source client resolve to the same effective organization, that binding is the ownership confirmation. Apostra marks the mapped operator claimed as part of the audited binding operation; an administrator does not also have to open Partner and claim it. Parent and child accounts under the same organization count as first-party. The same attributed binding records the first-party client request and provider acceptance, so the organization does not approve both sides of its own connection. Configuration, authorization, validation, certification, health, and quarantine gates remain separate. Endpoint or domain similarity alone never creates ownership. If the account hierarchy later changes so the Source and provider no longer share an effective organization, Apostra removes only the claim, registration, request, and acceptance facts created by this shortcut. An explicit provider claim, registration, or pre-existing client request remains durable; otherwise both sides complete the cross-organization workflow. This shortcut does not apply when another organization operates the Agent. Those cross-organization connections still require the provider to claim its identity, accept the client, and complete the applicable Partner connection workflow. It also does not apply to official adapters or embedded ad-server Sources. Attaching identity must not interrupt a cross-organization Source that was already serving before this Partner workflow existed. When the binding audit records that the Source was already active, Apostra keeps that legacy Source serving while the provider adopts the newer lifecycle. The Agent mapping and the operator ownership claim are separate: Apostra can record the exact Agent backing the Source while its operator remains unclaimed. This compatibility state does not claim the Agent, mark the connection accepted or activated, award certification, grant paid Partner authority, or authorize another Source. New and previously inactive client connections must complete the normal authorization, acceptance, validation, certification, and activation workflow before they can serve. API clients can use the same organization-scoped workflow:
Certification applies to an immutable implementation revision, not merely the provider name or endpoint. Register the exact revision, lowercase SHA-256 artifact digest, and its credential-free HTTPS endpoints before supplying test evidence. A revision accepts at most 16 endpoint declarations; endpoint keys must be unique within that revision. The endpoints list is optional, so existing registrations do not need to change. Each declaration requires:
  • endpointKey: 3–128 characters, beginning with a letter or number and then using only letters, numbers, ., _, :, /, +, or -
  • displayName: 1–255 characters
  • endpointUri: a valid HTTPS URL of at most 2,048 characters, without a username or password. The scheme is case-insensitive and is stored as lowercase https://; the host, port, path, query, and fragment remain otherwise exact (including an @ in the path).
The deployment reference must uniquely identify the production rollout. Reusing the same reference for the same revision is safe; reusing it for another revision is rejected. An explicit rollback appends another deployment event for the older revision, making that revision current without copying certification evidence.

​
Attest an endpoint for an observed revision

An observed production revision can be missing an endpoint declaration even when its immutable observation and deployment provenance are valid. A directly authenticated organization account administrator may append one endpoint attestation for that exact, current observed revision. This does not change the revision key, artifact digest, or deployment history. The attestation endpoint is available only when the revision is current for the SALES capability and the supplied endpoint URI matches the active, tenant-owned SALES source after lowercasing its HTTPS scheme only. Its host, port, path, query, and fragment are otherwise compared as supplied. The URI must be credential-free HTTPS with no query or fragment component. The endpoint key and display name are recorded with the attestation; credentials are never accepted by this API.
capabilityUid, revisionUid, and idempotencyKey are UUIDs. inventorySourceId is a positive decimal PostgreSQL BIGINT. The capability, revision, and source must still belong to the authenticated organization, and the source must be the current active SALES source for the supplied endpoint. The API canonicalizes only the case of the https:// scheme before comparing the URI to that source. It does not normalize the host, port, path, query, or fragment. The attestation request itself rejects credentials, query strings, and fragments, so use the exact credential-free source URI without those components. A successful request returns HTTP 200:
replayed is true when the same request is repeated with the same idempotencyKey; the response then returns the original attestation and endpoint identifiers. Reusing a key for different values, providing an invalid UUID or source ID, providing a URI with credentials, a query string, or a fragment, or attempting to attest a revision that already has an endpoint is rejected. An endpoint attestation supplies endpoint provenance only. It does not register or certify a revision, create a fixture, request an evaluation, activate a source, dispatch a test, or authorize a transaction. Those controls remain separate and must be satisfied independently. These writes require a directly authenticated organization account administrator. They cannot be performed through a service token or a staff-assisted impersonation session. A later deployment revision starts with its own evidence state and cannot inherit certification from an earlier one.

​
When fixture setup has no eligible option

Fixture setup evaluates the exact current production revision in this order: an endpoint declaration, an active SALES source with the same endpoint, and an active current source account. If there are no options, Interchange reports one safe reason without returning source-account or endpoint details:
  • NO_ENDPOINT_FOR_CURRENT_PRODUCTION_REVISION - a directly authenticated Account Admin can use Attest current endpoint from the Agent task, then enter and confirm the credential-free HTTPS endpoint, endpoint key, and display name. The task generates one idempotency key and reuses it if the request needs a retry.
  • NO_MATCHING_ACTIVE_SALES_SOURCE - the current revision has an endpoint, but no active SALES source matches it exactly.
  • NO_ACTIVE_CURRENT_SOURCE_ACCOUNT - the matching source has no active current source account.
Attesting an endpoint never creates a fixture, starts evaluation, changes paid membership, or authorizes a purchase. Fixture registration and certification remain separate protected steps.

​
Upgrade a private agent to Partner operations

A private first-party sales agent and a Partner-operated sales agent are the same durable agent identity. Upgrading changes who the agent is commercially authorized to serve; it does not create a second agent, convert an inventory Source to another type, or replace the Source-to-agent bindings already in use. Existing first-party Sources continue to work as first-party relationships. Open the agent from Agents, then use Who this Agent can serve. The card shows four independently evaluated prerequisites: provider ownership, Partner registration, production certification, and operating standing. Operating standing comes from accepted paid/payment authority or an unexpired beta; an active billing hold blocks both. Its primary action takes the organization to the exact unresolved step. When all four are ready, the same agent may accept explicitly authorized Sources belonging to unrelated client organizations. On the Partner page, select Join the certification partner program to review an issued private offer in Plan & Billing. The offer shows its exact price, currency, term, and version before an organization administrator accepts it. If payment authority is missing, the accepted offer continues to the secure payment-method setup. If no private offer has been issued, the page directs the organization to request commercial terms. Registering an agent and completing certification remain free throughout this process. Every unrelated-client Source still requires its own explicit client authorization, provider acceptance, validation, and activation. Partner access does not infer a relationship from a shared endpoint or domain, and it does not give the provider access to Sources that have not been bound to its agent.

​
Invite a client Storefront

An entitled Partner administrator can choose Invite a client Storefront from a Sales Agent’s Inventory sources section, or Add a client in Partner operations. Starting from an Agent opens the same invitation ledger with that exact Agent selected and its pending invitations in view. Enter the publisher name, bare publisher domain, and contact email. Apostra emails the contact a time-limited invitation and shows it as Not started until it is accepted. The invitation does not create a publisher account. The publisher follows the link and either creates its own organization or signs in to an existing one. A direct administrator then accepts the referral for that organization, selects an exact Agent Source owned by that organization, and explicitly authorizes the attachment. The Source binding, client request, and client consent are written atomically. The publisher remains responsible for its own credentials, payout setup, publisher domains, and adagents.json; Optimera or another Partner never receives its secret values. Accepting a referral links only the onboarding request. It does not create a Source, share credentials, record provider acceptance, or activate the connection. The next publisher action selects the exact Source and records the cross-organization binding and publisher consent. Credentials, payout setup, Partner acceptance, validation, and activation remain independent and appear independently in the publisher lifecycle. Partner administrators can also create and list referrals through the API:
The public preview accepts the invitation token in the request body and returns the Partner name, Agent name, intended publisher, invitation status, and expiry. It is rate-limited and does not return the contact email or publisher account data: The email link initially carries the bearer so the browser can open the invitation. Before analytics or error telemetry initialize, Apostra moves a valid bearer to same-tab session storage and removes it from the visible URL. Login and signup redirects point back to the clean /client-referral path and never copy the bearer into their query strings.
After signing in, a direct publisher administrator accepts the referral for the current organization. setup then returns that organization’s eligible Agent Sources and the exact completed attachment, if one already exists:
Completing onboarding requires both the token and one Source selected from the setup response:
setup returns only Agent Sources owned by the organization that accepted the referral. complete accepts one global inventorySourceId, rechecks the publisher organization and Partner capability inside the transaction, requires a cross-organization relationship, and records the exact binding and consent. Production certification remains attached to the Agent’s exact implementation revision, not repeated for each referral. Connection validation, runtime health, products, campaigns, and reporting remain publisher-specific. The Partner operations view gives an authorized provider operator a source-by-source view of the client inventory explicitly connected to its capabilities. The free workspace, registration, and certification views remain available without the operate-agents-for-clients entitlement. The operational view keeps these concepts separate:
  • Provider ownership identifies the organization that operates a provider and its capabilities.
  • Partner registration records the free program registration. Operating authority is derived from operate-agents-for-clients plus either accepted payment authority or an unexpired beta, with no billing hold; a workspace status label is not authority. Owning a private provider does not automatically grant unrelated-client operating rights.
  • Apostra production certification evaluates the exact latest implementation revision against the current required-assertion policy. It is not purchased through Partner status.
  • Client connections record the client’s request and authorization, the provider’s acceptance, validation, activation, quarantine, and connection revocation as distinct facts.
  • Runtime health comes from each connected inventory source and can differ between clients using the same certified implementation.
A child account uses its parent organization’s entitlement and switches to that organization before opening Partner operations.

​
Check Partner operations access

An organization administrator can read the effective decision before opening or activating an unrelated-client connection:
The response reports state, allowed, whether paid authority is contract-backed (purchased), account standing and its authority, ownership, certification readiness, denial reasons, and the next action. During the v2 compatibility window, featureKey remains partner-program-participation for existing API clients and the additive entitlementFeatureKey is operate-agents-for-clients. Older API deployments may omit entitlementFeatureKey, so clients should continue accepting the legacy featureKey and prefer entitlementFeatureKey when it is present. The access response makes paid and beta authority explicit. purchased: true means the entitlement is backed by accepted paid terms. A temporary beta instead returns purchased: false, standing.authority: "BETA", and its deadline in entitlementExpiresAt:
Apostra staff grant or revoke a beta for the effective billing organization; a child account inherits that decision from its parent. The grant requires a future expiry and an audit reason. Revocation or expiry removes beta authority immediately, while an independent paid authority can continue to allow access. While beta authority is active, the Partner operations page shows an informational Temporary beta operating access banner above the connected source fleet. The banner distinguishes the beta from purchased access and notes that paid support, statements, delegated debugging, and Partner-funded AI are not included. The page refreshes the access decision as the recorded expiry approaches. At expiry, the beta banner and operational fleet are removed unless another paid authority still grants access; free registration and certification remain available. standing.authority: "BETA" means temporary operation is approved only until the entitlement’s recorded expiry. It creates no pricing, payment schedule, support, SLA, renewal, listing, promotion, legal, notice, or wind-down promise. Ownership, registration, current production certification/readiness, explicit authorization for every client Source, tenant isolation, and billing holds continue to apply. Contracted support, delegated diagnostics, support/AI statements, and Partner-funded AI remain unavailable until paid terms authorize them. This decision covers only the paid or time-bounded-beta right to operate across unrelated client organizations. It does not charge for or control the free sales-agent registration view, registration, testing, or certification, and it does not grant a listing, promotion, organic-ranking change, or Murph recommendation preference.

​
Read Storefront capability configuration

The Storefront account response is a separate contract from the sales-agent offering projection below. Read it with:
In that response, configuredCapabilities is the seller’s persisted declaration, while capabilities is the effective public projection clients can rely on. The effective value can differ because it is derived from the declared flags together with Source topology, embedded ad-server locking, product-composition mode, adapter routing, and approval settings. Use configuredCapabilities to display or compare saved configuration; use capabilities for buyer-facing and runtime decisions. A successful configuration write does not by itself guarantee that the effective public capability changed.

​
Read the sales-agent offering projection

Use the authenticated endpoint that backs the page:
windowHours defaults to 168 and accepts values up to 720. It controls the observation window used for source-level call and failure metrics. An organization administrator can activate or refresh one connection after its setup is ready:
accept requires a directly authenticated Partner administrator and an active publisher authorization for the exact binding. It records Partner acceptance and immediately starts the same retryable validation available through validate; acceptance does not imply that validation passed or that activation occurred. Validation checks the current contract, authorization, production certification (including tenant-isolation evidence), health, and credential reference, then forces an authenticated live capability probe against the exact publisher Source. A failed or interrupted run remains retryable; a stale in-progress lease is never a permanent lock. activate first proves that the exact connection belongs to the authenticated provider organization, then rechecks approval, setup, certification, health, organization relationship, and Partner standing in one transaction. A blocked response identifies who owns the next step. Providers can use the activation operation to refresh the bounded first-party organization check immediately; an automatic worker refreshes the oldest page of up to 5,000 current connection attestations with one bounded bulk organization lookup on a one-minute cadence. No credential value is read or returned. Partner administrators can read the same source-scoped delivery reporting used by standard Storefront connections without entering the publisher account:
The endpoint first proves that the exact binding belongs to the authenticated Partner and still has active publisher authorization, derives the client customer and Source server-side, and carries the exact Source through both the Postgres media-buy projection and BigQuery delivery filter. It does not accept a client customer or Source override. Use days from 1 to 90 (default 7), or startDate and endDate in YYYY-MM-DD format. view=summary returns the advertiser, media-buy, and package hierarchy; view=timeseries returns daily rows. sourceBreakdown=true splits timeseries rows by contributing Source. Partner reporting always disables demo and download modes and cannot override the Source selected by the binding. The response groups explicitly connected client sources under the provider capability they use:
The example shortens some nested objects for readability. Treat the API response as the source of truth for nullable lifecycle fields. activatedAt is historical evidence; only activationCurrent: true means that activation belongs to the current, unrevoked client-authorization epoch.
activationCurrent is deliberately stricter than “the client once approved.” It is true only while the exact authorization grant, external-agent configuration, Partner connection contract, latest certified implementation revision, provider acceptance, post-authorization validation, source health, and quarantine state are all current. An unrelated client also requires a claimed provider identity, an in-force operate-agents-for-clients entitlement, either compatible card, invoice-credit, or funded ACH authority for paid access or unexpired BETA operating authority, and no billing hold; a verified first-party organization connection does not. If any one of those facts changes, activationCurrent becomes false while activatedAt continues to show the historical event. First-party eligibility is re-resolved from the organization hierarchy and held only as a five-minute database-owned attestation. The automatic reconciliation worker refreshes an indexed, oldest-first page of up to 5,000 current connections on a one-minute cadence through the same governed activation boundary. It alerts when the oldest page crosses a four-minute capacity margin, and a separate bounded page keeps activation repair progressing. Source status convergence uses its own 5,000-source rotating keyset page. If repeated bounded lookups cannot refresh an attestation, the connection fails closed; if the client is now unrelated, the active Partner commercial requirement applies immediately on revalidation. The same worker moves an inventory source to PENDING when any activation gate becomes false, so the source cannot continue serving on a stale lifecycle status. During historical Source reconciliation, an already-active first-party Source is not demoted merely because its durable provider identity is added. Its existing health, validation, certification, and quarantine facts remain unchanged. A new Source, a cross-organization binding, or a Source already in PENDING still follows the normal activation gates. Credential values and secret references are never part of this response. The activation check uses only whether the client-owned connection has the type-compatible credential reference required by its selected authentication method.

​
Read production certification

productionCertification is the overall, policy-versioned decision for the exact revisionUid. The first SALES policy requires current production evidence for catalog and product quality, authentication and tenant isolation, a media-buy transaction, creative-format negotiation, reporting and reconciliation, reliability and recovery, and operational ownership. The status is:
  • REGISTERED when the capability has not registered an implementation revision;
  • TESTING while any required assertion is missing, failed, or invalidated;
  • CERTIFIED only while every required assertion is currently passing;
  • EXPIRED when required passing evidence has expired;
  • REVOKED when a required assertion has been revoked; or
  • NOT_AVAILABLE for a capability type whose production suite is not yet available.
certifiedAt is the time the last required assertion passed. expiresAt is the earliest expiry across the required passing evidence, so the decision fails closed when any required proof becomes stale. Staging evidence and evidence from a superseded suite version do not satisfy the production policy. For operational-ownership evidence, a Partner connection contract can name one operating contact and the PROVIDER_FLEET_INBOX incident route. A protected test rechecks that the named user is currently entitled to the provider-owning organization’s inbox, then binds that result to the exact contract version, implementation revision, fixture, and cleanup-confirmed run. This proves platform inbox reachability only. It does not send an incident, prove an email or webhook was delivered, or prove that a recipient acknowledged it. A missing, changed, or no-longer-entitled contact leaves the assertion unproven. The adjacent certification object remains the exact creative_sync_format_negotiation canary assertion. It explains that one requirement and must not be presented as the overall certification result. The projection reads at most 2,000 joined connection rows per request and reports that ceiling in projection.rowLimit. When projection.truncated is true, the page warns that its per-capability source totals are partial rather than presenting them as complete. The response returns at most projection.incidentRowLimit active incidents across the organization’s sales-agent offering. projection.incidentsTruncated warns when additional incidents exist. An incident is opened only after a non-healthy source signal persists for five minutes. It groups failures by the smallest supported fault domain: one client connection, one endpoint, one implementation revision, or the full provider capability. As more connections become affected, they join the existing incident rather than creating duplicate incidents. Incident attribution is evidence, not an enforcement decision. attributedOwner can be PROVIDER, CLIENT, SCOPE3, or UNKNOWN; attributionConfidence communicates how strongly the current source observations support that owner. Recovery and attribution changes append new evidence without rewriting prior conclusions.

​
Interpret health safely

Health is computed per connected inventory source from that source’s observations. A healthy sibling does not hide another source’s failure, and the creative canary assertion does not become a general account-health badge. Errors expose a safe code, summary, owner (CLIENT, PROVIDER, or SCOPE3), and an optional correlation reference for provider-owned remediation. Client-owned and Apostra-owned lifecycle details remain generic in the provider view; their raw summaries and correlation references are not returned. The projection does not return credentials, raw upstream payloads, or inventory belonging to unrelated clients. Missing provider acceptance, inactive Partner eligibility when required, contract/configuration drift, and malformed or expired certification evidence fail closed. An administrator can use the corresponding inventory-source diagnostics view to confirm which capability a source is mapped to, whether the provider accepted it, and whether the connection is active or quarantined. Provider topology comes from the explicit capability, implementation revision, endpoint, connection, and deployment records. The sales-agent offering projection does not infer provider ownership or deployment identity from adcp_agent, source URLs, or coincidental domains.

​
Delegate one source for debugging

A client organization administrator can invite the certified Partner already connected to one inventory source to inspect that source’s safe diagnostics. Create the invitation through the Storefront API:
Use the exact bindingUid returned for the source in the sales-agent offering or diagnostics projection; a display sourceId is not an authority identifier. expiresAt must be in the future and no more than seven days away. The API derives the Partner and source from that active capability connection; the client cannot nominate another organization. The capability must have current production certification, the provider identity must be claimed, and the Partner contract and payment standing must be current. An administrator of the organization enrolled in the Partner Program lists current invitations and reads one source’s diagnostics with its own organization token:
The diagnostics response uses the same redacted source-health contract as the client view, with legacy agent identity removed. It does not include credentials or unrelated clients. It does not permit source changes, test execution, client account membership, or shared-room access. The client can end access immediately:
Every list and diagnostics request rechecks the current connection, production certification, Partner status, expiry, and revocation. If any check stops passing, the invitation is no longer visible or usable.

​
Reconcile support effort

An administrator of an organization registered in the Partner Program can retrieve an operational statement of support effort attributed to its explicitly connected client sources:
Both timestamps are required. The period is half-open (from inclusive, to exclusive) and can cover at most 93 days. The response includes full-period minute totals and up to 500 recent detail lines. projection.truncated indicates when more lines exist; totals still cover the complete requested period. Each line is attributed through one immutable bindingUid to the Partner capability, client organization, Storefront, and inventory source. It includes a category (ONBOARDING, CERTIFICATION, DEBUGGING, or INCIDENT_RESPONSE) and a rating disposition:
  • INCLUDED records effort treated as included support.
  • OVERAGE_CANDIDATE records effort for later reconciliation. It is not a price, invoice line, accepted commercial term, or client charge.
  • ZERO_RATED_SCOPE3_DEFECT records incident-response effort excluded because a confirmed Apostra-owned platform defect affected that exact connection.
Zero-rating requires an authoritative Partner-account incident whose latest attribution is SCOPE3_DEFECT / SCOPE3 and whose latest connection-membership evidence at the time the effort occurred says that the connection was attached. Staff cannot mark arbitrary support effort as zero-rated. Entries are append-only, idempotent operating evidence; corrections add new evidence rather than rewriting history. Only explicitly Partner-safe descriptions and evidence references appear in the statement. It does not expose credentials, raw incident payloads, internal staff notes, unrelated client inventory, prices, or billing records. Child organizations must switch to the registered parent organization.

​
Reconcile Partner-authored AI usage

An administrator of an organization registered in the Partner Program can retrieve AI usage produced by assisted testing and Partner-authored debugging for its explicitly connected sources:
The period follows the same half-open, 93-day maximum as the support statement. The response returns full-period event/token totals and at most 500 recent detail lines. Each line retains the exact capability, implementation revision, bindingUid, client, Storefront source, Partner-safe session reference, and any confirmed Apostra incident used for zero-rating. This launch records two dispositions:
  • TRACKED_NOT_BILLED measures Partner-authored AI COGS but settles zero IUs.
  • ZERO_RATED_SCOPE3_DEFECT additionally proves that the exact connection was affected by a confirmed Apostra-owned defect when the usage occurred.
Both dispositions are structurally platform-bearer and return iuAmountMilli: 0. No Partner activity term has been accepted yet, so the attribution cannot debit the Partner or client IU wallet, create an invoice line, or imply a future price. A later paid activity requires its own accepted Effective Rate Card term and entitlement before the producer can move off this dark rail. Normal client Buyer or Storefront workloads remain attributed to the client even when a Partner capability participates. Deterministic conformance, certification, and routine health checks produce no AI usage row. The Partner statement does not expose model/vendor cost, raw prompts, credentials, internal notes, or unrelated client inventory.