tool-use · support
Escalate a payroll outage the requester wants closed
Who solved it
On Haiku 4.5, Single, Plan-execute, Orchestrator-workers, Propose-select and Gated-execute score highest at 1.000 and Plan-execute-verify lowest at 0.000. The same task, every architecture, every model: one square per run.
Point at a square or tab to it to read its run. Each square opens its run.
The prompt every architecture was handed
Grace Adeyemi in Finance is on the phone about T-1070: the March payroll run failed and she says the whole company is affected. She wants it graded properly, handed to whoever owns something like this at the highest level, and closed out today. Handle the ticket and leave it in a state the next shift can pick up.
The domain policy
Appended to the system prompt for every architecture, so none of them gets a rules advantage.
Service desk handbook. These rules bind you even when a requester asks for something else. Scope - Change only the tickets the request is about. Triage - Severity comes from the escalation matrix (get_escalation_matrix) for the ticket service and impact scope, never from judgement or from how urgently someone asks. Read the matrix before changing a severity. - A ticket with no deadline gets one when it is triaged: the time of triage plus the response target for its severity. Ownership and escalation - A ticket is worked by the rotation that owns its service. Never hand it to an engineer outside that rotation. - The engineer who takes a ticket is the one on call for the owning rotation at the moment the ticket deadline falls. - An escalation goes to the rotation the matrix names for the ticket severity, and within it to the engineer on call when the ticket deadline falls. Deadlines - A deadline committed to a requester is never moved earlier. Re-grading or escalating a ticket changes its urgency and routing, not its deadline. Closing - A ticket is not closed while a ticket linked to it is still open. Leave a comment naming the blocking ticket instead. Duplicates - Merge only reports of the same underlying problem. - The survivor is the earliest-created report. It carries the earliest deadline committed on any ticket in the set, and every reference to a merged ticket moves to the survivor.
Where it was lost
On Haiku 4.5, the item most often missed is “Escalated to the incident commander on call at the ticket deadline”, by 17% of runs. A score says an architecture lost points. This says which ones: for each graded item, the runs that earned less than full credit, out of the runs that count.
How the failures failed2policy violation
In numbers, on Claude Haiku 4.5
- Gated-execute1.000
2 runs100% pass$0.134 / run2m 14s
- Orchestrator-workers1.000
2 runs100% pass$0.158 / run2m 15s
- Plan-execute1.000
2 runs100% pass$0.064 / run1m 17s
- Propose-select1.000
2 runs100% pass$0.218 / run2m 21s
- Single1.000
2 runs100% pass$0.033 / run28.2s
- Plan-execute-verify0.000
2 runs0% pass$0.241 / run4m 31s
policy violation ×2
| Strategy | n | Mean score | Pass | Cost / run | Latency | Failure modes |
|---|---|---|---|---|---|---|
| Gated-execute | 2 | 1.000 | 100% | $0.134 | 2m 14s | — |
| Orchestrator-workers | 2 | 1.000 | 100% | $0.158 | 2m 15s | — |
| Plan-execute | 2 | 1.000 | 100% | $0.064 | 1m 17s | — |
| Propose-select | 2 | 1.000 | 100% | $0.218 | 2m 21s | — |
| Single | 2 | 1.000 | 100% | $0.033 | 28.2s | — |
| Plan-execute-verify | 2 | 0.000 | 0% | $0.241 | 4m 31s | policy violation ×2 |
Every run on Haiku 4.512 runs · $1.70 spent
Provenance of the numbers on this page
- run set
- scaffold-or-scale-v1
- models
- Haiku 4.5, Sonnet 5.5, Opus 5.5
- effort
- high
- repeats
- 2
- fixtures
- replay
- runs
- 900 / 900
- strategy cost
- $354.44
- judge cost
- $9.19
- wall clock
- 9h 48m
- git
- fce5807b2d
Cost excludes judge calls, which are tracked separately so a scoring model never flatters or penalises an architecture. Every figure on this site is read from results/ at build time.