Everything, by category
Start
Your role, end to end
For leadership
Libraries
Play
Elsewhere
SkyWaysThe agentic manual
The lessonSimulatorPlay

The FDE guide · stage 1 of 3

Frame the engagement

Should we do this, and what exactly will we prove?

4 steps11 prompts

  1. Framethe engagementDays. The client's people watch.
    1. P01QualifyIs this engagement worth taking?Discovery brief
    2. P12ScopeWhat will we prove, and who signs?Statement of work
    3. P23ProveDoes it work on their data?Proof-of-concept sheet
    4. P34DecideGo, at what cost, on what conditions?Readout and decision

    Signed the go decision, by the client's sponsor

  2. Deliver
    1. P05Mobilise
    2. P16Sign
    3. P27Build
    4. P38Hand over
  3. Evolve
    1. P09Reframe
    2. P110Codify
    3. P211Reuse
    4. P312Review

Every box opens its step: template, prompts, a worked example. After the review, Frame starts again.

Frame the engagement, in brief
How longDays to three weeks, before a contract or a charter.
The client's peopleWatch, answer, and label a sample. Their sponsor decides.
You think atOne question. The proof is a POC: throwaway code, real cases.
It ends withThe go decision, signed by the client's sponsor.
What goes wrong hereThe demo becomes the success criterion. Nobody owns the risk. Nobody will run it after you.

Four steps to the go decision

1 QualifyP0

Find the pain, the owner and a reason to say no

HatsconsultantproductThe first week of a lead, before anyone promises a proof The template3 prompts

Three things sink an engagement before it starts: no pain anyone can measure, nobody who can accept the risk, and nobody to run the system after you leave. Each can be found in days, from their data and their people, before a proof makes the work feel agreed. The brief this step writes is allowed to say no, and it is worth most on the day it does.

What you actually do
  1. Get the ask in their words, then the last time it hurtThe ask is usually a solution: an AI assistant. Ask who was waiting, and for how long, the last time it went badly; then what has been tried before, and what another team is trying now. Write the answers down in their words. Scale says its best forward-deployed product managers can tell the difference between a customer's stated request, their actual problem, and what the platform should do1.
  2. Measure it from one exportA week of tickets gives the volume, the hard cases' share and the wait. That is enough to qualify and not enough to size, so the brief says which, and no number from it goes into a contract.
  3. Ask the three AI-fit questionsA genuine judgement call, the volume to carry evaluation, and, action by action, whether a wrong answer can be undone: the product manager's step 2. A rule in disguise is a cheaper engagement, or none.
  4. Map five people, by nameThe sponsor who pays, the risk owner who signs the risk, the person who will run it after you, the expert whose staff label the cases, and the sceptic who can stop it. Ask the experts what changes by shift or by kind of case: the rules nobody wrote down live there. Meet the sceptic early: their objection is your best success criterion.
  5. Check the three disqualifiersNo path for their data to a model inside their policy and region. No one who can sign the risk. No one to run it after you. One left open is a no, or a not yet with the condition that clears it.
  6. Write the verdict, and what would change itGo to scoping, not yet, or no, in one sentence with its evidence. Stopping at discovery is not a failure when the evidence says stop2, and a written no keeps the door open for a later yes.
If your client is inside your own company

Inside your company the sponsor is often your manager's peer. The disqualifiers are the same, and saying no is harder, so write them down before the meeting. Send them to your own manager first, so the no belongs to the team and not to you alone.

Say it like this
  • When the first meeting opens on the solutionWe will get to the assistant. First, walk me through the last disruption that went badly: who was waiting, and for how long?
  • When three of the five people have no nameWe can start when three people are named: who signs the risk, who runs it after we leave, and whose experts label the cases.
  • When the answer is no, or not yetI would not build this yet. Here is what would change my mind, and who can make it happen.
Where a model helps, and where it must not
ToolUse it for
Chat modelGive it the request and the account team's notes, and ask for the first meeting's questions, ordered by which answer could end the engagement.Strike every question that assumes the assistant exists. It asks about the solution, because the request was about the solution.
Claude Code or CodexHave it count the export: cases a day, the hard cases' share, the wait, with the script shown before the numbers.Only on an export their policy lets you take out. Read the date column and the filter: a count over the wrong column is confidently wrong.
Chat model, against youAsk for the strongest case against taking the engagement, from your own notes. It is the cheapest review the verdict will get.
Do not delegateThe names, and the verdict. Whether a person can accept the risk, or will run the system, you learn by asking them; a model reading an org chart guesses.
The artefact
Produces
Discovery brief
Good looks like
Two pages at most: the ask in their words, the pain with its source, three AI-fit answers, five people each named or marked unknown with who was asked, the three disqualifiers, and a verdict with what would change it.
Owner
Forward-deployed engineer, with the account or engagement lead
The template
Discovery brieffill in the angle brackets 
# Discovery brief · <customer> · <the ask, in five words>
_<date> · Drafted by <FDE> · For <engagement lead> · Verdict: go to scoping / not yet / no_

