> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Prepare inventory source inputs
> Where avails, products, properties, creative formats, execution, reporting, and CRM context come from — and who owns each one
You are inside **Step 2 of [storefront onboarding](/v2/setup/storefront-onboarding),
connect inventory sources**. Use this page when a connector cannot supply
everything on its own and you must provide some inputs yourself: avails,
products, properties, creative formats, execution, or reporting.
**Many storefronts never need this page.** If every buyer request passes straight
through to an external sales agent, you need
[the agent connection](/v2/storefront/inventory-sources/connect-your-agent) and
nothing here.
## What this page walks you through
Steps 1–4 scope the work. Steps 5, 9, and 10 line up with the three sections of
your source's live readiness checklist — **Set up inventory**, **Make it
merchandisable**, and **Prove it** — so this page and the checklist name the same
things. Steps 6 and 7 are not checklist rows at all: they are reported as
lifecycle stages. Step 8 has no status of its own.
| # | Step | Reported as | What it settles | Requirement |
| -- | ----------------------------------------------------------------------------- | ----------------------------------------- | ---------------------------------------------------------- | ---------------------- |
| 1 | [Confirm you need this page](#1-confirm-you-need-this-page) | — | Whether your path needs separately supplied inputs | Required |
| 2 | [Draw one source boundary](#2-draw-one-source-boundary) | — | What counts as a single inventory source | Required |
| 3 | [Answer five questions](#3-answer-five-questions) | — | Where each input comes from and who owns it | Required |
| 4 | [Send one representative sample](#4-send-one-representative-sample) | — | A shared, corrected map of your setup | Required |
| 5 | [Set up inventory](#5-set-up-inventory) | **Set up inventory** checklist rows | What can be sold, its identity, capacity, and price floors | Required |
| 6 | [Set up execution and trafficking](#6-set-up-execution-and-trafficking) | Lifecycle stages | How a reservation becomes a booked, trafficked campaign | Required to transact |
| 7 | [Set up reporting and reconciliation](#7-set-up-reporting-and-reconciliation) | Lifecycle stages | How delivery and spend come back and become final | Required to reconcile |
| 8 | [Add CRM context](#8-add-crm-and-commercial-context) | Nothing — supporting evidence | Buyer-specific merchandising context | Recommended |
| 9 | [Make it merchandisable](#9-make-it-merchandisable) | **Make it merchandisable** checklist rows | What buyers see, how it is priced and explained | Required for discovery |
| 10 | [Prove it](#10-prove-it) | **Prove it** checklist row | That the whole path holds end to end | Required |
**Order and dependencies.** Do steps 1–4 first and in order. Steps 5–8 are then
independent tracks: each is proven and signed off on its own, and their materials
may arrive at different times from different people. Two dependencies are hard —
step 5 before step 9, and both before a proposal means anything. Discovery needs
5 and 9; transacting also needs 6. One green track never makes another green.
Steps 5–7 each correspond to a module your source attaches: `INVENTORY_FEED`
(step 5), `BOOKING_LEDGER` and `TRAFFICKING` (step 6), and `STATUS_SYNC` and
`REPORTING_IMPORT` (steps 6–7). This page is what you prepare *before* any of
that can report ready — see
[how to read your status](#how-to-read-your-status) for where the real state
lives once the source exists.
Send representative or redacted material when files contain buyer, campaign,
pricing, or personal data. Never put credentials, private keys, API tokens, or
customer PII in an onboarding file — enter live credentials only in the
dedicated connection flow.
## 1. Confirm you need this page
Find your path. The first two mostly bypass this page; the last two need it.
| Your path | What to do |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pass through to an external sales agent** | [Connect your sales agent](/v2/storefront/inventory-sources/connect-your-agent) and stop. The agent stays responsible for its products, avails, formats, properties, execution, and reporting. |
| **Use a built-in provider connection** | [Choose the source path](/v2/storefront/inventory-sources/choosing-a-source) and [provide ad-server access](/v2/storefront/inventory-sources/ad-server-access). Built-in connections cover Google Ad Manager, FreeWheel, SpringServe, and AdsWizz; CitrusAd runs as a standard provider recipe. Come back here only for inputs the connector does not supply. |
| **Combine APIs, files, and human operations** | Use every step below to identify each input, its authority, and its operating owner. Apostra reviews the map with you before a custom path is activated. |
| **Hybrid** | Apply these steps only to the scopes the external agent does not fully own. Do not duplicate its catalog or capacity. |
If every buyer request passes through Apostra unchanged to an external
sales agent, stop here. You need the agent connection and authorization, not an
avails pack or a source-input worksheet.
## 2. Draw one source boundary
Everything else on this page is scoped to a source, so define the source first.
A **source boundary** is the line around one bookable pool: the inventory whose
capacity and booking authority are controlled together. It is not a vendor, a
credential, a transport, or a filename.
* **One source** when an ad server, publisher API, file, and human workflow all
describe the same bookable pool and share stable joins.
* **Separate sources** when inventory has independently allocatable capacity,
booking authority, execution, or reporting ledgers.
* **Not a new source** merely because a supported provider is connected later.
* **Never merge sources by matching vendor names.** First prove shared capacity
and booking authority, map identity, compare in shadow, choose the surviving
source ID, and keep a rollback path.
### Standard paths and custom configuration
Built-in ad-server connections for Google Ad Manager, FreeWheel, SpringServe,
and AdsWizz are standard supported paths within this model, and standard provider
recipes include CitrusAd. An Apostra-managed sales agent is plumbing behind some of
these connections, not a separate provider family. Each connector preconfigures
only the capabilities its published contract supports, and a feed or an
accountable person can supply a remaining scope without changing the source
boundary. Ad-server-backed and
modular sources still have separate setup surfaces today, so ask Apostra to map
supplemental material onto the existing source rather than creating a duplicate.
**Enterprise-assisted custom configuration** applies to a customer-specific or
not-yet-supported provider/capability configuration, a bespoke schema or API pull,
a custom authority or overlap rule, or a negotiated manual service. It applies to
that capability and its activation, not to a new kind of source. Standard
supported paths are not Enterprise-gated merely because the source is modular.
The advanced modular-composition surface is included with Premium and
Enterprise through the Merchandising profile, and in-place
provider
conversion and a single generalized source workspace are pilot preview design,
not shipped self-service behavior.
## 3. Answer five questions
These five answers tell us where each input comes from and who owns it. Answer
in your own language — different systems or people may answer each one, at
different times.
| Question | What to provide or identify | What it establishes |
| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **1. Where do avails come from?** | The planning API, ad server, forecast, file, or accountable person; stable inventory and capacity-pool IDs; period, unit, gross-or-net meaning, bookings, source price, cadence, corrections | What capacity can be offered, and when it goes stale |
| **2. Where do products and their descriptions come from, and how do they map to avails?** | An upstream catalog, or the materials Apostra should build one from: product/package IDs, buyer-facing names and descriptions, included inventory scopes, availability join keys, rate card, Media Kit, owner | What buyers discover, and which capacity backs each offer |
| **3. Where does CRM or buyer-account context come from?** | The CRM system or export, stable account and opportunity IDs, buyer-account mappings, sanitized relationship context, cadence, privacy rules, owner | Optional buyer-specific context — never inventory or booking authority |
| **4. Where do creative formats come from?** | The authoritative format matrix, canonical format mapping, dimensions or duration, asset and approval rules, lead times, owner | Which products accept which creative, and how compliance is decided |
| **5. Which properties carry the inventory?** | The Property Roster or source taxonomy for domains, apps, and channels; stable selectors, inventory coverage, authorization evidence, owner | Where the inventory runs, and who is authorized to sell it |
Record the answers in the
[source input and authority worksheet](/v2/setup/source-module-authority-worksheet).
It captures suppliers, joins, authority, cadence, and owners. You are not being
asked to design a software module.
## 4. Send one representative sample
One working session, one pilot scope, existing documentation and sanitized
samples. Do not redesign your exports or send every system at once.
| Bring first | Minimum useful example |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Source and system sketch | The ad servers, APIs, files, and operating teams involved, plus the intended pilot scope |
| Inventory and availability | One availability sample with stable inventory IDs, period, unit, gross-or-net meaning, source price, and any booking relationship |
| Products and properties | Current product or package descriptions, their availability joins, and the properties they cover |
| Creative requirements | Format matrix, asset and approval rules, lead times, and the team that decides acceptance |
| One campaign lifecycle | A sanitized example joining a proposal or order to booking, creative, trafficking, status, delivery, and corrections |
| Merchandising evidence | Current Media Kit or sales deck, rate card, policy rules, and four representative briefs or RFPs |
| CRM context, if useful now | A field dictionary and a few sanitized account rows, with no contact names or email addresses |
For each item, name the source system, covered scope, effective period, and
owner. Items may arrive separately. Do not include credentials, manifests,
checksums, or production PII.
**What you get back:** Apostra will return a receipt and version summary, a draft
input/authority map, the joined campaign trace, and a list of integration and
merchandising gaps. You confirm or correct that map before any custom or manual capability
counts as operational. This is enough to start a pilot design; it does not by
itself enable production transactions.
### What counts as a production import today
A file is a production import only when its row shape is documented for an
implemented parser. Everything else is evidence Apostra reviews with you.
| Material | Classification | What works today |
| --------------------------------------------------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Static avails CSV, XLS, or XLSX | **Production import — `static-avails-feed:v1`** (compatibility) | Preview and commit through the modular avails-feed path. Not the target Inventory Feed schema. |
| Static avails JSON | **Production import — `static-avails-feed:v1`** (compatibility) | Send as JSON text, or upload the document in Murph and use its document reference. Not the target Inventory Feed schema. |
| Ad-server wholesale avails and pricing CSV | **Production import — `wholesale-avails-pricing:v1`** | Download a source-prefilled template, preview, then commit for a Google Ad Manager, FreeWheel, SpringServe, or AdsWizz source. |
| Source input and authority worksheet | Supporting evidence | Reviewed with Apostra. Not an import schema. |
| Product list, rate card, Media Kit, Playbook, AI Business Rules | Merchandising evidence | Confirmed facts are applied through Listing, Playbook, AI Business Rules, products/components, and pricing. Attaching a file is not ingestion. |
| Complete campaign, booking, creative, trafficking, status, and reporting examples | Supporting evidence or manual pilot input | Used for contract rehearsal. No importer is implied. |
| Target Inventory Feed shapes | Target contract, not production input | Do not submit conceptual shapes as production input. Templates are published when their parsers ship. |
**static-avails-feed:v1 is a production compatibility parser,
not the target Inventory Feed schema.** Its `collectionId`, `collectionName`,
and `collectionDescription` fields are legacy grouping/container names. They have
represented generic pools and containers, and their values do not establish
AdCP Collection identity. Do not turn a monthly pool, placement, channel, or
portfolio into an AdCP Collection to satisfy this parser.
The [inventory source example pack](/v2/setup/publisher-onboarding-example-pack)
holds both parser-backed avails and clearly labeled evidence. Its manifest is
test-harness routing metadata maintained by Apostra. Customers do not author
manifests or calculate SHA-256 digests. Files, APIs, and human confirmations may
arrive independently; Apostra records receipts and content evidence when each item
arrives.
Start from one ZIP containing directly previewable CTV and display avails,
merchandising inputs, lifecycle evidence, proposal tests, and a deliberately
invalid feed for rehearsing diagnostics.
## 5. Set up inventory
Establishes what can be sold: its stable identity, capacity, source price, and
booking constraints. Nothing downstream is provable without it.
### Bring these materials
This step feeds four checklist rows. Three are always **required**. **Resolve
Property Roster identities and formats** is `REQUIRED` only when catalog
declaration validation applies to the source contract; the live checklist
reports `NOT_APPLICABLE` otherwise, and no Property Roster or `adagents.json`
work is required for that row. You can start before the later materials arrive.
| Checklist row it satisfies | Requirement | Bring this |
| ------------------------------------------------ | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Configure the source and inventory-feed module | Required | Systems, provider accounts, APIs, files, human workflows, and the capacity/booking boundary |
| Preview and commit inventory | Required | Row-level avails with stable IDs, periods, units, capacity basis, source CPM or floor, and overlap/pool meaning |
| Resolve Property Roster identities and formats | Required when catalog declaration validation applies; otherwise not applicable | Stable placement, property, and format identifiers; Property Roster and `adagents.json` ownership; canonical AdCP Collection identifiers only when the publisher declares a series, publication, event series, or rotation |
| Keep source inventory current | Required | Owner and backup, trigger or schedule, timezone, expected arrival, grace, stale effect, correction, escalation |
| *(gross-to-net and reconciliation, when needed)* | Conditional supporting material | Upstream order or line-item IDs, source scope, period, quantity/unit, status, update time |
The [source input and authority worksheet](/v2/setup/source-module-authority-worksheet)
records provider, scope, stable keys, authority, snapshot/delta/event semantics,
cadence, grace, stale consequence, owner, correction, and escalation. It is
supporting evidence, not an import schema.
### Stable identity and row grain
Use a stable ID from the system that owns the inventory. Never use a display
name, row number, or file position as identity.
One static-avails row is one availability window inside a legacy compatibility
grouping. Split rows when the capacity pool, dates, price, currency, property
coverage, canonical creative format, or booking ownership changes. Give an
event, issue, episode, takeover, or sponsorship its own row only when it has
independently controlled capacity. Row grain does not create AdCP Collection
identity.
Audience scale, market reach, household counts, and co-viewing studies are
evidence, not sellable capacity.
### Fields required by this starter kit
The production compatibility parser can derive **collectionId** and **availId**
when they are omitted. This starter kit requires them explicitly so later
corrections join predictably. The
`collection*` names exist only for `static-avails-feed:v1` compatibility.
| Field | Requirement |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `collectionId` | **Legacy name.** Stable seller-side ID for the parser's grouping/container. Does not establish AdCP Collection identity. |
| `collectionName` | **Legacy name.** Seller-facing label for that grouping. |
| `formatOptions` | Non-empty URL-free canonical declarations using `format_kind` and `params`. |
| `publisherProperties` | Non-empty Property selectors for the inventory in that grouping. |
| `availId` | Stable ID for the availability line. |
| `name` | Seller-facing name for the availability line. |
| `startTime`, `endTime` | ISO dates or date-times for the covered window. |
| Capacity | `impressionsCapacity` for net sellable capacity, or gross capacity plus upstream booked capacity. |
Optional: `collectionDescription` (**legacy name**), `channel`, `cpm`,
`currency`, `targeting`, `sourceMetadata`, and non-secret source join keys.
Channel is descriptive and never determines creative format.
The current static-avails parser is impression-based with optional CPM. It
cannot represent click or engagement pricing, whole-flight flat rate, slots,
or time-based sponsorships. Keep those native semantics in supporting evidence
and treat the missing production contract as a gap.
### Net and gross capacity
Use `impressionsCapacity` only for net sellable capacity available to this
source before new local holds or bookings.
If your source reports gross, send one gross field such as `avails` and one
upstream-booked field such as `upstreamBookedImpressions`. Preview calculates:
```text theme={null}
net sellable capacity = gross capacity - upstream booked capacity
```
Booked above gross is rejected. If net, gross, and booked all appear, the
explicit net value wins — avoid the ambiguity by using one model per row.
### Cadence and corrections
For every independently arriving stream, confirm:
| Decision | Record |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Grain and stable keys | Source, pool, property, placement, availability, campaign, creative, and reporting joins; AdCP Collection only where canonical content identity exists |
| Authority | Which system or person owns each fact and scope |
| Delivery semantics | Full snapshot, patch/upsert, delta, event, or human confirmation |
| Timing | Trigger or cadence, timezone, expected arrival, grace, freshness limit |
| Failure effect | Advisory, or a discovery / reservation / execution / reporting / pilot blocker |
| Recovery | Retry, corrected revision, mapping repair, approved exception, owner, backup, escalation |
A late reporting file does not invalidate current inventory identity. An invalid
availability revision does not rewrite accepted merchandising facts. Each
capability goes stale only where its own stream requires it.
### Replacement, patch, and rejection recovery
The static-avails contract is a patch/upsert keyed by `availId`: reusing an ID
updates that line, changing it creates another, and omitted rows remain active
until they expire or the source is archived. Omission is not deletion or
cancellation, and a rejected update does not retire the last accepted row.
The ad-server wholesale-pricing contract is an atomic full replacement — follow
its [separate field and replacement guide](/v2/storefront/inventory-sources/wholesale-avails-pricing).
Never apply one contract's replacement rules to the other.
Use the Inventory Feed Task for `static-avails-feed:v1`, or inspect the REST
preview response, before correcting a mixed-validity file. Those surfaces
return `rejectedRowCount`, `rejectedRows`, and `warnings`. The legacy
`ingest_modular_avails_feed` tool does not surface row diagnostics and can
commit the accepted subset, so do not use it for rejection recovery or to
validate a complete refresh.
The Task and REST paths also permit an intentional accepted-row patch and do
not enforce zero rejections before commit. When the file is meant to be a
complete operational refresh, stop if `rejectedRowCount` is above zero, repair
the file, and preview the whole patch again.
To fix a rejected row:
1. Match `rowNumber` to the one-based data-row position. CSV data row 1 is file
line 2; JSON row 1 is the first item in the avails array.
2. Repair the named identity, date, number, currency, canonical-format, or
property-selector error.
3. Preview the entire intended patch again.
4. Confirm row count, stable IDs, periods, price, format and property coverage,
and normalized capacity.
5. Commit only the reviewed preview. Resolve every rejection before treating a
complete operational refresh as successful.
### `static-avails-feed:v1` compatibility templates
These files are maintained as parser tests for the implemented
`static-avails-feed:v1` compatibility parser. They are production-importable for
that parser only, not canonical generalized templates or the target Inventory
Feed schema.
One net-capacity row with canonical format and Property declarations; legacy `collection*` headers remain for parser compatibility.
One gross-minus-booked row for the JSON-text path.
Three fictional rows covering net and gross-minus-booked capacity.
Use the source-prefilled production download endpoint.
#### CSV template: net capacity
```csv theme={null}
collectionId,collectionName,collectionDescription,availId,name,startTime,endTime,impressionsCapacity,channel,cpm,currency,targeting,sourceMetadata,formatOptions,publisherProperties
compat-streaming-group,Legacy group: Streaming video,Static v1 compatibility grouping; not an AdCP Collection,example-streaming-2099-07,Streaming video July,2099-07-01,2099-08-01,4000000,CTV,24.00,USD,"{""market"":""US""}","{""reportingJoinKey"":""report-example-streaming-2099-07""}","[{""format_option_id"":""example_ctv_vast"",""format_kind"":""video_vast"",""params"":{""duration_ms_exact"":30000}}]","[{""selection_type"":""all"",""publisher_domain"":""example-publisher.synthetic.invalid""}]"
```
#### JSON template: gross minus booked
```json theme={null}
{
"avails": [
{
"collectionId": "compat-broadcast-group",
"collectionName": "Legacy group: Broadcast video",
"collectionDescription": "Static v1 compatibility grouping; not an AdCP Collection",
"availId": "example-broadcast-2099-07",
"name": "Broadcast video July",
"startTime": "2099-07-01",
"endTime": "2099-08-01",
"avails": 1000000,
"upstreamBookedImpressions": 200000,
"channel": "broadcast",
"cpm": 18,
"currency": "USD",
"targeting": {
"market": "US"
},
"sourceMetadata": {
"reportingJoinKey": "report-example-broadcast-2099-07"
},
"formatOptions": [
{
"format_option_id": "example_broadcast_vast",
"format_kind": "video_vast",
"params": { "duration_ms_exact": 30000 }
}
],
"publisherProperties": [
{
"selection_type": "all",
"publisher_domain": "example-publisher.synthetic.invalid"
}
]
}
]
}
```
Upload CSV, XLS, or XLSX through the static-avails file-upload path. Send JSON
through `jsonText`; the REST multipart endpoint does not accept JSON files.
Murph can instead use an uploaded JSON document reference. TSV is accepted only
as pasted CSV text, never as a multipart file.
## 6. Set up execution and trafficking
Establishes how a reservation becomes an upstream campaign or line item.
Inventory being visible proves none of this.
For each intended pilot scope, name the system or person that owns each
operation and provide evidence for it:
| Operation | Materials and proof needed |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Reserve, book, release | Request and response or named manual work item; quantity and unit; idempotency or duplicate handling; returned reservation, order, or line-item IDs |
| Create and approve a campaign | Advertiser alias, dates, budget, product and inventory scope, targeting, price, approvals, returned upstream IDs |
| Approve and traffic creative | Exact format and asset rules, lead times, approval and rejection examples, creative references, handoff evidence, owner |
| Observe status and failures | State vocabulary, success and failure evidence, observed time, retry behavior, customer-visible pending state, escalation |
| Update, cancel, release | One representative update and cancellation, released capacity, version or correction behavior, final returned state |
Classify **how each operation is fulfilled**, using the modes your source reports
once connected — `AUTOMATED` (a module runs it), `HITL` (a named human or
secure-file step completes it), or `UNSUPPORTED` (a gap). One operation can carry
more than one mode, such as automation with a named human fallback. The mode is
not a readiness verdict: your source reports stage readiness separately, and an
`AUTOMATED` stage can still be blocked.
A `HITL` step counts for a pilot only with an owner, response expectation,
durable evidence, failure handling, and escalation. One successful handoff does
not prove update, cancellation, retry, or release.
This starter kit does not claim a generalized execution or trafficking importer.
Use these materials to prove a supported operation or rehearse a manual pilot —
never as production API requests.
## 7. Set up reporting and reconciliation
Establishes how delivery and spend come back, join to the booked line, and
become final.
Provide a representative delivery and spend report that joins to the exact
booked line, plus:
* stable source, media-buy or package, upstream order, and line-item joins;
* report period, delivered quantity and unit, spend and currency;
* whether each value is observed, estimated, or modeled;
* preliminary, final, and corrected report identity and finality rules;
* cadence or trigger, timezone, expected arrival, grace window, and the effect
of stale or missing data;
* correction, quarantine, replay, owner, backup, and escalation behavior.
The reporting example in this kit is evidence. It becomes a production reporting
path only when a documented importer or an approved, operated manual workflow
proves the exact source scope and cadence. A customer commitment such as daily, weekly,
or quarterly reporting must be recorded with its delivery window and its enforced
stale-data consequence.
## 8. Add CRM and commercial context
An optional input to buyer-specific merchandising. Skip it unless an approved
workflow depends on it — it never blocks inventory, execution, or reporting
setup.
Useful evidence: a CRM field dictionary, five to ten sanitized account or
opportunity rows, buyer-account mappings, and representative proposal outcomes.
Useful fields: stable CRM account and opportunity IDs, account alias and type,
opportunity stage, referenced product or package, expected flight, amount and
currency, outcome or loss reason, seller-owner role, last activity time, source
update time.
Remove contact names, email addresses, and other personal data. CRM material is
supporting evidence, not inventory, availability, booking authority, a canonical
buyer account, or a production import schema. See the
[sanitized CRM example](/v2/setup/publisher-onboarding-example-pack#optional-crm-context).
## 9. Make it merchandisable
Turns eligible source-backed inventory into what buyers actually see: products,
prices, positioning, policies, and proposal behavior. Each decision has one
canonical owning surface — never a file you attached.
These are the rows your source's **Make it merchandisable** checklist reports,
with the requirement each one carries:
| Checklist row | Owning surface | Requirement | Proof |
| -------------------------------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------------- |
| Publish buyer-visible products | Product catalog | Required | Every offer points to eligible source identity and grounded evidence |
| Attach source pricing | Pricing | Required | Every active row has CPM and currency; price respects source floors and effective periods |
| Map inventory components | Inventory components | Recommended | Components resolve to ready source identity |
| Apply properties to decisioning inputs | Decisioning inputs | Recommended | Properties are mapped to the inputs that decide selection |
| Set selling behavior | Playbook | Recommended | Repeated brief tests select and explain the expected products |
| Set acceptance policy | AI Business Rules | Recommended | Fit, rejection, and review cases match policy without exposing private rules |
Two more surfaces sit alongside the checklist:
| Decision | Owning surface | Proof |
| ------------------------ | ---------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Storefront positioning | Listing (the Media Kit is supporting evidence) | Positioning uses confirmed facts, and the Media Kit is never treated as an owning surface |
| Buyer-specific treatment | Buyer discounts and buyer instructions | Terms apply only to the intended buyer and stay auditable |
## 10. Prove it
Two proofs before go-live: the source-scoped discovery proof your checklist
requires, then one full campaign rehearsal.
### Run source-scoped discovery proof
Required. Run six cases from the briefs in the
[example pack](/v2/setup/publisher-onboarding-example-pack), including a
source-isolation case:
1. an obvious fit returning the expected source-scoped product;
2. a correct no-fit or policy rejection;
3. a human-review case;
4. a stale or conflicting-source case;
5. a source-isolation case that must not return another source's product;
6. a pricing or format edge case that must ask for clarification or decline
rather than invent support.
### Know what proposal proof does not establish
A passing proof is a pilot preview of discovery behavior. It does not contact a
buyer, create a media buy, confirm upstream booking, traffic a campaign, import
delivery, or prove production readiness.
### Rehearse one complete campaign
Walk one campaign through every stage and record an honest verdict for each.
Open the
[sanitized complete-campaign example](/v2/setup/complete-campaign-example), which
joins advertiser, campaign/order/line item, dates, budget, source product,
targeting, quantity/unit, price, creative, approval, status, delivery,
reporting, and returned IDs. It is a manual pilot walkthrough, not a production
API request or import schema.
Record **two** things per stage, because your source reports them separately:
* **Which mode or modes fulfil it** — `modes` is a list, so a stage can report
more than one, such as automation with a named human fallback. It is empty when
nothing declared how the stage operates.
* **Its readiness status** — exactly one of `READY`, `BLOCKED`, `MISSING_SETUP`,
`RUNTIME_INPUTS_REQUIRED`, `HITL_PENDING`, `UNSUPPORTED`, or `NOT_DECLARED`.
Mode and status are independent: an `AUTOMATED` stage can still be `BLOCKED`, so a
rehearsal that records only the mode can mark an unready campaign path as proven.
Two statuses are easy to misread. `UNSUPPORTED` means every attached module
declared what it runs and none of them runs this stage — a real gap you can close
by attaching a module that does. `NOT_DECLARED` means a module that could run the
stage is attached but we could not read what it does, so whether it runs is
unknown rather than absent; no configuration of yours produces or clears it, so
tell Murph instead of treating it as a setup task.
| What you rehearse | Stages it covers |
| ---------------------------- | --------------------------------------------------- |
| Discovery and proposal | `GET_PRODUCTS` |
| Reservation and booking | `RESERVE_AVAILS`, `FINALIZE_BOOKING` |
| Creative and trafficking | `SYNC_CREATIVES`, `TRAFFIC_CAMPAIGN` |
| Status, update, cancellation | `SYNC_STATUS`, `UPDATE_CAMPAIGN`, `RELEASE_BOOKING` |
| Reporting and reconciliation | `IMPORT_REPORTING`, `RECONCILE_DELIVERY` |
Never treat a successful feed preview or a compelling proposal as evidence that
a booking, campaign, trafficking, reporting, or conversion workflow exists.
## How to read your status
Nothing on this page is a status. Once the source exists, three surfaces report
the real state, and each answers a different question:
| Your question | Where to read it | Ready looks like |
| ------------------------------------------------------ | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Can this source make truthful availability decisions? | **Set up inventory** section of the source's readiness checklist | Every `REQUIRED` row `READY`, with `freshness: FRESH` |
| Can buyers be shown a truthful product? | **Make it merchandisable** section | *Publish buyer-visible products* and *Attach source pricing* `READY` |
| Does discovery behave correctly for this source alone? | **Prove it** section | *Run source-scoped discovery proof* `READY` |
| Can a booking be reserved, trafficked, and updated? | The source's lifecycle stages | `RESERVE_AVAILS`, `FINALIZE_BOOKING`, `RELEASE_BOOKING`, `SYNC_CREATIVES`, `TRAFFIC_CAMPAIGN`, `UPDATE_CAMPAIGN`, and `SYNC_STATUS` all `READY` |
| Does delivery and spend come back? | The source's lifecycle stages | `IMPORT_REPORTING` and `RECONCILE_DELIVERY` `READY` |
| Can the storefront transact at all? | [Storefront readiness](/v2/storefront/tasks/get-readiness) | `canTransact: true` and `effectiveStatus: live`, with no `hard` requirement outstanding |
Read each answer on its own. A `READY` checklist section does not make a lifecycle
stage ready, and neither one makes the storefront live.
A stage reported as `HITL` is fulfilled by a named human rather than automation.
It counts only when the work item, response expectation, durable evidence,
failure handling, and escalation are operational; `UNSUPPORTED` is a gap. Two
things this page prepares have no status of their own: CRM context is recommended
supporting evidence, and whether your team can operate the source unaided —
refreshing each stream, reading diagnostics, correcting revisions, working manual
queues, releasing capacity, reconciling reports, and escalating through named
owners — is a conversation with Apostra, not a field.
Where publisher authorization applies, require current positive authorization
evidence before inventory is merchandisable. For a connected platform account
where it does not apply, use the connection-based selling rights rather than
inventing an `adagents.json` requirement.
## Related guides
Compare current connection and pilot paths.
Use the static-avails preview, patch, reservation, and work-item flow.
Put confirmed facts in their authoritative Pages and keep the Media Kit as evidence.
Reconcile Properties, canonical AdCP Collections where present, formats, and authorization.