Skip to decision

GAP-04 · Agent architecture

Structured Output Reliability Gate

Follow one authored output from a schema failure to a corrected field.

Current decision

This authored output passes the supplied schema

Inspect the exact fields and validation errors. Editing source text does not run a model, and no record is written.
Schema fields
6
Changed fields in retry
0
Source state
Supplied example

Same instrument · 3 industries choosing a scenario replaces its inputs; save or share your current changes first

Prefer to read? The two minute case study · problem → approach → metric → outcome

Problem

Enterprise systems cannot absorb malformed writes because a model response looked plausible. Structured output requires schema validation, error handling, corrective retry, and a clear decision about when to stop automation and escalate.

Approach

The artifact runs representative tasks through a schema validation workflow. It shows where raw model output fails, how a corrective retry repairs it, and what tradeoff the retry introduces.

Why this way

This connects model behavior to operational reliability, auditability, downstream system integrity, and the cost of failed automation.

The metric

Schema valid rate at the gate; repair success rate; escapes downstream.

The trade-off

A strict gate adds retries and latency; a loose one lets bad data write to systems of record.

Outcome

A clear answer on where to place the validation gate and how strict to make it.

Raw input

Target schema

  • enum(open_dispute|status|general)*
  • string|null*
  • number|null*
  • enum(positive|neutral|negative)*
  • enum(low|med|high)*
  • string*

* required key must be present (nullable where typed).

Select Inspect example to inspect the supplied extraction. Custom drafts are never presented as extracted output.

Where the gate sits

Model

raw JSON

Validate

schema + retry

System of record

only valid passes

Read the complete supplied field comparison
Authored extraction values — not an extraction of edited text
FieldFirst attemptAccepted exampleChange
intentNo separate attempt"open_dispute"Unchanged / first pass
account_idNo separate attempt"ACCT-0021"Unchanged / first pass
amount_usdNo separate attempt214.5Unchanged / first pass
sentimentNo separate attempt"negative"Unchanged / first pass
priorityNo separate attempt"high"Unchanged / first pass
summaryNo separate attempt"Cardmember disputes a $214.50 charge from GLOBEX DIGITAL; wants a dispute opened."Unchanged / first pass

If you act on this · the call → expected lift → how you'd measure it

The call

Place a validation gate before any model output writes to a system of record.

Expected lift · illustrative

Raises system ready output reliability through schema enforcement and corrective retry.

How you'd measure it

Validation pass rate, retry rate, failed write prevention, latency added, escalation rate.

The retry is the reliability

The first pass is often almost-right, a string where a number belongs, a missing key. A validation gate with a single corrective retry turns “usually valid” into “always valid or explicitly flagged.” That's the difference between a demo and production.

Steering committee takeaway: If model output updates a system of record, validation is not optional. It is a reliability control.

How this is built

Each sample targets a JSON schema (typed, nullable, required keys). The output is validated key by key; on failure the errors are fed back in a corrective retry and re validated.

Extractions are authored and deterministic (not live model output); the hard sample's first attempt is constructed to fail schema validation so the corrective retry is visible. A live model variant is designed for but not wired today, so the badge stays SIMULATED.

Stack: Next.js (static) + shared design system; client side.

Limitations: this model demonstrates validation behavior with authored tasks. Production use would require real schema contracts, logging, retry policies, exception handling, and system integration.