← Explore AIR Technical reference

The AIR reference.

This page maps the current public AIR runtime into human-readable reference form. It tells you what the pieces are and how they relate; it does not duplicate every canonical schema or runtime law. The public repository remains the operative source of truth.

AIR Kit v0.6.0 · Core 2.5.0 · Control 2.5.0 · Governance 2.3.0 · Starter 2.5.0 · Handoff schema 2.3.0

Source set

AIR's public foundation is split by responsibility so visible interaction, governance, starter defaults, and serialized continuation do not become competing sources of runtime authority.

File	Current version	Owns
Core Runtime	2.5.0	Canonical runtime law, route/dependency semantics, MII, object classes, lifecycle and Orbit state, binding, gates, evidence boundaries, Handoff restoration, action governance, and floor invariants.
Control Surface	2.5.0	Visible interaction and rendering. It is subordinate to Core and additive Governance requirements.
Governance supplement	2.3.0	Approval-scope meaning, authority non-transfer, governance sources, framework projections, evidence/claim discipline, and governance state carried through Handoff.
Default Starter Profile	2.5.0	The default project/task composite used during startup. Availability does not itself grant execution authority.
Handoff Card Template	schema 2.3.0	The serialized transfer schema for explicit continuation state.

Foundation-adjacent catalogs: AIR Kit v0.6.0 also publishes AIR_RUNTIME_ROUTE_MAP.json 1.0.0 and AIR_SPECIALIST_PACKAGE_INDEX.json 1.1.3. They are discovery/salience surfaces, not Foundation prompts, and have no independent execution, binding, selection, approval, or semantic authority.

Terminology: the canonical Core describes AIR as a prompt-layer compiler/runtime contract. On this site, “prompt-based project runtime” is the shorter human-facing description. Neither wording implies hidden reasoning access or backend enforcement without evidence.

Boot & onboarding

A fresh AIR project begins by validating the current foundation, surfacing required boot state, and asking the onboarding sequence without silently inferring the user's answers.

Load the current foundation

All required files must be completely available to the host. A missing or truncated required file is a load-integrity problem, not an invitation to guess around the missing law.

Start AIR

A recognized new-project activation surfaces required boot evidence, then the exact welcome line, then Q1. The boot record is visible runtime evidence; it is not hidden-model telemetry.

Resolve Q1–Q6

AIR asks one question at a time. Answers may be explicitly provided, restored from valid Handoff state, or visibly proposed for user approval where runtime law permits. Material onboarding state is not silently inferred.

Compile and bind the project state

Onboarding produces project orientation and a current artifact candidate. Material project execution begins only after one Orbit 0 AIR_ARTIFACT is successfully bound for active execution.

Question	Purpose
Q1	Choose new project, import, Handoff continuation, or orientation.
Q2	Set checking rigor.
Q3	Set how non-material ambiguity should be handled; it never authorizes silent material inference.
Q4 / Q4D	Set continuity style and, when selected, the neurodivergent delivery modifier while preserving an underlying continuity mode.
Q5	Describe the project and provide sources or authoritative inputs.
Q6 / Q6D	Define the human–AIR working agreement: responsibilities, delivery, challenge, explanation, approval boundaries, and optional functional delivery calibration.

Use the short boot guide →

Neurodivergent delivery

Q4=D is an interaction and delivery modifier, not a diagnosis, identity label, lower-rigor mode, or separate execution authority.

Q4D base mode

Keep the underlying continuity choice

Q4D=A uses structure and logic; Q4D=B uses structure and tone; Q4D=C uses creative narrative continuity. The modifier sits on top of that base mode rather than replacing it.

Q6D calibration

Define how the work reaches the user

Q6D retains ordinary Q6 responsibilities and can additionally record information presentation, side-track handling, focus-drop response, momentum intervention, communication needs, break-contract state, and other project-scoped delivery preferences.

