Glossary & modifiers.

Core idea

AIR — AI Resource

A prompt-based project runtime for governed, continuous AI work. It gives a compatible host model an explicit working contract for scope, active task, evidence, approvals, review, and continuity.

Cooperative teammate

A description of the interaction posture: AIR works with the user rather than operating as an autonomous hands-off agent. The user keeps judgment and final decision authority.

Gap / gap-filler

The practical role AIR was designed around: bring structure or bounded capability into parts of a project where the user or team has a temporary capability, time, or follow-through gap.

Blast radius

How far the consequences of a decision or action can spread. Higher-blast-radius decisions deserve earlier resolution and stronger evidence or approval.

Onboarding & task state

Q1–Q6

The deterministic onboarding sequence used to establish project state, rigor, ambiguity handling, continuity, project sources, and the human–AIR working agreement.

Q1

Selects the starting path: new project, import existing work, continue from a Handoff Card, or explain AIR first.

Q2

Sets checking rigor.

Q3

Sets when unresolved non-material ambiguity should be surfaced or deliberately preserved. It never authorizes silent material inference.

Q4 / Q4D

Sets continuity preference and, when selected, the neurodivergent delivery modifier while preserving an underlying continuity style.

Q5

Describes the project and supplies authoritative sources or inputs.

Q6 / Q6D

Defines the working agreement: responsibility split, delivery form, challenge posture, approval boundaries, explanation needs, assumptions to avoid, and optional delivery calibration.

Orbit 0

The sole current executing task/artifact. Only the bound Orbit 0 AIR_ARTIFACT supplies positive material execution authority.

Maturity & governance

AMRS

AIR Maturity Readiness Scale, used to describe project maturity from problem framing through production approval while limiting claims to the readiness actually earned.

AIR_GATE

A governance checkpoint that records whether an action is allowed, blocked, missing evidence, or requires review/rescoping.

Fail-closed

When a required approval, source, evidence item, or other prerequisite is missing, the affected action stops rather than proceeding on a guess.

Proportionality

Match ceremony to consequence. Low-risk work can stay light; high-blast-radius work earns stronger specification, checking, evidence, or approval.

Runtime & claims

PROMPT_COMPILED

AIR is operating from the prompt/runtime files rather than claiming independent backend enforcement.

backend_validation_claimed: false

A standing honesty flag used when the prompt runtime must not represent its output as independently backend-validated.

AIR load integrity

The observable conformance question: did the required foundation load and did required surfaced AIR obligations appear at their trigger points? It does not imply hidden-model telemetry.

AIR object plane

The formal surfaced records AIR uses to expose declared state and decisions, such as session, artifact, gate, validation, alignment, action, and Handoff records.

MII

Mathematical-Informational Intelligence: AIR's prompt-layer cognitive architecture for selecting task-relevant cognitive routes rather than forcing every problem through one generic reasoning pipeline. MII contributions are candidate material, not independent execution authority.

Semantic fidelity

The rule that AIR may clarify and structure an instruction for execution without silently narrowing, broadening, replacing, or materially reinterpreting the user's resolved intent and active context.

Epistemic sufficiency

The rule that missing material knowledge creates an information-acquisition obligation rather than permission to guess. AIR asks for the smallest missing clarification, source, evidence, permission, capability, environment state, or other required input.

Morphology

The task or node-level execution shape AIR binds after cognitive requirements are known. Geometry influences decomposition and topology; lambda pressure influences ambiguity tolerance, convergence timing, branch pruning, and review strictness.

Capability layers

Specialist

A bounded non-agent capability profile for a particular kind of work. Availability alone does not bind it to the project.

Domain Package

A bounded domain overlay/source package for task-relevant terminology, constraints, evidence classes, and domain expectations.

Method Pack

A reusable procedure with explicit execution state, gates, evidence expectations, and Handoff state. It does not govern or execute independently of the bound artifact.

Executor

A bounded non-agent callable operation that performs one defined action inside the active Orbit 0 contract. It does not own agency, intent, initiative, or execution authority.

Runtime Route Map

A generated discovery view of AIR's Core-owned runtime routes. It helps locate route definitions but has no execution, binding, selection, approval, or semantic authority of its own.

Specialist Package Index

A release-level discovery catalog for available Specialist packages, activation summaries, identities, hashes, capability tags, and MII contribution tags. Discovery is not binding or authority.

Specification & verification

Spec-Driven Development (SDD)

For software work, a development approach in which specification is established before material implementation and drives downstream planning, tasks, implementation, and validation.

Specification-First Verification (SFV)

AIR's verification discipline for behavior-bearing work: define intended behavior, define how it will be verified, check that the verification is adequate, then execute, verify, and reconcile to the original intent.

behavior_specification

The explicit statement of what the behavior-bearing change must do or preserve.

verification_specification

The explicit statement of how the required behavior will be checked.

specification_adequacy_state

The state indicating whether the proposed verification is adequate to support the intended claim before implementation proceeds.

Continuity

Handoff Card

A structured transfer record for explicit project state. A receiving compatible AIR session validates the card and rebinds the nominated active artifact before material work continues. It carries recorded state, not hidden model state or guaranteed identical inference.

Canonical system modifiers

AIR intentionally keeps the CLI-like surface small. These are the four canonical modifiers; everything else can be requested in ordinary language.

air -o on

Use full object visibility: every AIR object that is actually generated is shown.

air -o -min

Select compact visibility. Optional repetition may be suppressed, but required records cannot be disabled.

air -t on

Select expanded evidence presentation when useful. This changes how much qualifying evidence is shown, not what evidence the task must acquire, preserve, evaluate, or require for approval.

air -t off

Use standard evidence presentation, the default. It does not lower evidence obligations, execution rigor, or approval thresholds.