Mechanics 4 of 8 · 2 min read
Parse the Proposal, Then Assess It
A structural contract makes model output usable without confusing format, evidence, and authority.
Part of our current product model. These essays explain responsibilities and required checks, not a certification of deployed behavior.
Before a system can assess a model's proposal, it needs to know what it received. A paragraph that sounds like an approval is not an approval record. A capacity value without a unit or source is not enough to evaluate a plan.
An output contract makes those expectations explicit. The boundary accepts a value that conforms to the structural contract or records a failure that callers must handle.
Structure is the first check
For the delivery example, an illustrative proposal could identify the specification version, candidate allocation, resource snapshot, and supporting evidence references. These are conceptual fields, not a published API.
The parser can check required fields and data shapes. Later checks must establish whether the references resolve, whether the units agree, whether the resource information is current enough, and whether the evidence supports the claim.
Even a perfectly structured object can contain a false statement.
Do not smuggle authority through a field
A model can produce text that says “approved,” include a person's name, or assign itself a high confidence score. None of those values demonstrates an authorization decision.
The system must obtain and check authority through the governed boundary. Model-produced narrative remains a contribution to assess, even when it appears inside a typed object.
Keep proposal records and binding commitments distinct so application code cannot casually treat one as the other. Structural separation helps; it does not replace enforcement of the actual mandate.
Make failure visible
Malformed output should produce an explicit failure outcome. A retry needs a budget and a recorded relationship to the failed attempt. It must not silently invent missing values or convert an absent result into success.
A structurally valid proposal can still fail semantic or evidence checks. Record which stage rejected it and why. That distinction helps determine whether to change the output contract, clarify the specification, obtain better evidence, or try another contributor.
Test each boundary separately
Use examples of missing fields, unresolved references, wrong versions, and well-formed but unsupported claims. Test that none becomes a commitment merely by passing the parser.
A common output contract can make contributions from different models easier to compare. It does not make their reasoning equivalent or guarantee that any model will satisfy the contract on every attempt.