The done-with-you kit for this week’s play: turn one live AI feature into a buyer-ready Model Receipt Packet a small SaaS vendor will pay $350 for. Free for one issue cycle, then it retires into the Pro Vault.

What this kit does. Every routed AI feature has a supply chain nobody wrote down: a router, several eligible models, policies that change monthly, logs that capture some of it. When an enterprise buyer’s security review lands, the vendor’s answers live in an engineer’s memory. This kit builds the packet that answers them: eight linked artifacts, every claim dated and sourced, every gap labeled instead of hidden. You’ll build a practice specimen first (FieldNote, below), then sell the real one.

What’s in it: the scope sheet, the data-path map, the model register, the route-receipt schema, the evidence index, the buyer FAQ, the change card, the signoff sheet, the FieldNote worked specimen, the outreach note, the pricing script, the honesty rules, and a day-by-day install SOP.

What it saves you: the 20+ hours of figuring out what a “good answer” to a security questionnaire even looks like, and the credibility cost of learning it on a paying client.

Build these as one folder per client. Plain files beat fancy tools: Google Docs + Sheets, or markdown + CSV. The numbering is the build order.

01-scope-and-claims (doc). The frozen scope: one feature, one environment, one router, up to three eligible models, one interviewed engineer. Plus the claims list: every sentence the client currently tells customers about the AI feature (“we don’t train on your data,” “processing stays in the US”), each marked PROVE, SOFTEN, or DROP.

02-data-path (one page, diagram or tidy doc). The request’s journey: customer action → the SaaS app → the router → eligible providers/models → logging location → response path → human escalation. Every node gets a named owner. If you can’t draw it on one page, the scope is too big: cut it.

03-model-register (sheet). One row per provider/model that CAN serve the feature. Columns: Provider | Model + version | Role (primary, fallback, eval) | Hosting path | Retention statement | Training-use statement | Geographic claim | Evidence link | Date checked | Status: SUPPORTED / CONTRADICTED / UNKNOWN.

04-route-receipt-schema (sheet). The eight fields a log needs to prove what ran: timestamp, feature, router, selected provider, selected model + version, policy version, fallback event (yes/no), internal owner. One column for “captured today?”, one for “decision” (add the field, or narrow the customer claim). The client’s engineer fills the truth column, not you.

05-evidence-index (sheet). One row per source: URL or document name | exact claim it supports | date checked | where your saved copy lives. Screenshot or PDF every policy page the day you cite it. Vendor pages change; your dated copy is the receipt’s receipt.

06-buyer-faq (doc). The 10-15 questions from the client’s actual review, answered in plain language, each answer pointing at an evidence row or an unknown. This is the artifact the buyer actually reads.

07-change-card (one page). The five trigger events: a model is added or removed; routing rules change; a provider changes retention or training terms; a jurisdiction or customer restricts a model; the fallback fires in production. Each trigger: one named owner, one review action, one customer-notice decision (notify / don’t / decide then).

08-unknowns-and-signoff (doc). Every claim the client could not verify, in one honest list, plus the sign-off lines: product lead and engineer confirm the packet is accurate as of the date. Their signoff, not yours: you organized the evidence, they own the facts.

Copy this, then rebuild it for a fake company in a niche you know. It is your pitch attachment and your practice run. Label it HYPOTHETICAL SPECIMEN on every page.

The setup. FieldNote is a fictional 12-person field-service SaaS. New feature: AI summaries of technician notes. Stack: one router; two eligible models (call them Model A, a US-hosted closed model, and Model B, a cheaper open-weight model on a US cloud); logs capture timestamp, feature, cost, and latency.

01 Scope: Feature = note summarizer, production only. Claims list from their site: “your data is never used for training” → PROVE (currently unproven for Model B’s host) and “summaries are generated securely” → SOFTEN (undefined).

02 Data path: Technician saves note → FieldNote backend → router (rules: under 800 words → Model B; over → Model A; Model B down → Model A) → response → stored summary → nightly log. Owner per node; the router config’s owner is the CTO.

03 Register (2 rows):
- Model A: closed provider, API, zero-retention tier per provider policy page (dated copy saved) → SUPPORTED.
- Model B: open-weight model served by a US cloud host; host’s data-use page says inputs “may be logged for abuse monitoring for 30 days”; training-use statement not found → UNKNOWN. That single UNKNOWN is the packet’s most valuable row: it contradicts the site’s “never used for training” claim scope, so the claim gets narrowed or the host gets a written confirmation.

04 Route receipt: timestamp CAPTURED, feature CAPTURED, cost CAPTURED, latency CAPTURED, selected provider NOT CAPTURED, model version NOT CAPTURED, policy version NOT CAPTURED, fallback event NOT CAPTURED. Decision row: engineering adds a returned provider/model field to the log this sprint, or the FAQ says “we cannot yet identify the model per request.”

05 Evidence index: 6 rows (two provider policies, the router docs, the host’s data-use page, the client’s own ToS, the log sample). Each with the date checked and the saved-copy location.

06 Buyer FAQ, the flagship answer:
> Can FieldNote identify which model processed a specific request? Not from the current application log. The router configuration shows two eligible routes, but the selected route is not preserved in the log sample provided. Status: unverified. Owner: engineering. Next decision: preserve the selected provider/model per request, or narrow the claim made to customers.

