> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Prepare inventory source inputs
> Decide where avails, products, CRM context, creative formats, properties, execution, and reporting come from
Use this guide when one or more inventory-source inputs or operations must be
supplied to Interchange separately. That includes built-in ad-server
connections and sources that combine provider APIs, files, or accountable
people. It is not required for every Storefront.
## Choose the setup path
| Your path | What to do |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pass through to an external sales agent** | [Connect your sales agent](/v2/storefront/inventory-sources/connect-your-agent). The agent remains responsible for its products, avails, formats, properties, execution, and reporting. Do not prepare this materials pack unless Scope3 will separately operate one of those capabilities. |
| **Use a built-in provider connection** | [Choose the inventory-source path](/v2/storefront/inventory-sources/choosing-a-source) and [provide ad-server access](/v2/storefront/inventory-sources/ad-server-access), then use this guide only for inputs the connector does not supply automatically or that still require customer configuration. Built-in ad-server connections include Google Ad Manager, FreeWheel, SpringServe, and AdsWizz; standard provider recipes include CitrusAd. |
| **Combine APIs, files, and human operations** | Use this guide to identify each input, its authority, and its operating owner. This is the custom source path, regardless of who operates each capability. Scope3 reviews the map with you before any custom path is activated. |
| **Use a hybrid of both** | Apply this guide only to the inventory scopes or operations that the external agent does not fully own. Do not duplicate the pass-through agent's catalog or capacity. |
If every buyer request passes through Interchange unchanged to an external
sales agent, stop here. You need the agent connection and authorization, not
an avails pack or a source-input worksheet.
## Answer five questions first
Start in customer language. Different systems or people may answer each
question, and the answers do not need to arrive in one file or at one time.
| 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, and corrections | What capacity can be offered and when it becomes stale |
| **2. Where do products and their descriptions come from, and how do they map to avails?** | An upstream product catalog or the materials Scope3 should use to create one: product/package IDs, buyer-facing names and descriptions, included inventory scopes, availability join keys, rate card, Media Kit, and 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, and 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, and owner | Which products can accept which creative and how compliance is decided |
| **5. Which properties carry the inventory?** | The Property Roster or source taxonomy for domains, apps, channels, or other publisher properties; stable selectors, inventory coverage, authorization evidence, and 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).
The worksheet records suppliers, joins, authority, cadence, and owners. It does
not require the customer to design a software module.
## Start with one representative exchange
You do not need to redesign your exports or send every system at once. For the
first working session, use existing documentation and sanitized samples where
possible:
| Bring first | Minimum useful example |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Source and system sketch | The ad servers, publisher APIs, files, and operating teams involved, plus the intended pilot inventory scope |
| Inventory and availability | One representative 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 inventory or availability joins, and the domains, apps, channels, or other properties they cover |
| Creative requirements | The format matrix, asset and approval rules, lead times, and the team that decides acceptance |
| One campaign lifecycle | A sanitized example that connects a proposal or order to booking, creative, trafficking, status, delivery, and correction evidence |
| Merchandising evidence | A current Media Kit or sales deck, rate card, policy or approval rules, and four representative briefs or RFPs |
| CRM context, if useful now | A field dictionary and a few sanitized account or opportunity rows; omit contact names, email addresses, and other personal data |
Tell Scope3 the source system, covered scope, observed or effective period, and
owner for each item. Materials may arrive separately. Do not include
credentials, manifests, checksums, or production customer PII.
Scope3 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 the map before a custom or manual capability is treated
as operational. This first exchange is enough to start a pilot design; it does
not by itself enable production transactions.
## Prove the operating path
After locating the five core inputs, prove five distinct operating tracks:
| Track | What it establishes |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Inventory and availability** | What can be sold, its stable identity, capacity, source price, and booking constraints |
| **Execution and trafficking** | How a reservation becomes an upstream campaign or line item, how creative is approved and trafficked, and how updates, cancellations, failures, and returned IDs are handled |
| **Reporting and reconciliation** | How delivery and spend return, join to the booked line, become final, and are corrected |
| **CRM and commercial context (optional)** | Account, opportunity, and historical relationship context that can inform buyer-specific merchandising without becoming inventory or booking authority |
| **Merchandising** | How eligible source-backed inventory becomes buyer-facing products, prices, positioning, policies, and proposal behavior |
The tracks join through stable source, inventory-scope, availability, property,
format, product, campaign, account, and reporting identifiers, but their APIs,
files, and human confirmations may arrive independently. A source is not fully
operational merely because its inventory is visible. Add an AdCP Collection
identifier only for canonical content identity such as a series, publication,
event series, or rotation. A media kit does not create capacity. An
availability feed does not decide the product story.
Send representative or redacted material when files contain buyer, campaign,
pricing, or personal data. Do not put credentials, private keys, API tokens,
or customer PII in an onboarding file. Enter live credentials only in the
dedicated connection flow.
## What is production-importable today
Only use a file as a production import when its row shape is documented for an
implemented parser.
| Material | Classification | What works today |
| --------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Static avails CSV, XLS, or XLSX | **Production-importable for static-avails-feed:v1 (compatibility)** | Preview and commit through the modular avails-feed path. This is not the target Inventory Feed schema. |
| Static avails JSON | **Production-importable for static-avails-feed:v1 (compatibility)** | Send as JSON text, or upload the document in Murph and use its document reference. This is not the target Inventory Feed schema. |
| Ad-server wholesale avails and pricing CSV | **Production-importable: 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** | Review with Scope3; it is not an import schema. |
| Product list, rate card, Media Kit, Playbook, and Business Rules | **Merchandising evidence** | Use the Media Kit as supporting Product Marketing evidence. Apply confirmed structured facts through Discovery Card, Playbook, 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** | Use for contract rehearsal. No generalized importer is implied. |
| Target Inventory Feed shapes | **Target contract / not production input** | Do not submit conceptual shapes as production input. Public generated templates will be published only when their production parsers ship. |
**static-avails-feed:v1 is a production compatibility parser, not the target
Inventory Feed schema.** Its exact `collectionId`, `collectionName`, and
`collectionDescription` fields are legacy grouping/container field 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)
contains both parser-backed avails and clearly labeled evidence. Its manifest is
test-harness routing metadata maintained by Scope3. Customers do not author
manifests or calculate SHA-256 digests. Files, APIs, and human confirmations may
arrive independently; Scope3 records receipts and content evidence when each
item arrives.
## Start with one durable source boundary
Define a source by coherent capacity and booking authority, not by vendor,
credential, transport, or filename.
* Keep one source when an ad server, publisher API, file, and human workflow
describe the same bookable pool and have stable joins.
* Use separate sources when inventory has independently allocatable capacity,
booking authority, execution, or reporting ledgers.
* Do not create a second source merely because a supported provider is
connected later.
* Never merge existing sources by matching vendor names. First prove shared
capacity and booking authority, map identity, compare in shadow, choose the
surviving source ID, and retain a rollback path.
### Standard provider paths and custom configuration
Built-in ad-server connections for Google Ad Manager, FreeWheel, SpringServe,
and AdsWizz are standard supported paths within this model. CitrusAd is exposed
through a standard provider recipe. A Scope3-managed sales agent is plumbing
behind some of these connections, not a separate provider family. Each
connector preconfigures only the inventory, execution, status, and reporting
capabilities its published contract supports. A supported feed or accountable
person may supply a remaining scope without changing the business-source
boundary.
Today, ad-server-backed and modular sources still have different setup
surfaces. In-place provider conversion and a single generalized source workspace
are pilot preview design, not shipped self-service behavior. Ask Scope3 to map
supplemental material to the existing source instead of creating a duplicate.
**Enterprise-assisted custom configuration** applies to a customer-specific or
not-yet-supported provider/capability configuration, bespoke schema or API pull,
custom authority or overlap rule, or negotiated manual service. The assistance
applies to that capability and its production activation, not to a new kind of
source. Standard supported paths are not Enterprise-gated merely because the
source is modular. The current advanced modular-composition surface remains
entitlement-gated while this converges.
The standard-versus-custom boundary and its capability-specific support rules
apply consistently across every source.
## Set up inventory and availability
### Bring these materials
The **Needed to prove** column names the first capability that depends on the
item. You can start before later materials arrive.
| Purpose | Representative material | Needed to prove |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------- |
| Source and system map | Systems, provider accounts, APIs, files, human workflows, and the capacity/booking boundary | Source authority |
| Inventory identity and authorization | Stable placement, property, and format identifiers; canonical AdCP Collection identifiers only when the publisher declares a series, publication, event series, or rotation; Property Roster and adagents.json ownership | Discovery |
| Availability and source price | Row-level avails with stable IDs, periods, units, capacity basis, source CPM or floor, and overlap/pool meaning | Discovery and reservation |
| Upstream bookings, when needed | Order or line-item IDs, source scope, period, quantity/unit, status, and update time | Gross-to-net normalization and reconciliation |
| Inventory owners and cadence | Owner and backup, trigger or schedule, timezone, expected arrival, grace, stale effect, correction, and escalation | Repeatable inventory operations |
Download or copy the
[source input and authority worksheet](/v2/setup/source-module-authority-worksheet).
It records provider, scope, stable keys, authority, snapshot/delta/event
semantics, cadence, grace, stale consequence, owner, correction, and escalation.
It is supporting evidence, not a production import schema.
### Stable identity and row grain
Use a stable ID from the system that owns the inventory. Do not use a display
name, row number, or file position as identity.
One static-avails row represents one availability window within a legacy
compatibility grouping. Split rows when the capacity pool, dates, price, currency,
property coverage, canonical creative format, or booking ownership changes. Use
one event, issue, episode, takeover, or sponsorship row only when it has its own
independently controlled capacity. This 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 explicit stable
IDs so later corrections join predictably. The exact `collection*` names below
remain only for `static-avails-feed:v1` parser compatibility.
| Field | Requirement |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| collectionId | **Legacy field name.** Explicit stable seller-side ID for the parser's grouping/container. It does not establish AdCP Collection identity. |
| collectionName | **Legacy field name.** Seller-facing label for that compatibility grouping/container. |
| formatOptions | Non-empty URL-free canonical declarations using format\_kind and params. |
| publisherProperties | Non-empty Property selectors for the inventory represented by the compatibility grouping. |
| availId | Explicit stable ID for the availability line. |
| name | Seller-facing name for the availability line. |
| startTime and endTime | ISO dates or date-times for the covered window. |
| Capacity | impressionsCapacity for net sellable capacity, or gross capacity plus upstream booked capacity. |
Optional fields include `collectionDescription` (**legacy field name** for the
compatibility grouping description), channel, CPM, currency, targeting,
sourceMetadata, and source-specific non-secret join keys. Channel is descriptive
and never determines creative format.
The current static-avails parser is impression-based with optional CPM. It
does not 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 the source reports gross capacity, provide 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
```
The parser rejects booked capacity above gross capacity. If you provide net,
gross, and booked values together, the explicit net value wins in the current
compatibility parser; avoid that ambiguity by using one model per row.
### Capacity, cadence, and correction worksheet
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 when 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, and freshness limit |
| Failure effect | Advisory, discovery blocker, reservation blocker, execution blocker, reporting blocker, or pilot blocker |
| Recovery | Retry, corrected revision, mapping repair, approved exception, owner, backup, and escalation |
A late reporting file does not invalidate current inventory identity. An invalid
availability revision does not rewrite accepted merchandising facts. Each
capability becomes stale or blocked only where its owning stream requires it.
### Replacement, patch, and rejection recovery
The current static-avails contract is a patch/upsert keyed by **availId**:
* reusing an ID updates that availability line;
* changing the ID creates another line;
* 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).
Do not 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 preview
surfaces return **rejectedRowCount**, **rejectedRows**, and **warnings**. The
legacy **ingest\_modular\_avails\_feed** tool does not currently surface those
row diagnostics and can commit the accepted subset, so do not use it for
rejection recovery or to validate a complete refresh.
The canonical Task and REST path also permit an intentional accepted-row
patch. They do not enforce zero rejections before commit. When the file is
meant to be a complete operational refresh, stop if **rejectedRowCount** is
greater than zero, repair the source file, and preview the whole patch again.
For a rejected static-avails 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/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. They are for the implemented
**static-avails-feed:v1** compatibility parser only. They are production-
importable for that parser, not canonical generalized templates or the target
Inventory Feed schema.
One complete net-capacity row with canonical format and Property declarations; legacy collection\* headers remain for parser compatibility.
One complete gross-minus-booked row for the JSON-text compatibility path.
Three fictional rows covering net and gross-minus-booked capacity.
Parser-backed CTV/display avails plus clearly classified evidence and proposal cases.
Use the source-prefilled production download endpoint described in this guide.
### 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, not as a multipart file.
## Set up execution and trafficking
Inventory visibility does not establish an execution path. For each intended
pilot scope, identify the system or accountable person that owns each operation
and provide representative evidence for:
| 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, and returned upstream IDs |
| Approve and traffic creative | Exact format and asset rules, lead times, approval and rejection examples, creative references, handoff evidence, and owner |
| Observe status and failures | State vocabulary, success and failure evidence, observed time, retry behavior, customer-visible pending state, and escalation |
| Update, cancel, and release | One representative update and cancellation, released capacity, version or correction behavior, and final returned state |
Classify each operation as **connected automation**, **named human or secure-file
pilot step**, or **gap**. A manual step counts for a pilot only when it has 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 supplied materials to prove the exact supported operation or to
rehearse a manual pilot; do not treat them as production API requests.
## Set up reporting and reconciliation
Provide a representative delivery and spend report that can join to the exact
booked line. Before calling the source reporting-ready, establish:
* 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; and
* correction, quarantine, replay, owner, backup, and escalation behavior.
The reporting example in this kit is supporting 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 enforced stale-data consequence.
## Add CRM and commercial context (optional)
CRM context is an optional input to buyer-specific merchandising and operating
decisions. Useful evidence includes a CRM field dictionary, five to ten
sanitized account or opportunity rows, buyer-account mappings, and
representative proposal outcomes. Useful fields include stable CRM account and
opportunity IDs, an 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, and 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. A missing CRM feed does
not block inventory, execution, or reporting setup unless a specific approved
workflow declares that dependency. See the
[sanitized CRM example](/v2/setup/publisher-onboarding-example-pack#optional-crm-context).
## Make it merchandisable
Once inventory identity and readiness are explicit, route buyer-facing
decisions to their canonical owners:
| Decision | Owning surface | Proof |
| -------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Product/package definition | Inventory products/components | Every offer points to eligible source identity and grounded evidence |
| Storefront positioning | Discovery Card; Media Kit is supporting Product Marketing evidence | Buyer-facing positioning uses confirmed facts without treating the Media Kit as an owning surface |
| Structured selling price and currency | Pricing owner | Deterministic price respects source floors and effective periods |
| Selection, packaging, event/seasonality, and explanation | Playbook | Repeated brief tests select and explain the expected products |
| Advertiser and creative acceptance | Business Rules | Fit, rejection, and review cases match policy without exposing private rules |
| Buyer-specific treatment | Buyer discounts and instructions | Terms apply only to the intended buyer and remain auditable |
### Prove source-scoped proposal behavior
Use the fictional briefs in the sample pack to run:
1. an obvious fit with 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; and
6. a pricing or format edge case that must ask for clarification or decline
instead of inventing support.
### Know what proposal proof does not establish
A source-scoped proposal test 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
Open the
[sanitized complete-campaign example](/v2/setup/complete-campaign-example).
It joins advertiser, campaign/order/line item, dates, budget, source product,
targeting, quantity/unit, price, creative, approval, status, delivery,
reporting, and returned IDs. It is supporting evidence and a manual pilot
walkthrough, not a production API request or import schema.
Classify every stage in the rehearsal:
| Stage | Valid verdict |
| -------------------------------- | ------------------------------------------------------------------- |
| Discovery and proposal | Available now, pilot preview, or blocked |
| Reservation and transaction | Production path, approved manual path, or blocked |
| Creative and trafficking | Production path, named human work with durable evidence, or blocked |
| Status, update, and cancellation | Production path, named human work with durable evidence, or blocked |
| Reporting and reconciliation | Production import, approved manual evidence, or blocked |
Do not use a successful feed preview or compelling proposal as evidence that a
booking, campaign, trafficking, reporting, or conversion workflow exists.
## Readiness decisions
Readiness is decided per track and per source scope. One green track does not
make the others green.
### Inventory-ready
Stable inventory identity, authorization, property and format coverage,
capacity semantics, source-price constraints, booking overlap, cadence,
correction behavior, and owners are proven for the intended scope. This means
the source can make truthful availability decisions. It does not prove that a
campaign can be executed or reported.
### Merchandising-ready
Stable inventory identity and selling-rights evidence appropriate to the
source, exact formats, current capacity/source constraints, product definition,
structured selling price, positioning, Playbook guidance, and Business Rules
support fit, rejection, review, edge, and source-isolation tests. Where
publisher authorization applies, require current positive authorization
evidence. For a connected platform account where it does not apply, use the
connection-based selling rights rather than inventing an `adagents.json`
requirement. This means buyers can be shown a truthful pilot preview. It does
not mean they can transact.
### Execution-ready
The exact offer has a proven reservation and booking path, creative and
trafficking ownership, returned upstream IDs, status and failure handling,
update, cancellation, retry, and release behavior. This decision is independent
of whether reporting is ready.
### Transaction-ready
The exact offer is both inventory-ready and execution-ready, with no hard
readiness blocker. A named human may satisfy a pilot stage only when the work
item, response expectation, evidence, and escalation are operational.
### Reporting-ready
Delivery and spend join to the booked line with stable source IDs, an agreed
cadence and finality rule, correction behavior, and an owned quarantine path.
The general reporting example in this kit is evidence only until a production
importer or approved manual workflow proves this stage.
### CRM context available (optional)
Sanitized account and opportunity context has stable joins, declared authority,
privacy handling, cadence, and an owner for the workflow that consumes it. This
is not a prerequisite for inventory-, execution-, transaction-, or
reporting-readiness unless the approved workflow explicitly makes it one.
### Pilot preview
A pilot preview may classify materials, run current parsers, inspect projected
products, and test source-scoped proposal behavior. It must display unsupported
transaction, creative, trafficking, status, reporting, or conversion stages as
manual or gaps. It is never a production-launch verdict.
### Operationally self-sufficient
The publisher team can refresh each stream, interpret diagnostics, correct
revisions, operate manual queues, release capacity, reconcile reports, and
escalate exceptions through named owners and backups. This is an operating
milestone, not one API status.
## Related guides
Compare current connection and pilot paths.
Use the current static-avails preview, patch, reservation, and work-item flow.
Put confirmed structured facts in their authoritative Pages and use the Media Kit as supporting evidence.
Reconcile Properties, canonical AdCP Collections when present, formats, and authorization.