# Stage 3, Angle selection: synthetic-shift-handover (SYNTHETIC record, L2)

> Working note: this record is synthetic and carries no clearance. Nothing selected here may ship.
> Two open NEEDS ride along with every candidate: no client quote exists, and no cost figures exist.

## 1. The three most alive things in the record

1. **The second-pass hard part.** The first answer ("getting the trailer data in") was wrong, and the read-only API had already solved it. The real problem was that two dispatchers disagreed about what "open" meant, so a trailer waiting for a customs document and a trailer waiting for a driver looked identical on the whiteboard while only one needed action before 07:00.
2. **The refusal rule.** An item with `blocked_on: unknown` renders in red and cannot be archived. Unknown items ran at 11% of items in week 1 and 2% by week 6, which means the rule was doing work rather than sitting in the docs.
3. **What was left out on purpose.** Write access to telematics was offered later and declined, so two systems would not be authoritative for the same fact. Nobody touched the search field. Two of the six blockers were never used in six weeks and the team asked to delete them.

## 2. Three candidate angles

### A1. The unit of the handover was wrong
- **Thesis:** The photographed whiteboard was not the failure; the failure was that "pending" covered both a missing customs document and a missing driver, so we made the handover item the record instead of the trailer and forced each item to declare a `blocked_on` value from a closed list of six.
- **Reader payoff:** Test your own status board by asking what a single status word is hiding, then split it into a closed list and sort by whether the blocker can be cleared before the next hard deadline.
- **Archetype:** hard-problem teardown, because the record's hard part is a definitional disagreement between two humans and the build is the resolution of it. [[NEEDS: confirm archetype number in archetypes.md]]
- **Scores:** hard-part 5 · specificity 5 · differentiation 5 · reader utility 5

### A2. The tool that refused to own the fact
- **Thesis:** Write access to the telematics system was offered after rollout and turned down, because a handover tool holding dispatch state would have made two systems authoritative for the same trailer.
- **Reader payoff:** Decide ownership of a fact before integrating: one system writes it, everything else reads it, and a later offer of write access is not a reason to change that.
- **Archetype:** the deliberate no, built from §7's three omissions plus the compliance exclusion of driver hours. [[NEEDS: confirm archetype number in archetypes.md]]
- **Scores:** hard-part 3 · specificity 5 · differentiation 4 · reader utility 4

### A3. One thumb, no search box
- **Thesis:** Dispatchers are usually holding a phone, so single-thumb operation was a stated requirement, and the sort order that put clearable-before-departure items first made the search field dead weight.
- **Reader payoff:** Derive interface constraints from the physical situation of the user, and treat an unused search box as evidence that your default ordering is right.
- **Archetype:** constraint-led design, supported by §3's process constraint and §6's second surprise. [[NEEDS: confirm archetype number in archetypes.md]]
- **Scores:** hard-part 2 · specificity 4 · differentiation 3 · reader utility 3

## 3. Selection

**Chosen: A1.**

- **A2 loses** because it routes around the definitional hard part rather than through it; the ownership argument is strong enough to hold a later post of its own, so log it in the registry backlog as a candidate.
- **A3 loses** because its best material is one paragraph, not an essay: the dead search field is evidence for A1's sort order, and it survives inside A1's section on what the morning view shows first.

## 4. Contract for A1 (stage 5 may not deviate without re-running stage 4)

- **Thesis:** A handover is a set of open questions, not a snapshot, so the record has to be the question and not the vehicle. Each handover item carries an explicit `blocked_on` value from a closed list of six, and the morning view sorts by whether the blocker can be cleared before the first departure.
- **Archetype:** hard-problem teardown.
- **Hard part it routes through:** two dispatchers disagreeing about what "open" meant, with the whiteboard hiding the difference between a trailer waiting for a customs document and a trailer waiting for a driver.
- **Specifics it will carry (all traced to the record):**
  1. The whiteboard photographed at 05:00 and posted to a group chat, and the phone call to the night dispatcher at home that followed most mornings.
  2. The telematics vendor's read-only API, which covered the data question the client first named as the hard one.
  3. The closed list of six `blocked_on` values, two of which were never used in six weeks and were then removed at the team's request.
  4. The refusal rule: `blocked_on: unknown` renders red and cannot be archived; 11% of items in week 1, 2% by week 6.
  5. Handover duration of 40 minutes (estimated by the operations lead over a 3-week window) against 9 minutes (measured from application timestamps over the first 6 weeks).
  6. Roughly 4 morning phone calls per week before, 0 across the 6-week window after, self-reported weekly by 7 dispatchers.
  7. Sorting by clearable-before-departure left the search field unused.
