Declare an interface fit for consumption by an autonomous or AI system

In plain terms

Judge whether an interface is described accurately and completely enough that a consumer unable to ask questions can act on it correctly. This replaces the consultation a developer used to perform by asking the team that owned the system.

What is being judged

Not whether the interface works. Whether it is intelligible without judgment.

A human developer arrived with context, patience and a route to ask. A specification that was mostly complete was sufficient, because the gap closed through intuition, a ticket or a conversation. An autonomous consumer has none of that. It has the surface and nothing else.

So the acceptance test is narrow and specific:

Could a consumer with no context beyond this specification, and no way to ask a question, act correctly on every field and every error it will encounter?

Four things carry the judgment.

Descriptions that are true. A field described as customer_status returning one of six enumerated values, three of which are undocumented, will be used confidently and wrongly. Under human consumption this was a documentation defect. Under autonomous consumption it is an input integrity defect, and nothing surfaces, because nothing was confused.

Examples that are real. A schema example carrying placeholder data teaches a shape and hides a convention. Dates, nullability and units are where this bites.

Errors that are documented. Every response code the consumer can receive, with a cause and what to do. Undocumented errors are where autonomous consumers fail silently, because there is no path from an unexpected response to a question.

Relationships that are explicit. Where two operations must be called in order, or where one field’s meaning depends on another’s value, that has to be stated. A human infers it. A consumer without judgment does not.

Why the Data Steward and not architecture

Architecture owns whether the contract is well-formed: it validates, it versions, it follows the standard. That is L2-04.

Whether a decision may rest on what the contract returns is a data judgment, and it follows the same pattern already applied to data domains at L3-03. An interface no steward has assessed is an unassessed model input.

What this decision does not cover

It does not approve the interface for use generally. Human consumers are unaffected by this declaration.

It does not classify the action surface. Whether an autonomous consumer reads through this interface or acts through it is set by the contract standard at L2-04, and an action-bearing interface carries additional requirements beyond fitness.

It does not authorize the AI system to call it. That follows from the deployment authorization.

When it fires

On event. Before an AI system first consumes the interface. On any change to the schema, the enumerated values, the error set or the authentication method. On a breaking change under L2-08, which should invalidate the record rather than survive it. See finding 1 at section 4.

On cycle. At the review date stated in the record.

What you need before deciding

• The current interface specification, machine-readable
• The list of fields the consuming system actually reads, which is usually narrower than the interface offers
• The error set, and evidence each documented condition is reachable
• The action surface classification
• Which data domains the interface exposes, and their fitness declarations

How this goes wrong

The ninety-percent specification. Complete enough that human developers integrate successfully, and has been for years. The autonomous consumer produces confident wrong output on the undocumented remainder and raises no ticket, because nothing was confused. Detected by listing fields with no description, then checking whether any AI system reads them.

Fitness declared once and never revisited. The record has a review date. The interface changed twice before it arrived.

Fitness for the wrong consumer. An interface declared fit for one model is treated as fit for all. Fitness is a judgment about whether the description supports the use, and a different consumer reading different fields is a different question.

Assessing the interface nobody uses. The catalog lists twelve interfaces and the model reads four of them directly and two through a cached copy nobody catalogued. Shadow data access, and it is why the Layer 1 reconciliation exists.

Related decisions

Upstream L2-04 interface contract standard. L2-01 integration pattern.

Downstream L3-01 model release to validation. L4-AUT-01 production authorization.

Invalidating L2-08 breaking change.

Parallel L3-03 data domain fitness, the same judgment applied to data at rest.

Instrument references

No instrument addresses interface completeness for a consumer that cannot ask questions. TOGAF predates the condition. ISO/IEC 27001 A.8.26 addresses whether an interface is secure, not whether it is intelligible. Recorded as gap 2 in the consolidated crosswalk.