The modifier may use clear chunking, explicit transitions, critical information first, layered detail, fewer hidden assumptions, stable labels, one question at a time, visible parked side tracks, calibrated redirection, bounded break contracts, voice-to-text ambiguity checks when consequential, and familiar structure when requested.

Hard boundary: Q4=D must not diagnose or infer neurodivergence, require disclosure, infantilize the user, reduce competence assumptions, weaken truth/evidence/safety/scope/AIR_GATE/backend boundaries, or suppress required AIR objects. Functional support is available without diagnosis disclosure.

Familiar-artifact preservation and small-step delivery are working-agreement behaviors, not automatic diagnosis rules. When selected, they can preserve known labels and anchors or expose one current action at a time while still correcting errors and surfacing blockers.

Runtime & Orbit

AIR 2.5 makes runtime order explicit through a Core-owned route and dependency kernel. Every post-activation user turn begins with current alignment before semantic instruction handling, then preserves the raw request while translating it into a machine-usable intent and active context.

Orbit 0

One current execution center

Material execution requires exactly one AIR_ARTIFACT with active execution binding. Its current task, step, scope, sources, acceptance conditions, approvals, evidence obligations, evaluation basis, and benchmark define what AIR may materially advance.

Route dependency

Order is part of the contract

The normal turn path begins RT.TURN → RT.ALIGN → RT.INPUT_TRANSLATE → RT.CLASSIFY before a selected route continues. Route discovery material does not override the Core definitions.

MII cognition

Select the reasoning the task needs

Mathematical-Informational Intelligence is AIR's prompt-layer cognitive architecture. It can combine task-relevant routes for knowledge-to-execution, multiple lenses, causal/counterfactual analysis, risk, adversarial disconfirmation, trade-offs, uncertainty, temporal dynamics, information gain, and evidence triangulation.

Semantic & epistemic fidelity

Clarify without rewriting the task

AIR may structure the user's request but may not silently replace its resolved intent. Missing material knowledge becomes the smallest required clarification, source, evidence, capability, permission, environment state, artifact, or operator action rather than an inferred fact.

Morphology: after cognitive requirements are known, AIR can bind task-level or node-local geometry and lambda pressure. Geometry shapes decomposition/topology; lambda shapes ambiguity tolerance, convergence timing, branch pruning, and review strictness. AIR does not claim measurable latent-space effects without instrumentation.

Authority boundary: MII nodes, Specialists, translators, methods, sources, Handoff state, and other processors can contribute candidate material. They do not acquire positive execution authority; validated contributions become operative only through the bound Orbit 0 artifact and its benchmark.

AMRS readiness

The AIR Maturity Readiness Scale tracks how far implementation-bearing work has actually progressed and constrains what AIR may claim at that stage. Promotion is explicit; AIR does not silently upscale readiness.

Stage	Meaning	Allowed / required	Claim boundary
AMRS-0	Problem framing	Objective framing, task-center formation, constraint discovery, blocker surfacing.	No production, implementation-ready, or code-acceptance claim.
AMRS-1	Concept shape	Concept architecture, capability clustering, dependency framing and relevant task-vector selection where used by the runtime.	No production-grade code, deployment, or acceptance claim without executable design.
AMRS-2	Executable design	Interfaces, architectural invariants, review/test/security planning, coding-contract formation.	No production acceptance or implementation-complete claim without generated output and review.
AMRS-3	Controlled prototype	Narrow implementation and controlled testing; degraded mode, missing coverage and rejection conditions must stay explicit.	No production-ready claim unless promoted.
AMRS-4	Integrated system	Subsystem integration, reproducible execution-path work, contract-governed refactors, structured testing; blockers and integration assumptions remain visible.	Integration progress does not silently become production readiness.
AMRS-5	Production candidate	Packaging, deployment planning, operational hardening, security checks, test requirements, rollback/failure handling and explicit acceptance criteria.	No production approval while production-critical blockers remain.
AMRS-6	Production approved	No unresolved production-critical blockers, evidence-complete review state, decision trace and visible approval.	Production-approved claim is permitted only when those conditions are satisfied.

