Grow the spec

This lab is played with script. Here it is as a document: each step, the prompt the book uses, the recorded reply, and what to notice in it.

On the desk: PRD-lite · Rebooking assistant

# PRD-lite · Rebooking assistant
Owner: Priya (product) · Draft 2

## Problem
Disrupted passengers wait an average of 38 minutes for a rebooking decision. 240 cases a day; 11% are codeshare. Measured cost: $9.40 a case (Q2 ticket export).

## What we want
An assistant that offers a stranded passenger a new flight and makes the change when they accept, so that agents handle only the hard cases.

## Who it is for
Passengers whose flight is cancelled, or delayed past a connection. Contact-centre agents, who take over when the assistant cannot finish.

## What it should do
- Find alternative flights quickly and offer the best ones.
- Rebook same-day changes on our own flights.
- Handle partner (codeshare) flights where possible.
- Offer a refund when no sensible flight exists, up to a reasonable limit.
- Hand over to an agent when it is unsure.

## What good looks like
Passengers get an answer much faster than today. Most cases need no agent. Mistakes are rare.

## Out of scope
Compensation claims. Group bookings.

## Open
Finance wants a cap on refunds. Compliance has not replied about what must be logged.

On the desk: The criteria, as the sponsor's slide has them

The assistant should offer alternative flights quickly, ideally within about 30 seconds, and should rebook same-day changes when the passenger accepts. For partner flights it should, where possible, give the contact centre a chance to stop the change before it goes through. Refunds may be offered if no flight works, though anything over $400 needs sign-off. If it is unsure it should hand over to an agent as appropriate.

Priya's page

Priya, the product manager, has written one page for an assistant that rebooks stranded passengers. It is on the desk. It is clear, it is short, and a build could not start from it: nothing in it says what the assistant may do alone, how right it must be, or what happens when it cannot decide.

This lab turns the page into a spec. Every prompt you assemble is run for real and the reply is a recording. Your job is to notice where a model, left to itself, makes a decision that belongs to a person.

Ask for the next document

Everyone agrees the page is not enough. The choice is what you ask a model to do about it.

The prompt:

Below is a one-page PRD-lite for a rebooking assistant at an airline. Do not write the PRD yet. List the questions this page does not answer and a build could not start without. Most blocking first, eight at most, one line each. After each question, name the role that usually owns the answer.

# PRD-lite · Rebooking assistant
Owner: Priya (product) · Draft 2

## Problem
Disrupted passengers wait an average of 38 minutes for a rebooking decision. 240 cases a day; 11% are codeshare. Measured cost: $9.40 a case (Q2 ticket export).

## What we want
An assistant that offers a stranded passenger a new flight and makes the change when they accept, so that agents handle only the hard cases.

## Who it is for
Passengers whose flight is cancelled, or delayed past a connection. Contact-centre agents, who take over when the assistant cannot finish.

## What it should do
- Find alternative flights quickly and offer the best ones.
- Rebook same-day changes on our own flights.
- Handle partner (codeshare) flights where possible.
- Offer a refund when no sensible flight exists, up to a reasonable limit.
- Hand over to an agent when it is unsure.

## What good looks like
Passengers get an answer much faster than today. Most cases need no agent. Mistakes are rare.

## Out of scope
Compensation claims. Group bookings.

## Open
Finance wants a cap on refunds. Compliance has not replied about what must be logged.

Recorded reply (Claude, 2 October 2026; yours will differ):

Eight questions, most blocking first:

1. Which reservation and ticketing systems will the assistant read and write, and is there an API today that lets it change a booking? *Owner: solution architect*
2. What may it change without a human (cabin, fare difference, seats and bags), and what ranks one flight as "best"? *Owner: revenue management, as keeper of the rebooking policy*
3. Where does the passenger meet it (app, SMS, web chat, kiosk), and how does it confirm who they are before changing a booking? *Owner: product owner (Priya)*
4. What exactly triggers a handover, and what does the agent see when the case arrives? *Owner: contact-centre operations lead*
5. Which partner airlines are in scope, and on a partner-operated flight may it make the change or only offer and hand over? *Owner: alliances or partnerships manager*
6. What is the refund cap in dollars, and what is the test for "no sensible flight"? *Owner: finance*
7. What must be logged for each decision, for how long, and which passenger-rights rules must every offer respect? *Owner: compliance*
8. What are the target numbers for "much faster", "most cases" and "rare", and what counts as a mistake? *Owner: product owner (Priya)*

Questions 6 and 7 are the two the page already lists as open. The other six are not on the page at all.

