What Is Output-Contract Validation?

Definition

Output-contract validation is the boundary check that decides whether a generated result is admissible to the next step, using a contract fixed before the run.

It is not a review of quality — it is a test of admissibility, computed at the moment of the run without a person judging it.

What it is not

An output contract is not a design-by-contract precondition — design by contract places obligations on the caller and the routine, while an output contract places them on the result that may cross a boundary.
An output contract is not a schema — a schema describes the shape data may take, while the contract also names the source a result must have come from and the action it is allowed to trigger.
An output contract is not a contract test — a contract test compares two systems across a change, while validation runs on every execution at the step boundary.
Output-contract validation is not verification — verification asks after the fact whether an output was correct, while validation asks at the boundary whether it is admissible.
An output contract is not a general guardrail — the guardrail is the enforcement around a step, while the contract is the standard that enforcement applies.

How it works

The contract is a document before it is a check, and it is a standard before it is a verdict. Six things happen in order.

It is written down first. Before the step runs, the process definition names the fields a result must carry, the range it must fall in, the source it must have come from, and the action it may trigger. Nothing is validated until those conditions exist in writing.
The owners agree to it. The team that runs the workflow and the business that depends on the result both accept the contract, in the way a contract between two parties is settled before either side performs. It is not inferred afterward from what the output happened to look like.
The check runs at the boundary. Validation sits between the generated result and the system of record. The reasoning upstream may vary; the test applied to whatever crosses is fixed, and it is computable at the moment of the run.
Every run writes a verdict. Each validation produces a pass or fail, with the failing condition named, so the outcome can be traced rather than recalled. The contract a result satisfied becomes an artifact, not a memory.
A failure blocks the write. A result that does not satisfy the contract does not reach the record. The default is not to write and inspect; it is not to write.
Failures count, and they surface early. A blocked run appears in telemetry as a failure. Because the block happens while the input and the run are still in hand, the cost is contained instead of travelling downstream into a record, a report, or a conversation.

Worked example

Consider a workflow that reads incoming support messages, decides which ones are refund requests, extracts the amount, and writes a case into a finance system. During design, the people who own the process write the output contract for the extraction step. A valid result must carry the ticket reference it came from, an amount the finance system can store, and an action drawn from a short list the process allows.

The contract is not a description of a good answer. It is the set of conditions a result must satisfy before the step is allowed to have an effect. A result that satisfies it continues to the write. A result that does not is blocked at the boundary, while the message, the run, and the version of the contract are still available.

Suppose the extraction step returns an amount and a confident-looking classification, but the ticket reference is missing. The result may be plausible; it is not admissible. The validation fails, the write does not happen, and the run records the failing condition and the contract it was checked against. The message is routed to a person rather than dropped.

The record is what makes the event reviewable. It shows which run produced the result, which contract version applied, and which condition failed. Nobody has to reconstruct afterward whether the output looked reasonable. The contract says what may be written, and the failure says what was stopped.

Common questions

What is an output contract?

An output contract is a written statement, fixed before a step runs, of what a valid result of that step has to satisfy. It names the fields a result must carry, the range it must fall in, the source it must have come from, and the action it is allowed to trigger. Only results that meet those conditions are passed.

What is an output contract example?

A support workflow that extracts a refund amount from a message can require every result to carry the ticket reference, a storable amount, and an action from an approved list. A result with a missing reference is blocked before it reaches the finance system, and the run records which condition failed.

What does output-contract validation actually check?

It checks admissibility, not quality. The question is whether a result is the kind of result this step is permitted to produce, given the contract written in advance. That question has a definite answer at the boundary, computable during the run without a person judging it. A result that looks convincing but breaks a condition is still blocked.

Is output-contract validation the same as verification?

No. Verification asks after the fact whether an output was correct, and that judgment needs context, expertise, and time. Output-contract validation asks at the boundary whether a result is admissible, and the pipeline runs that test itself on every execution. Only the second can sit inside a running process and hold it to a standard each time.

What happens when a result fails validation?

The result is blocked before it reaches the system of record, and the run records a fail with the failing condition named. Blocked runs count as failures in telemetry rather than being excluded. The input and the run stay available, so the cause can be examined and the result routed to a person.

How Opsyl implements it

Stated in scope. The contract is defined during scoping, approved by the client, and fixed before the pipeline runs. It is not inferred from behavior afterward.
Per step, not per system. Each step in the graph — ingest, decide, validate, act, record — has its own notion of a valid result, checked at its own boundary.
Blocked before the write. A result that fails validation does not reach a system of record. The default is not to write and inspect; it is not to write.
A recorded verdict. Every validation produces a pass or fail on the run, with the failing condition named, so the outcome can be traced rather than recalled.
Failures count. Blocked runs appear in telemetry as failures. Nothing is excluded to make the numbers look better, and the client sees the same figures Opsyl reports against.

The claim the system works to is unchanged by the step it is applied to: AI is probabilistic, our pipelines are not. Output-contract validation is where that claim is enforced on every run — not by making the reasoning reliable, but by making the boundary between reasoning and record non-negotiable. It is also what makes ownership possible: when a review, an auditor, or leadership asks why a record exists, the answer is the contract the result satisfied and the check it passed, written before the run rather than assembled after it.

Where this connects

Output-contract validation is the test; Guardrails are the enforcement around it — the checks that keep a step from proceeding when the test fails. Both sit inside the Operating Layer and make up the enforceable half of Agent Governance: a contract states what may be written, and the record proves what was. When validation blocks a result, the run does not end there — it continues on the path described in Human-in-the-Loop.

Sources

Retrieved 2026-09-27.

What is JSON Schema? — JSON Schema, states that a valid result can be described declaratively, before it exists.
Design by Contract Introduction — Eiffel Software, describes a contract as benefits and obligations that each party accepts.
Contract Test — Martin Fowler, describes tests that check calls against a test double return the same results the external service would.

The commercial consequence

A pipeline is only as dependable as the standard its outputs have to meet, and that standard has to exist before the pipeline does. The first paid step with Opsyl is the Agentic Ops Audit: a fixed-scope week that maps the operation and returns a written assessment naming where a contract would remove the most risk. The contracts any build runs on start from that assessment, and you keep it whether or not you build.

Start with the audit →

→ Related: Guardrails · Operating Layer