Operational rule: readiness state belongs in the project/execution state when the active step is maturity-bearing. If a requested action exceeds the current stage, AIR must block, degrade, or surface the stage constraint rather than silently promoting the work.

Formal objects

Formal AIR objects expose declared runtime and governance state. Their identities and record classes are canonical across compatible providers.

Object	Record class	Purpose
`AIR_RUNTIME_BRIDGE`	STATE_TRANSITION_RECORD	Compiles onboarding/restoration inputs into v2 runtime state.
`AIR_SESSION`	SESSION_STATE_RECORD	Current session/runtime state and truthfulness flags.
`AIR_PROJECT_INITIALIZATION_BRIEF`	PROJECT_STATE_RECORD	Initial project orientation after onboarding.
`AIR_PROJECT_EXECUTION_MAP`	PROJECT_STATE_RECORD	Project steps and queued/deferred work map.
`AIR_ARTIFACT`	ACTIVE_EXECUTION_RECORD	The sole positive material execution authority when bound in Orbit 0.
`AIR_ACTIVE_CONTRACT`	EXECUTION_CONTRACT	Task center, scope, allowed/prohibited actions, evidence, approvals, sources, and stop conditions.
`AIR_GATE`	DECISION_RECORD	Allow, review, reject, rescope, or evidence-required decision at a governed boundary.
`AIR_VALIDATION_REPORT`	VALIDATION_RECORD	What was checked, against what basis, with what decision and limitations.
`AIR_ALIGNMENT_CHECK`	ALIGNMENT_EVALUATION_RECORD	Compact current alignment/drift projection associated with the matching detailed validation report.
`AIR_ERROR`	ERROR_RECORD	Blocking/recoverable error state and safe next action.
`AIR_ACTION_AUTHORIZATION`	ACTION_AUTHORIZATION_RECORD	Single-use authority for one exact material action.
`AIR_ACTION_RECEIPT`	ACTION_RECEIPT_RECORD	Observed result of an attempted material action and reconciliation of expected versus actual effect.
`AIR_PRIOR_EFFECT_RECORD`	RECOVERY_RECORD	Reconciles a material effect that occurred without valid action authority; retrospective authorization is prohibited.
`AIR_REQUIRED_INPUT_REQUEST`	REQUIRED_INPUT_REQUEST_RECORD	Names the smallest exact missing input needed to continue an affected route without converting uncertainty into operative fact.
`AIR_HANDOFF_CARD`	TRANSFER_RECORD	Serialized continuation state for another compatible AIR session.

Evaluation basis: state-dependent formal objects carry the current evaluation basis required by Core. A material state transition, external effect, artifact revision, approval/scope change, or source-state change can make an earlier basis stale.

Claim boundary: a formal object shows that a record was surfaced as part of the AIR prompt-layer working contract. Its presence is not independent proof that the underlying evaluation, an external action, correctness, backend enforcement, or hidden reasoning exists beyond the evidence available.

Visibility & modifiers

AIR keeps the CLI-like surface intentionally small. Project operations can otherwise be requested in normal language.

Modifier	Effect
`air -o on`	Select `ALL_OBJECTS` and show every AIR object that is generated. `ALL_OBJECTS` is the default visibility posture.
`air -o -min`	Explicitly select `MINIMUM_REQUIRED_OBJECTS`. Optional repetition may be suppressed; required objects and material transition records cannot.
`air -t on`	Select `EXPANDED_EVIDENCE_PRESENTATION` when a more reviewable evidence display is useful.
`air -t off`	Select `STANDARD_EVIDENCE_PRESENTATION`, the default. Presentation mode never lowers evidence acquisition, preservation, evaluation, rigor, or approval obligations.

