See a full session

Everywhere else, this site tells you AIR is verifiable, structured, and resumable. This page shows it. Below is a real AIR session — booted on Claude Opus 4.8, captured object for object, nothing tidied. AIR frames a risky project, refuses to guess at the part that matters most, stages how mature the work actually is, and stops at a clean save point. Then the same project travels to a different model and picks up exactly where it left off.

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 lead on something genuinely risky.

The boot

The session starts with the AIR files loaded and one line: "Start a new AIR project." A real boot's first act is to emit a formal object — not prose claiming it started, an actual record that states what it is and, just as importantly, what it is not.

{
  "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 it blocks itself from saying anything is implementation-ready, production-ready, or accepted. It cannot overclaim, because the ruler will not let it. 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 proof: 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

Everything here is downloadable. Grab the boot files from the kit, grab the card, start AIR, choose Q1 = C (Continue from handoff card), and attach the card — you will land on the same access-tier decision this session stopped at. If you would rather read the whole thing first, the full unedited transcript is here too.

If your model role-plays instead of booting, the resume will not produce these objects — and now you know how to tell.