Venture Proof Page
The evidence-and-offer page of a venture. Its job is to convert an intent-stage reader from "interested" to "committed" by handing them a falsifiable test design and the live offer terms. Without a falsifiable test, the offer is vapour; without offer terms, the test is theoretical.
Primary audience: An intent-stage reader who has read the pitch, said "maybe," and needs the offer specifics before yes or no.
Job
The proof page causes an intent-stage reader to convert from interested to committed — by stating the live offer (who, what, dates, pass and fail conditions) and the trust design that protects the reader's downside.
Reader Profile
Role. A reader who has been persuaded by the pitch and is now deciding whether to commit. Could be a cohort candidate, a venue counterpart, a partner, or a funder — but at the proof page, all of them are evaluating the same question: are the offer terms specific enough that I can say yes?
Moment. Has clicked through from pitch with intent. Wants the unknowns named explicitly so they can decide; will defer indefinitely if asked to "trust the process."
Tension. Wants to be the kind of person who joins early; fears unnamed scope creep, missing exit conditions, or commitments that compound silently.
Direct Action Contract
The page must answer each of the seven on-surface in two sentences or fewer.
- What problem matters now? — Restate the problem from the pitch in one line, then immediately link to the evidence trail that proves it is real.
- What happens if nothing changes? — Stated as the cost the reader carries personally by not joining the proof loop now.
- What better future is available? — Stated as the artifact the reader will hold after the proof loop completes. Concrete deliverable, not abstract value.
- Why trust this route? — The trust design. How custody of data, time, and money is handled at every rung. The reader holds what the reader produces.
- What is the first action? — The live offer block: who is in the cohort, what happens in each session, dates, pass condition, fail condition, exit clause.
- What outcome makes the journey worth joining? — The artifact at the end of the proof loop, named explicitly, with the standard for what counts as the artifact being shipped.
- What kill signal keeps the bet honest? — The reactivation gate (or commission gate): a falsifiable set of conditions that, if met, advances the venture; if unmet, the venture stops.
Output — the artifact shape
| Slot | Section | Purpose |
|---|---|---|
| 1 | Eyebrow + venture name | Identity |
| 2 | Hero: the one-sentence offer line | The bet, stated as an offer |
| 3 | Evidence ledger — what we know, what we are guessing | Tagged claims (FACT / ESTIMATE / ASSUMPTION / UNKNOWN) |
| 4 | The live offer panel | Who, what, dates, pass condition, fail condition, exit clause |
| 5 | Trust design — the custody ladder | How the reader holds what the reader produces |
| 6 | The artifact the proof loop will ship | Named deliverable + standard for "shipped" |
| 7 | Reactivation or commissioning gates | Falsifiable advance conditions |
| 8 | Kill signals | Falsifiable stop conditions, owned |
| 9 | Close — copyable prompt for the reader weighing yes/no | The decision survives the tab close |
The live offer panel is non-optional. A proof page without a live offer is an evidence page; an evidence page does not cause commits.
Action
Primary action. Agree to the live offer. Name + slot + first session date. The commit is specific enough that no follow-up is needed to start.
Wrong action. Read, save, defer. Maybe book a discovery call to "discuss next steps" — which is decision-deferral disguised as engagement.
Source affordance. The live offer panel itself is the affordance. Each field is one line. The reader takes the offer by replying to a named human with the three fields filled (name, slot, date). The offer's specificity removes the excuse to defer.
Outcome Cascade
Right action (the bet pays out)
| Order | Effect |
|---|---|
| 1° Direct | A booking is confirmed; the offer's first session is scheduled with a named reader |
| 2° Downstream | The proof loop runs; pass-condition evidence accumulates per session |
| 3° System | The artifact the proof loop was designed to produce is shipped; another human can re-run it |
| 4° Cultural | The next cohort fills because the prior cohort produced a shipped artifact, not a story; readers learn this venture ships proofs, not promises |
| 5° Structural | Reactivation or commissioning gates fire; the venture advances to the next funding rung honestly; or the kill signal fires and the venture stops without burning credibility |
Wrong action (the page fails its job)
| Order | Effect |
|---|---|
| 1° Direct | The reader leaves having neither committed nor declined; no booking; no signal |
| 2° Downstream | The proof loop does not run; pass-condition evidence does not accumulate; the offer cannot be evaluated |
| 3° System | The founder cannot tell whether the offer was wrong, the trust design was wrong, or the timing was wrong; the failure was silent |
| 4° Cultural | Readers train themselves to "save for later"; the venture accumulates phantom intent that never converts |
| 5° Structural | The reactivation or commissioning gate cannot fire because there is no data; the venture sits in a permanent "almost ready" state and the kill signal cannot fire either, because no evidence either way is being produced |
Kill Signal
bookings = 0 for 30 days post-publish → offer terms are not converting; the ask is wrong or the reader is wrong heuristic
Owner: the venture lead. Measurement: bookings tied to the offer block. Consequence when the signal fires: revise the offer (terms, dates, pass condition, trust design) or revise the reader (the proof page may be targeting the wrong rung of the persuasion ladder).
The proof page also carries the venture-level kill signal that the pitch references. Two kill signals: one for the page itself (above), one for the venture (named in the gate block below). Both are falsifiable, owned, measured.
Instrument Flow
Upstream
These instruments feed the proof page.
Adjacent
These instruments strengthen or qualify the proof.
Downstream
These artifacts consume the proof page output.
Source Map
| Proof section | Primary source instrument | Supporting instrument | Downstream consumer |
|---|---|---|---|
| Evidence ledger | Operations Scorecard | Idea Capture | One-Page Plan §9 |
| Live offer | Lead Magnet Strategy | Unit Economics | Data Room |
| Trust design | Idea Capture custody section | Operations Scorecard | One-Page Plan §5 |
| Artifact spec | Operations Scorecard | Idea Capture | One-Page Plan §15 |
| Reactivation gates | Operations Scorecard | Cash Flow Projection | One-Page Plan §14 |
| Kill signals | Operations Scorecard | Cash Flow Projection | One-Page Plan §14 |
Claim Tags
Every claim on the evidence ledger must carry one tag:
FACT: observed, evidenced, or contractually true.ESTIMATE: calculated from known inputs.ASSUMPTION: required belief that has not been proven.UNKNOWN: open issue that affects the offer.
Use the tag inline: [FACT] N readers signed the waitlist as of [date] — [ASSUMPTION] Price point of [amount] will be acceptable to the named segment.
Procedure
- Write the live offer first. If you cannot fill all six fields (who, what, dates, pass, fail, exit), the page is not yet ready and the offer is not yet a real offer.
- Write the artifact spec next. What does "shipped" mean? Name the deliverable, name the standard, name who certifies the standard met.
- Build the evidence ledger from upstream instruments. Tag every claim. Honesty bias:
[ASSUMPTION]and[UNKNOWN]are not weaknesses; they are decision-useful signals. - Write the trust design. Walk each rung where the reader's data, time, or money is exposed. Name the custody arrangement. The reader holds what the reader produces.
- Write the reactivation gates (for pre-launch ventures) or the commissioning gates (for ventures past first revenue). Three to five gates. Falsifiable, owned, dated.
- Write the kill signals. At least one venture-level signal and one page-level signal. If a kill signal cannot be measured weekly, it is rhetoric, not a signal.
- Order the slots top-to-bottom. The live offer comes BEFORE the trust design, which comes BEFORE the gates. Readers commit when they see the offer; trust and gates are the validation layer they read after they have already decided yes.
- Close with a copyable prompt for the reader weighing yes or no. The prompt is the decision-aid, not a summary.
Do Not Include
- An offer without fail conditions. A pass-only offer is a one-way commitment for the reader; a falsifiable test names both sides.
- Soft asks. "Get in touch" is not an offer; "Reply with name + first session date by [date]" is.
- Promises without artifacts. "You will feel different" is not an artifact; "A two-page story another person can re-run" is.
- Open-ended commits. Every offer has a fixed window. Open-ended commits compound silently and erode trust.
- A pricing table for a pre-revenue venture. Pricing follows demand; demand follows the proof loop. If the venture has not run the proof loop, pricing is fiction.
- Kill signals that require negotiation to fire. If the signal cannot fire mechanically, it is rhetoric.
- Discovery calls as the primary CTA. The proof page exists to remove the need for a discovery call.
Scoring Rubric
Score each dimension from 1 to 5.
| Dimension | 1 | 3 | 5 |
|---|---|---|---|
| Offer specificity | Soft ask | Named verb, missing some fields | Verb + window + owner + pass + fail + exit |
| Evidence tagging | Untagged claims | Some claims tagged | Every claim tagged FACT/ESTIMATE/ASSUMPTION/UNKNOWN |
| Trust design | No custody named | Some rungs named | Every rung where the reader is exposed has a named custody arrangement |
| Artifact spec | "You will benefit" | Artifact named generically | Artifact named, standard named, certifier named |
| Gate honesty | No gates | Gates stated but not falsifiable | Gates falsifiable, owned, measured weekly |
| Kill signal | None | Stated but not measurable | Page-level + venture-level, both measurable, both owned |
Investor or board standard: no dimension below 4.
CopyablePrompt
For the page builder, before writing the proof page:
I am designing the proof page for a venture. Before I write any content, I
want to confirm the live offer is specific enough to cause commits and the
trust design is honest enough to survive scrutiny.
For the live offer, fill all six fields. Refuse to write the page until every
field is filled:
- Who: named participants or named segment, capped at N
- What: named protocol or session shape
- Dates: first session, last session, decision window
- Pass condition: what counts as advance
- Fail condition: what counts as stop
- Exit clause: how the reader leaves cleanly mid-cycle
For the trust design, walk each rung where the reader is exposed:
- Data: who holds it, where, with what retention
- Time: what hours, over what window, with what cancellation policy
- Money: any payment, refund terms, escrow if any
For each rung, the reader holds what the reader produces. If a rung violates
that, name the exception explicitly.
For the artifact spec:
- Named deliverable: what will the reader hold at the end of the proof loop
- Standard: what makes the deliverable "shipped" vs "draft"
- Certifier: who signs that the standard is met
For the reactivation or commissioning gates:
- Three to five gates, falsifiable, owned, dated
- If the gates fire, the venture advances; if unmet, the venture stops
For the kill signals:
- Page-level: when this page is not doing its job
- Venture-level: when the venture itself is not doing its job
- Both measurable weekly, both owned by a named person
Close with a copyable prompt for the reader weighing yes or no. The prompt is
the decision-aid; the offer is the action.
Questions
- Which field of the live offer was hardest to fill — and is it hardest because the answer is unknown, or because the answer would force a no?
- For each rung of the trust design, would the reader agree the custody arrangement is honest? If you cannot ask them, ask a stand-in who matches the reader profile.
- Of the reactivation gates, which is most likely to be falsified by the proof loop — and is the founder ready to honour that?
- If the page-level kill signal fired tomorrow, would the founder admit the offer was wrong, or rationalise the bookings drought as "market timing"?