> ## 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.
# The story-first proposal
> When your agent composes a pitch, the proposal pass reads as a case for this buyer — what they asked for, why you, the plan, proof from your own case studies, the terms, and the ask — and you can try it yourself with a practice brief.
## Overview
A [proposal pass with a composed pitch](/v2/storefront/pitch) doesn't have to
read as a table of products and prices. When one composes, the pass opens on
a story told in six parts, in this order:
1. **What we heard**: the buyer's brief, played back in their own words.
2. **Why us**: the argument for why your storefront fits this brief, grouping
two parts right beneath it: **The value**, the case for the price, and
**The limits**, what your catalogue genuinely doesn't cover.
3. **The plan**: the products, each led by the reason it's in the plan
rather than its name and price alone — and, under each product, **what
you're buying**: the property each placement runs on, how much delivery
capacity you've actually made available for its window, and — where
you've taught your agent who the audience is — the audience facts
themselves, with their source.
4. **Proof**: a case study from your own [product marketing](/v2/storefront/product-marketing/overview)
that matches this brief, when one does, plus **How we'll know it worked**,
how success on this plan will be measured.
5. **Terms**: the flight, the budget, and the guarantee mix, stated directly.
6. **The ask**: what happens next if the buyer books it, refines it, or
tests it.
The product table is still there underneath. Nothing about the plan is
restructured, and every fact still carries the same
["fed by" receipts](/v2/storefront/demand-inbox#where-fed-by-comes-from) it
always has. The story is a different reading order for the same pass, not a
second copy of it: the [demand inbox](/v2/storefront/demand-inbox) ledger row
and the full pass both render this exact arc from the exact same pitch, never
two versions that can drift.
**Proposal is an evidence-backed label.** If `get_products` returned products
without a persisted `proposal_id`, the same surface labels the response a
**product offer**, not a Proposal. Advertiser brand remains the primary header
identity and the buying operator appears beneath it. The story-first reading
order does not change those response-contract or identity facts.
This is the same [composed pitch](/v2/storefront/pitch) described on its own
page: the seven-part argument, what it can cite, and why it reads plainer
when your storefront gives it less to argue from. This page is about how
that pitch, plus one matched case study, reads together as one story on the
pass.
## Where each part comes from
| Part | Comes from |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| What we heard | The buyer's brief, mirrored back — see [the pitch's "What we heard"](/v2/storefront/pitch#the-seven-parts). |
| Why us | The pitch's thesis, value case, and limits — argued only from your inventory, Playbook pricing, and Playbook instructions. |
| The plan | Your products, each led by the pitch's fit argument for that product (its role in the plan) instead of its catalog description, plus what you're buying — see below. |
| Proof | A case study confirmed on your [product marketing page](/v2/storefront/product-marketing/overview#case-study-stories), matched to this brief by advertiser, industry vertical, or channel, plus how success on this plan will be measured. |
| Terms | The plan's own numbers — the buyer's committed budget, the flight window, and how many of the plan's products are guaranteed. |
| The ask | The pitch's invitation — what you're proposing the buyer do next. |
**Shaped by** names the endorsed pair the agent followed and gives its reason,
or says that none fit. A reusable Library slide appears as a block with its
source named; it is not rewritten as pitch text.
## The plan, specifically: what you're buying
A product row in the plan states its mechanics — guaranteed or
non-guaranteed, a rate — but mechanics alone don't say what the buyer is
actually purchasing. A product can also be backed by more than one avail (a
homepage takeover made of several daily slots, say), so **what you're
buying** lists a placement line PER AVAIL — never merged into one row that
would misattribute delivery to the wrong property or blend disjoint windows
into a fabricated range. Each placement states three things, resolved by
your storefront's own data rather than composed by the pitch:
* **The property.** Which property in your [Property Roster](/v2/storefront/publisher-domains#the-property-roster)
this avail actually runs on, and the specific placement within it, when one
is named. An avail whose Property Roster selector matches more than one
live property (for example, a tag-based selection) lists every one of
them, up to 8 — never just the first — since all of them carry that
avail's delivery. A selector matching more than 8 shows the first 8 plus
"+N more properties" rather than an unbounded list. When the property
can't be resolved yet, the row says so directly and offers a way to name
it — never a guessed property.
* **The available delivery.** This states what your feed currently reports as
available for this avail's own window — `impressionsCapacity` minus
whatever is already held or booked — never a guarantee: no hold exists on
an avail until a buyer's booking actually places one, so the same capacity
stays open to any buyer until then. When the product's entire backing is
this one avail, the row says "full slot available"; every other case
states the net available impression count directly ("up to N impressions
available"). A genuinely sold-out avail says so plainly with its actual
window ("sold out · Jan 1 – Jan 31", or "no impressions currently
available" for a partial listing) rather than the "available" wording a
zero would otherwise fall into. Where the price is a flat rate, the
effective CPM that rate works out to is shown alongside it — except when
any of the product's backing avails is missing OR listed but unresolved,
since dividing the full price by a known-partial delivery total would
overstate it; that line is omitted rather than shown misleadingly cheap.
* **The window.** The exact dates this avail's own delivery covers — never
unioned with another avail's window.
Below the placement lines, **the audience** lists facts about who the
audience is, drawn from your [product marketing](/v2/storefront/product-marketing/overview)
claims that match the product, each with its source (capped at 5 facts per
product, 24 per response — a large response can run a later product out of
budget, which reads as no facts for that product rather than a false "your
agent hasn't been taught anything"). Either cap — a product matching more
than 5 facts, or the response running out of its 24-fact budget — shows a
"showing the first N audience facts" note rather than letting a shortened
list read as complete. A claim you scoped to a channel and/or a creative
format only matches a product that actually carries that channel and
format; when a product's channel or format can't be determined at all,
only your UNSCOPED claims still match it. When you haven't taught your agent
an audience fact for this product yet, the row says so plainly and offers a
way to add one — never a generic audience description. A storefront with a
very large claim corpus is read up to its own scan bound; if a matching
claim exists beyond that bound, this row renders silently (the same way a
response-level budget cap does) rather than showing a confident "you haven't
taught anything" that the corpus may not actually support.
Today, placement and delivery resolve for inventory fed through a static
avails feed. A product sold through another connection (an ad server sync,
or an embedded sales agent) states its property and delivery honestly as not
yet resolved, rather than guessing — support for those connections is
coming.
If one of a product's backing avails has since been archived or deleted, the
row says plainly that some placements could not be resolved rather than
letting the avails that did resolve stand in as the whole product — a
missing avail never upgrades the remainder to "full slot available". The
same honest "some placements could not be resolved" line covers a product
backed by more than 12 avails (only the first 12, in the product's own
declared order, are shown) and a product with MIXED backing — some avails
plus another connection (an ad server sync, or an embedded sales agent) —
where the avails-feed portion resolves normally but the other connection's
share of the product is not yet resolvable, so it is disclosed the same
way rather than letting the resolved avails read as the product's complete
backing.
## Proof, specifically
Proof is the one part that doesn't come from the pitch itself: it's your own
[case-study story](/v2/storefront/product-marketing/overview#case-study-stories),
matched independently, by the same rule that page describes: the brief has to
point at it by naming the advertiser, matching the industry vertical, or
matching a channel. A brief that doesn't point at any story draws none in.
When a story matches, Proof shows the challenge, the method, and the
**results verbatim**: each measured outcome together with who measured it,
exactly as your case study records it. Nothing is paraphrased and nothing is
added: what you confirmed on your product marketing page is what shows up
here.
## Honest absence, every time
Every part of the story is independently omittable, and absence is never
filled in:
* **No matching case study?** Proof says so plainly — "No case study matched
this brief yet" — with a way to add one, rather than showing a made-up
example or a generic one that doesn't fit.
* **A thin Why-us?** If your storefront's Playbook and product marketing gave
the pitch little to argue from beyond the headline thesis, the section
reads thinner and offers a way to teach your agent more — never padded with
invented reasoning.
* **An unsupported attribution request?** The limits names the requested
attribution exactly and says that it is unavailable or an explicit gap. It
is never promoted into affirmative Why-us or Proof language.
* **Custom work that requires manual fulfillment?** The limits names the work
and the human handoff it requires. The agent never implies that it executes
that work itself.
* **No pitch at all?** The whole story arc is skipped. The pass renders
exactly as it did before pitches existed — the plan, and nothing invented
around it. See [When there's no pitch at all](/v2/storefront/pitch#when-theres-no-pitch-at-all).
## Try a brief
You don't have to wait for a real buyer request to see your storefront's
story-first proposal. On your
[product marketing (Teach) page](/v2/storefront/product-marketing/overview),
**Try a brief** lets you paste brief text and see what your agent would
compose for it:
1. Paste a brief — real or hypothetical — into the box and run it.
2. Your agent composes a **real** proposal and pitch for it, through the same
path a live buyer request takes, tagged as a **practice** run.
3. It opens immediately as the story-first proposal, so you can read it end
to end right there.
A practice run is never billed and never sent to a buyer — nothing about it
is a real pursuit. Because it's tagged as practice rather than real demand,
it does **not** appear afterward in your [demand inbox](/v2/storefront/demand-inbox)
list, which shows only live buyer activity. There is no separate history view
for practice runs yet, so this is the one chance to read it — reopen **Try a
brief** and run it again if you want another look.
## Related
The seven-part composed argument this story is built from.
Case studies, selling points, and where Try a brief lives.
The ledger and the proposal pass the story renders on.