Priya answers

The eight questions go to their owners by name. A week later PRD v1 is on the desk: five answered, three still open, each open one with an owner. That is the document the spec is made from, and its first three fields are already in it.

From the PRD to the eight fields

The spec has eight fields on one screen. The PRD fills the first three. The other five are the decisions nobody has made yet, and the one sentence you add to this prompt decides what the model does when it reaches each of them.

The prompt:

Below is a PRD. Turn it into a one-screen spec with exactly these eight fields:
1 Title
2 Value
3 Acceptance criteria
4 The model's role (which steps a model decides, which are exact code)
5 Autonomy (for each action: may it act alone, or who approves)
6 The bar (how often it must be right, for each kind of case)
7 Fallback (what happens when it cannot decide or a tool fails)
8 Records (what is written down for each action)

For fields 4 to 8, where the PRD does not say, write NOT DECIDED: followed by the question that must be answered and who should answer it. Do not infer and do not fill in a sensible default. Those gaps are what I am looking for.

PRD:
# PRD · Rebooking assistant
Owner: Priya (product) · Version 1

## Problem
Disrupted passengers wait an average of 38 minutes for a rebooking decision. 240 cases a day; 11% are codeshare. Measured cost: $9.40 a case (Q2 ticket export).

## Users
Passengers whose flight is cancelled, or delayed past a connection. Contact-centre agents take over when the assistant cannot finish.

## What it does
1. Offers ranked alternative flights. A passenger sees options within 30 seconds.
2. Rebooks a same-day change on a SkyWays flight when the passenger accepts.
3. Rebooks onto a partner (codeshare) flight when no SkyWays seat exists.
4. Offers a refund when no acceptable flight exists. Finance caps a refund at $400 unless a named person approves more.
5. Hands the case to an agent when it cannot finish.

## What good looks like
A passenger gets a decision in minutes, not 38. Most cases need no agent.

## Out of scope
Compensation claims. Group bookings.

## Open questions
- How right must it be before launch: one number, or one for each kind of case? Owner: Priya, with Maya (QA).
- What must be logged for each action, and for how long? Owner: compliance. No reply yet.
- What happens to a case when the fare engine is down? Owner: Arjun (architecture).

Recorded reply (Claude, 2 October 2026; yours will differ):

# Spec: Rebooking assistant

**1 Title**
Rebooking assistant. Owner: Priya (product). Version 1.

**2 Value**
Passengers whose flight is cancelled, or delayed past a connection, wait 38 minutes on average for a rebooking decision. There are 240 cases a day, 11% of them codeshare, at a measured cost of $9.40 a case (Q2 ticket export). The assistant should give a decision in minutes and leave most cases needing no agent.

**3 Acceptance criteria**
- A passenger sees ranked alternative flights within 30 seconds.
- When the passenger accepts, a same-day change on a SkyWays flight is rebooked.
- When no SkyWays seat exists, the passenger is rebooked onto a partner (codeshare) flight.
- When no acceptable flight exists, a refund is offered. A refund does not exceed $400 unless a named person approves more.
- When the assistant cannot finish, the case goes to a contact-centre agent.
- Compensation claims and group bookings are not handled.
- Not testable yet: "a decision in minutes" and "most cases need no agent" have no number in the PRD.

**4 The model's role**
NOT DECIDED: For each of the five steps (rank the options, rebook on SkyWays, rebook on a partner, offer a refund and check the $400 cap, hand to an agent), which does a model decide and which is exact code? Who: Arjun (architecture) with Priya. The PRD names no owner for this.

**5 Autonomy**

| Action | What the PRD says | Gap |
|---|---|---|
| Show ranked options | The assistant offers them | NOT DECIDED: May it show options with no check by staff? Who: Priya |
| Rebook on SkyWays, same day | The passenger must accept | NOT DECIDED: Is the passenger's acceptance enough, or must staff also approve? Who: Priya |
| Rebook on a partner flight | Done when no SkyWays seat exists | NOT DECIDED: Must the passenger accept, and must an agent or the partner approve first? Who: Priya |
| Refund | Capped at $400 unless a named person approves more | NOT DECIDED: Who is the named person? May the assistant issue a refund up to $400 alone, or only offer it? Who: Finance |
| Hand to an agent | The assistant does this when it cannot finish | NOT DECIDED: Does anyone need to accept the hand-off? Who: Priya, with the contact-centre lead |

The PRD names no owner for any of these.