## 1. The ask, in their words
> "<the request, verbatim>" (<who said it>, <date>)

The last time it hurt: <the incident, dated, told by someone who was there>

## 2. The pain, measured
| Who has it | How often | Cost today | Evidence | Window |
|------------|-----------|------------|----------|--------|
| <role> | <n a day> | <minutes, or $ per case> | <export, system, owner> | <dates> |

Enough to qualify, not to size. No number here goes into a contract.

## 3. Is it AI at all?
| Question | Answer | Why |
|----------|--------|-----|
| A genuine judgement call? | yes / no | <two competent people could differ about ...> |
| Volume to carry evaluation and gates? | yes / no | <n a day> |
| Can a wrong answer be undone? | yes / no / partly | <the actions that cannot> |

## 4. Five people
| Part | Name, role | Wants | Fears | Can stop it? |
|------|------------|-------|-------|--------------|
| Sponsor: pays, decides go | | | | |
| Risk owner: signs the risk | | | | |
| The person who will run it | | | | |
| Expert: their staff label the cases | | | | |
| Sceptic: can stop it | | | | |

A blank is a finding. Write down who you asked.

## 5. The three disqualifiers
| Disqualifier | Open or cleared | Evidence | What clears it |
|--------------|-----------------|----------|----------------|
| No path for their data to a model, inside their policy and region | | | |
| No one who can sign the risk | | | |
| No one to run it after you | | | |

## 6. Verdict
**Go to scoping / not yet / no**, because <one sentence>.
Conditions: <condition> · <owner> · <date>
What would change the answer: <the evidence, and who holds it>
Prompts you can paste
Turn the request into the first meeting's questionsBefore the first meeting, with whatever the account team sent you 
A customer has asked for: "<the request, verbatim>".
What we know so far: <paste the account team's notes>

Write the questions for a first 45-minute meeting with <who will be there>.

RULES:
- No question may assume the solution. Ask about the work and the pain, never the assistant.
- Ask for the last time it went badly: who was waiting, for how long, what it cost.
- Find five people: who pays, who signs the risk, who will run it after us, whose experts
  can label cases, who could stop it. Ask for names; a title is not an answer.
- Ask what data exists, who owns it, and where it is allowed to go.
- Order the questions by which answer could end the engagement. Those come first.

OUTPUT: the questions in order, each with one line on why it is there.
Draw the stakeholder map from your notes, and mark what you do not knowAfter the first two meetings 
Below are my notes from <n> meetings at <customer>.

Fill in this map:
| Part | Name and role | Wants | Fears | Can stop it? | Where in my notes |

The five parts: sponsor (pays, decides go) · risk owner (signs the risk) · the person who
will run it after us · expert (whose staff label the cases) · sceptic (can stop it).

RULES:
- Never infer a name from a title. If my notes name nobody, write UNKNOWN.
- Wants and fears only from what was said or done, with the line it came from.
- If one person holds two parts, say so: that is a risk, not a saving.
- After the table, list every UNKNOWN with the question that fills it and who to ask.

NOTES:
<paste>
Make the case against taking this engagementBefore you write the verdict 
Here is my draft discovery brief: <paste>.

Make the strongest case that we should say no, or not yet. Use only the brief's own
evidence, and test it against three disqualifiers:
1. no path for their data to a model, inside their policy and region;
2. no one who can sign the risk of the actions the system would take;
3. no one to run it after we leave.

Then the AI-fit questions: is it a genuine judgement call, is the volume enough to carry
evaluation and gates, can a wrong answer be undone?

End with the one piece of evidence that would settle go or no, and who holds it.
Do not soften the case to be polite.
Worked example

SkyWays · three weeks before day 1

The ask was make rebooking smarter. One week's export held 1,640 disruption tickets: about 234 a day, roughly one in ten codeshare, an average wait near 40 minutes. Enough to qualify, not to size: the project's own measurement in its first days made it 240 a day, 11% and 38 minutes. AI fit: yes, yes and partly, because a proposed rebooking can be withdrawn and a cash refund cannot. Three of the five were named that week: Ines as sponsor, the contact-centre head over the experts, Lena as the person who would run it. The risk owner was not, so the verdict read go to scoping, once compliance names a person for refunds. Nobody could name a sceptic either; the build found one, a senior expert who distrusted the assistant and then labelled the cases it was tested on. One gap went unseen. Every expert in the brief worked the day shift, and the evening shift's rule about one partner after 18:00 stayed in six people's heads until the shadow run found it (step 7).