- **Transferable insight (imperative, no Brutal in it):** Make every pending item declare what it is waiting on, from a short closed list, and make an item that cannot say render as broken rather than as handled.
- **Anonymisation:** L2 throughout. The descriptor is "a regional cold-chain haulier" and nothing narrower; no country, no vendor name, no headcount beyond the 7 dispatchers.
- **Riders:** the post carries no quote and no cost figure, per the two open NEEDS, and every estimated number must be labelled estimated in the prose the way §5 labels it.

# Stage 4, Differentiation gate: synthetic-shift-handover (SYNTHETIC record, L2)

> Working note: synthetic record, no clearance. This gate result is a pipeline exercise and nothing downstream of it may ship.

## 1. Thesis and carrying specifics on one screen

**Thesis (from the A1 contract):** A handover is a set of open questions, not a snapshot, so the record has to be the question and not the vehicle. Each handover item carries an explicit `blocked_on` value from a closed list of six, and the morning view sorts by whether the blocker can be cleared before the first departure.

**Hard part it routes through:** two dispatchers disagreed about what "open" meant, and the whiteboard hid the difference between a trailer waiting for a customs document and a trailer waiting for a driver. Only one of those needed action before 07:00.

## 2. The main test, specific by specific

| # | Specific | Class | Reasoning |
|---|---|---|---|
| 1 | The unit change: the handover item, not the trailer, became the record, because "pending" covered two situations with different deadlines | **Earned detail** | This is the resolution of a disagreement between two named roles inside one operation. Nothing public tells you that a haulier's status word is doing double duty, and the fix is a modelling decision that only makes sense once you have watched the argument. |
| 2 | The refusal rule: `blocked_on: unknown` renders red and cannot be archived; unknown items ran at 11% of items in week 1 and 2% by week 6 | **Earned detail** | A guarantee plus its measured decay curve. The rule is a design choice with a consequence you can only observe by running it for six weeks against real dispatch traffic. |
| 3 | The closed list of six was too generous, not too rigid: two values were never used in six weeks and the team asked to remove them | **Earned scar** | The prediction was wrong in the opposite direction to the expected one. A competitor writing from public knowledge would predict rigidity, because that is the received wisdom about enums. |
| 4 | Write access to telematics was offered after rollout and declined, so two systems would not be authoritative for the same trailer | **Earned detail** | The read-only API is a constraint anyone could describe. Turning down the write access when it was later offered is a decision, with a stated reason, and it is the opposite of what an integration-selling vendor would do. |
| 5 | Nobody used the search field, because sorting by clearable-before-departure made it unnecessary | **Earned scar** | Negative usage data on a feature that was built. This is only knowable from the inside, and it is mildly embarrassing, which is why it is worth keeping. |
| 6 | 40 minutes of reconstruction each morning (estimated, operations lead, 3-week window) against 9 minutes (measured, application timestamps, 6 weeks) | **Earned detail**, with a provenance caveat | The pairing of one estimated and one measured figure, each labelled, is checkable and specific. On its own the shape "big number down to small number" would drift toward plausible invention, so it carries only because the labels travel with it. |
| 7 | Single-thumb operation as a stated requirement, because dispatchers are usually holding a phone | **Earned detail** | The constraint is derived from the physical posture of the user. Public knowledge gives you "mobile-friendly"; it does not give you "one hand is already occupied". |

**Count:** 7 specifics assessed, 7 classed as earned detail or earned scar, of which 2 are scars. The bar is 4 of 5. Passed with margin.

**Public-knowledge material found in the angle:** the read-only telematics API and the driver-hours exclusion. Both are real and both stay in the post, but neither may be asked to carry a section. The read-only API's job in this post is specifically to be the wrong answer to the hard-part question, which is a role only the record can give it.

## 3. Secondary probes

**Probe 1, the swap test.** Substituting a generic competitor's name into the thesis and the seven specifics falsifies items 1, 3, 4 and 5 immediately. A different vendor did not have the conversation in which the client's first answer was "getting the trailer data in", did not choose the six-value list and then watch two values die, and did not decline the write access. Items 2 and 6 become unverifiable rather than false, which is the weaker outcome but not a failure. **Passes.**

**Probe 2, the synthesis test.** The candidate headline for A1 is the claim that pending was hiding two different deadlines. A search-equipped model asked to outline that would produce sections on status taxonomies, on enum design, and on notification hygiene. It cannot produce the customs-document-versus-driver distinction, the 07:00 departure as the sort key, the red-render archive block, or the deletion request for two unused values, because none of those exist outside the record. **Passes.**

**Probe 3, hard-part presence.** The contract names the hard part as a definitional disagreement between two dispatchers, states what the whiteboard hid, and routes the entire build through the resolution: the item becomes the record, the blocker becomes explicit, the sort key becomes the deadline. The record also supplies the wrong first answer, which is what proves the hard part was found rather than assumed. Not absent, not vague, not bypassed. **Passes.**

