Contracts before generation

Generated code is a proposal. A contract describes what the receiving system will accept. Keeping those two ideas separate makes an integration easier to reason about.

Consider a function that creates an order. A language model can propose an object with the right-looking fields. That does not establish that the fields have the right types, that the values satisfy the application rules, or that the caller is allowed to create an order.

Three different checks

A schema check asks whether the object has an acceptable shape. A policy check asks whether the requested action is permitted. An execution check asks whether the external system actually accepted it.

Those checks answer different questions. Passing the first does not imply passing the other two.

type Decision =
  { allowed: true; orderId: string } | { allowed: false; reason: string };
 
function requirePositiveQuantity(quantity: number): boolean {
  return Number.isInteger(quantity) && quantity > 0;
}

The function above is intentionally small. It establishes one property of one value. It says nothing about inventory, payment, identity, or an external API's availability.

A boundary that can be inspected

One useful arrangement is to preserve the proposed input, the validation result, and the external response as separate records. When something goes wrong, this lets an engineer ask where the expectation stopped matching reality.

Versioning the contract adds another piece of context. An input accepted yesterday may be rejected after a field becomes required. The version belongs with the evidence, not only in a release note.¹

What this does not establish

A valid schema does not prove that an integration is useful, secure, or correct in every situation. It gives the rest of the system a smaller, more explicit starting point.

This note is an initial editorial example for the archive, not a report of measured project results.