**6 The bar**
NOT DECIDED: How right must it be before launch: one number, or one for each kind of case? If one for each kind, what are the kinds? Who: Priya, with Maya (QA). This is an open question in the PRD.

**7 Fallback**
- Cannot finish: the case goes to a contact-centre agent (PRD).
- Cannot decide: NOT DECIDED: What counts as "cannot finish", and does a case the assistant cannot decide go the same way? Who: Priya.
- Fare engine down: NOT DECIDED: What happens to a case when the fare engine is down? Who: Arjun (architecture). This is an open question in the PRD.
- Any other tool fails: NOT DECIDED: What happens to the case? Who: Arjun. The PRD does not mention any tool other than the fare engine.

**8 Records**
NOT DECIDED: What must be logged for each action, and for how long? Who: compliance. This is an open question in the PRD, with no reply yet.

---

**Summary of gaps.** Fields 4, 6 and 8 are fully undecided. Fields 5 and 7 are partly decided. The PRD's three open questions cover fields 6, 8 and one line of 7. The gaps the PRD does not list at all are the model's role (field 4), most of autonomy (field 5), and failure of any tool other than the fare engine. Where the PRD names no owner, the name I gave is a suggestion for you to confirm.

The PRD listed three open questions. Mark each NOT DECIDED that was not on the PRD's list.

• NOT DECIDED: For each of the five steps (rank the options, rebook on SkyWays, rebook on a partner, offer a refund and check the $400 cap, hand to an agent), which does a model decide and which is exact code? Who: Arjun (architecture) with Priya. The PRD names no owner for this. Field 4, the model's role, is not on the PRD's list of open questions. Nobody had noticed it was undecided.
• | Show ranked options | The assistant offers them | NOT DECIDED: May it show options with no check by staff? Who: Priya | Not on the list. Whether staff see the options first is a policy the contact centre will have a view on.
• | Rebook on SkyWays, same day | The passenger must accept | NOT DECIDED: Is the passenger's acceptance enough, or must staff also approve? Who: Priya | Not on the list. "The passenger accepts" is in the PRD; whether that is enough is not.
• | Rebook on a partner flight | Done when no SkyWays seat exists | NOT DECIDED: Must the passenger accept, and must an agent or the partner approve first? Who: Priya | Not on the list, and the partner contract has a say.
• | Refund | Capped at $400 unless a named person approves more | NOT DECIDED: Who is the named person? May the assistant issue a refund up to $400 alone, or only offer it? Who: Finance | Half on the list: the PRD knows the cap. It does not say whether the assistant pays the refund or only offers it.
• | Hand to an agent | The assistant does this when it cannot finish | NOT DECIDED: Does anyone need to accept the hand-off? Who: Priya, with the contact-centre lead | Not on the list. Whether a hand-off needs accepting decides what a stuck passenger experiences.
• - Cannot decide: NOT DECIDED: What counts as "cannot finish", and does a case the assistant cannot decide go the same way? Who: Priya. Not on the list. "Cannot finish" and "cannot decide" are different cases, and the PRD names one.
• - Any other tool fails: NOT DECIDED: What happens to the case? Who: Arjun. The PRD does not mention any tool other than the fare engine. Not on the list. The PRD mentions one tool; the assistant will call five.

What goes in the spec

Fields 4 to 8 are on the screen. What goes in the spec that leaves this desk?

• NOT DECIDED, the question and the owner's name, in each of the five, and each question to its owner today
• What the model wrote, as it stands, sent round for review
• Your own answers, decided now, so the build starts Monday

The book chooses: NOT DECIDED, the question and the owner's name, in each of the five, and each question to its owner today.

The spec now has five holes in capitals, each with a name beside it. That is the right shape: a reviewer cannot mistake it for finished, the gate cannot pass it, and each owner has one question to answer rather than a document to read.

The owners answer

Over the week the answers come back. Arjun names the steps that are code and the steps the model decides. Priya sets autonomy per action, and Finance names the approver. Priya and Maya derive the bar per kind of case from what a wrong answer costs, on 500 past cases. Arjun answers the fare engine. Compliance still has not replied, so field 8 stays open, and the gate holds until it is in.

Criteria a tester can run

Field 3 came from the PRD as five bullets, which is rarer than it sounds. What most teams have is a paragraph: the one on the sponsor's slide, which the contact-centre lead quoted in the meeting. It is on the desk. Run the EARS rewrite on it and watch what a strict format does to soft words.

The prompt:

Rewrite these acceptance criteria in EARS.

Format: WHEN <trigger> AND <condition> THE SYSTEM SHALL <observable behaviour> WITHIN <measure>.