Ten answers in that shape: specific, sourced, dated, owned, honest about the gap.

07 Change card: the five triggers, CTO owns model add/remove and routing changes, support lead owns customer notices, review date set 90 days out.

08 Unknowns: Model B’s training-use statement; the “securely” claim’s definition. Signed by the (fictional) product lead and CTO.

That is the whole product. Notice what it is not: no credentials, no production data, no legal opinions, no promises. Organized, dated, owned facts, with the gaps lit up.

The policy-mining prompt (run per provider, in any strong model with web access, then verify every line yourself against the live page before it enters the register):

```
You are helping me document the data-handling terms of an AI model provider.
Provider: [name]. Model: [model + version]. Serving path: [API / cloud host].
Find and quote, with the exact URL and the page’s last-updated date if shown:
1. The retention policy for API inputs and outputs.
2. Whether inputs/outputs are used for model training, and any opt-out.
3. Any geographic/data-residency statements for this serving path.
Quote the exact sentences. If a statement does not exist, say NOT FOUND.
Do not summarize, do not infer, do not soften.
```

The FAQ-drafting prompt (after the register is filled):

```
Draft plain-language answers to the following security-review questions about
one AI feature. Use ONLY the facts in the register and route-receipt sheet I
paste below. Rules: every answer cites its evidence row; if the evidence is
UNKNOWN or CONTRADICTED, the answer says so and names the owner; never write
“compliant,” “secure,” “never,” or “guaranteed”; where a claim cannot be made,
write what CAN be said instead. Questions: [paste from the client’s review]
Register: [paste] Route-receipt sheet: [paste]
```

The interview script (the one technical interview, 45-60 minutes):
1. Show me the feature working, as a customer sees it.
2. Walk me through the router config: what routes exist, what rules pick one, what happens when the primary fails.
3. Which providers and models are eligible today? Any others enabled but unused?
4. Show me one log line for one request (blank or dummy data only). Which of the eight receipt fields does it capture?
5. Who approves adding or removing a model? Where is that recorded?
6. What have you already told customers about this feature, anywhere (site, ToS, sales deck)?
7. What’s the one question from the buyer review you dread most?

Legal note. The packet organizes client-approved facts. It is not legal, compliance, security, or audit advice, and it must say so on page one. Two sentences to include verbatim: “This packet documents the model supply chain of one feature as of [date], based on evidence supplied by [client] and public vendor statements. It is not a legal opinion, a security assessment, or a compliance certification.”

Day 0 (today, 5 minutes). Copy the FieldNote specimen. Swap in a fake company from a niche you know. Read the flagship FAQ answer out loud once: that tone is the product.

Day 1. Finish your specimen: all eight artifacts, HYPOTHETICAL SPECIMEN on every page. Build the 20-prospect list: small vertical SaaS companies that (a) announced an AI feature and (b) sell an enterprise plan. Their changelog, their pricing page, and their case-study logos tell you both.

Day 2. Send the outreach note (below) to the founder or product lead of all 20, specimen attached or linked. Cold outreach is commercial email: use your real name and working contact info, a truthful subject line, personalize one-to-one (never bulk-blast), and honor any opt-out immediately. Qualify hard: ask to see the live questionnaire or review email. No live buyer review, no sale; tell them so and keep the list warm.

Day 3-4. First conversations. Price it exactly: $350 pilot, $175 before the interview, $175 at delivery, five business days, fixed scope (one feature, one environment, one router, three models max, one revision). Take the deposit before the interview.

Day 5-9 (the sprint). Day one: interview + freeze scope. Day two: evidence collection and the register. Day three: data path + route-receipt sheet. Day four: FAQ + change card + unknowns. Day five: technical signoff, one revision, deliver editable files plus a sendable PDF.

Day 10. Ask three questions: which buyer questions did the packet answer, which stayed open, how long did the first response take versus the last review? Those answers are your case study, your $700 standard price justification, and your $125 quarterly-refresh pitch.

The outreach note (copy, personalize the first line):
> A routed AI feature can change providers without changing the button your customer clicks. When a buyer asks who handled their data, the answer usually lives across product settings, vendor policies, and an engineer’s memory. I turn one live feature into a source-backed Model Receipt Packet for the review already on your desk. The pilot is $350, fixed scope, five business days. If no customer is asking these questions yet, you shouldn’t buy it. Here’s a hypothetical specimen of exactly what I deliver.

The kill rule. 20 qualified contacts with a live enterprise motion, fewer than 3 conversations, 0 paid pilots: stop. Don’t convert weak demand into free audits. You keep the specimen, the skill, and the register format; they compound elsewhere.

The free kit builds the packet by hand. The Proof Room, this issue’s Pro build, is the compression: the provider register pre-filled for the major model vendors with dated policy evidence, the 40-question buyer-FAQ bank mined from real security questionnaires, the FieldNote packet as editable templates, and the outreach-to-retainer pricing ladder. It gets built out with the founding cohort, alongside the four finished builds already in the Vault.

Pro is $129 a year, founding rate, locked forever, and the rate closes at 25 members. Join founding here. Your license key arrives by email and opens the Vault, all 45 plays and the deeper builds included.

Overyield is educational, not financial, legal, or business advice.