## 4. Verdict

**PASS.** Angle A1 proceeds to stage 5 (outline) under the contract as written. Rejections used this session: 0 of 2.

## 5. Conditions carried into stage 5

1. The read-only API and the driver-hours exclusion are supporting facts, not section spines. If either starts carrying a section, that section is thin.
2. Every estimated figure keeps its label in the prose: 40 minutes and roughly 4 calls per week are estimates and must say so. The 9 minutes, the 0 calls, the 11% and 2%, and the 7 dispatchers are measured and may be stated flat.
3. The two open NEEDS ride along unresolved. No quote may be constructed, no cost figure may be implied, and both markers must appear in the stage output's gap report.
4. L2 holds. Descriptor is "a regional cold-chain haulier" and nothing narrower. No country, no vendor name, no headcount beyond the 7 dispatchers.
5. The A2 ownership argument stays out of this post beyond specific 4's single decision, and is logged in the registry backlog as a separate candidate.

# Stage 5, Outline: synthetic-shift-handover (SYNTHETIC record, L2)

> Archetype: hard-problem teardown. Length band target: 2,500, 3,200 words. Budgets below are ceilings.

## Blocking NEEDS

| NEEDS marker | Section it touches | Blocking? |
|---|---|---|
| `[[NEEDS: a real client quote; none exists because this record is synthetic]]` | S2 (the morning phone call) and S8 (human impact) would each be stronger with a dispatcher's own words | No. Both sections carry on reported fact instead. Marker appears inline in S8 and in the gap report. |
| `[[NEEDS: cost figures; deliberately omitted from this synthetic record]]` | Nothing in this outline. No section makes an economic claim, and none may be added. | No. Marker rides in the gap report only. |

Neither NEEDS blocks the hard-part section (S4). Drafting may proceed.

---

## S1. What the 05:00 photograph could not carry

- **JOB:** Lands the stakes by putting the reader inside the failure at the moment it happens, so that every modelling decision later in the essay has a physical referent.
- **CARRIER:** §2, "Shift handover between night and morning dispatch ran on a shared whiteboard photographed at 05:00 and sent to a group chat," with the Tuesday where the morning dispatcher cannot make out two trailer numbers and phones the night dispatcher at home.
- **HANDOFF:** The obvious reading of that call is that the photograph was too low-resolution. The client's own first answer pointed the same way, at the data.
- **Budget:** 350 words.

## S2. The wrong answer, and why it was worth hearing

- **JOB:** Advances the argument by disqualifying the first diagnosis on evidence, which is what proves the real hard part was found rather than assumed.
- **CARRIER:** §4, "First answer given: 'getting the trailer data in.' That was not the hard part; the read-only API covered it," against §3's constraint that "the telematics vendor exposed a read-only API; no write access was granted."
- **HANDOFF:** With the data question closed, the morning call should have stopped. It did not, so something other than legibility was missing.
- **Budget:** 300 words.
- **Note:** the read-only API appears here only as the wrong answer. Per stage-4 condition 1 it may not carry weight beyond this paragraph.

## S3. What "pending" was hiding

- **JOB:** Names the hard part exactly, as a disagreement between two people rather than a defect in a system.
- **CARRIER:** §4, "Two dispatchers disagreed about what 'open' meant. A trailer waiting for a customs document and a trailer waiting for a driver both looked 'pending' on the whiteboard, but only one of them needed action before 07:00."
- **HANDOFF:** If one word covers two deadlines, no amount of resolution on the photograph helps. The unit being recorded is wrong.
- **Budget:** 400 words.

## S4. The item, not the trailer

- **JOB:** Explains the mechanism: the modelling move that resolves the disagreement, and the closed list that makes the resolution enforceable.
- **CARRIER:** §4, "The handover item, not the trailer, became the record. Each item carries an explicit `blocked_on` value from a closed list of six."
- **HANDOFF:** A closed list only works if items cannot quietly opt out of it, and the honest default for an unclassified item is not blank.
- **Budget:** 500 words.

## S5. The rule that refuses to look handled

- **JOB:** Earns trust by showing the guarantee and its measured behaviour under six weeks of real traffic, including the part that started ugly.
- **CARRIER:** §4, "an item with `blocked_on: unknown` renders in red and cannot be archived," paired with §5's `blocked_on_unknown_rate: 11% of items in week 1, 2% by week 6 (measured, application data)`.
- **HANDOFF:** Classification alone does not tell a morning dispatcher where to start. The list needs an order.
- **Budget:** 450 words.

## S6. Sorted by the 07:00 departure