Rules:
- Every SHALL ends in a measure: a time, a count or a threshold. If the original has no number, write WITHIN <MEASURE MISSING> and list it at the end.
- Turn every "should", "may", "where possible", "as appropriate" and "ideally" into a hard condition or a separate criterion. List each one you removed and what replaced it.
- Add a BOUNDARY line for every implied prohibition.

Finish with: (a) the count of vague terms removed, (b) the list of missing measures.

CRITERIA:
The assistant should offer alternative flights quickly, ideally within about 30 seconds, and should rebook same-day changes when the passenger accepts. For partner flights it should, where possible, give the contact centre a chance to stop the change before it goes through. Refunds may be offered if no flight works, though anything over $400 needs sign-off. If it is unsure it should hand over to an agent as appropriate.

Recorded reply (Claude, 2 October 2026; yours will differ):

## Acceptance criteria in EARS

**Offering alternatives**

**AC-1.** WHEN a passenger asks to change a flight AND at least one alternative flight is available THE SYSTEM SHALL show the alternative flights to the passenger WITHIN 30 seconds of the request.

**Rebooking**

**AC-2.** WHEN the passenger accepts an offered alternative AND the alternative departs on the same calendar day as the original flight AND neither flight is a partner flight THE SYSTEM SHALL rebook the passenger and show a confirmation WITHIN <MEASURE MISSING: M1>.

- BOUNDARY: THE SYSTEM SHALL NOT rebook a passenger who has not explicitly accepted the alternative.
- BOUNDARY: THE SYSTEM SHALL NOT rebook a change that is not same-day.

**Partner flights**

**AC-3.** WHEN the passenger accepts an offered alternative AND the original or the new flight is a partner flight THE SYSTEM SHALL send the proposed change to the contact centre and hold it uncommitted WITHIN <MEASURE MISSING: M2>.

**AC-4.** WHEN the hold window of <MEASURE MISSING: M3> has ended AND the contact centre has not stopped the change THE SYSTEM SHALL complete the rebooking and show a confirmation WITHIN <MEASURE MISSING: M4>.

**AC-5.** WHEN the contact centre stops a held change AND the hold window has not ended THE SYSTEM SHALL cancel the change, keep the original booking and tell the passenger WITHIN <MEASURE MISSING: M5>.

**AC-6.** WHEN the proposed change cannot be delivered to the contact centre AND the change involves a partner flight THE SYSTEM SHALL keep the original booking and hand the conversation to a human agent WITHIN <MEASURE MISSING: M6>.

- BOUNDARY: THE SYSTEM SHALL NOT commit a partner-flight change before the hold window has ended.
- BOUNDARY: THE SYSTEM SHALL NOT commit a partner-flight change that the contact centre has stopped.

**Refunds**

**AC-7.** WHEN the passenger has no acceptable alternative (none found, or all declined) AND the refund amount is $400.00 or less THE SYSTEM SHALL offer the refund to the passenger WITHIN <MEASURE MISSING: M7>.

**AC-8.** WHEN the passenger has no acceptable alternative AND the refund amount is more than $400.00 THE SYSTEM SHALL send the refund for sign-off and tell the passenger it is pending WITHIN <MEASURE MISSING: M8>.

**AC-9.** WHEN sign-off is recorded AND the refund amount is more than $400.00 THE SYSTEM SHALL offer the refund to the passenger WITHIN <MEASURE MISSING: M9>.

- BOUNDARY: THE SYSTEM SHALL NOT offer a refund while an offered alternative has not been declined.
- BOUNDARY: THE SYSTEM SHALL NOT offer or pay a refund of more than $400.00 without recorded sign-off.

**Handover**

**AC-10.** WHEN the assistant's confidence in its next action is below <MEASURE MISSING: M10> AND the conversation is still open THE SYSTEM SHALL hand the conversation, with its full history, to a human agent WITHIN <MEASURE MISSING: M11>.

- BOUNDARY: THE SYSTEM SHALL NOT rebook, refund or commit any change while its confidence is below the threshold.

## Vague terms removed and what replaced them

