Reference

Glossary & commands

Plain-language definitions for the words AIR uses, and the CLI-style commands you can type to steer a session. Inside a live session, air help is always the source of truth — this is the at-a-glance version.

Glossary

The vocabulary that shows up across this site and inside a session, in plain terms.

Core idea

AIR — AI Resource: A prompt-based framework that governs how an AI chatbot works, by direct analogy to HR. It gives a capable model a set of working rules — how to scope, check, and deliver — so it behaves like an accountable teammate rather than a free-form assistant.
Cooperative teammate: AIR's stance: it works with you, not for you. It is not autonomous and not built for hands-off automation — you keep the judgment and the final say.
Gap / gap-filler: The cooperative dynamic. You bring the goal and the decisions; AIR fills the gap on the parts where structure, checking, or follow-through would otherwise slip.
Blast radius: How far the damage could spread if a decision or action goes wrong. AIR settles the highest-blast-radius decision first, deliberately, instead of letting it be decided by accident downstream.

Onboarding — the Q-codes

Q-codes (Q1–Q6): The six questions AIR asks, one at a time, before it activates a project. Together they set the working agreement for the session.
Q1 — What are you doing today?: Picks the starting flow: A new project, B import an existing one, C continue from a handoff card, or D explain AIR first.
Q2 — How strictly should AIR check your work?: Sets the rigor level, from light review to high scrutiny.
Q3 — How should AIR handle the unclear?: Resolve ambiguity early, or leave it open until it actually blocks progress.
Q4 — What should AIR keep consistent?: What to hold steady as you work — structure and logic, structure and tone, and so on.
Q5 — Describe your project: You state what you're building and attach any supporting sources. AIR compiles its first project frame from this.
Q6 — AIR & user alignment: The working agreement: who leads, how AIR reviews, how it delivers. Project-scoped by default.
Orbit 0 contract: The active working agreement for the task at hand — what AIR is doing right now, and on what terms. AIR keeps it in view so the session doesn't drift.

Maturity & governance

AMRS — AIR Maturity Readiness Scale: A 0-to-6 scale for how far along a project is: 0 problem framing, 1 concept, 2 executable design, 3 controlled prototype, 4 integrated system, 5 production candidate, 6 production approved. Each stage limits what AIR may claim, and AIR never silently promotes a project to a higher one. See the full ladder →
Gate (AIR_GATE): A governance checkpoint. Before a consequential action, AIR checks whether it's allowed, blocked, missing evidence, or needs rescoping — and stops if the conditions aren't met.
Fail-closed: When something required is missing — evidence, an approval, a needed file — AIR blocks rather than proceeding on a guess. The safe default is stop, not continue.
Proportionality: Matching effort and ceremony to the stakes. Low-risk work stays light; high-blast-radius work earns the full checking.

Runtime & claims

PROMPT_COMPILED: AIR's runtime origin when it's running purely from the uploaded prompt files, with no backend. The rules are real, but enforced by the model following them — not by external software.
backend_validation_claimed: false: A standing honesty flag. When AIR is prompt-compiled it must never claim its output was validated by a backend system. It states what it is — and what it isn't.
Real boot vs roleplay: A real boot emits formal AIR objects — structured JSON — into the chat. A model that only describes AIR in prose is role-playing, not running it. The objects are the tell. How to tell →
The AIR object plane: The set of formal JSON objects AIR emits to show its state and decisions — for example AIR_SESSION (where things stand), AIR_GATE (a checkpoint), AIR_ARTIFACT (a unit of work), AIR_PROJECT_EXECUTION_MAP (the plan), and AIR_HANDOFF_CARD (continuation state). Visible structure, not just talk.

Grounding layers

Specialist: A grounding profile that gives the session focused expertise for a particular kind of work, when the project needs more than the general runtime.
Domain Package: Grounding for a specific subject area — the facts, constraints, and vocabulary of a domain — layered on when the work depends on them.
Method Pack: Grounding for a specific way of working — a procedure AIR should follow — added when the task calls for it.

Continuity

Handoff card: A structured snapshot of the session's state that lets you resume the work later — in the same model or a different one — from where you left off. Created with air handoff. Treat it as sensitive: it can carry project detail.

CLI-style commands

You steer AIR by typing short commands in the chat. AIR reads anything beginning with air — or a plain-language request for help, status, or control — as a command. They let you inspect, steer, compress, expand, validate, patch, and hand off. What they can't do is bypass a gate.

Visibility — how much machinery is shown

air status: Show where the session is: the current visibility mode, and whether boot evidence has been emitted.
air object on: Restore the default level of visible AIR objects.
air object off: Go quiet — stop showing objects unless they're required — once the boot and state objects have already appeared.
air compact: Use compact object state wherever possible.
air verbose: Use fuller object state when it's useful.
air quiet: Conversation-first mode. Required objects still surface.
air immersive: Reduce visible machinery during ordinary work. Required objects still surface.

Task & benchmark — what's being worked, and against what

air task: Show the active task AIR is executing.
air benchmark: Show the benchmark AIR is holding the work to.
air scope: Show — or adjust — the boundaries of the current work.
air uncertainty: Surface where AIR is unsure, and what that uncertainty affects.
air ask: Show the one narrow question AIR needs answered to continue.

Reasoning & review — inspect how AIR is thinking

air lanes: Show AIR's separate reasoning tracks instead of a single blended take.
air adversarial: Run an adversarial pass — have AIR argue against its own current answer.
air evidence: Show the evidence behind the current claims.
air risks: Surface the risks AIR is currently tracking.
air sources: Show the sources and references AIR is relying on.
air proportionality: Check that the effort and ceremony match the stakes.

Execution & governance — move work forward, under the gates

air smoke: Run a quick smoke check of the current output for obvious breakage.
air validate: Run a fuller validation pass on the current work.
air gate: Show whether the requested action is allowed, blocked, missing evidence, or needs rescoping.
air approve?: Check whether the current output is ready to accept, or still needs evidence or review.
air handoff: Create continuation state — a handoff card — so another session can pick up where you left off. Needs the control surface and handoff-card template; fails closed if either is missing.
air patch plan: Draft a plan to change AIR's own behavior, for review before anything is applied.
air patch: Apply a reviewed change to AIR's behavior.

Help — find your way around

air help: Show the command menu. In a live session, this is the source of truth.
air help statusalso: air help patch / modes / objects: Focused help on a specific area — status, patching, modes, or the object plane.
air -helpair --help: Aliases for air help.

Commands don't override governance

A command can inspect, steer, or request — it can't push AIR past a backend-validation boundary, a missing approval, an evidence requirement, or a safety, security, or legal gate (commands_cannot_bypass_gates: true). Enter a command AIR doesn't recognize and it shows a short help hint rather than inventing behavior — try air help or air -help.

See the words in motion

The vocabulary and commands make the most sense once you have watched a session use them.

How it works See a full session Boot a session