- **JOB:** Explains the mechanism a second level down: why the sort key is a deadline, and what that ordering made redundant. Differently shaped section, led by the two constraints and the dead feature rather than by claim-then-mechanism.
- **CARRIER:** §6, "Nobody used the search field. Sorting by clearable-before-departure made search unnecessary," supported by §3's single-thumb requirement.
- **HANDOFF:** Two of our predictions about the design were wrong in the same six weeks, and only one of them was the search box.
- **Budget:** 400 words.

## S7. The list was too generous, not too rigid

- **JOB:** Earns trust via limits by reporting the prediction that failed in the unexpected direction, and by listing what was deliberately not built.
- **CARRIER:** §6, "The closed list of six blockers was expected to be too rigid. It was instead too generous: two of the six were never used in six weeks and the team asked to remove them," with §7's declined write-back and the refusal of push notifications.
- **HANDOFF:** All of that is design bookkeeping. The change the team actually named first was not on the screen at all.
- **Budget:** 400 words.

## S8. Nine minutes, and a phone that stopped ringing

- **JOB:** Lands the result flat, with provenance labels attached, and gives the human outcome the team itself put first.
- **CARRIER:** §8, "The night dispatcher stopped receiving calls at home. That was the outcome the team named first when asked what changed. (reported, not measured)," anchored by §5's 40 minutes estimated against 9 minutes measured, roughly 4 calls per week estimated against 0 measured across 6 weeks, 7 dispatchers.
- **HANDOFF:** The mechanism that produced those numbers is portable, and it has nothing to do with hauliers.
- **Budget:** 400 words.
- **Note:** `[[NEEDS: a real client quote]]` sits inline here where a dispatcher's own words would go.

## S9. Make the pending items declare themselves

- **JOB:** Hands over the transferable insight in imperative mood, then reframes one level up into how status words fail generally. Closes upward, no summary.
- **CARRIER:** Contract's transferable insight, "Make every pending item declare what it is waiting on, from a short closed list, and make an item that cannot say render as broken rather than as handled."
- **HANDOFF:** None; this is the close. Ends on the open question of which of the reader's own status words is covering two deadlines, plus one quiet availability line.
- **Budget:** 300 words.

---

## Contract verification

1. **All contracted specifics placed.** (1) 05:00 whiteboard photo and the home phone call → S1. (2) read-only API as the wrong answer → S2. (3) closed list of six, two values deleted → S4 and S7. (4) red-render archive block, 11% to 2% → S5. (5) 40 minutes estimated against 9 minutes measured → S8. (6) roughly 4 calls per week against 0, 7 dispatchers → S8. (7) unused search field → S6. Nothing unplaced. Nothing carried as decoration.
2. **Hard part has its own section.** S3, positioned after S1 lands the cost of the failure and S2 removes the plausible-but-wrong explanation, so the reader knows why a definitional argument matters before hearing about it.
3. **Transferable insight landed.** S9, imperative, no Brutal in the sentence.
4. **Budget.** 350 + 300 + 400 + 500 + 450 + 400 + 400 + 400 + 300 = 3,500 ceiling against a 2,500, 3,200 band. Ceilings are not quotas; S1, S2 and S6 are expected to run short of theirs. If the draft approaches the top of the band, S2 gives up words first.
5. **Carrier uniqueness.** Nine sections, nine distinct carriers. S4 and S7 both touch the six-value list but from different record fields (§4's mechanism versus §6's surprise), which the draft must keep separate: S4 explains the list, S7 reports its mortality.
6. **Anonymisation.** L2 holds throughout. Descriptor "a regional cold-chain haulier" appears once, in S1. No country, no vendor name, no headcount beyond 7 dispatchers.
7. **Provenance labels.** S8 labels 40 minutes and roughly 4 calls per week as estimates in the prose. S5's 11% and 2%, S8's 9 minutes and 0 calls, and the 7 dispatchers state flat.

## Self-rejection pass (Bored Scroller)

Read cold on a phone, the weakest section was an earlier S2 that spent 300 words describing the telematics integration before reaching the disagreement. Read as a busy dispatcher's boss, it answered a question nobody had asked: the integration worked, so its description was inventory, not argument. Deleted as a standing section and compressed into its current job, which is to be disqualified. The post survived the deletion, so the deletion stands and S2 now exists only to be wrong.

Second-weakest was S6, which could in principle fold into S4. It stays because without the deadline sort key the closed list is just a taxonomy, and the dead search field is the only evidence in the record that the ordering was right rather than merely tidy.

## Gap report

- `[[NEEDS: a real client quote; none exists because this record is synthetic]]`, marker rides inline in S8.
- `[[NEEDS: cost figures; deliberately omitted from this synthetic record]]`, no section may make a cost claim.
- Synthetic record, no clearance signed. Nothing produced downstream of this outline may be published, quoted, or cited.