Mechanism reportLifecycle truthProduction verified

Fail-loud runtime

How Kairo separates a response ending from an action succeeding—and preserves machine facts through repair, containment, cancellation, interruption, and settlement.

The historical failure shape

A request could execute a tool, receive a failure, and still end in fluent bounded prose. Earlier lifecycle representations let “the response completed” stand in for “the request completed successfully.” Later recovery phases could also replace the response candidate and accidentally replace the job’s action summary. That was a correctness defect: prose and terminal lifecycle state could both conceal an observed failure.

tool/action attempt → typed terminal outcome ↓ response generation → verification → review → repair/containment/cancellation ↓ JobSettled preserves the earlier action fact

Independent terminal dimensions

Dimension	Question answered	Representative values
Response completion	Did the conversational turn reach an ending?	`completed`, contained, cancelled
Requested action	What happened to the operation the user requested?	`succeeded`, `failed`, `indeterminate`, `not_applicable`
Verification	Was the relevant claim or effect established?	pass, fail, indeterminate
Review	Did the reviewer accept the candidate under the evidence?	pass, fail, indeterminate, revise
Durability	Was persistence confirmed by an authoritative receipt?	confirmed, failed, indeterminate

Coherent failure:
response_completion = completed
requested_action_outcome = failed
verification_state = fail
review_state = fail
outcome = bounded

Authoritative current-turn state

The final-answer model receives a compact, delimited block derived from current-turn machine state rather than reconstructing truth from natural-language tool output. It can explain, apologize, suggest an alternative, or close naturally. It cannot upgrade a failed action into “saved,” an indeterminate write into “stored,” or missing evidence into confirmed absence.

A deterministic contradiction boundary checks claim shape against the typed state. It is state-sensitive and context-sensitive: “I saved that” conflicts with a failed write, while “I couldn’t confirm that it was saved” does not. Quotation, negation, hypothetical discussion, and truthful descriptions of earlier failures are not treated as present assertions.

Repair and bounded fallback

Generate. The normal final voice produces a candidate.
Check. Deterministic invariants compare its factual claims with current-turn outcomes.
Repair once, bounded. The model receives the specific contradiction and authoritative state, without a personality rewrite.
Re-check. Only a resolved candidate may proceed.
Contain truthfully. Repeated failure yields minimal bounded prose, while the job retains every observed action, verifier, and reviewer fact.

Cancellation and interruption obey the same rule. Once ToolFinished establishes a terminal action outcome, no later response disposition may rewrite it to not_applicable.

Evidence

Deterministic failed, successful, and indeterminate tool-outcome regressions.
Exact containment sequence: successful tool → indeterminate verification → reviewer revision → repeated-output containment → settled action remains successful.
Exact cancellation sequence: failed action → failed verification/review → governed cancellation → settled action remains failed.
Authenticated production-path mutation canaries with zero remote writes and durable failed action state.
Real-engine historical-mutation corpus in semantic agreement with machine state.

Boundaries

This machinery is not a universal hallucination detector and does not govern ordinary style. It protects facts the runtime already knows: action outcome, evidence availability, persistence receipts, retrieval status, and related current-turn state. A completed conversation still does not prove successful action, and a passing verifier does not confer facts outside the evidence it reviewed.