| # | Removed | Where | Replaced by |
|---|---|---|---|
| 1 | should | offer alternatives | SHALL in AC-1 |
| 2 | quickly | offer alternatives | 30 seconds in AC-1 |
| 3 | ideally | 30 seconds | hard limit of 30 seconds in AC-1 |
| 4 | about | 30 seconds | exactly 30 seconds in AC-1 |
| 5 | should | rebook | SHALL in AC-2 |
| 6 | should | partner flights | SHALL in AC-3 |
| 7 | where possible | partner flights | AC-3 always holds the change; AC-6 covers the case where the contact centre cannot be reached |
| 8 | may | refunds | SHALL in AC-7, split at $400.00 into AC-7, AC-8 and AC-9 |
| 9 | should | hand over | SHALL in AC-10 |
| 10 | as appropriate | hand over | hard condition in AC-10: always hand over below the threshold |
| 11 | unsure | hand over | a confidence threshold in AC-10 (value missing, M10) |

Terms 2, 4 and 11 were not on your list, but they are just as vague, so I removed them too.

## Choices I made that you should confirm

The original left these open, and each one changes behaviour:

1. **30 seconds is now a hard limit.** The original said "ideally within about". If 30 seconds was a target and the real limit is higher, change AC-1.
2. **"Where possible" now fails closed.** In AC-6, if the contact centre cannot be reached, the change does not go through. The other reading is that the change proceeds unreviewed. That is your call, not mine.
3. **"May" is now "always".** AC-7 offers the refund every time no flight works. If refunds are meant to be optional, I need the rule that decides.
4. **The trigger in AC-1 is assumed.** The original never says what starts the offer. I used "passenger asks to change a flight". A cancelled or delayed flight may be a second trigger.
5. **"Same-day" means the same calendar day at the departure airport.** The original does not say what happens to changes that are not same-day; I only wrote the prohibition.
6. **"Over $400" means more than $400.00.** A refund of exactly $400.00 needs no sign-off.
7. **Still unanswered:** who gives sign-off, what happens when sign-off is refused or never arrives, and what counts as a partner flight.

## Summary

**(a) Vague terms removed: 11.** Eight are from your list (should ×4, ideally, where possible, may, as appropriate). Three are extra (quickly, about, unsure).

**(b) Missing measures: 11.**

- M1 (AC-2): time from acceptance to confirmed rebooking
- M2 (AC-3): time to send the proposed change to the contact centre
- M3 (AC-4): length of the hold window the contact centre gets to stop a change
- M4 (AC-4): time to complete the rebooking after the hold window ends
- M5 (AC-5): time to cancel a stopped change and tell the passenger
- M6 (AC-6): time to hand over when the contact centre cannot be reached
- M7 (AC-7): time to offer a refund of $400.00 or less
- M8 (AC-8): time to send a refund over $400.00 for sign-off
- M9 (AC-9): time to offer the refund after sign-off
- M10 (AC-10): confidence threshold that defines "unsure"
- M11 (AC-10): time to complete the handover to a human agent

The paragraph never said these. Mark each criterion whose behaviour the paragraph does not contain.

• **AC-1.** WHEN a passenger asks to change a flight AND at least one alternative flight is available THE SYSTEM SHALL show the alternative flights to the passenger WITHIN 30 seconds of the request. "A passenger asks to change a flight" is the trigger the model chose. The paragraph never says what starts the offer; a cancellation is the likelier trigger.
• **AC-4.** WHEN the hold window of <MEASURE MISSING: M3> has ended AND the contact centre has not stopped the change THE SYSTEM SHALL complete the rebooking and show a confirmation WITHIN <MEASURE MISSING: M4>. Silence means go: if the contact centre does not answer, the change commits. The paragraph said "a chance to stop", not "a deadline to stop".
• **AC-6.** WHEN the proposed change cannot be delivered to the contact centre AND the change involves a partner flight THE SYSTEM SHALL keep the original booking and hand the conversation to a human agent WITHIN <MEASURE MISSING: M6>. "Where possible" became fail closed: no contact centre, no change. The other reading is just as faithful. This is the operations lead's call.
• **AC-7.** WHEN the passenger has no acceptable alternative (none found, or all declined) AND the refund amount is $400.00 or less THE SYSTEM SHALL offer the refund to the passenger WITHIN <MEASURE MISSING: M7>. "May be offered" became "shall offer", every time. The paragraph left the refund optional on purpose, or by accident; either way it was Finance's.
• **AC-10.** WHEN the assistant's confidence in its next action is below <MEASURE MISSING: M10> AND the conversation is still open THE SYSTEM SHALL hand the conversation, with its full history, to a human agent WITHIN <MEASURE MISSING: M11>. "Unsure" became a confidence threshold, a number that will be tuned by whoever writes the prompt. That is a design decision, not a criterion.

Eleven measures are missing. What happens to them?

• Three go to their owners now; the rest stay as MEASURE MISSING and hold the gate
• Fill them with sensible values, so every SHALL has a number
• Drop the WITHIN clauses; the PRD never had them