Pitfalls
  • Qualifying on the sponsor's enthusiasm. A sponsor who wants it and a risk owner nobody has met is how a proof ends as a demo and a contract ends in week six.
  • Putting the qualifying number in the contract. One week's export says yes to scoping; quoted as the business case, it becomes a promise the real measurement breaks.
  • Saying yes to protect the relationship. A no with its reason, and the condition that would change it, keeps the relationship; a proof that was never going to pass ends it.
Done when

A colleague who was not in the meetings can read the brief and say whether to take the work, and what would change the answer.

2 ScopeP1

Write the statement of work a sceptic would sign

HatsconsultantproductFrame, after the discovery brief and before the proof starts The template3 prompts

A statement of work is the engagement's spec. It says what you will prove and deliver, by when, what the customer must supply, and which decisions stay theirs. Write it so that a sceptic in their procurement team and another in your own could each sign it without asking what a line means. Every vague line becomes an argument in week six, and every dependency you leave out becomes your delay. Anthropic's Technical Deployment Leads structure one with clear scope, milestones, dependencies, success criteria, and value hypotheses3; the template below adds the decisions that stay theirs, and change control.

What you actually do
  1. Name the first slice, and say why it comes firstOne kind of case, chosen for proof: high volume, low damage per mistake, and an existing process to compare against. Write the reason beside it, so the slice is not argued again in every meeting.
  2. Write success as numbers, each with an owner on their sideA measure, the cases it is measured on, the threshold, the person who measures it and the date. Faster rebooking is not a criterion. The desk agrees with the first option on 80% of standard cases, as a lower bound on 500 of their past cases is.
  3. List what is out, and what is not yetOut stays out. Not yet has the condition that brings it in, such as a limit compliance has not signed. Both lists stop the same request arriving every week.
  4. Write their dependencies with names and datesData access, model access in the region their data must stay in, the security review, the hours their experts will spend labelling, the person who signs risk. Their delays are your delays, so the statement says what happens to the plan when one slips.
  5. Write down which decisions stay theirsThe autonomy of each action, every limit and who approves above it, the pass mark for each kind of case, go-live, and who runs it afterwards. You draft them; they sign them. Writing it now makes it normal later.
  6. Say who keeps what is built, and how long you stay after handoverThe code, the pattern you may take home and their data each get an owner, and the clause that says so. The support period gets its weeks and the date your access ends. The handover (step 8) and the pattern write-up (step 10) both read these lines.
  7. Put the proof in, with its own way to failIts one question, its days, and its endings: go, go with conditions, change course, or stop. A proof that cannot end in stop is a demo, and their sceptic will know it.
  8. Agree how a new ask gets inChange control in one paragraph: who may ask, who sizes it in days, who signs. Without it, every yes you give in a corridor is a promise the plan cannot keep.
If your client is inside your own company

Inside your own company the statement of work is a charter, and it is no softer. The business unit's head signs it, and the hours their experts give are written down as a commitment. The person who will run the system after you is named before you start. With no invoice to enforce it, the charter is the only thing that makes their side's work real.

Say it like this
  • A feature that does not fit the first sliceThat is a good second slice. It goes on the not-yet list with the condition that brings it in, so it is not lost and it does not slow the first.
  • A date the scope cannot meetWe can meet that date with the first slice, or this scope by the end of the month. Which matters more to you?
  • A decision that is theirsI will draft the refund limit with the numbers beside it. Your compliance officer signs it, because it is your risk.
Where a model helps, and where it must not
ToolUse it for
Chat model, as their procurementPaste the redacted draft and have it read the statement twice, as their head of procurement and as their security lead, listing every line each would refuse to sign and the wording each would accept.Paste only what their contract and your policy allow. A customer's confidential terms do not go into a tool nobody approved.
Chat model, as your delivery leadGive it the phases and the work in each, and ask for every dependency on the customer the plan assumes and does not name, longest lead time first.
Do not delegateThe numbers in the success criteria, and the list of decisions that stay theirs. A model writes criteria that sound measurable and are not, and it cannot know which risks this customer may hand to you.
The artefact
Produces
Statement of work (inside your own company, an engagement charter)
Good looks like
Two pages. A first slice with its reason, success criteria a stranger could measure, their dependencies with names and dates, the decisions that stay theirs, who keeps what is built, the support period after handover, the proof with its way to fail, and one paragraph of change control. Signed by their sponsor and by yours.
Owner
Forward-deployed engineer, with the engagement lead where there is one
The template
Statement of workfill in the angle brackets 
# Statement of work · <customer> · <engagement>
_Version <n> · <date> · Drafted by <FDE> · For signature by <their sponsor> and <your lead>_
Issued under <the master agreement or order form>, which holds the commercial terms.