Ask normally for status, blockers, scope, evidence, risks, readiness, sources, validation, queue changes, or Handoff. See Glossary & modifiers for plain-language definitions.

Material actions

Repository writes, publication, deployment, sending, deletion, purchase, credential-bearing operations, and other consequential external effects use a stricter action interlock than ordinary analysis or drafting.

Current artifact and alignment

Exactly one Orbit 0 artifact must be actively bound, still describe the proposed work, and have a current satisfied evaluation basis for the pre-effect state.

Active lease and exact scope pin

The artifact lease must still be current and the proposed target/action class must match the exact resource scope.

Current approval and single-use authorization

The exact action must be permitted by the contract and current approval basis, then receive one matching AIR_ACTION_AUTHORIZATION.

Attempt, receipt and post-effect reconciliation

Every attempted material action requires an AIR_ACTION_RECEIPT and current post-effect reconciliation before dependent execution or closure. The receipt records what actually happened, including unexpected effects.

No retrospective approval: if a material effect already happened without valid matching authority, AIR records and reconciles the prior effect. It does not manufacture authorization after the fact.

Specification & verification

AIR uses proportionate Specification-First Verification when success depends on correctly understanding an intended outcome and the evidence needed to justify closure.

Universal

`verification_specification`

Defines the planned verification before execution when feasible, and specification_adequacy_state asks whether those checks could pass while a material part of the intended outcome remained wrong.

Behavior-bearing software

`behavior_specification`

When implementation can change observable behavior, contracts, state transitions, security boundaries, or defect outcomes, coding additionally specifies the intended behavior before code generation.

Planned verification is not observed test evidence. After execution, AIR compares the evidence and implementation back to the resolved original intent; passing tests alone are insufficient if material intended behavior was never represented. SFV can contribute verification material into the MII/benchmark path, but it does not acquire execution authority or bypass evidence sufficiency.

Read the SFV mechanism → · Read the SDD classification →

Capability layers

AIR can bring task-specific capability into a project without turning capability availability, discovery, or cognitive contribution into independent agency or execution authority.

Layer	Role
Specialist	Bounded non-agent capability profile for a particular kind of work. The v0.6.0 release includes Capability Ecology Architect, AI Governance, Grounding, and Specification-First Verification packages at 2.4.0.
Domain Package	Task-relevant terminology, constraints, evidence classes, standards, or domain expectations.
Method Pack	Reusable procedure with state, gates, evidence expectations, staleness, and Handoff state.
Executor	Bounded callable operation that performs one defined action inside the current contract.

Lifecycle: availability is not binding. Capability resolution determines whether the task can use an existing bounded capability, needs a reusable Specialist construction path, or is blocked. Specialist and MII outputs remain candidate contributions until validated and compiled into or explicitly referenced by the current Orbit 0 artifact.

Discovery: the Specialist Package Index publishes identities, hashes, activation summaries, capability tags, and MII contribution tags; the Runtime Route Map publishes Core route discovery. Neither catalog selects, binds, authorizes, or executes.

Evidence boundary

AIR separates the record of a working contract from evidence about the world outside that contract. Presentation controls can change what the user sees; they do not change what evidence the task requires.

Prompt-side

Surfaced governance records

Support bounded claims about what AIR declared, required, blocked, approved, or reconciled in the visible prompt-layer process. A rendered object is not independent proof that the underlying evaluation occurred correctly.

Source-dependent

Source evidence

Claims about documents, law, standards, repository content, or other sourced facts require the corresponding source evidence.

Execution-dependent

Tool or operator evidence

Claims that code ran, a deployment occurred, a tool changed state, or a test passed require evidence from the execution path that actually produced the result.

Backend-enforced

Backend evidence

AIR does not label prompt-compiled state as backend-enforced. Stronger enforcement claims require corresponding backend evidence.

See the full claim-to-evidence map →

Handoff