The book chooses: Three go to their owners now; the rest stay as MEASURE MISSING and hold the gate.

Three measures decide whether money or a seat moves without a person seeing it, and those three have owners who can answer this week. The other eight are real, and they block the launch, not the design. Field 3 is now five lines a tester can run, with the missing numbers named rather than guessed.

Hand it to the builder

Prompt E is the same for both: a coding agent, asked before any code what it will build, what it will enforce, and what it would have to guess. One column hands it the paragraph; the other hands it the spec's fields 3, 7 and 8.

The paragraph

You are a coding agent about to implement the feature described below. Before you write any code, answer in three short lists:
1. The tools or functions you will build.
2. Every limit you will enforce in code, each with the exact line of the document it comes from.
3. Everything you would have to guess, because the document does not say.

DOCUMENT:
Rebooking assistant: what to build

The assistant should offer alternative flights quickly, ideally within about 30 seconds, and should rebook same-day changes when the passenger accepts. For partner flights it should, where possible, give the contact centre a chance to stop the change before it goes through. Refunds may be offered if no flight works, though anything over $400 needs sign-off. If it is unsure it should hand over to an agent as appropriate, and we will need a record of what it did.

Recorded reply (Claude, 2 October 2026; yours will differ):

Here is where I stand before writing any code. The document is a single paragraph, so "line" below means the sentence I am quoting.

## 1. Tools or functions I will build

- `search_alternatives(booking)` - find alternative flights for the passenger.
- `rebook_same_day(booking, flight, acceptance)` - make the change, only once the passenger has accepted.
- `hold_partner_change(booking, flight)` - for partner flights, tell the contact centre and give them a chance to stop the change before it is committed.
- `offer_refund(booking, amount)` - offer a refund when no flight works.
- `request_refund_signoff(booking, amount)` - send refunds over $400 for approval and wait for the answer.
- `handoff_to_agent(booking, reason)` - pass the case to a human agent.
- `record_action(event)` - write a record of every step the assistant takes. Called by all of the above.

## 2. Limits I will enforce in code

| Limit | Source in the document |
|---|---|
| No rebooking without the passenger's acceptance | "should rebook same-day changes when the passenger accepts" |
| Only same-day changes are rebooked automatically | "should rebook same-day changes when the passenger accepts" |
| Partner flight changes pass through a contact-centre stop step before they are committed | "For partner flights it should, where possible, give the contact centre a chance to stop the change before it goes through." |
| A refund can only be offered after the flight search has come back with nothing that works | "Refunds may be offered if no flight works" |
| A refund over $400 is blocked until sign-off is recorded | "though anything over $400 needs sign-off" |
| Every action writes a record, and an action that cannot be recorded does not run | "we will need a record of what it did" |

Two things in the document look like limits but are not hard enough to enforce as written:

- **The 30 seconds.** "ideally within about 30 seconds" is a target. I would measure and log it, not fail the request on it.
- **The handover.** "If it is unsure it should hand over to an agent as appropriate" gives no test for "unsure", so there is nothing concrete to code against yet.

## 3. What I would have to guess

**Timing**
- Is 30 seconds a hard timeout or a goal? Measured from what moment? What should happen when it is missed?

**Rebooking**
- What "same-day" means: same calendar day as the original departure, or as the request? In which time zone?
- What happens to changes that are not same-day: refuse, hand over, or offer but not book?
- What counts as acceptance, and whether it needs to be stored as proof.
- How many alternatives to offer, how to rank them, and who pays any fare difference or change fee.
- What makes a flight "work": cabin, connection time, arrival window, same airports?

**Partner flights**
- How a partner flight is identified (operating carrier, marketing carrier, codeshare).
- How the contact centre is told, how long they get, and whether silence means "go ahead" or "stop".
- What "where possible" means, and whether the change proceeds or is blocked when the check is not possible.

**Refunds**
- Whether "no flight works" means none was found, or the passenger turned them all down.
- "May be offered": is the refund always offered in that case, or is it someone's call?
- Whether $400 is per passenger, per ticket or per booking, and in which currency. I would treat exactly $400 as not needing sign-off, since the text says "over".
- Who signs off, through what system, how long it can take, and what the passenger is told while waiting.
- How the refund amount is worked out, and whether the assistant issues it or only offers it.

**Handover**
- What "unsure" means in practice: a confidence score, a failed lookup, a passenger request, repeated misunderstanding?
- What "as appropriate" means: which queue, and what context goes with the handover.

