Safe Defaults: Designing AI Pipelines That Fail Visibly, Not Silently
The most dangerous failure in an AI pipeline is not the one that crashes the system. It is the one that keeps the system moving. An agent that returns malformed output and gets treated as a success is not a failed agent. It is a hidden approval. Every agent in every production pipeline here has a named failure behavior, defined before it ever runs.
Pipelines designed to keep moving are pipelines designed to silently approve
When a language model returns a malformed response, the pipeline has a choice. It can stop, flag the item, and route it for inspection. Or it can keep moving, treating the malformed response as if it were a valid one. Most pipelines, by default, keep moving. The pressure to ship, the assumption that the model will usually be right, and the difficulty of defining what "wrong" looks like all push toward the same decision: pass it through.
The consequence is silent approval. An image that depicts the wrong subject gets published because the verification step returned an ambiguous result and the pipeline interpreted ambiguity as success. A narration that contains an unverifiable claim enters the review queue because the grounding check timed out and the pipeline moved on. A code suggestion that fails a governance check gets logged as a warning instead of a blocker because the gate was never wired to stop the flow.
Silent approval is structurally worse than a crash. A crash is visible. It stops the pipeline, produces an error, and demands attention. Silent approval produces output that looks correct, passes downstream checks, and may reach production before anyone realizes the upstream step failed.
The solution is not better error handling applied after the fact. It is named failure behaviors defined as part of the agent's specification before it is built.
Every agent has a role, and every role has a safe default
A safe default is the behavior an agent exhibits when its output cannot be verified, its input is malformed, or its upstream dependency is unavailable. It is not an error handler bolted onto an existing implementation. It is part of the agent's contract, specified alongside its primary function.
The key insight is that safe defaults should be conservative with respect to the pipeline's most dangerous failure mode, not its most common one. For a content pipeline, the dangerous failure mode is publishing unverified content. For a governance pipeline, it is approving a decision without adequate review. For an image pipeline, it is associating an image with the wrong subject. The safe default for each agent should make that specific failure mode impossible, even when the agent itself malfunctions.
This means different agents in the same pipeline will have different safe defaults. A scout agent that cannot retrieve data should return empty results, not partial results that look complete. A verification agent that cannot confirm a fact should return a failure, not a conditional pass. A composition agent that produces output it cannot ground should reject its own output, not submit it for review. Each default is calibrated to the specific risk that agent's failure would introduce.
Named failure behaviors across four production systems
Each implementation below illustrates how named failure behaviors are specified at the agent level and enforced at the pipeline level, across different domains and different failure modes.
Four agents, four named defaults
The Big Aloha Guide pipeline uses four agents with Hawaiian names, each with a bounded role and an explicit safe default when that role cannot be completed reliably.
Kiaʻi (guardian, verifies images) defaults to suspect on ambiguous or unresolvable verification. The image is flagged for human review, not passed through.
Kilo (scout, discovers entities) defaults to skip on malformed or unresolvable entity data. The entity is omitted from the candidate set, not included with missing fields.
Nīnau (questioner, builds queries) defaults to empty query on failed query construction. An empty query is never submitted, because a broken query produces worse results than no query.
Haku (composer, writes narrations) defaults to reject on any narration that cannot be substring-grounded against its source. The narration does not enter the review queue at all.
Gates as enforced defaults
MetaGen Auto implements safe defaults through 112 verification gates, grown iteratively from 71 through a series of hardening passes. Each gate defines what the pipeline must verify before proceeding, and what happens when verification fails.
The governing principle is that gates are the contract. A build that breaks a gate stops. It does not log a warning and continue. The gate failure is the signal, and the signal demands a human response.
The most significant safe default in the system is at the merge boundary: the AI never merges its own code. A gate failure at any stage produces a pending human review item, not an automatic resolution. The mutation agent (Glaucon) has a single job when a decision is contested: steelman the rejected option before the human reviews the chosen one. The safe default for disagreement is more information, not auto-resolution.
SHACL as a structural safe default
MetaMuseum's safe default for agent-produced structured data is SHACL validation. Every piece of data that claims to be CIDOC-CRM-compatible JSON-LD must expand to valid RDF and pass the SHACL shapes before it can enter the review queue.
This is a safe default in the structural sense: the system's default assumption is that agent output is invalid until SHACL proves otherwise. A rights conflict, a malformed provenance chain, or a missing required field fails SHACL before a curator sees the record. The default is failure, not tentative success.
The rights agent, Themis, has its own safe default: a rights state that cannot be resolved produces a contested flag on the record, not a rights-clear pass. Unresolved rights are treated as contested, not as unencumbered.
Enrichment failure that does not cascade
Artwork of the Day publishes zero content that is not sourced from Wikidata, Wikipedia, or Wikimedia Commons. The LLM layer was removed entirely when it could not be grounded reliably. That removal is itself a safe default at the architectural level: when a layer cannot be verified, the layer is cut, not patched.
The remaining enrichment architecture is explicitly tested for graceful degradation. If a SPARQL fetch fails, the Wikibase REST layer continues. If Wikipedia is unavailable, the article renders without that section. No enrichment layer failure cascades into a broken page. Each layer's safe default is to omit its contribution, not to block the others.
The system requires zero API secrets and zero paid model dependencies. The safe default for unavailable external services is a fully functional article from open data alone.
Safe defaults are a specification, not an afterthought
The consistent pattern across all four systems is that safe defaults are specified at design time, not discovered at incident time. The Big Aloha Guide's four agent defaults were defined before the agents were built. MetaGen Auto's gate-stops-the-build rule was established before the first gate was written. MetaMuseum's SHACL-or-reject posture was part of the schema design, not a later addition.
This has a practical consequence: the failure behavior is testable. The Big Aloha Guide pipeline has 33 agent unit tests and 20 infrastructure tests, all offline with LLM calls mocked. Those tests include failure cases: what happens when Kiaʻi gets an ambiguous response, what happens when Kilo cannot resolve an entity, what happens when Haku's grounding check returns no matches. The safe default is not assumed to work. It is verified to work.
A safe default that has not been tested is a hope, not a constraint. The same discipline that applies to primary behavior applies to failure behavior: define it, implement it, test it, and treat a broken safe default as a first-class bug.
Four rules for defining safe defaults in AI pipelines
Safe defaults do not emerge naturally from good intentions. They require explicit decisions, made before the agent is built, about what the agent does when it cannot do its job correctly.
- Name the failure behavior before naming the success behavior. For every agent in the pipeline, define what it does when its output cannot be verified before defining what it does when everything works. The safe default is part of the agent's specification, not a footnote.
- Calibrate the default to the most dangerous failure mode, not the most common one. The safe default for a composition agent is not "return what I have." It is "reject output that cannot be grounded," because ungrounded output entering the queue is more dangerous than an empty queue.
- Make ambiguity a failure, not a pass. An ambiguous verification result, an unresolved rights state, a grounding check that times out, these are not successes with caveats. They are failures. The pipeline should treat them as such, routing to a human rather than proceeding.
- Test the failure path as a first-class behavior. Write explicit tests for each safe default. Mock the upstream dependency, produce a malformed response, confirm the agent fails in the named way rather than silently continuing. A safe default that has not been tested is untested behavior in production.
The goal is a pipeline where every failure mode has a known, predictable, human-visible outcome. Not every failure can be prevented. But every failure can be designed to surface rather than hide.
A pipeline that fails visibly is one you can fix. A pipeline that fails silently is one you discover in production, after the damage is done.