Fail-closed outcomes
When stop is a successful agent outcome
Agent dashboards often color anything short of completion red. That incentive is dangerous: when authority or evidence is missing, continuing is the failure. A precise stop is the correct result.
A stop can preserve the boundary
Imagine a worker receives an approved canary change, but the requested continuation now includes production. The worker should not trim the request silently, infer broader intent, or proceed because the transport delivered it successfully. It should return SCOPE_CONFLICT, identify the packet and decision it evaluated, state that successor work did not begin, preserve the evidence, and name the human action that could unblock the workflow.
Common reasons to stop
| Condition | Useful outcome |
|---|---|
| A real decision is presented, but it does not establish the required bounded authority | MISSING_AUTHORITY; no successor start. |
| Packet or decision is stale | STALE_PACKET; return the mismatch for review. |
| Requested scope exceeds approval | SCOPE_CONFLICT; do not narrow or widen silently. |
| A relationship is only caller-asserted | UNVERIFIED_ASSUMPTION; do not manufacture the chain. |
| Required runtime or tool boundary is unavailable | Stop with the environment evidence and an unblock path. |
| External outcome is uncertain | Report ambiguity for a human decision; do not infer safe retry. |
The minimum useful stop response
- A closed reason code and human-readable summary.
- The task packet and real decision identity that were evaluated.
- Evidence references and the failed boundary condition.
- An explicit statement about whether successor work began.
- The disposition: terminal, retryable under stated conditions, or returned for human decision.
- A concrete unblock path that does not invent new authority.
The candidate stop-response schema makes that result machine-checkable. The public fixtures include a pre-start stop and a later human response as separate bundles. A response decision can record what the human chose next; it does not rewrite the earlier stop.
A known candidate gap
The current schema requires decisionId. In HACP v0.3-candidate that field is only the identity of a real human-decision record presented or evaluated as the authority basis. It is not a decision digest and proves neither authenticity nor sufficiency. A stop before any decision exists cannot be represented honestly under this shape; producers must not invent a sentinel. Issue #52 tracks a future contract.
What this does not prove
- A stop’s no-start assertion does not prove absence of activity outside the declared evidence boundary.
- Not every failure is retryable or recoverable.
- Transport acknowledgement does not prove the agent read or understood the request.
- A decision identity alone does not prove current, revision-exact authority.
- The candidate does not cover a pre-decision or no-decision stop.
Review the valid stop bundle and the negative spliced-packet case.