A Handoff Card is a serialized transfer record, not execution authority. Schema 2.3.0 preserves explicit continuation state so another compatible AIR session can validate current conditions and rebind the project.

Create the transfer record

Preserve the current artifact and contract, task/step state, blockers, working agreement, approvals, visibility/evidence-presentation choices, governance state, capability bindings, current alignment provenance, semantic/epistemic state, MII/fusion state, morphology, action/receipt history, catalog provenance, and other material continuation state.

Validate the incoming card

Current v2 restoration requires strict JSON with the AIR Handoff root, schema 2.3.0, required restoration carriers, and compatible truthfulness/runtime fields. Older cards may require migration review.

Re-evaluate and rebind in the receiving session

The receiver performs current-session HANDOFF_RESTORE alignment and artifact binding before material work continues. Prior-session alignment records, authorizations, bindings, or other operative state in the card are provenance/input, not current-session authority.

Authorization does not travel: historical action authorizations can be preserved as history, but they do not survive Handoff as executable authority. Material action state must be revalidated against the restored artifact and current environment.

Alignment & watchdog

AIR 2.5 treats current alignment as a runtime dependency rather than a periodic reminder. The work about to be performed must still match the bound state before semantic continuation.

Profile	When it runs
Turn entry	On every post-activation user turn before semantic instruction handling.
State transition	When material task, artifact, scope, source, approval, benchmark, capability, morphology, or other governed state changes.
Pre-effect	Immediately before a material external action as part of the action interlock.
Post-effect	After a material action so expected and actual effects are reconciled before dependent execution or closure.
Handoff restore / recovery	When restoring transferred state or recovering from drift, invalid state, or a prior-effect condition.

AIR_ALIGNMENT_CHECK is the compact surfaced projection; the matching AIR_VALIDATION_REPORT carries the detailed checks and limitations. The records are evidence surfaces, not a substitute for the underlying evaluation dependency.

Compatibility

AIR's representation is provider-independent; useful execution is host-dependent.

The runtime, schemas, governance records, route/catalog representations, and Handoff state are text/JSON rather than one provider's private project-memory format.
Instruction following, effective context, file handling, higher-priority host instructions, safety constraints, tools, provider updates, and context-management behavior can still change how well AIR runs.
PROMPT_COMPILED is a valid prompt-layer runtime origin. It is not equivalent to BACKEND_COMPILED, and it must not claim backend validation without evidence.
Host adapters or gateways can strengthen enforcement by independently validating permissions, tests, tool calls, or receipts, but those stronger claims exist only when that infrastructure and evidence actually exist.
Compatibility statements should name the configuration tested and should not be treated as permanent guarantees. AIR Kit v0.6.0 does not claim universal behavioral certification across every provider/model or deterministic LLM inference.

Troubleshooting

Symptom	Interpretation / next check
AIR-looking prose but required boot records are absent	Treat the run as non-conformant and use AIR load integrity. Do not infer hidden compliance.
No valid Orbit 0 artifact	Material project execution is blocked; restore, compile, select, or rebind a valid current artifact.
The user changes scope or active work	Run current alignment and classify the effect. Material changes revise or replace formal state before affected work continues.
A required source/tool/approval is unavailable	Name the smallest exact missing requirement through the uncertainty/required-input path and distinguish blocked work from work that can continue safely.
A Handoff Card will not restore	Check schema 2.3.0 compatibility, required carriers, migration state, runtime truthfulness fields, current restore alignment, and artifact rebinding requirements. Invalid cards inform review; they do not become active contracts.
Tests pass but the intended outcome still looks wrong	Reconcile the observed result to resolved original intent and specification. Passing checks prove only the checks that actually ran.

Need the source itself? The repository is authoritative. This reference is deliberately an index of the operative concepts, not a parallel copy of thousands of lines of canonical runtime law.

Open the AIR Kit How AIR works Glossary & modifiers