Symptom, cause, action — and when the refusal is right.

1. 01

   The run stops before a belief, and there is no receipt at all.

   Cause

   A fact was published after the decision time. Evidence is admitted against the decision clock, not the wall clock, so the run refuses before inference rather than learning from its own future.

   Action

   Compare the availability time on the evidence with the decision time you asked for. If the fact genuinely arrived later, the refusal is correct; if you meant to decide later, move the decision time with the evidence, not the other way round.

   In the output · A named error line and a non-zero exit. No partial receipt and no history record exist to clean up.

2. 02

   The run abstains and names the mandate instead of acting.

   Cause

   Either no authority was presented for the requested effect, the authority had already expired at the decision clock, or it was malformed or internally inconsistent.

   Action

   Check that a mandate is present, that its expiry is after the decision time, and that it permits the effect being requested. Expiry is read at the decision clock, not at the moment you run the command.

   In the output · decision=abstain with the reason on the abstention line — missing_mandate, expired_mandate, or invalid_mandate. The run still settles and still counts.

3. 03

   Promotion was rejected and nothing was decided.

   Cause

   The candidate’s coverage on the held-out cases fell below the declared floor. Abstentions are counted in that figure, so declining hard cases cannot raise it.

   Action

   Read the evaluation with abstentions included and ask why the candidate declined the cases it did. A lower floor is a policy decision, not a troubleshooting step; changing the data or the candidate is the honest fix.

   In the output · rejection=coverage_below_floor, decision=none, evaluated=true, settled=false. The local verified count does not move.

4. 04

   Promotion was rejected even though the candidate looked strong in development.

   Cause

   Promotion was attempted on development evidence, or the development and holdout case identities overlap. In-sample fit can never promote a candidate.

   Action

   Evaluate on the sealed out-of-sample cases, with development and holdout identities kept disjoint. A stronger in-sample number is not evidence.

   In the output · rejection=dataset_not_oos. The holdout stays sealed, and nothing downstream of the gate runs.

5. 05

   A repeated request was refused instead of completing.

   Cause

   A retry presented a known idempotency key with a different requested effect. Failing closed is the point: repeating the effect would be the defect.

   Action

   Read the original receipt back with the same key and the same request, or use a fresh key for a genuinely different request. Do not edit the key on an existing run and expect a second effect.

   In the output · A named idempotency conflict. The original receipt stands, and no second execution is recorded.

6. 06

   A receipt document was rejected before the merge gate.

   Cause

   One of four things: the document is absent or empty, its schema string or fields are wrong, a field breaks its declared law, or its content seal does not match its payload.

   Action

   Ask the authority that owns the document to re-emit it. Do not hand-edit it: the seal covers the payload fields, unknown fields are rejected rather than ignored, and a repaired document will not verify.

   In the output · error=missing_receipt, schema_mismatch, field_invalid, or digest_mismatch, each naming the flag it came from. No metric is printed.

7. 07

   The door refused a wake and ran nothing.

   Cause

   The wake did not present a usable bearer tick, or it presented a token the door cannot verify. Verification against the Compute-published key set is not implemented at this revision, so every presented token is refused.

   Action

   Post to the declared wake route with the declared method, and expect the refusal while the schedule is paused. The refusal is counted, so the health document shows that the door saw the wake.

   In the output · 401 compute_tick_bearer_required without a tick, 501 tick_verification_unimplemented with one. Nothing else about the request is interpreted.

8. 08

   You expected a token to be checked against a published key set, and no check happened.

   Cause

   The door refuses every presented token before any key lookup, because the signed-tick verification does not exist yet. A key set that cannot be fetched is therefore unreachable today rather than unhandled.

   Action

   Treat the refused wake as the expected outcome at this revision. The recorded requirement is that a bad, absent, or unverifiable tick keeps failing closed and prints no metric, so an unreachable key set must never become an accepted tick.

   In the output · The same two refusals as any other wake, and grows wakes_refused. If a wake ever runs without a verified tick, that is the finding worth reporting.

The complete list of boundaries, with the scenario token that reproduces each one, is in the refusal reference. The flags each mode takes are in the command reference.