See a full session

Everywhere else, this site tells you AIR is structured, inspectable, and resumable. This page shows an earlier captured AIR session — booted on Claude Opus 4.8, preserved object for object, nothing tidied. AIR frames a risky project, refuses to guess at the part that matters most, uses AMRS to stage how mature the work actually is, and stops at a clean save point. The project then moves to a different model and continues from recorded Handoff state. The object shapes shown here belong to the AIR version captured at the time; the current repository defines today's canonical schemas.

One honest note first, because it is the whole point: this is framing, not building — no code is written here. That is not a gap. It is AIR doing the disciplined thing at the riskiest moment, the start.

The project, in the user's own words

The person driving this is not a developer. Their Q5, verbatim:

I want to build a SaaS web app with user accounts and built AI
support assistant. Users must register and log in to use the
service and the AI support assistant must be able to help during
onboarding or answering any questions. Today's focus is the AI
support assistant.

And when AIR asked how they wanted to work together (Q6), the answer was just as plain: "I don't really know how to do it. I'm not really technical. You take the lead and I'll do my best to fill any gaps." Everything AIR does next is shaped by a non-technical person asking it to guide the work and fill capability gaps on something genuinely risky.

The boot

The session starts with the AIR files loaded and one line: "Start a new AIR project." This historical capture begins with the formal boot record required by the AIR version used at the time. Current AIR still requires surfaced governance records at defined trigger points, but those records describe declared prompt-layer state; they are not hidden-model telemetry or independent proof of external execution.

{
  "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
    }
  }
}

runtime_origin: PROMPT_COMPILED and backend_validation_claimed: false appear on every object in this session — AIR stating its own honest boundary: built from prompts, not a validated backend. Onboarding then runs (strict checking, resolve ambiguity early, protect structure and logic — an A/C/A/A posture), and AIR records each answer as the user's explicit choice rather than inferring it.

Why a Specialist was loaded

Once the project is described, AIR binds a governing contract and uses a capability layer. This is worth understanding plainly. AIR's base runtime — Core Runtime, Control Surface, and a Starter Profile — gives you the discipline. On top of that sits an optional capability layer: a Specialist governs a kind of work, a Domain pack carries a field's standards, and a Method pack is a reusable procedure.

This session loaded the Grounding trio on purpose. A non-technical user building a risky, from-scratch AI feature is exactly its remit: blast-radius scanning, viability and implementation realism, claim hygiene. That is why the session caught the right risk and refused to overclaim. When you would not load it: routine, well-scoped, low-risk work — a copy edit, a concept explained, a small contained change. The base runtime alone is plenty. Grounding is opt-in, for when ambition and risk earn it. (More in how AIR works, step 03.)

Framing the work — and being honest about how far along it is

AIR frames the project and lays out a path. The part that matters is the readiness stage:

{
  "AIR_PROJECT_EXECUTION_MAP": {
    "current_active_step": "Scope the AI support assistant: access tier + source of truth",
    "critical_path": [
      "1. Scope assistant (access tier + knowledge source) [ACTIVE]",
      "2. Executable design (answers, readable data, vendor/model)",
      "3. Controlled prototype (real source, logged-in context)",
      "4. Integrate with accounts/auth and the live product"
    ],
    "blockers": [
      "Assistant access tier undecided (docs-only vs account-aware vs action-capable)",
      "Source of truth for answers undecided (no knowledge base attached)",
      "No stack/AI-vendor specified; AIR will not assume one"
    ],
    "readiness_stage": "AMRS-0 PROBLEM_FRAMING",
    "blocked_capabilities": ["implementation-ready claims", "production claims", "code acceptance claims"]
  }
}

That AMRS-0 is doing real work. AMRS — the AIR Maturity Readiness Scale, AIR's take on NASA's Technology Readiness Levels (TRLs) — runs from problem-framing (0) to production-approved (6), and each stage gates what AIR is allowed to claim. At AMRS-0 the prompt contract binds a claim ceiling: AIR is instructed not to describe the work as implementation-ready, production-ready, or accepted without the required evidence. That is a prompt-layer control, not deterministic backend enforcement. That is the mechanism behind "won't oversell a sketch."

The decision the whole session turns on

The user asked for "an AI support assistant." AIR did not start building one. It found the single decision with the largest blast radius — what the assistant is allowed to know and do — and refused to proceed until the human chose it:

{
  "AIR_ARTIFACT": {
    "task_center": "Define the assistant's capability scope and foundational dependencies",
    "method": "Resolve the highest-blast-radius decision (access tier) first,
               then source of truth, then proceed to executable design",
    "method_execution_state": "STEP_1_AWAITING_USER_DECISION",
    "readiness_stage": "AMRS-0 PROBLEM_FRAMING"
  }
}

Then it framed the choice in plain language, by escalating risk — the blast-radius idea made concrete:

No "gate" object fired here, and we will not pretend one did — at the framing stage, before any code, there is nothing to gate yet. What you see is AIR reasoning about blast radius, not reciting a checklist: it found the riskiest fork and made the human own it.

A clean save point

AIR parked the project right there — AMRS-0, both blockers open, implementation deliberately not engaged. Then the user asked for a save slot.

AIR wrote a real AIR_HANDOFF_CARD as an actual file — the full live state, the bound specialist, the active step, the open blockers, the Q1–Q6 answers, all of it. It also stated the honest boundary: the card is a faithful written snapshot, not a backend-validated checkpoint; restoring it depends on the next session loading it correctly.

The continuity test: the project traveled to another model

This is the part role-play cannot copy. The card was taken to a different model — ChatGPT 5.5-thinking — and loaded with "Continue from handoff card." It booted and dropped straight back onto the access-tier decision, both blockers intact.

Two front doors, both valid: the original session entered with "Start a new AIR project" (a fresh boot, Q1=A); the continuation entered with "Continue from handoff card" (a restore, Q1=C). Same runtime, same project, different model — resumed at the exact step. Portability and continuity, demonstrated rather than asserted.

What is loaded, and when

To avoid confusion, here is exactly which files each stage used. The boot files come from the AIR kit repo; the filled card and the transcript are linked below.

Continue this project yourself

The original historical download artifacts linked from this page were never committed to the site repository. Rather than inventing those originals after the fact, the links below now provide current AIR v2.4 examples, clearly separate from the historical capture above. Use the current Handoff template as a schema/reference file, and the walkthrough to reproduce a fresh current-format session.

If a required file or surfaced record is missing, treat the boot or continuation as invalid and use the load-integrity guide rather than inferring hidden state from style alone.