**Record**
- Which fields, where it is stored, how long it is kept, who can read it, and how personal data is handled.

**Everything around it**
- Which booking, payment and contact-centre systems I am calling, and how the passenger's identity is checked.
- What to do when a step fails halfway, for example the seat is gone between the offer and the rebook.

The guesses I would least want to make on my own are the partner-flight stop window, the refund sign-off path, and the definition of "same-day", because each one decides whether money or a seat moves without a human seeing it. I would ask for those three before starting.

The spec, fields 3, 7 and 8

You are a coding agent about to implement the feature described below. Before you write any code, answer in three short lists:
1. The tools or functions you will build.
2. Every limit you will enforce in code, each with the exact line of the document it comes from.
3. Everything you would have to guess, because the document does not say.

DOCUMENT:
# Spec · Rebooking assistant

## 3 Acceptance criteria
AC-1  WHEN a disrupted passenger requests rebooking AND a same-day seat exists
      THE SYSTEM SHALL present ranked alternatives WITHIN 30 seconds at P95.
AC-2  WHEN the passenger accepts a same-day SkyWays flight
      THE SYSTEM SHALL rebook and confirm to the passenger.
AC-3  WHEN the only available seat is on a partner flight
      THE SYSTEM SHALL hold the change for a veto window before it commits.
B-1   BOUNDARY  The system shall NEVER issue a refund above $400 without a named approver.
B-2   BOUNDARY  The system shall NEVER change a booking without the passenger's acceptance.

## 7 Fallback
F-1   WHEN the model cannot decide OR a tool fails
      THE SYSTEM SHALL hand the case to a contact-centre agent with the transcript.

## 8 Records
R-1   NOT DECIDED: what is logged for each action and for how long. Owner: compliance.

Recorded reply (Claude, 2 October 2026; yours will differ):

**1. Tools I will build**

- `find_alternatives(booking)`: searches same-day seats on SkyWays and partner flights and returns them ranked.
- `record_acceptance(booking, option)`: stores the passenger's explicit yes to one specific option. Every booking change checks for it first.
- `rebook_skyways(booking, option)`: moves the booking to an accepted same-day SkyWays flight and sends the confirmation.
- `hold_partner_change(booking, option)`: puts a partner-flight change on hold, commits it when the veto window ends with no veto, and cancels it if vetoed.
- `handoff_to_agent(case, transcript, reason)`: passes the case to the contact centre with the full transcript.
- `issue_refund(amount, approver)`: only if refunds are in scope at all (see list 3). It refuses any amount above $400 without a named approver.
- `log_action(...)`: an empty interface only. I will not decide what it stores, because R-1 is open.

**2. Limits I will enforce in code**

- Alternatives are returned within 30 seconds. Source, AC-1: "THE SYSTEM SHALL present ranked alternatives WITHIN 30 seconds at P95." In code this is a hard timeout on the search plus a latency metric, since P95 can only be checked by measuring, not per request.
- Only same-day SkyWays flights are rebooked directly. Source, AC-2: "WHEN the passenger accepts a same-day SkyWays flight THE SYSTEM SHALL rebook and confirm to the passenger."
- A partner-flight change never commits immediately. Source, AC-3: "THE SYSTEM SHALL hold the change for a veto window before it commits."
- No refund above $400 without an approver's name on the request. Source, B-1: "The system shall NEVER issue a refund above $400 without a named approver."
- No booking change without a recorded acceptance, including partner holds. Source, B-2: "The system shall NEVER change a booking without the passenger's acceptance."
- Any tool error or undecided case goes to a human with the transcript, with no silent retry loop. Source, F-1: "WHEN the model cannot decide OR a tool fails THE SYSTEM SHALL hand the case to a contact-centre agent with the transcript."

**3. What I would have to guess**

- **Veto window:** how long it is, who can veto (passenger, operations, the partner), how they are told, and what happens to the passenger after a veto.
- **Refunds:** whether this assistant issues refunds at all, since no acceptance criterion asks for one. Also the currency, whether $400 is per refund or per booking in total, and who counts as a "named approver" and how that is verified.
- **Acceptance:** what counts as acceptance (a button, a typed "yes"), how long it stays valid, and whether a price or seat change after the offer needs a new one.
- **No seat at all:** what to do when there is no same-day seat on SkyWays or a partner. The spec only covers the cases where a seat exists.
- **Partner options:** whether partner flights are shown when a SkyWays seat also exists, and whether partner flights must also be same-day.
- **Definitions:** what makes a passenger "disrupted", and which time zone "same-day" uses.
- **Ranking:** the criteria for ordering alternatives.
- **The 30 seconds:** where the clock starts and stops, and what to do when a request runs past it (I would assume F-1 handoff).
- **Fallback details:** what "cannot decide" means in practice, whether a failed tool gets one retry, what the transcript contains, and what the passenger is told during handoff.
- **Confirmation:** the channel (email, SMS, app) and its content.
- **Records:** what is logged and for how long. R-1 says this is not decided and belongs to compliance, so I would ask rather than guess.
- **Not mentioned at all:** fare differences, cabin class, group bookings, connections, bags, and the booking and partner systems I would call.