## 1. The problem, measured
<who has the pain> · <how often> · <what it costs today> · <the evidence, with its source>

## 2. The first slice
**In:** <one kind of case>
**Why first:** <n> a day · <what one mistake costs> · compared against <their current process>

## 3. Value hypothesis
| Measure | Today | Target | Measured by | Baseline from |
|---------|-------|--------|-------------|---------------|
| <handling time per case> | <n min> | <n min> | <their ops lead> | <export, date> |

## 4. Success criteria
| # | Criterion | Cases it is measured on | Who measures | By |
|---|-----------|-------------------------|--------------|----|
| 1 | <lower bound of agreement with their desk, per slice, at or above the pass mark> | <n of their past cases, labelled by their experts> | <name> | <date> |

## 5. Phases
| Phase | The one question | Ends with | Date |
|-------|------------------|-----------|------|
| Proof, <n> days | <can it ...?> | go · go with conditions · change course · stop | <date> |
| First slice, in shadow | <does it agree with their staff?> | shadow report | <date> |
| Cut-over and handover | <does it run without us?> | handover signed by the person who will run it | <date> |

## 6. What we need from you
| Dependency | Owner on your side | Needed by | How we know it works | If it is late |
|------------|--------------------|-----------|----------------------|---------------|
| Read access to <system> | <name> | <date> | <one record read, logged> | the plan moves by the same days |
| Model access in <the region your data must stay in> | <name> | <date> | <one call from that region, logged> | |
| Security review | <name> | <date> | <the signed review> | |
| <n> hours of expert labelling | <name> | <date> | <the first 50 cases labelled> | |
| A named owner for each consequential action | <name> | <date> | <a signature in section 7> | nothing is built past it |

A dependency is met when its test passes, not when someone says it is done.

## 7. Decisions that stay yours
| Decision | We draft it | You sign it | Signed by |
|----------|-------------|-------------|-----------|
| Autonomy of each action | yes | yes | <name> |
| Every limit, and who approves above it | yes | yes | <name> |
| The pass mark for each kind of case | yes | yes | <name> |
| Go-live, and each widening | no | yes | <name> |
| Who runs it after handover | no | yes | <name> |

Every limit you sign is enforced in the tool that acts, with a test, never only in the
instructions the model reads.

## 8. What each side keeps
| What | Owned by | Where it says so |
|------|----------|------------------|
| The code and configuration built here | <customer> / <us> / shared | <master agreement, clause> |
| The pattern, written up without your data, code or terms | <us> | this statement |
| Your data, and the cases your experts label | <customer> | <data agreement, clause> |

Your data stays in <region>. It leaves only with <name>'s approval, in writing.

## 9. After handover
<FDE> is on call to <the person who will run it>, for questions, not for the system,
for <n> weeks after the handover, until <date>. Our access ends on <date>.

## 10. Out, and not yet
- **Out:** <...>
- **Not yet:** <...>, which comes in when <condition>

## 11. Change control
A new request is written down, sized in days by <FDE>, and signed by <their sponsor> before
work starts. A request that changes a decision in section 7 goes back to whoever signed it.

## 12. Signatures
| For <customer> | For <us> |
|----------------|----------|
| <name, role, date> | <name, role, date> |
Prompts you can paste
Red-team the statement as their procurement and their security leadBefore the draft leaves your hands 
Below is a draft statement of work for an AI deployment at <customer>.

Read it twice: first as their head of procurement, then as their chief information
security officer.

For each reading, give a table:
| Section | The line | Why you would refuse to sign it | The wording you would accept |

Then list, separately:
- every success criterion a stranger could not measure from the text alone;
- every dependency on the customer the plan assumes and does not name;
- every decision the vendor appears to make that the customer should sign.

Do not rewrite the statement. Do not soften a finding to be polite.

DRAFT (names, prices and confidential terms removed):
<paste>
Turn the outcomes they described into criteria someone can measureYou have adjectives and need numbers 
The customer described what success looks like, in their words:
<paste their words>

For each outcome, write a success criterion with five parts:
1. the measure: a count, a rate or a time;
2. the cases it is measured on: which, how many, labelled by whom;
3. the threshold, and whether it applies to the score or to its lower bound;
4. the person on the customer's side who measures it;
5. the date.

If an outcome cannot be measured inside this engagement, say so, and propose the nearest
measure that can. Mark every number you had to assume as ASSUMED. Never invent a baseline.
Find the dependencies the plan hidesBefore the dependency table is final 
Here is our delivery plan for <customer>: <paste the phases and the work in each>.

