feat(failure-taxonomy): a blame axis (machine / provider / agent), outage detection, and time-expiring holds

[drewstone]

What is missing

The failure taxonomy names WHAT went wrong but never WHO it went wrong on. FAILURE_CLASSES is a flat list of 25-plus classes — sandbox_failure, timeout, budget_exceeded, missing_credentials, and so on — and FailureClassification carries failureClass, reason, and two trigger ids. There is no blame axis, so a consumer cannot separate "the machine never reached a model" from "the agent's own budget ran out", and every comparison silently charges infrastructure outages to the agent under test.

Three related capabilities, one axis:

1. A blame axis on every class. machine — the run never reached a model: the bridge refused, its lane was full, the box never provisioned. An agent cannot route around this, so a run that recorded nothing behind only machine failures is not evidence about the agent and must be voided, not counted as a loss. provider — the model was reached and the turn did not complete: an empty completion, a torn stream, a killed process. Every arm faces the same provider on the same day, so this stays charged. agent — the agent's own budgeting or scheduling ran out. Charged.
2. Outage detection. From a series of runs, the trailing streak of consecutive machine/provider deaths per arm, and a per-credential verdict on whether the recent record reads as an outage.
3. A time-expiring hold. A stateless verb that answers "should this credential be used right now" from the run record alone, with no ledger, no probe rows, and no per-arm state — so there is nothing to latch and nothing to unwedge by hand.

Where it lives today

• discovery-lab/tools/failure-classes.mjs 180 lines — the ordered taxonomy carrying the three blames, with the note that ordering is load-bearing because one reason string carries two signals: a seat killed by SIGKILL while the bridge refuses connections is a bridge failure, not a process failure.
• discovery-lab/tools/line-health.mjs 763 lines — the read-only report and the one enforced verb, --hold <seat>.

Where it belongs

• src/failure-taxonomy.ts:450 — export function classifyFailure(, and the FailureClassification interface at :23. Add blame beside failureClass.
• src/trace/schema.ts:234 — export const FAILURE_CLASSES, which today has no blame mapping. blame appears 0 times in either file.

Measured motive

All six director cells in one round settled with the runtime journal's own infra flag reading FALSE, because the runtime cannot see why the bridge stopped answering. Their real reason was host-executor: acquire timeout after 900000ms (in_flight=10/10) — the bridge's host lane had saturated. Read on the runtime's flag alone, six machine outages would have been charged to the agent profile as six failures to produce science (failure-classes.mjs:33-40).

Separately, measured 2026-08-22: 8 arms burned 236 runs at 83% no-winner, and the audit read most of those deaths as sandbox or bridge deaths — the machine, not the question. The attempt cap forgives a zero-spend death, so each question was retried against a machine that was down, and every retry was one more zero-token run directory. No reader of the fleet could tell "this arm's bridge is dead" from "this arm's questions are hard" (line-health.mjs:11-16).

Acceptance

Both files can be deleted when classifyFailure returns a blame for every class, a test asserts that an ordered rule set charges a SIGKILL-during-bridge-refusal to machine rather than agent, and an exported reader turns a run series into a per-credential outage verdict plus a stateless time-expiring hold.

[drewstone]

Measured against the installed 0.171.0 while trying to delete discovery-lab/tools/failure-classes.mjs (180 lines) onto this taxonomy. The blame axis this issue asks for is one of two blockers; the other is that the class list itself is closed.

FailureClass = (typeof FAILURE_CLASSES)[number] (dist/schema-DID1Cqct.d.ts:202) over a 35-member union that describes agent BEHAVIOUR: reasoning_error, tool_selection_error, hallucination, instruction_following, bad_retrieval, and so on, plus timeout, sandbox_failure, budget_exceeded, unknown.

The lab taxonomy is 20 ordered regexes over the TRANSPORT death reasons this fleet records. 4 of the 20 have a member here — budget-pool-exhausted -> budget_exceeded, deadline -> timeout, box-provision-timeout -> sandbox_failure, and arguably traversal-cap. The other 16 have none: bridge-unreachable, bridge-lane-saturated, router-usage-mismatch, session-profile-conflict, runtime-restart, root-driver-failed, box-teardown, profile-refused, empty-completion, sse-json-error, stream-no-terminal, message-sealed, process-sigkill, cancelled, terminated, unclassified.

The signature is the second half of the mismatch: classifyFailure(ctx: FailureContext, rules?) where FailureContext = { run, spans, events }. The lab classifies a reason STRING — the text on result.json, failure.json, or a spawn-journal settle row — because that is often all a dead run left behind. A run that died before any span exists has no FailureContext to build.

So the full ask, if you want a consumer to delete its copy rather than keep one:

1. The blame axis this issue already describes (machine / provider / agent), which is what the lab`s machine-void verdict turns on.
2. An open or extensible FailureClass, so a caller-registered rule can name a class this union does not have — the same shape #704 asks for on EvidenceRef.kind.
3. A reason-string entry point, e.g. classifyFailureReason(text, rules?), that the trace-shaped classifyFailure can also call.

The measured motive for (1), from the lab: all six r1 director cells settled with the runtimes own infraflag reading FALSE, because the runtime cannot see why the bridge stopped answering. Their real reason washost-executor: acquire timeout after 900000ms (in_flight=10/10)`. Read on that flag alone, six machine outages would have been charged to the director profile as six failures to produce science.

[drewstone]

PR #720 opens for part 1 (the blame axis) plus the two blockers in the comment above: a reason-string entry point, and a class surface that holds the 20 transport classes.

One deliberate reversal of the ask, stated here so it is not buried in a PR body: I widened FAILURE_CLASSES (35 -> 52) instead of opening FailureClass with (string & {}).

Two reasons, both checkable:

1. An open type over a closed runtime gate is a lie. run-record.ts, release-confidence.ts, trace/task-failure-attributes.ts and hosted/schemas.ts all reject anything not in FAILURE_CLASSES. An open union would compile a caller-invented class and then have run-record.ts throw on it at write time.
2. An open type has no blame. FAILURE_BLAME is an exhaustive Record<FailureClass, FailureBlame> precisely so a class cannot arrive with undefined blame — and a missing blame that reads as "not an outage" is the failure this issue exists to fix.

What a caller gets without a release instead: classifyFailureReason(text, rules) takes its own ordered rule set, and each rule may override its class blame. A class this union still cannot name is a defect report worth an issue naming the class, the same way these seventeen arrived.

If you still want the open union, that is real follow-on work worth its own PR: the four validators need a documented policy for an unknown class, and FAILURE_BLAME needs a lookup that answers honestly for one.

Still open in this issue and NOT in the PR: part 2 (outage detection over a run series) and part 3 (the stateless time-expiring hold).