AIR load integrity

AIR is prompt-based. You hand a compatible host the current foundation and ask it to boot a project. A capable model can read those files, reproduce AIR vocabulary, and even mimic the onboarding flow while still missing required AIR obligations. The useful distinction is observable conformance: did the foundation validate, did required formal records appear at their trigger points, and did later work remain bound to the active AIR artifact? If not, the run is non-conformant and must be recovered rather than trusted because it sounds right.

What we watched happen

This is not hypothetical. A frontier model was handed the AIR files and asked to start a project. It reproduced the onboarding questions, answered them, and announced the project was active. It used the right words — active step, gate, benchmark, review — and the work it produced was, on the surface, decent. Yet across thousands of lines it never emitted the required AIR records: no AIR_SESSION, no execution map, no artifact — only prose that named those things. At one point it also pressed past the gates and treated a live-page change as already done, with no approval record. Under current AIR rules those are concrete conformance failures. We do not need to infer a hidden internal state to say that; the required surfaced obligations themselves failed.

What made that dangerous was not that the output was bad. It was that the output was good enough to trust — and convincing prose lulls you into believing the governance is real, right up until it does something the governance would never have allowed. Honest-looking is not the same as honest.

What the visible records tell you

A fresh AIR boot has required visible conditions: the foundation files must pass the runtime's load checks, and the formal governance records required at each trigger point must actually be surfaced. Their presence is necessary visible evidence of AIR conformance at that point. They do not independently prove that every prompt law was followed, reveal hidden reasoning, or prove an external action occurred. The complete current AIR_SESSION carries more state than the simplified excerpt below:

{
  "AIR_SESSION": {
    "object_version": "2.0.0",
    "record_class": "SESSION_STATE_RECORD",
    "runtime_origin": "PROMPT_COMPILED",
    "artifact_presence": "NO_ARTIFACT_PRESENT",
    "object_visibility_mode": "ALL_OBJECTS",
    "backend_validation_claimed": false,
    "hidden_reasoning_claimed": false
  }
}

The important point is not that a model is incapable of imitating JSON. It can. AIR defines required records, schemas, transitions, gates, and recovery behavior that can be checked against the current prompt contract. A missing required record is an observable process defect; a present record is a governance record whose claims remain bounded by its evidence.

Default output vs AIR output

Put them side by side and the practical gap is plain. Default-style output may simply announce that a project is active. A conformant AIR run must surface the formal records required by the current runtime when their triggers occur, then keep later work reconciled to the bound artifact. The distinction is contractual and observable, not a claim that we can inspect the model's hidden internal state.

What to do about it

When you boot AIR, check the required record and the load-integrity result. If required boot state is missing, treat the boot as invalid or non-conformant and recover or retry; do not infer a hidden explanation for why it failed. Host behavior varies: some models refuse the files, some boot cleanly, and some miss required AIR obligations. If a host refuses AIR or repeatedly fails the checks, tell us in Discussions — those reports help keep the compatibility picture honest.

Why this is the point

A product about honesty has to be checkable, or it is just another claim. AIR's formal records give you an inspectable contract surface: what state was declared, what was blocked, what was approved, and what evidence was cited. That does not prove hidden execution or correctness by itself. It does make failures such as missing records, broken binding, skipped approvals, and unsupported external-action claims visible enough to challenge and recover.