Output Validation¶

Runtime output procedure — instantiates Domain–Codomain Delimitation

A runtime check on each produced result that confirms it lies inside the declared codomain before release — and blocks, qualifies, or reroutes anything that doesn't rather than letting it reach downstream reliance.

Output Validation is the boundary applied to what a unit emits, at the moment it emits it. It is the output-side twin of an input gate: after the core has computed a result, this check confirms the result actually lies within the declared codomain — right categories, in-range values, no forbidden content — and decides whether to release it, qualify it, reroute it, or block it outright, before anyone downstream relies on it. Its distinguishing point is that it defends against the unit's own out-of-codomain outputs, which structural checks alone miss: a result can be perfectly well-formed and still be a value the codomain never promised. It exists because the most dangerous bad output is the one that is shaped correctly and simply wrong.

Example¶

An automated pricing engine computes a price for every item before it reaches checkout. Its Output Validation runs on each computed price: the codomain says a price must be a positive amount within a sane band relative to cost, in the item's currency. Most results pass and are released. But a mispriced product feed combined with a rounding bug produces \$0.00 for a normally-$400 item — structurally a valid price, catastrophically out of codomain. Output Validation catches it at the boundary: rather than emit \$0.00 to the storefront, it blocks the value and reroutes the item to a manual-review fallback, so the checkout never shows a free product. A separate result that comes back slightly outside the band is qualified — released but flagged for review — rather than blocked. The check has kept the engine's own bad output from becoming a downstream commitment.

How it works¶

The check evaluates each produced result against the codomain's value-level rules (ranges, category membership, invariants, forbidden content), then routes on the verdict: pass → release; borderline → qualify or hold; out-of-codomain → block and divert to a safe fallback. The disposition is the point — validation without a defined action for a failing output just relocates the failure. It runs last, on the value the core actually produced, which is why it catches computation errors, model hallucinations, and boundary violations that no up-front declaration could anticipate.

Tuning parameters¶

Block vs. qualify vs. clamp — what happens to an out-of-codomain result: hard block, release-with-flag, or coerce into range. Clamping keeps things flowing but can hide the underlying fault; blocking is safest but can stop legitimate edge outputs.
Fallback behaviour — what is emitted when a result is blocked (a safe default, a held state, an escalation). A good fallback degrades gracefully; a missing one turns a blocked output into an outage.
Strictness of value rules — how tightly ranges and category checks are drawn. Tight rules catch more bad outputs but raise false blocks on rare-but-valid results.
Coverage — how many outputs are checked and how deeply. Full coverage is safest; sampling is cheaper but lets some bad outputs through.

When it helps, and when it misleads¶

Its strength is that it is the last line before reliance: it catches the well-formed-but-wrong result — the negative-of-a-positive, the hallucinated citation, the price of zero — that structure checks and type systems wave through, and it converts a silent bad output into a controlled, safe response. Its failure modes are the mirror of an input gate's. A default of clamping rather than blocking can mask a real defect, letting a broken producer keep shipping "fixed-up" outputs indefinitely; the safer default when a result can't be validated is to fail closed — withhold rather than release.^[1] Over-strict rules block legitimate rare outputs; under-coverage lets bad ones slip. The discipline is to route every blocked output to a defined fallback (never a silent drop), to prefer fail-closed on high-stakes outputs, and to treat a spike in blocks as a signal about the producer, not just noise to suppress.

How it implements the components¶

output_conformance_rule — applies the codomain's value-level rules (ranges, categories, invariants, forbidden content) to each produced result at emit time.
safe_rejection_or_deferral_path — defines what happens to a non-conforming output: block, qualify, or reroute to a safe fallback rather than release it downstream.

It checks values, not structure — the declarative shape of the codomain is Output Schema — and it acts on the output side only; the input-side runtime check is Input Validation Gate, and governing why outputs keep failing is Scope Change Review.

Instantiates: Domain–Codomain Delimitation — Output Validation enforces the codomain on live results.
Consumes: Output Schema supplies the declared codomain whose value-level rules this check applies.
Sibling mechanisms: Input Validation Gate · Output Schema · Contract Test Suite · Type Signature · Service Scope Statement · Model Applicability Card · Eligibility Criteria · Clinical Indication Criteria · Scope Change Review · Unsupported Case Triage Workflow

References¶

[1] Fail-safe / fail-closed design — when a component cannot confirm a safe result, it defaults to the safe state (withhold, deny, stop) rather than the permissive one. Applied to outputs, it means an unvalidated result is withheld rather than released, which is why "block by default, clamp only deliberately" is the conservative stance. ↩