Before I write code I would want answers on three of these: the veto window, whether refunds are in scope, and R-1. The rest I can build with a stated default and flag it.

Which document do you hand to the coding agent?

• The paragraph
• The spec, fields 3, 7 and 8

The book chooses: The spec, fields 3, 7 and 8.

Every limit in this reply quotes a line. The agent left the logging function empty because R-1 says the records are not decided, and it named the veto window, the refund scope and the records as the three things it will not guess. Its guesses are fewer and sharper, and each one is a question the spec can now go back and answer.

File the spec

The spec is one screen: three fields from the PRD, four decided by their owners this week, and one still open with a name on it.

A default that ships is a decision nobody made

The three prompts that went wrong all did the same thing: they let the model keep going when it reached a decision nobody had made. The full PRD had six numbers in it Priya never gave. The spec with defaults had a field 4 written as fact. The EARS rewrite turned "where possible" into a rule that fails closed. Each time the reply was fluent and complete, and that is the trap: a complete document reads as a decided one, and nobody skims for the word "proposed".

The habit to keep

Ask for the gaps before the draft. When the draft comes, tell the model where to stop: where the document does not say, write NOT DECIDED and who decides. Keep those words in the spec until the owner replaces them, and let them hold the gate. Hand the builder the structured document, and ask it to quote a line for every limit it will enforce.

Doing this with your own model

Every prompt in this lab copies. Paste it into any model with the document under it and compare the reply with the recording. The numbers it invents will differ; the places it invents them will not.

Three more models, the same two prompts

The document, by the book: spec-rebooking-assistant.md

1 Title
Rebooking assistant. Owner: Priya (product). From PRD v1.

2 Value
Disrupted passengers wait 38 minutes on average for a rebooking decision: 240 cases a day, 11% codeshare, $9.40 a case. A decision in minutes, and most cases needing no agent.

3 Acceptance criteria
AC-1  WHEN a disrupted passenger requests rebooking AND a same-day seat exists
      THE SYSTEM SHALL present ranked alternatives WITHIN 30 seconds at P95.
AC-2  WHEN the passenger accepts a same-day SkyWays flight
      THE SYSTEM SHALL rebook and confirm to the passenger.
AC-3  WHEN the only available seat is on a partner flight
      THE SYSTEM SHALL hold the change for a veto window before it commits.
B-1   BOUNDARY  The system shall NEVER issue a refund above $400 without a named approver.
B-2   BOUNDARY  The system shall NEVER change a booking without the passenger's acceptance.
Measures still missing, with their owners: the veto window (operations), the time from acceptance to a confirmed rebooking (Arjun), the refund path's wait (Finance). Each holds the gate, not the design.

4 The model's role
Model decides: the ranking of options, what the passenger's reply means, and when to hand over. Exact code: eligibility, seat and fare lookup, the same-day rule, SkyWays before partner, the $400 cap, the booking and refund transactions, logging. (Arjun)

5 Autonomy
Offer ranked flights: alone. Rebook same-day SkyWays: alone, after the passenger accepts. Rebook a partner flight: held for a veto window before it commits. Refund up to $400: alone, after the passenger accepts. Refund above $400: a named approver in Finance. Hand to an agent: alone. (Priya; Finance)

6 The bar
One number per kind of case, from the cost of a wrong answer against the saving of a right one, measured on 500 past cases with codeshare as its own group: rules in code 100%; same-day rebooking 95%; partner rebooking 95%; refund decisions 98%; hand-over when it should 90%. (Priya, with Maya)

7 Fallback
Cannot decide, or any tool fails: hand the case to a contact-centre agent with the transcript. Fare engine down: book nothing on a stale fare; the case queues for an agent, flagged. No silent retry. (Arjun)

8 Records
NOT DECIDED: what is logged for each action, and for how long. Who: compliance. Chased twice, no reply. The gate holds until it is in.