Skip to main content
This page gives you a complete set of fake files from a made-up publisher, “Sample Publisher Network”. Copy them, preview them, and see exactly what a working setup looks like — before you prepare your own. Use it when you are preparing inventory-source inputs (Prepare inventory source inputs) and want to see a finished example, rehearse the upload and preview steps, or check that your own files are shaped correctly. You do not need it if your inventory passes through to an external sales agent that owns its own products, avails, formats, and reporting.
Everything here is synthetic. No customer data, and all domains use the reserved .invalid suffix so nothing can accidentally resolve.

Download the complete example pack

Get every file below in one ZIP, including the two directly previewable static-avails compatibility feeds, the deliberately invalid diagnostic fixture, merchandising evidence, and lifecycle examples.

​
How to use this pack

1

Decide where to rehearse

Nothing reaches buyers until you commit. A preview validates rows and records the attempt, but only a commit makes capacity active. Creating the source itself is a real change, so use a storefront you are willing to add a custom source to — and it needs a Premium or Enterprise account using the Merchandising profile. Standard managed integrations are included with every seller plan.For a fully separate sandbox, ask Scope3: a Demo Storefront is a seven-day seller account with synthetic data, created for you by a Scope3 platform administrator. Ordinary accounts cannot create one.
2

Set up merchandising first

Apply the Seller Account profile, rate card, playbook, business rules, and creative specs through their owning surfaces (or with Murph). Review every proposed write before confirming it.
3

Create one source per durable source boundary

For this fictional pack, treat CTV and display as separate boundaries because their capacity and booking authority are controlled independently. The two availability rows in each file are pools inside that source, not separate sources. In your own setup, split sources only where capacity and booking authority are independently controlled.
4

Preview and commit the avails

Each file should show 2 accepted rows, 0 rejected, no warnings. Reconcile formats and properties against your Property Roster, then commit.
5

Check the products, then test the briefs

Confirm the four projected product IDs, then run briefs.json to see how the agent sells, refuses, and asks for clarification.
6

Stop before turning on transactions

Transactions, delivery, and marketplace listing are separate readiness decisions. A good preview proves none of them.

​
Which files do you need?

Two groups do the core work — inventory and merchandising. The rest are optional. Almost every file belongs to exactly one group.
One file sits in both groups. creative-specifications.md is a merchandising document (what creative you accept, approval rules, lead times), but its formats must match the formatOptions declared in the avails files. Reconcile the two before you commit.
Only the avails files labeled static-avails-feed:v1 can be imported into production, and only through that compatibility parser. Every other file is supporting evidence or a manual pilot input — attaching one is not ingestion.
Download the complete ZIP above, or use a code block’s copy button and save the copied content under the filename in its heading.

​
Inventory files

The only production-importable files in this pack. One row is one availability window: an inventory pool, a date range, a capacity, and a price. The examples use CTV and display — set channel to whatever is relevant for you (audio, dooh, retail-media, broadcast, …) and declare the matching formatOptions. Channel is descriptive; the format declaration is what constrains the product.
The parser is impression-based with an optional CPM. Flat-rate flights, slot or time-based sponsorships, and click pricing have no field here yet — keep those in supporting evidence.
Prime-time streaming and live sports, US, Q1 2030, with 15–30s VAST video. Previews with 2 accepted rows.
Homepage impact and contextual article display, US, Q1 2030, 300×250 image. Previews with 2 accepted rows.
Shows both capacity models side by side: net (impressionsCapacity) and gross minus already-booked (avails − upstreamBookedImpressions). Also shows that numeric shorthand like 12m is accepted. Use one model per row, never both.
Preview this to see what real errors look like: a missing format, a forbidden legacy format identity (canonical formats never carry an agent_url), and a missing Property declaration. Preview it; never commit it.
collectionId, collectionName, and collectionDescription are legacy grouping field names kept for parser compatibility. They do not create an AdCP Collection. Don’t turn a monthly pool, placement, or channel into one to satisfy the parser.

​
Merchandising files

None of these are importable. They are evidence you review, then apply as confirmed facts through the surface that owns each one — see Listing, Playbook, and AI Business Rules.