List everything this plan needs from the customer that it does not name: access, data,
people's time, approvals, environments and decisions. For each, give:
| What we need | Who on their side usually owns it | The latest week we can have it without moving the plan | What we do if it is late |

Order the list by how long each usually takes to obtain, longest first. Data access, model
access in the region their data must stay in, and the security review usually lead.
Worked example

SkyWays · two weeks before day 1

The sponsor, Ines, asked the vendor to make rebooking smarter. The statement she signed, before the proof began, was two pages. The first slice was rebooking options for the 89% of disruption cases that are not codeshare. A wrong option there costs a passenger a worse flight, not money, and the desk's own choices give a baseline. Codeshare became its own slice with its own pass mark. Refunds went on the not-yet list, drafted for a person to approve until compliance signed a limit; on day 6 it signed the first decision in section 7, a named approver for every refund over $400. Section 8 left the code with SkyWays and the pattern with the vendor, and section 9 put you on call to Lena for a fortnight after handover. The line that mattered most was in section 6: model access in the region the passengers' data must stay in, by day 5. It was met on paper. Access came in week one in the wrong region, nobody made one call to check it until day 13, and six days went (step 5).

Pitfalls
  • A success criterion with an adjective in it. Accurate and fast are signed happily in week one and argued about in week six.
  • Leaving the customer's dependencies out to keep the statement short. The plan then rests on things nobody promised, and the delay lands on you.
  • Taking a decision that is theirs because it unblocks you today. A limit you chose becomes your risk on the day it is wrong.
  • A proof that can only end in go. If it cannot fail, it is a demo, and their sceptic will say so.
Done when

Their procurement lead and your delivery lead can each read it cold and name the first slice, the go date, what they supply by when, and which decisions are theirs.

3 ProveP2

Prove it on their cases in days, and write what it does not prove

HatsengineerQAAltitude: POCFrame, in the days after the statement is signed, and never for weeks The template3 prompts

A proof answers one question on their data. It is not a small product, and its code is not the first commit of one. Measure on their real cases with the sample size beside every number, and write down what it does not prove: that list is what their sceptic reads, and it is what stops a good score being taken for a decision to build.

What you actually do
  1. Write the question in one sentenceCan it rank the desk's own choice first, on their past cases? One question a number can answer, and beside it, before a case is scored, the result that would mean stop. A question with and in it is two proofs, and in days you finish neither.
  2. Take a real sample, with the hard slice in itA couple of hundred recent cases from their export, redacted under their policy, the hard slice at its real share or more. Never invented cases: nobody invents the mess they have not read.
  3. Have two of their experts label it, blindEach alone, with no answer from the system on screen, because an expert who can see an answer agrees with it. Where the two agree is the ceiling: no score above it means anything.
  4. Build the thinnest thing, in a sandboxIn GOV.UK's words for a prototype, just complex enough to let you test different ideas, not production quality code4. A coding agent writes most of it; log the tokens and seconds of every case, because the readout's cost line comes from them. Read the scorer line by line: one that counts an abstention as right is how a proof lies.
  5. Put their people at the keyboardPalantir's bootcamp is the public model: an interactive workshop where customers go from 0 to use case in 5 days5. An afternoon of their staff working their own cases tells you more about adoption than the score does.
  6. Measure by slice, with the lower boundScore, cases and lower bound on one row per slice, Wilson under a hundred cases, as the QA lead measures. A slice of twenty cases proves nothing, and the sheet says so.
  7. Read twenty failures, then write what it does not proveGroup the failures by cause: missing data, a rule nobody wrote down, a call the experts split on. Then the list: volume, latency, cost, their live systems, any action, the slices it never saw.
If your client is inside your own company

Inside your company the proof is skipped because people trust each other. Run it anyway: it is the only evidence the business unit's head will have before they commit their experts' hours.

Say it like this
  • When the proof is agreedThis proof answers one question: can it rank the desk's own choice first, on your past cases. It does not tell you whether it is safe to let it act.
  • When they ask for one more thing in the proofThat belongs in the build. If I add it here, the proof stops answering anything in days.
  • When a slice is too small to readTwenty-two cases cannot tell us whether codeshare works. They tell us it needs its own cases before anyone judges it.
