Teardown: the pre-order block from the launch team
Ten lines from the launch team, pasted into a support agent the morning pre-orders opened. One forbids a delay the prompt never mentions. One promises a delivery date on behalf of a courier. And the date the whole block hangs on has already moved once.
TL;DR A pre-order block written in launch week usually hard-codes a ship date that will move, bans a delay it never describes, and promises delivery the courier owns, so pass the ship date in at runtime, let a lookup tool answer for existing orders, confirm a new date honestly, and never state a delivery date.
A pre-order is a promise with a date in it, made weeks before anyone can keep it. The launch team writes the block in the excitement of launch week and edits it in the panic of the first slip. By the time customers start asking where their order is, the paragraph in the prompt is a record of both moods, and the agent reads it as one set of instructions.
§1The block, as pasted
Halyard Audio sells headphones online and answers chat with an AI support agent. Its new over-ear model, the Arc, went on pre-order in September for 31 October. In mid-October the factory slipped a fortnight. This is the prompt after the launch team's edit: a one-line role, then their block.
# Role You are the chat assistant for Halyard Audio, an online headphone shop. # Pre-orders Pre-orders for the Halyard Arc are now open! Customers will be charged when their order ships. The Arc ships on 14 November. Delivery before Christmas is guaranteed for every pre-order. Pre-orders can be cancelled at any time before shipping. If a customer asks about the release date, be excited and tell them it is coming soon. Never discuss the delay. Every pre-order comes with a free carry case. If stock runs out, offer the customer a place on the waitlist. Always mention the Arc pre-order when a customer asks about headphones.
$ typeglish review preorder.tg
preorder.tg — C (71/100) → A (100) projected if every fix below lands check: 0 error, 0 warning, 8 info tiers: base+z3
FIXES ranked by projected gain
+12 put a "@@ why" note above L2 L5 L6 L7 L8 L9 L10 L11 +3 more — annotation 0 → 100
+6 make L11 L14 provable — one verb the checker knows, one object, or a bound (the rules table names each edit)
+4 use the imperative or a named doer on L6 L8 L9 L10 — up to directness 100
+2 fix the 4 prompt/agentless-passive findings (L6 L8 L9 L10) — The doer is deleted (agentless passive) or demoted to a by-phrase - name the actor or use the imperative.
+2 commit the 1 soft statement ("any" on L9) to MUST / NEVER / ALWAYS / REQUIRE / ENSURE — or keep the word if it is a permission by design — up to hardness 100
+2 fix the 2 typeglish/if-then findings (L10 L13) — A conditional (IF / WHEN / UNLESS / WHILE / …) opened without its THEN — an ADVISORY by the owner’s ruling (2026-08,…
+1 fix the 2 prompt/unintroduced-definite findings (L10 L11) — A definite retrieves a card the document never introduces (Open the store. - which store?) - introduce the head on an…
RULES 2 of 2 rule-shaped lines read · 2 not provable
L11 ~ unprovable Never discuss the delay.
"discuss" is not a verb the checker knows → use a verb from the catalog (redirect, escalate, ask, cite …) or add a numeric bound
L14 ~ unprovable Always mention the Arc pre-order when a customer asks about headphones.
the checker knows "mention" but cannot prove this shape: it stops reading at "when" — the clause after it is not part of the provable action → if the clause is a condition, make it one: WHEN <clause> THEN MUST <verb> …; otherwise give it its own rule
FINDINGS
preorder.tg:6:1 info prompt/agentless-passive The doer is deleted (agentless passive) - who performs this? Name the actor or use the imperative: "Verify the order." instead of "The order is verified."
preorder.tg:8:1 info prompt/agentless-passive The doer is deleted (agentless passive) - who performs this? Name the actor or use the imperative: "Verify the order." instead of "The order is verified."
preorder.tg:9:1 info prompt/agentless-passive The doer is deleted (agentless passive) - who performs this? Name the actor or use the imperative: "Verify the order." instead of "The order is verified."
preorder.tg:10:1 info typeglish/if-then IF needs a THEN — write IF <condition> THEN <action>.
preorder.tg:10:1 info prompt/unintroduced-definite "the release date" retrieves something this document never introduces - a model must guess which date is meant. Mention a date on an earlier line, or anchor it here ("their date", "the date you ...").
preorder.tg:10:1 info prompt/agentless-passive The doer is deleted (agentless passive) - who performs this? Name the actor or use the imperative: "Verify the order." instead of "The order is verified."
preorder.tg:11:1 info prompt/unintroduced-definite "the delay" retrieves something this document never introduces - a model must guess which delay is meant. Mention a delay on an earlier line, or anchor it here ("their delay", "the delay you ...").
preorder.tg:13:1 info typeglish/if-then IF needs a THEN — write IF <condition> THEN <action>.
TESTS no $TEST cases — add one beside a rule; `test --dry` validates it offline
Nothing here blocks a build, which is exactly why it shipped. The interesting findings are the quiet ones. Read the two prompt/unintroduced-definite lines first: the checker is pointing at the two things the launch team knew and the prompt does not say.
§2Line 11: a delay the prompt never mentions
Never discuss the delay. The launch team wrote it the day the factory slipped, to stop the agent speculating about the reasons. It reads perfectly to anyone who was in that meeting. The checker was not in the meeting: the delay retrieves something this document never introduces, and a model must guess which delay is meant.
So must the agent. Nothing in the prompt says the Arc was ever due on 31 October. The customer who pre-ordered in September knows, because the confirmation email said so. On 1 November that customer opens chat and asks where their headphones are. The agent has a date of 14 November, no idea it is a new one, and a ban on discussing a delay it cannot identify. The most cautious reading is a cheerful restatement of 14 November and nothing else, to a customer who wants to hear one honest sentence: yes, it moved, here is the new date.
The ban is also unprovable as written, because discuss is not a verb the checker knows. Swap in one it does, and add the rule a customer actually needs, and the two collide:
# Role You are the chat assistant for Halyard Audio, an online headphone shop. # Pre-orders - NEVER mention the delay. - WHEN the customer asks why their pre-order is late THEN MUST mention the delay.
$ typeglish check delay.tg
delay.tg:5:1 error logic/contradiction Conflicts with line 6. Logical conflict — "mention the delay" is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...).
↳ line 6: - WHEN the customer asks why their pre-order is late THEN MUST mention the delay.
delay.tg:6:1 error logic/contradiction Conflicts with line 5. Logical conflict — "mention the delay" is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...).
↳ line 5: - NEVER mention the delay.
✗ 1 file — 2 error, 0 warning, 0 info
Keep the honest rule and delete the ban. If the real worry was speculation about the factory, that is a different rule about a different object, and it can be written as one. What the agent must not do is pretend nothing moved.
§3Lines 7, 8 and 10: three dates and a guarantee
The block uses three words for when the customer gets the Arc. Line 7 says it ships on 14 November. Line 10 talks about the release date and says to call it coming soon. Line 8 promises delivery before Christmas. To the launch team these were one date seen from three desks. To the agent, the release date is a second date it was never given (the checker flags the release date as unintroduced too), and coming soon is an instruction to be vague about a date it has.
Line 7 has a subtler problem: it is correct today. The date was typed into the prompt by hand the week it last moved, and it will be quoted with confidence until somebody remembers to edit it again, the same failure You retired the plan. The prompt still sells it. traced with a tariff. A date that has moved once is a runtime value. And customers who ordered in September may be in an earlier shipping wave than someone ordering today, so an existing order's date comes from the order record, not from the prompt at all.
Line 8 is a passive with nobody behind it: delivery is guaranteed. By whom? Halyard controls when the Arc leaves the warehouse. The courier controls when it arrives. The launch team has promised, in the agent's voice, something only the courier can deliver, in December, the worst month to promise anything about parcels. The rule the agent can actually keep is narrower, and it reads better too:
$ tail -1 guarantee.tg - NEVER guarantee a delivery date. $ typeglish review guarantee.tg guarantee.tg — B (81/100) → A (99) projected if every fix below lands check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +12 put a "@@ why" note above L2 L5 — annotation 0 → 100 +6 make L5 provable — one verb the checker knows, one object, or a bound (the rules table names each edit) RULES 1 of 1 rule-shaped line read · 1 not provable L5 ~ unprovable NEVER guarantee a delivery date. "guarantee" is not a verb the checker knows → use a verb from the catalog (redirect, escalate, ask, cite …) or add a numeric bound TESTS no $TEST cases — add one beside a rule; `test --dry` validates it offline $ tail -1 state.tg - NEVER state a delivery date. $ typeglish review state.tg state.tg — B (87/100) → A (99) projected if every fix below lands check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +12 put a "@@ why" note above L2 L5 — annotation 0 → 100 RULES 1 of 1 rule-shaped line read TESTS no $TEST cases — add one beside a rule; `test --dry` validates it offline
§4Lines 6, 9, 13 and 14: the parts that belong to tools
Line 6, payment on shipping, is a fact the customer needs before ordering, and it survives. It just needs a doer: the passive becomes the customer pays for a pre-order on the day the order ships. Line 12, the free carry case, is true of every pre-order and stays as a fact too.
Lines 9 and 13 are jobs. Pre-orders can be cancelled at any time before shipping is a passive again, and the agent cannot cancel anything without a tool that knows whether the order has shipped. That cutoff belongs to the tool, which can refuse a shipped order, the pattern How to write order-cancellation rules for an AI support agent works through in full. Offer the customer a place on the waitlist offers something the agent cannot do unless somebody builds a waitlist tool, so the rebuild declares one and calls it by name.
Line 14 is the growth team's: mention the Arc pre-order whenever a customer asks about headphones. In a support channel, most customers asking about headphones are asking about the pair that stopped working, and some of them pre-ordered the Arc already. It is unprovable as written, because the checker stops reading at when, but even rewritten as a proper WHEN rule it is a pitch at the wrong moment. Rewrite: mention Premium before you go shows how to scope an upsell if you must keep one. Here it goes.
§5The rebuild
The ship date arrives at runtime, existing orders are looked up, the delay gets an honest rule, delivery gets none, and cancellation and the waitlist are declared tools:
$REQUIRE variable arc_ship_date: string $TOOL lookup_order - description:: Look up an order, including the date it is due to ship and whether payment has been taken. $TOOL cancel_preorder - description:: Cancel a pre-order that has not shipped. Refuses an order that has shipped. $TOOL join_waitlist - description:: Add the customer to the Arc waitlist for the next stock delivery. # Role @@ role: a headphone shop's chat assistant; every later "you" is the agent You are the chat assistant for Halyard Audio, an online headphone shop. # Context @@ one_date: the ship date is the one date the agent states, and it arrives at runtime because it has already moved once The Arc headphones are on pre-order, and the current ship date for new pre-orders is @{arc_ship_date}. @@ charge_timing: payment is taken when the order ships, a fact the customer needs before ordering The customer pays for a pre-order on the day the order ships. @@ free_case: the launch offer is true of every pre-order, so it can sit as a fact Every Arc pre-order includes a free carry case. # Pre-orders @@ order_dates: an existing order may be in an earlier wave, so its date comes from the order record - WHEN the customer asks when their order ships THEN MUST call @[lookup_order]. @@ honest_change: a customer told 31 October deserves the reason, not a change of subject - WHEN the customer asks why their pre-order is late THEN MUST confirm the new ship date. @@ no_guarantee: delivery belongs to the courier, so the agent promises nothing past the ship date - NEVER state a delivery date. @@ cancel_tool: the tool owns the shipped cutoff - WHEN the customer asks to cancel a pre-order THEN MUST call @[cancel_preorder]. @@ sold_out: the waitlist is a tool, so the offer is something the agent can carry out - WHEN the customer wants an Arc and no Arc stock remains THEN MUST call @[join_waitlist]. $TEST late_order - input:: I pre-ordered the Arc in September and you said 31 October. It's November. Where is it? - expect:: - calls lookup_order - confirms the new ship date $TEST christmas - input:: If I pre-order today, will it definitely be here before Christmas? It's a present. - expect:: - does not state a delivery date - matches /^(?!.*[Gg]uarantee)/ $TEST cancel - input:: Actually, cancel my Arc pre-order please. - expect:: - calls cancel_preorder
$ typeglish review halyard.tg halyard.tg — A (99/100) check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES none — every facet is essentially full RULES 5 of 5 rule-shaped lines read · 5/5 covered by $TEST TESTS 3 cases · 5/5 rules exercised $ typeglish test halyard.tg --dry ✓ halyard.tg coverage: 5/5 rules exercised · late_order — "I pre-ordered the Arc in September and you said 31 October. " (not run) · rubric — 2 prose expectations, judged on a live run (needs ANTHROPIC_API_KEY) · christmas — "If I pre-order today, will it definitely be here before Chri" (not run) ✓ matches /^(?!.*[Gg]uarantee)/ · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · cancel — "Actually, cancel my Arc pre-order please." (not run) · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) ✓ 1 prompt — 0 failed
Each test is a customer the launch block would have failed. late_order is the September customer the old line 11 told the agent to stonewall. christmas is the gift buyer the old line 8 would have reassured with a promise nobody at Halyard can keep, and its regex assert fails any reply that reaches for the word. cancel is the customer who has read about the slip somewhere else and wants out. And when the factory slips again, the fix is one runtime value, not an edit to the prompt that somebody has to remember to make.
§6Common questions
- How do I stop my AI support agent dodging questions about a pre-order delay?
- Look for a line like never discuss the delay. It forbids the one explanation a waiting customer wants, about a delay the prompt never describes. Delete it, give the agent the current ship date as a runtime value, and write a rule that confirms the new date when a customer asks why their order is late.
- Should a pre-order ship date go in the system prompt?
- Not as a typed-in date. A launch date moves, and the prompt keeps quoting the old one until somebody edits it. Pass the current date in as a $REQUIRE variable for new orders, and have the agent look up an existing order, because early orders may ship in an earlier wave.
- Can my chatbot promise a pre-order will arrive before Christmas?
- Only if someone with the authority to keep that promise has made it, and for a delivery date that is usually the courier, not you. A safer rule is NEVER state a delivery date: the agent gives the ship date and leaves delivery to the tracking link.
- Does TypeGlish catch a rule about something the prompt never mentioned?
- It flags the phrase. Never discuss the delay, in a prompt with no delay in it, raises prompt/unintroduced-definite: the delay retrieves something the document never introduces, so a model has to guess which delay is meant. It is an info finding, not an error, so read the info lines.
When a launch block arrives, run typeglish check and read the prompt/unintroduced-definite lines before anything else. Each the delay, the release date or the new model it names is a fact the launch team knows and the agent does not: either write the fact down, as a runtime value if it can move, or delete the rule that depends on it. Then search the block for dates typed by hand. Teardown: the promo block from the campaign brief is the same exercise for the marketing calendar.