Failure Detection
Our reliability layer attempts to detect when a workflow has entered an invalid, incomplete, unsupported, or unexpected state before downstream execution continues.
Conditions
Failure conditions can include invalid output, a missing source, tool failure, timeout, contradictory evidence, unsupported claims, and unexpected state.
The system should detect failure rather than silently continue.
Failure classes
Different failures require different responses.
- Malformed output → retry / alternate parse
- Tool unavailable → fallback / retry
- Missing evidence → retrieve / escalate
- Contradiction → review
- Invalid state → stop
- Timeout → resume / fallback
A generic error state is often insufficient. The more precisely the system classifies the failure, the more safely it can decide whether to retry, route elsewhere, request review, or terminate.
Unsupported claims
Some failures are syntactically valid. A model can return well-formed output containing a conclusion that is not supported by the available evidence. Citation or provenance checks can help detect this class of failure even though the response itself looks normal.
Contradictory evidence creates a related condition: the system may have enough information to answer, but not enough agreement to answer safely.
Unexpected state
Automation must also detect when the surrounding business system is not in the state the workflow expected. A write should not proceed merely because the model proposed it if the underlying record changed after the analysis was prepared.
State checks can convert hidden race conditions into explicit failures.
Reliability posture
Failure detection does not guarantee recovery. Its first responsibility is to prevent silent continuation. Once a failure is visible and classified, the system can apply fallback, exception routing, escalation, rollback, or human review appropriate to the consequence.
A system that knows when it failed is materially more controllable than one that produces fluent output through an invalid state.
Detect before recover
Failure detection and recovery are separate capabilities. The first responsibility is to establish that the current result or state should not be trusted. Only then should the system decide whether to retry, route to another model, request more evidence, roll back, or escalate. Combining those decisions too early can hide repeated failure behind repeated retries.
For example, a missing source should not necessarily trigger the same response as a timeout. Contradictory evidence should not be handled like malformed output. Distinct failure classes allow different recovery policies and different observability.
This matters operationally because the reliability of the system depends not only on successful executions, but on whether unsuccessful executions terminate visibly, safely, and with enough state preserved to diagnose what happened.