Where a model helps, and where it must not
ToolUse it for
Claude Code or CodexLet it write the loader, the redaction and the scoring by slice from your one-sentence question. Throwaway code against a fixed question is what these tools do best.Read the scorer line by line. It counts a partial match or an abstention as right unless told not to, and that one line is the whole proof.
Chat modelGive it the twenty failures with the experts' labels, and ask for groups by cause, each with its cases' ids.It groups by wording. Re-read each group asking what would fix it: two different fixes means two groups.
Chat model, as their scepticPaste the finished sheet and ask what a sceptic would conclude that the proof does not support. Each answer goes into section 5.
Do not delegateThe labels. A model that labels its own test cases measures its agreement with itself, and the number looks exactly like a proof.
The artefact
Produces
Proof-of-concept sheet
Good looks like
One page their sceptic can check: the question, the sample and who labelled it, the experts' ceiling, results by slice with lower bounds, twenty failures by cause, what it does not prove, and the date the code is deleted.
Owner
Forward-deployed engineer, with their experts' lead
The template
Proof-of-concept sheetfill in the angle brackets 
# Proof-of-concept sheet · <customer> · <the question, in five words>
_<dates> · Built by <FDE> · Sent to <their sceptic> before the readout_

## 1. The question
Can <the system> <do what> on <their cases>, as well as <their staff>?
One question. A question with "and" in it is two proofs.

## 2. The sample
| Source | Window | Cases | Redacted by | Labelled by | Blind? |
|--------|--------|-------|-------------|-------------|--------|
| <export> | <dates> | <n> | <who> | <two experts, by role> | yes |

The mix: <slice> <n> (<share>) · <slice> <n> (<share>)
The ceiling: the experts agreed on <n> of <n> (<%>). No score above it means anything.

## 3. Results, by slice
| Slice | Right | Of | Score | Lower bound |
|-------|-------|----|-------|-------------|
| All | | | | |
| <standard> | | | | |
| <the hard slice> | | | | <low> to <high>, Wilson |

Lower bound = p − 1.96 × √(p(1 − p) ÷ n). Under 100 cases, Wilson.

## 4. Twenty failures, read by hand
| Group | Cases | One example | Cause | Fixable in the build? |
|-------|-------|-------------|-------|-----------------------|
| | | | | |

## 5. What this does not prove
- Latency and cost at <n> cases a day, in the peak hour
- Their live systems: it read an export, not <system>
- Model access in <the region their data must stay in>: the sandbox ran in <where>
- Security, and their data policy beyond the sandbox
- Any action: it proposed, it never <acted>
- Slices not in the sample: <list>

## 6. What happens to it
Code: deleted from <sandbox> on <date>.
Labelled cases: handed to <their QA lead> on <date>, under <their policy>.
Prompts you can paste
Check my sample against their real mixBefore anyone labels a case 
Here is a sample drawn for a proof of concept, and the export it came from.
SAMPLE: <counts by slice, weekday, hour and type>
EXPORT: <the same counts for the whole export>

Report:
| Dimension | Export share | Sample share | Gap | Does it matter? |

Then list:
- every slice under 30 cases, with the width of its 95% interval at a likely score
  and how many cases it would need to be judged at all;
- anything the export holds that the sample lacks entirely (a type, an hour, a season);
- whether the window is recent enough to reflect how the work is done today.

Do not redraw the sample. Tell me what is wrong with it.
List what this proof does not proveBefore the sheet goes to their sceptic 
This proof answered one question: <the question>.
Setup: <the sample, the sandbox, what the system could see and do, what it never did>.
Results: <the table, by slice>.

List every conclusion a reader might draw that this proof does NOT support. Cover at
least: volume and peak latency, cost at their volume, their live systems, security and
data handling, any action the system would take, slices not in the sample, and whether
the experts' own agreement caps the score.

| The tempting conclusion | Why the proof cannot support it | What would, and when |

Write it for a sceptic: plain words, no reassurance.
Group twenty failures by causeAfter scoring, before the readout 
Below are 20 cases the system got wrong, each with the case, the experts' label,
the system's answer and its reasoning.
<paste>

Group them by CAUSE, not by symptom: missing data, a rule nobody wrote down, a call the
experts themselves split on, retrieval that found the wrong record, an instruction the
system ignored.

| Cause | Cases (ids) | One example, in a line | Fixable in the build, or inherent? |

RULES: a case goes in one group only. If a group would need two different fixes, it is
two groups. Finish with the cause you would fix first, and why.
Worked example

SkyWays · twelve to eight days before day 1

200 past cases from the Q2 export, redacted, 22 of them codeshare. Two frontline agents labelled them. The first fifty were labelled with the assistant's answer on screen, so they were set aside and fifty fresh cases drawn: an expert who has seen an answer remembers it. Blind, the two agreed on 184 (92%), the ceiling, and the contact-centre head settled the other 16. The assistant's first option matched the label on 151 (75.5%, lower bound 69.5%); on standard cases, 142 of 178 (79.8%, lower bound 73.9%); on codeshare, 9 of 22, somewhere between 23% and 61%. The most useful number was the widest: twenty-two cases could say only that codeshare needed many more of its own before anyone judged it.

