The model behind AIR.
AIR — short for AI Resource — turns a chatbot session into a structured, auditable environment, with a teammate's discipline rather than an agent's autonomy. Here is the machinery, from the first question to the final handoff.
Start a session
Every project begins with one question — what are you doing? AIR never guesses the branch. From there a short, deterministic set of questions configures the session before any work starts.
Fix the scope and the agreement
Two questions do the heavy lifting: what you are building — goal, constraints, sources — and how you and AIR will work together. This is where responsibilities get divided — what is yours, what is AIR's — alongside files, diffs, review, and pace.
Layer on capability
A default profile governs by default. On top of it AIR binds reusable capability — a Specialist (a capability profile), a Domain pack (a standards overlay), a Method pack (a procedure with its own gates), and Executors (bounded, callable operations, not agents). Each stays subordinate to the contract and the gates, and nothing binds until it clears the capability gate. Full specs in the repo →
Keep context in orbit
The active task sits at Orbit 0. Supporting and background context orbit around it and inform inward, so focus stays on what is live without losing the surroundings.
Govern with gates
Procedures track their own live state, and gates decide when work advances. When two gates disagree, the stricter one governs.
Continue across sessions
Each session ends with a strict-JSON handoff card. The next session boots from it — so a project survives context limits and resumes exactly where it left off. Because that card is a complete, portable snapshot of your project, treat it like sensitive data — see the threat model.
Structure, not slop
Vibe coding generates first and cleans up later. AIR binds a contract, surfaces blockers, benchmarks the work, and only delivers when it clears its own state.
How mature is your project?
AIR treats your project's maturity as something it tracks, not something it claims. The AIR Maturity Readiness Scale (AMRS) climbs from problem-framing to production-approved, and each stage gates what AIR is allowed to say — its own version of the familiar NASA-style Technology Readiness Levels (TRLs). You cannot get a "production-ready" claim out of AIR until the work has earned it.
AIR fails closed if you ask for something above the current stage, and it never promotes silently. That is the mechanism behind "won't oversell a sketch" — the ruler will not let it.
What a real boot emits
None of this is narrated into being — it is emitted as formal objects you can inspect. The first thing a real session prints:
{
"AIR_SESSION": {
"session_state": "BOOT_ONBOARDING",
"runtime_origin": "PROMPT_COMPILED",
"backend_validation_claimed": false,
"current_onboarding_question": "Q1",
"decision_state": "AWAITING_Q1_SELECTION",
"air_object_visibility": {
"boot_objects_required": true,
"boot_objects_emitted": true
}
}
}
A model performing AIR writes about these objects; a model running AIR emits them. See a full session → — a real project from boot to handoff, every object — or learn how to tell a real boot from a roleplay.
See it in a session.
The fastest way to understand AIR is to run it. Grab the boot bundle and start a project.