​
Publisher identity — publisher-adagents.json

What the publisher authorizes: the properties and canonical format IDs the feeds reference. Replace the reserved domain, then publish this file at the publisher-controlled /.well-known/adagents.json path. The empty authorized_agents list is intentional: only the publisher may add the sales agent it authorizes.

​
Storefront profile — storefront-profile.json

Who you are as a seller: name, domain, channels, markets, and currency. Buyers need to know who they are buying from, so this feeds Seller Setup and your listing.

​
Media kit — media-kit.md

Your sales pitch in prose: what each product is good for and who it reaches. It’s supporting positioning evidence — it does not create inventory or capacity.

​
Rate card — rate-card.csv

What each product costs: a target, floor, and ceiling CPM per product, with the window it applies to. Structured pricing lives in the Playbook; the agent never quotes below a floor.

​
Playbook — playbook.md

How your agent should sell: how many options to offer, when to ask instead of substituting, and how much reasoning to reveal. This is judgment, not policy.

​
Business rules — business-rules.md

What you refuse and what needs a human: banned categories, review gates, and the rules the agent must never quote back to a buyer. This is policy, not judgment.

​
Creative specifications — creative-specifications.md

Which ads you accept: formats, sizes, durations, approval rules, and lead times. These must match the formatOptions in your avails files — this is the one document that spans inventory and merchandising.

​
Optional CRM context

What it is: a sanitized slice of your CRM — which agency or advertiser an opportunity belongs to, its stage, amount, and outcome. When you need it: only when you want the agent to treat specific buyers differently — for example applying an agreed discount to an agency you already have a relationship with, or prioritizing a renewal. Skip it otherwise. When you don’t: it is never required for inventory, execution, transaction, or reporting readiness. The CRM example is not inventory, availability, booking authority, a canonical buyer account, or a production import schema. Start with a field dictionary and a handful of sanitized rows. Agree the mapping and handling before sending a larger export, and remove contact names, email addresses, and other personal data.

​
Lifecycle evidence (optional)

Use these to rehearse the joins that connect a booked line back to inventory and forward to delivery. No generalized importer exists for either — they are manual pilot inputs.

​
Booking export — booking-export.csv

What’s already sold upstream. Subtract it from gross capacity so you never offer inventory twice. Joins on availId.

​
Reporting export — reporting-export.csv

What actually delivered and what it cost. Joins back to the avail through reportingJoinKey, and carries finalAsOf so you can tell preliminary numbers from final ones.
To trace one campaign end to end, use the complete campaign example.

​
Proposal tests (optional)

Lifecycle evidence above checks your plumbing on a sale that already happened. These check your agent’s judgment on a sale that hasn’t — fake buyer requests, run before any real buyer sees your storefront. The vague-brief case accepts either one grounded product or the storefront’s normal silent no-fit. The Simulator’s decision summary is seller-only evidence; the grader does not treat that private rationale as a clarification shown to a buyer.

​
Brief corpus — briefs.json

Thirteen fake buyer requests with the answer we expect. Good fits, a policy refusal, a below-floor price, an unsupported duration, a vague brief, and an attempt to trick the agent into leaking private rules. Run them to see whether your setup sells correctly — no buyer is ever contacted.
A passing brief test proves discovery behavior only. It does not contact a buyer, create a media buy, book upstream, traffic a campaign, or prove production readiness.

​
Evaluation prompt — agent-evaluation-prompt.md

A prompt to hand a fresh agent so it grades your setup from zero, using only these files and the public docs. Useful as an independent second opinion. It mentions a manifest.json; that is Scope3’s own test-harness routing file, so substitute your four expected product IDs for step 5.

​
Next steps

Prepare your own inputs

Field requirements, capacity rules, and how to fix rejected rows.

Record who owns each fact

Which system or person is the authority for avails, products, formats, and reporting.

Trace one campaign end to end

Proposal → booking → creative → trafficking → status → reporting.

Put facts in the right Page

Listing, Playbook, and AI Business Rules — one fact, one owner.
Files can arrive independently. Accepting one file does not mean another lifecycle stage is ready — an accepted avails revision proves nothing about booking, creative, trafficking, reporting, or merchandising.