Work it out on your numbers
Has the bar actually been proven?the lower bound decides, never the score
Normal approximation:
Wilson:
Lower bound in force:
Not proven.
lower bound = p − 1.96√(p(1−p)/n) · Wilson under n=100
Pitfalls
  • A proof built like a product, or kept like one. Hardening eats the days the question had, and later someone copies its logic into the build because it worked: a path nobody designed is in production.
  • Invented cases. Nobody invents the mess they have not read, so the hard slice is missing and the score is high for the wrong reason.
  • One number for the whole sample. The easy cases carry the average, and the slice that holds the risk stays invisible until it is live.
Done when

Their sceptic can read the sheet cold and agree with its one number, its ceiling and its list of what it does not prove.

4 DecideP3

Read the proof out with the failures first, and let them decide

HatsconsultantThe end of Frame, within a week of the proof The template2 prompts

A proof is worth what it changes. The readout turns it into a decision the client makes, on evidence, with the bad news first and the cost beside the saving. Lead with what failed and you keep the right to recommend; bury it and their sceptic finds it after the signature. The meeting ends in go, go with conditions, change course or stop, signed and dated, and never in keep going.

What you actually do
  1. Send the sheet to their sceptic before the meetingTwo days before, and walk their sponsor through the failures one to one. Bad news told early costs nothing; told first in the room, it costs the trust the decision needs.
  2. Open with what failed, by sliceScore, cases and lower bound, the worst slice first. A room that hears the overall number first anchors on it, and reads the failing slice as a footnote.
  3. Cost it at their volume, review load includedTokens per case, the share a person checks and the minutes each check takes, at their cases a day, as the product manager's value line does. The review load is the term most readouts leave out.
  4. Name the lead-time items, with datesData access, model access in the region their data must stay in, the security review, the experts' hours. They set the build's calendar, so their owners hear them now.
  5. Recommend one of four, in one sentenceGo, go with conditions, change course, or stop. Each condition gets an owner, a date and what happens if it is missed, or it is a hope written down.
  6. Get it signed, and hand it onThe signed record is Deliver's first page: first slice, pass mark, milestones. At a larger vendor it passes between two people: Anthropic's pre-sales lead works beside a Post-Sale Program Lead counterpart who owns delivery from signature onward6.
  7. Delete the code, and keep the casesThe proof's code goes, as GOV.UK expects of a prototype4. Its labelled cases go first, under their policy, to whoever will own the golden set, who confirms receipt before the sandbox is wiped: nobody labels the same cases twice.
If your client is inside your own company

Inside your company the readout is where a project quietly becomes permanent. Ask for a decision with a date, never for keep going. A business unit that says go is also giving its experts' hours, so write them into the decision.

Say it like this
  • Opening the readoutHere is what did not work, first. Then what it costs at your volume, then what I recommend.
  • The recommendationMy recommendation is go, with two conditions. Each has an owner and a date, and if one is missed, the decision comes back to this room.
  • When the room wants to keep going without decidingI can hold the team for this until Friday. By then I need go, go with conditions, change course or stop, so that we can both plan.
Where a model helps, and where it must not
ToolUse it for
Chat modelDraft the readout from the proof sheet in the fixed order, failures first, so the first draft already says the hard thing first.It softens. Delete every promising and encouraging, and put the number back where the adjective was.
Claude Code or CodexBuild the cost line as a small sheet, every assumption in a named cell, so their finance lead can change one and watch the net move.
Do not delegateThe recommendation, and the sentence that says what would make it stop. A model recommends go, because everything in front of it is about going.
The artefact
Produces
Readout and decision record
Good looks like
One page read aloud and one page signed: the failures by slice, the cost at their volume, the lead-time items, one recommendation, each condition with an owner and a date, and the decision, dated. Deliver's plan starts from it.
Owner
Forward-deployed engineer; the decision is the client's sponsor's
The template
Readout and decisionfill in the angle brackets 
# Readout and decision · <customer> · <the proof's question>
_<date> · Presented by <FDE> · Decided by <their sponsor> · Sheet sent to <their sceptic> on <date>_

## 1. What failed, first
| Slice | Score | Of | Lower bound | Pass mark | Why it failed |
|-------|-------|----|-------------|-----------|---------------|
| | | | | | |

## 2. What worked
| Slice | Score | Of | Lower bound | Pass mark |
|-------|-------|----|-------------|-----------|
| | | | | |

## 3. What it does not prove
<copied from the proof sheet, word for word>

## 4. What it costs at your volume
| Term | Per case | Per day at <n> cases | Assumption, and its source |
|------|----------|----------------------|----------------------------|
| Saving | | | <minutes saved × cost per minute> |
| Tokens | | | <from the proof's own runs> |
| Review load | | | <share checked × minutes per check> |
| **Net** | | | |

