How AIR works.
AIR is a prompt-based project runtime for governed, continuous AI work. It gives a compatible host model an explicit working contract before the work is generated: what is active, what is allowed, what evidence matters, what needs approval, and what state must survive the session.
AIR is part of the working context.
AIR is not a post-processing layer that waits for a raw answer and rewrites it afterwards. In prompt-compiled operation, the AIR foundation, project state, sources, conversation, tool results, and current request are all part of the context the host model interprets when it produces the next response or action proposal.
Govern and structure the work.
Bind the active task, preserve scope and constraints, establish approval and evidence requirements, surface blockers, and keep continuation state explicit. AIR 2.5 also uses MII — Mathematical-Informational Intelligence — to select task-relevant cognitive routes such as multi-lens analysis, risk propagation, adversarial disconfirmation, trade-offs, uncertainty and evidence triangulation.
Perform the work.
Reason, draft, analyze, generate, call available tools, or execute through host capabilities inside the current AIR contract. Capability comes from the model and host; AIR structures how it is applied. MII describes observable prompt-layer cognitive routing, not hidden chain-of-thought access or human-equivalent intelligence.
The model does the work. AIR governs the work.
One material task is allowed to be current.
AIR keeps a single bound Orbit 0 artifact as the positive execution center. Other ideas, queued tasks, specialists, methods, cognitive contributions, and available tools do not acquire project authority merely because they exist.
The work that may move.
The current artifact carries the task, scope, relevant sources, constraints, acceptance conditions, approval boundaries, and execution state for the material work in front of AIR.
Available does not mean bound.
Queued work stays queued. Capability packages stay unbound until selected for task fit. MII routes and specialists contribute candidate material rather than independent authority. A tool may be callable without being authorized for the current action.
From request to reviewed result.
The exact ceremony scales with the stakes, but the ordering keeps current intent, evidence and high-consequence decisions ahead of execution.
Align and frame the work
Every post-activation user turn begins with current alignment. AIR reconciles the incoming request with the bound state, preserves the user's intent and context, and routes material uncertainty to the smallest needed clarification, source, evidence, permission or other missing input instead of silently guessing.
Bind the active task
AIR narrows the next material unit of work into one current artifact so scope, authority, evidence requirements, completion conditions, and the evaluation basis have a single center.
Select cognition and specify before consequential execution
AIR can select task-relevant MII cognitive routes and task morphology. Where the work changes behavior or carries material risk, it also establishes what must be true and how that claim will be verified before treating implementation as ready to proceed.
Execute inside the contract
The host model performs the work with the sources, capabilities, cognitive contributions, methods, and tools that are relevant and permitted for the bound task. Missing authority, evidence, or required input blocks only the affected action.
Verify and review
AIR reconciles delivered work against the specification, evidence, acceptance criteria, and resolved original intent. Tests and AIR records support only the claims their evidence actually establishes.
Continue or hand off
When the session ends or the work moves, a Handoff Card serializes the explicit continuation state. A receiving compatible AIR session validates current conditions and rebinds that state before material work resumes.
Governed does not mean guaranteed.
Prompt AIR can materially shape a capable host model's behavior, but the prompt layer is still interpreted by the host model. AIR therefore keeps its claims proportional to the evidence available.
A reviewable working contract.
Declared scope, task state, assumptions, gates, approvals, evidence posture, validation state, blockers, action records, cognitive contribution state, and continuation state can be surfaced for inspection.
Proof from a prompt record.
AIR does not claim hidden chain-of-thought access or deterministic backend enforcement in prompt-compiled mode. Claims about code execution, deployments, sources, security, tools, or other external events require corresponding external evidence.
Follow the question, not the jargon.
This page owns the operating model. The detailed mechanics live where they belong.
Where AIR fits
Compare AIR with raw chat, SDD harnesses, agentic engineering environments, and agent runtimes.
See the category map →AIR documentation
Look up routing, MII, onboarding, objects, modifiers, packages, Handoff, compatibility, and formal runtime details.
Open the reference →Specification-First Verification
See the specification, verification, adequacy, execution, and reconciliation loop in detail.
Open SFV →See the model in use.
Boot AIR yourself, or inspect an observed AIR session before you do.