> ## 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 pitch

> A proposal pass can now argue for the plan, not only price it — the seven-part case, where every sentence comes from, and why it reads plainer when your catalogue gives it less to argue from.

## Overview

A [proposal pass](/v2/storefront/demand-inbox#the-proposal-pass) can carry a
**pitch**: a written argument for why this plan is right for this buyer,
sitting above the plan itself. Where a pass used to open on a table of
products and prices, it can now open on the case your Merchandising Agent
would make — built only from what your storefront genuinely knows.

The pitch composes shortly after your storefront answers a brief — normally
within a minute — and lands on that brief's pass in your
[demand inbox](/v2/storefront/demand-inbox). It doesn't hold up the buyer: the
plan and prices go out as soon as they're ready, whether or not a pitch has
finished composing.

The pass header leads with the advertiser BrandRef and shows the buying operator
secondarily. It also names the response contract honestly: returned products
without proposal-id evidence are a **product offer**; only a persisted response
with a non-empty `proposal_id` is a **Proposal**. An undecided outcome names who
is expected to act next instead of showing a generic *Pending* state.

<Note>
  **The pitch is seller-side only today.** It renders on your demand inbox
  pass. It is **not** part of what a buyer's agent receives from `get_products`
  — the wire response still carries the plan and prices exactly as before.
  Sharing the argument with a buyer today is up to you; a buyer-facing wire
  projection is a later change.
</Note>

## The seven parts

A composed pitch has seven parts — every part is its own honest claim, so a
part with nothing to say is simply absent rather than padded out:

| Part                         | What it says                                                                                                                                                          |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The thesis**               | One specific argument connecting this buyer's brief to your storefront's supply — why this plan, for this buyer, now.                                                 |
| **What we heard**            | The buyer's brief, mirrored back in their own words, before you argue anything.                                                                                       |
| **The plan as roles**        | Each product presented as a role in a strategy — the anchor, the amplifier, the experiment — with a *fit argument*: why this asset, for this outcome, for this buyer. |
| **How we'll know it worked** | What will be measured, on what cadence, from your products' real reporting capabilities — and, just as honestly, what won't be measured.                              |
| **The value**                | The argument for the price: the guarantee, the packaging, how the price was built — never a bare number in a grid.                                                    |
| **The limits**               | What the brief asked for that your catalogue genuinely lacks, and what you'd do instead.                                                                              |
| **What's next**              | The invitation — what happens if the buyer books it, refines it, or tests it.                                                                                         |

<Note>
  **Reading order on the pass.** These seven parts, plus one matched case
  study and the plan's own terms, read together as a **story**, in an order
  built for the buyer's eye rather than the composer's: what we heard, why
  you, the plan, proof, terms, then the ask. See
  [The story-first proposal](/v2/storefront/proposal-story) for that full
  reading order and where each part of it comes from.
</Note>

When a pitch composes, the pass keeps its product table too — it moves under
a **Plan appendix** heading beneath the narrative, same products, same prices,
unchanged. Nothing about the plan is restructured; the pitch adds the argument
on top of it.

## Where every sentence comes from

**This is the rule that matters most: every sentence in a pitch cites at
least one real source, or it never appears.** That's enforced at the moment
the pitch is composed, not a style guideline applied afterward — a sentence
with no source behind it is deleted before anyone reads it.

A sentence may cite:

* **Your buyer's brief** — mirroring the buyer's own stated words and facts.
* **Your inventory and product data** — the bundles and signals selected for
  this plan, delivery type, and the products' real reporting capabilities.
* **Your Playbook pricing** — the rate-card facts that anchored or floored a
  price. See [Playbook pricing](/v2/storefront/playbook/overview).
* **Your Playbook instructions** — the guidance version the pass composed
  under. See [Playbook instructions](/v2/storefront/operating-instructions/overview).

Each claim carries its receipts the same way a product row already does: the
same ["fed by" chips](/v2/storefront/demand-inbox#where-fed-by-comes-from) sit
behind individual sentences, and tapping one opens the exact ingredient it
cited — your inventory source, or your Playbook — so you can check any claim
in the argument, not just the plan underneath it.

<Note>
  **A superlative only composes when something you told your storefront says
  so.** A claim like "our highest-attention placement" or "read by N million
  people a month" needs a source that states it. Today nothing does —
  your Listing and buyer-facing story aren't a pitch source yet, the same gap
  [the demand inbox](/v2/storefront/demand-inbox#where-fed-by-comes-from)
  already documents for "fed by" — so those sentences don't compose, and the
  value case rests on the guarantee, the packaging, and what your inventory
  data can state plainly. That's not a bug to route around: it's the honest
  result of nothing yet backing the bigger claim.
</Note>

## Why your pitch reads plainer than you expected

A pitch gets richer exactly as your storefront's own data gives it more to
argue from — that's the lever you have, not a setting to find:

* **A thin rate card produces a thin value case.** Add target prices,
  floors, and the conditions they apply under in Playbook pricing, and the
  value case can argue from them instead of the number alone.
* **A generic Playbook produces a generic thesis and limits section.** The
  more your Playbook instructions say about how you position your inventory
  and where it doesn't fit, the more specific those two sections get.
* **A claim you expected to see and don't** almost always means it didn't
  have a real source at compose time — not that the composer forgot it. Check
  what fed the surrounding claims; the gap is usually the ingredient, not the
  argument.

Nothing is ever reconstructed to fill a gap. A section with nothing to say
stays empty rather than showing an invented sentence.

## Every claim is checked twice

Citing a real source isn't the whole check. Before a pitch is attached to your
pass, every sentence also has to genuinely follow from the source it cites —
a second, independent pass verifies that the claim's actual wording is
supported by the fact behind it, not just that the fact exists. A sentence
that names a real bundle but overstates what that bundle's own data says is
caught here and removed, the same way an unsourced sentence never survives
composition in the first place. If this verification step itself can't run,
no pitch composes at all for that pass — a pitch with an unverified claim is
worse than no pitch.

## Resolving a dropped sentence

A dropped sentence isn't discarded — the pass keeps it, along with why it was
dropped and the facts it was checked against, so you can act on it. On a
proposal pass whose compose dropped one or more sentences, the pass shows a
**"What didn't make it"** section listing each one.

Three ways to resolve one:

| Action                     | What it does                                                                                                                                                                                                                     |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **This is a fair reading** | Tells us the sentence was a fair reading of what you've already told us. We add its factual content to your corpus as a fact you've stated, so it can be checked and pass next time. You can edit the wording before confirming. |
| **Teach the fact**         | Points you to your product-marketing corpus, where you can teach the missing fact directly. Once it's there, the sentence becomes checkable the next time this pitch composes.                                                   |
| **Drop it**                | Confirms the sentence should have been left out. Nothing changes in your corpus.                                                                                                                                                 |

**None of these loosen what gets checked.** Ruling on a sentence only ever
adds a fact to your own corpus, or confirms the drop stands — it never
changes the standard sentences are checked against, and there is no setting
that lowers that bar for your storefront specifically. The check above is
what every future sentence, from every seller, is still held to.

## While it's composing

A pass can show a quiet note that its pitch is still being composed. This is
normal — composing an argument happens after your response has already gone
to the buyer, so it never holds anything up — and it resolves within a few
minutes to either the finished pitch or one of the absent reasons below. It
never silently disappears: if something interrupts composing partway through
(a deploy, for instance), the pass is guaranteed to eventually pick back up
and resolve, retrying once before giving up.

## When there's no pitch at all

A pass can carry no pitch. When that happens, the pass renders **exactly as
it did before pitches existed** — the plan, and nothing invented around it.
Reasons a pitch may be absent:

| Reason                | What it means                                                                                                                                                                                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Not yet enrolled      | Pitch composition is rolling out to selected storefronts (see [Availability](#availability)).                                                                                                                                              |
| Composing failed      | A real fault interrupted composing or its verification pass.                                                                                                                                                                               |
| Nothing to argue from | Even the thesis — the one part every pitch must have — needs a real, verified source. When nothing in your own data could ground one, no pitch is composed at all, rather than one built on a claim that wouldn't survive an honest check. |
| Superseded            | You adjusted the proposal before the pitch for the earlier version finished; the revision gets its own pitch instead (see [Revisions get their own pitch](#revisions-get-their-own-pitch)).                                                |
| Timed out             | Composing an argument runs against a deadline so it never holds up your response to the buyer, and retries once if interrupted; if it still can't finish, the pass ships with the plan only.                                               |

## When the pitch can't be checked right now

Separately from the reasons above, a pass can occasionally show the plan only
because the pitch lookup itself hit a transient problem — a slow database
query, for example — rather than because a pitch never composed. This renders
identically to "no pitch at all": the plan, and nothing invented around it.
It isn't one of the reasons in the table above, because it says nothing about
whether a pitch actually exists; refreshing the pass usually resolves it.

## Revisions get their own pitch

When you [adjust a proposal and send a revision](/v2/storefront/demand-inbox#adjusting-a-proposal),
the revision is re-argued: it composes its own pitch from the revised plan
rather than reusing the one that shipped with the original. A revision is a
new case, not a relabeled one.

## Availability

<Note>
  The pitch is rolling out to selected storefronts. If your proposal passes
  show the plan only, check with Apostra on current availability for your
  storefront.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="The story-first proposal" href="/v2/storefront/proposal-story" icon="book-open">
    The full reading order this pitch renders in, plus proof and terms.
  </Card>

  <Card title="Demand inbox" href="/v2/storefront/demand-inbox#the-proposal-pass" icon="inbox">
    The ledger and the proposal pass the pitch renders on.
  </Card>

  <Card title="Playbook pricing" href="/v2/storefront/playbook/overview" icon="tags">
    The rate-card facts a pitch's value case can cite.
  </Card>

  <Card title="Playbook instructions" href="/v2/storefront/operating-instructions/overview" icon="scroll">
    The versioned guidance a pitch's thesis and limits section draw on.
  </Card>
</CardGroup>