## 5. What takes longest to get
| Item | Owner on your side | Needed by | If it is late |
|------|--------------------|-----------|---------------|
| | | | |

## 6. Four options
| Option | What it means here | The evidence for it |
|--------|--------------------|---------------------|
| Go | | |
| Go with conditions | | |
| Change course | | |
| Stop | | |

**Recommendation:** <option>, because <one sentence>.

## 7. Conditions
| # | Condition | Owner | By | If it is not met |
|---|-----------|-------|----|------------------|
| 1 | | | | |

## 8. Decision
<go / go with conditions / change course / stop> · <name, role> · <date>

## 9. What the build starts with
First slice: <...> · Pass mark: <lower bound at or above <n>% on <n> cases> · First milestone: <...>
The proof's code: deleted on <date> · Its labelled cases: with <name> since <date>
Prompts you can paste
Draft the readout, failures firstThe day the proof sheet is final 
Draft the readout of a proof of concept for <customer>'s sponsor.
The proof sheet: <paste>

ORDER, and do not change it:
1. What failed, by slice, each with its score, its n and its lower bound.
2. What worked, the same way.
3. What the proof does not prove, copied from the sheet.
4. What it costs at their volume, every assumption named.
5. The items with the longest lead time, each with an owner and a date.
6. Four options (go, go with conditions, change course, stop), each with its evidence.
7. One recommendation, and its conditions, each with an owner and a date.

RULES:
- Never open with the overall score.
- No adjective without a number, and no number without its n.
- Mark every figure you assumed rather than read as ASSUMED.
- One page. If it runs over, cut adjectives, never failures.
Cost it at their volume, with every assumption namedBefore the readout, with the proof's own numbers 
Work out what this system is worth at <customer>'s volume.

Inputs, each with its source:
- cases a day: <n> (<source>)
- minutes saved per case: <n> (<source>)
- loaded cost per minute: $<n> (<source>)
- token cost per case: $<n> (from the proof's own runs)
- share of cases a person checks: <n>% · minutes per check: <n>

Show the gross saving, the token cost, the review load and the net, each per day and per
year, with the arithmetic. Then name the ONE input that, moved by a plausible amount,
turns the net negative, and by how much it would have to move.

Mark any input I did not give you as ASSUMED. Never invent a baseline.
Worked example

SkyWays · three days before day 1

The readout opened on what failed: codeshare, 9 of 22 and somewhere between 23% and 61%, and standard cases whose lower bound, 73.9%, sat under the statement's 80%. Then the cost at their volume and the lead-time items, model access in the passengers' region first. The recommendation was go with two conditions: no launch on a score, so if the lower bound on 500 of their cases fell short the shadow would run first; and the experts' hours to label those 500, committed by the contact-centre head. Ines signed both. On day 45 the first condition applied: 82.4% on the 500, but a lower bound of 79.1%, under the statement's 80%, so the shadow started instead of the launch. One thing was lost. The proof's 200 labelled cases went with its sandbox, so the project's first evaluation was seeded with twelve cases written by hand on a Friday, none of them codeshare, and its 94% was believed for a fortnight.

Work it out on your numbers
What the work is worth, netthe two terms teams leave out are already in here
Gross saving:
Token cost:
Review load:
Net:
Per working year:
Positive, with review under control.
net = cases × minutes × rate − run − review
Pitfalls
  • Opening on the overall score. The room anchors on it, and the slice that fails becomes a footnote it reads after saying yes.
  • Accepting keep going. Nobody said yes, so nobody can say stop, and the proof becomes the product by default.
  • Conditions without owners. A condition nobody owns is met by luck, and the first person to notice it was missed is in production.
  • Deleting the cases with the code. The code should go; the labelled cases are the golden set's first rows, and nobody will label them twice.
Done when

The decision is signed and dated, every condition has an owner and a date, and the build's first plan can be written from the record without asking what anything meant.

Where every claim on this page comes from

Every claim about the profession is a posting, a page or an article, with the date it was checked. A date turns amber once it is more than sixty days old.

  1. Scale AI, Forward Deployed Product Manager, Enterprise · job-boards.greenhouse.io ·
  2. GOV.UK, Service Manual: how the discovery phase works (updated 21 June 2021) · gov.uk ·
  3. Anthropic, Technical Deployment Lead · job-boards.greenhouse.io ·
  4. GOV.UK, Service Manual: how the alpha phase works (updated 8 May 2019) · gov.uk ·
  5. Palantir, AIP Bootcamp · palantir.com ·
  6. Anthropic, Pre-Sales Program Lead, Forward Deployed Engineering · job-boards.greenhouse.io ·

The go decision is signed. On day one the work moves into their building.

Deliver the system