AIR v0.3.0

AIR v0.3.0 — Modular Runtime and Function-Oriented Repository

AIR v0.3.0 introduces the modular runtime, integrated documentation, complete specialist packaging, and the OBJECT_ALL formal-object visibility default while retaining the monolithic system-prompt path.

Highlights

• Clean repository taxonomy: system prompts live in prompts/; complete specialist packages live in profiles/<specialist name>/; runtime implementation assets are grouped by function under runtime/.
• No duplicated prompt/profile payloads: the modular manifest references canonical files across the repository root.
• Complete specialist packages: each package contains a specialist profile, domain pack, method, executor, and package manifest.
• 22-module graph preserved: the WS7 module graph remains unchanged in count and dependency behavior; only repository-relative paths changed.
• OBJECT_ALL visibility: every formal AIR object actually created, restored, updated, or made operative is printed canonically without manufacturing future-step objects.
• Local tools: modular boot, handoff signing/verification, and optional local OPA policy evaluation remain bounded and separately documented.
• Integrated documentation: quick start, operator guide, architecture, repository structure, installation, dependencies, troubleshooting, rollback, and release guidance.

Repository structure

prompts/                         canonical system prompts
profiles/<specialist name>/     profile + domain + method + executor
runtime/boot/                    kernel, manifest, receipts, evidence, tool
runtime/modules/                 derived runtime and control modules
runtime/artifact-lifecycle/      shared method and evaluation packs
runtime/policy/                  deterministic policy and OPA adapter
runtime/handoff/                 templates, schemas, policy, executor, tool
runtime/source-control/          registry, adapters, source manifests

The first unreleased v0.3.0 candidate duplicated system prompts and specialist assets inside runtime/. This structure-revised candidate removes those copies and supersedes that candidate.

Migration from v0.2.5

1. Back up the current repository or installed AIR files.

2. Replace the prompt/profile files as one coherent v0.3.0 set.

3. Add the function-oriented runtime/, expanded docs/, examples/, CHANGELOG.md, and release/ paths.

4. Validate from the repository root:

   python runtime/boot/tools/air-boot.py validate-manifest

5. Run a NEW_PROJECT plan and bundle smoke test.

6. Keep the previous release archive until operator acceptance.

Do not merge the earlier unreleased v0.3.0 overlay with this structure-revised overlay.

Optional dependencies

• Modular boot uses Python 3 standard library only.
• Handoff signing/verification uses the pinned packages in runtime/handoff/tools/requirements.txt.
• OPA policy execution requires a local OPA binary; prompt-simulated policy posture remains an explicitly limited fallback.

Claim boundary

AIR is prompt-native. Model behavior varies by provider, interface, context limits, and load conditions. Local hashes, signatures, policy results, and boot checks are tool-observed evidence, not general authorization or a guarantee of correctness, safety, compliance, or backend enforcement.

v0.2.7

v0.2.7 — Load integrity, honest context floors, routing fixes

This release makes a truncated or partially loaded AIR boot detectable
and fail-closed instead of silent, and states the kit's real context
requirements everywhere the portability claim appears.

Added

• Runtime Load Integrity Law (AIR_LOAD_INTEGRITY_V1): both markdown
  kit files now end with a terminal sentinel line. At boot — before Q1 —
  AIR verifies each sentinel and that each JSON profile parses, and
  reports a per-file load_state. A missing sentinel fails closed with
  AIR_ERROR / TRUNCATION_OR_PARTIAL_LOAD and blocks activation
  (explicit user override continues in visible degraded mode).
• Defense in depth: the Control Surface carries an operative
  standalone copy of the check (the absence of the runtime's own
  integrity law is itself treated as evidence of partial load), and the
  README strict-boot prompt triggers the check directly.
• Context-floor documentation: README, user guide, portability notes,
  and the get-started page now state the boot bundle size (~130k tokens
  minimal, ~172k full stack; chars/4 estimate) and a practical floor of
  a 200k-token context window for new-project boots.

Fixed

• Onboarding routing: the A/C/A/A code mapped to two mode labels with
  identical behavior; deduplicated (no behavioral change intended).
• Onboarding interpretation map now covers Q1 branch D explicitly
  (instructional-only, no routing target).

Tested

Operator-witnessed boot tests, transcripts in
docs/tests/G1_load_integrity/:

• Intact boot: per-file load report before Q1, onboarding unchanged
  (ChatGPT 5.5 thinking).
• Tail-truncated runtime (~30% removed): fail-closed truncation error,
  activation blocked, intact files correctly verified (ChatGPT 5.5
  thinking).
• [PLACEHOLDER — model #2: add vendor/model + T1/T2 results before
  publishing]
• Adversarial mid-file deletion runs are documented in the same folder;
  they motivated the defense-in-depth layer and the roadmap items below.

Known boundaries (read this)

• A verified sentinel proves the file's end arrived — not that the
  middle did. Mid-file loss with surviving bookends is not detected by
  this mechanism; a section manifest is a hard acceptance criterion for
  the upcoming compiled distribution build.
• All checks are instructions to a model, not enforced code paths.
  Reliability is model-dependent (see docs/AIR_MODEL_PORTABILITY_NOTES.md).
  This is truncation detection, not tamper-proofing or a security
  boundary.
• The integrity patch adds ~770 tokens to the boot bundle — the price of
  detection until the compiled build reduces total size.

Upgrading

Re-download the boot bundle from prompts/. Bundles saved before this
release have no sentinels and will (correctly) produce no load report.

Full findings behind this release: docs/AUDIT_2026-07_FINDINGS_REGISTER.md.

VM4AI AIR Kit v0.2.6

Transparency hardening: delivery-state triple + self-report boundary

Adds two always-on laws converting disposition-reliant transparency into
checkable procedure (markers AIR_TRANSPARENCY_UNCONDITIONAL_STATE_TRIPLE_V1,
AIR_TRANSPARENCY_SELF_REPORT_BOUNDARY_V1) across Core Runtime and Control
Surface. Handoff card template extended to carry the triple across restore.

Backward-compatible / additive schema change. Recommended startup bundle:
re-upload Core Runtime, Control Surface, and the handoff card template
together so sessions and restored cards share this doctrine version.

VM4AI AIR Kit v0.2.5

v0.2.5 - Discovery Executor and Patch Source Upload Gate

This release hardens AIR’s prompt-native runtime with Discovery Executor behavior, unknown-unknown handling, and a patch-source upload gate.

Highlights

Discovery Executor

AIR now includes AIR_DISCOVERY_EXECUTOR_UNKNOWN_UNKNOWN_SOURCE_DEPENDENCY_V1.

This lets AIR identify missing decision frames, constraints, source requirements, dependency state, and unknown unknowns before material execution.

AIR can help users discover what information matters when they do not yet know the right decision frame, source map, or capability path.

Patch Source Upload Gate

AIR now includes AIR_PATCH_SOURCE_UPLOAD_GATE_V1.

Before AIR executes a patch, AIR must request and use the current files to patch. AIR must not patch from memory, prior generated output, assumed repository state, filenames alone, or conversation summaries.

Uploaded files function as both source of truth and security gate.

Executor and non-agent layer alignment

This release continues the AIR_EXECUTOR and non-agent ontology work.

AIR Specialists, Domain Packages, Methods, and Executors are not agents. They are constraint layers, optimizers, tuning functions, execution shapers, referential overlays, governed procedures, and bounded operation contracts.

Source and dependency boundary

AIR does not depend on users finding a prebuilt external skill before a task can be shaped.

However, AIR is not data-independent. External evidence, files, repositories, APIs, tools, connectors, credentials, or current data may still be required before execution, approval, or claims.

Documentation cleanup

ROADMAP.md was removed.

Release versions and GitHub Releases now serve as the changelog authority. Future work should be tracked through issues, milestones, or explicit planning docs rather than a mixed roadmap/changelog file.

Updated areas

This release updates:

• AIR Core Runtime
• AIR Control Surface
• AIR Default Starter Profile
• AIR Handoff Card Template
• Grounding Specialist
• Grounding Domain Package
• Grounding Method Pack
• AIR User Guide
• README
• Markdown reference documentation

Claim boundary

AIR remains prompt-native.

This release does not add:

• backend validation
• runtime enforcement outside the model session
• signed contracts
• tamper-evident artifacts
• autonomous agent execution
• guaranteed correctness
• tool execution

Prompt-side discipline is not backend validation.

VM4AI AIR Kit v0.2.4

AIR v0.2.4 — User Alignment and Execution Workflow

AIR v0.2.4 adds user alignment and execution workflow routing to the public prompt-based AIR Kit.

This release focuses on a practical problem in prompt-native work: different users expect different output forms, and prompt sessions can drift between complete files, snippets, diffs, scripts, review-only guidance, or step-by-step support. AIR now treats that delivery preference as explicit project state instead of leaving it to model habit.

What changed

Q6 — AIR & User Alignment

AIR onboarding now includes a sixth question:

Q6 — AIR & User Alignment

This question asks how the user wants AIR to work with them on the project.

The user may describe:

• how they prefer output delivered
• whether they want complete artifacts, snippets, diffs, scripts, reviews, or guidance
• where AIR should take more responsibility
• where the user wants to stay in control
• how much explanation is useful
• anything AIR should avoid assuming

The user may also skip or defer Q6 when it is not material.

Q6 is designed to improve collaboration fit without turning AIR into a personal profiling system.

User alignment profile

AIR may now compile Q6 into an internal user_alignment_profile.

This profile can preserve project-relevant working preferences such as:

• preferred explanation depth
• implementation responsibility split
• support needs
• output delivery preferences
• assumption boundaries
• handoff-relevant workflow notes

The profile is project-scoped by default.

It is not a fixed identity label.

Working agreement, not user classification

AIR v0.2.4 adds a privacy and surface rule:

AIR should surface the working arrangement, not reductive user labels.

For example, AIR should prefer:

For patch tasks, AIR will provide complete replacement files unless another delivery mode is approved.

Instead of:

The user is semi-technical.

AIR must not label users as beginner, non-technical, semi-technical, advanced, weak, expert, or similar unless the user explicitly chooses that wording or asks to inspect the internal profile.

The goal is fit, not classification.

User execution workflow

AIR now tracks user_execution_workflow when delivery form materially affects success.

Supported workflow modes include:

• COMPLETE_ARTIFACT_DELIVERY
• PATCH_SNIPPET_DELIVERY
• DIFF_PATCH_DELIVERY
• SCRIPTED_PATCH_DELIVERY
• REVIEW_ONLY
• PAIR_IMPLEMENTATION_GUIDANCE
• OPERATOR_TEST_MODE
• HYBRID_BY_STEP

This lets AIR distinguish the task from the delivery form.

For example, two users may ask AIR to patch the same files:

• one user may want complete replacement files
• another may want diffs
• another may want review notes only
• another may want guided implementation while they edit locally

AIR should preserve that difference instead of randomly switching output style across sessions.

Delivery-form gate

AIR now includes a delivery-form gate.

Before material output, AIR should check whether the proposed delivery form matches the active user execution workflow.

If the active workflow requires complete replacement files, AIR should not deliver snippet-only patch instructions as final output unless the user approved that mode.

If the active workflow is review-only, AIR should not generate implementation as final output unless requested.

If the active workflow is diff, script, or guided mode, AIR should format the output accordingly.

A delivery mismatch should route to REVIEW when it materially affects success.

Q1-D tutorial update

The beginner orientation now explains that AIR may ask how the user likes to work.

This helps new users understand that Q6 exists to improve collaboration fit, not to judge skill level or collect unnecessary personal detail.

The tutorial should explain that some users want:

• complete replacement files
• snippets
• diffs
• patch scripts
• review-only support
• step-by-step guidance

Users do not need to provide personal details. They can answer casually, provide project-relevant background, attach a profile/CV/LinkedIn export if they want, or skip the step.

Handoff preservation

AIR handoff cards now preserve user alignment and execution workflow state when material.

This helps continuation sessions keep the same working agreement instead of reverting to host-model defaults.

Preserved state may include:

• active user alignment profile
• execution workflow mode
• delivery preferences
• avoided delivery forms
• assumption boundaries
• whether the state was user-declared, user-confirmed, restored, inferred, or deferred

Grounding profile alignment

The Grounding Specialist and Grounding Domain Package were updated to respect the new user alignment and execution workflow layer.

Grounding can now detect workflow-related delivery problems, such as:

• snippet-only output when complete replacement files are required
• implementation output when review-only mode is active
• unapproved shell/script delivery
• reductive user classification
• delivery-form mismatch affecting approval or closure

The existing Grounding Method Pack was also lightly updated so method-governed review and closure decisions can account for workflow fit.

No new Method Pack was created for this patch.

Boundaries

This release does not change AIR’s evidence model.

User alignment and execution workflow do not override:

• AIR_ACTIVE_CONTRACT
• AIR_GATE
• evidence requirements
• safety boundaries
• claim hygiene
• rescope protocol
• backend validation limits
• prompt/backend claim boundaries

The user’s preferred workflow changes how AIR delivers approved work.

It does not change what AIR may truthfully claim, approve, close, or execute.

Why this matters

Prompt-native AIR is still probabilistic.

Without explicit workflow state, one session may produce complete files, another may produce snippets, another may produce diffs, and another may generate local patch scripts.

That inconsistency can create real failure modes:

• users misplace snippets
• technical users receive over-explained complete files they did not want
• review-only users receive unwanted implementation
• local command examples may not match the operator’s environment
• handoff sessions lose the working arrangement

AIR v0.2.4 reduces that drift by making the collaboration model explicit.

Known follow-up hardening

During release work, one additional issue was identified:

AIR should check the operator environment before giving local commands.

For example, a Windows 11 / PowerShell user should not receive Bash-style local git commands by default.

A future hardening patch should add explicit operator-environment delivery fit, covering:

• operating system
• shell
• command syntax
• path conventions
• local execution assumptions
• whether commands should be PowerShell, Bash, CMD, or another environment

This is not treated as fully solved in v0.2.4.

Summary

AIR v0.2.4 adds a project-scoped collaboration layer:

• Q6 user alignment
• user execution workflow state
• delivery-form gates
• working-agreement surfacing
• no reductive user labels
• tutorial coverage
• handoff preservation
• grounding profile alignment

The result is a more consistent prompt-runtime experience across users, sessions, and output styles, while preserving AIR’s existing evidence, scope, and claim-boundary discipline.

VM4AI AIR Kit v0.2.3

AIR v0.2.3 — Runtime Grounding and Onboarding Hardening

Status

Released.

Commit: 62331f3

Summary

AIR v0.2.3 hardens prompt-runtime behavior around onboarding, active-step anchoring, capability routing, benchmark explanation, visionary idea handling, regulatory pressure discovery, and handoff output.

This release keeps AIR prompt-native. It does not add backend validation, runtime enforcement outside the model session, signed contracts, autonomous execution, or external verification.

What changed

Deterministic onboarding and Q1 handling

Q1 remains a branch selector, not an intent classifier.

AIR now handles Q1 questions, objections, or uncertainty as onboarding detours rather than silently inferring a branch. If a user asks for clarification during Q1, AIR should answer briefly, preserve Q1 state, and return to Q1.

Q1-B and Q1-C are now more clearly separated:

• Q1-B imports an existing non-AIR project, repo, spec, transcript, note set, or file set into AIR.
• Q1-C continues only from a valid AIR_HANDOFF_CARD.

Q1-D beginner orientation refinement

The beginner orientation path remains instructional only and must return to Q1 before activation.

Q1-D examples are now framed as optional example projects showing how AIR works. The user-facing flow should ask explicitly whether the user wants to see the example before returning to Q1.

The example flow avoids calling the example “fake” and uses clearer language for new users.

Benchmark synthetic-role clarity

AIR now explains benchmark identity as a synthetic role.

A synthetic role is not a normal human job title, employee role, or persona. It is a task-fitted blend of vectors, constraints, evidence expectations, and relevant professional taxonomies selected for the current active step.

Benchmark identity is active-step scoped unless explicitly carried forward by the active contract or artifact.

Orbit 0 prompt-side anchoring

AIR now has stronger prompt-side anchoring when drift risk is material.

Before material execution, review, closure, handoff, mutation, or rescope, AIR can surface a compact active-step anchor showing:

• active contract or task kernel
• current active step
• active benchmark when material
• demoted or conflicting outer-orbit context when relevant
• allowed next action
• evidence required to close

This is meant to prevent older context from silently overriding the current active step.

Capability brief permission gates

Capability-layer routing now requires clearer explanation before approval.

When AIR recommends a specialist profile, domain package, or method pack, it should explain:

• detected trigger
• recommended layer
• primary constraint
• output effect

This helps users understand what behavior will change before approving attachment, generation, binding, or degraded continuation.

Capability layer output effects

The release clarifies how capability layers affect AIR output:

• Specialist profiles change evaluation posture, benchmark defaults, review strictness, blocking conditions, preferred vectors, and output contracts.
• Domain packages change terminology, constraints, evidence expectations, unsafe-assumption checks, failure-mode scanning, and claim boundaries.
• Method packs change repeatable procedure, templates, evidence-to-advance gates, failure handling, and handoff portability.

Domain packages remain referential overlays and do not govern Orbit 0 by themselves.

Strict handoff JSON output

When generating a copyable AIR_HANDOFF_CARD, AIR should emit a strict JSON restoration object without greetings, narrative framing, sign-offs, or explanatory wrapper text unless the user explicitly asks for an explanatory version.

This improves handoff portability across sessions.

Workflow convention authority

AIR now distinguishes prompt-binding workflow conventions from provisional assumptions.

Workflow conventions may be:

• USER_DECLARED_PROMPT_BINDING
• USER_CONFIRMED_PROMPT_BINDING
• HANDOFF_RESTORED_PROMPT_BINDING
• INFERRED_PROVISIONAL
• DEFAULT_PROVISIONAL

Prompt-binding means AIR must follow the convention during prompt execution unless changed by the user. It does not imply backend enforcement.

Minimal boot orientation header

After required boot evidence and before Q1 onboarding, AIR may show a compact orientation header:

AIR boot active.

Prompt-compiled from uploaded AIR materials.
Not backend-validated.

The header must not replace AIR_SESSION boot evidence and must not become a greeting, marketing copy, or repeated onboarding receipt.

Visionary grounding question loop

AIR now handles visionary, speculative, frontier, impossible-sounding, or currently unsupported ideas as grounding states rather than dismissal states.

AIR should not reject an entire idea merely because the current mechanism is not evidenced or buildable.

Instead, AIR should:

• preserve the ambition
• separate ambition from proposed implementation
• identify current feasibility state
• mark frontier or blocked layers
• ask clarifying and grounding questions
• extract executable kernels where possible
• create research paths or future claim targets

Current infeasibility is a routing state, not a dismissal state.

High-strength claim handling

Words such as “military-grade,” “quantum,” “guaranteed,” “unbreakable,” or other high-strength/frontier terms should not automatically block the project.

They should trigger claim hygiene, evidence checks, and clarification.

AIR may preserve these terms as ambition or future claim targets, but must not approve them as current public/product claims without evidence.

Regulatory pressure discovery gate

AIR now detects regulatory or compliance pressure earlier.

When a project may involve regulated surfaces such as customer data, cloud storage, accounts, payments, analytics, AI processing, location, health, finance, identity, children, publishing, or commercial deployment, AIR should ask narrow discovery questions before treating the project as launch-ready, compliant, or publicly claimable.

AIR should ask about:

• operator or company location/registration
• intended user/customer locations
• collected, stored, processed, transmitted, or shared data
• sensitive or protected data categories
• third-party services
• deployment/release stage
• available legal or compliance sources

Regulatory uncertainty is a routing and evidence state, not project rejection and not legal advice.

Updated files

• README.md
• ROADMAP.md
• docs/AIR_USER_GUIDE.md
• prompts/AIR CONTROL SURFACE.md
• prompts/AIR CORE RUNTIME.md
• prompts/AIR DEFAULT STARTER PROFILE.json
• prompts/AIR HANDOFF CARD TEMPLATE.json
• profiles/grounding specialist/AIR GROUNDING DOMAIN PACK.json
• profiles/grounding specialist/AIR GROUNDING SPECIALIST.json

Validation

JSON validation passed locally for:

• prompts/AIR DEFAULT STARTER PROFILE.json
• prompts/AIR HANDOFF CARD TEMPLATE.json
• profiles/grounding specialist/AIR GROUNDING DOMAIN PACK.json
• profiles/grounding specialist/AIR GROUNDING SPECIALIST.json

Manual prompt testing passed for:

• minimal AIR boot header
• Q1-D beginner orientation flow
• optional example-project invitation
• synthetic benchmark-role explanation
• visionary/dual-use grounding behavior
• high-level defense-adjacent feasibility framing without operational escalation

Boundary

This release does not claim:

• backend validation
• runtime enforcement outside the model session
• signed or tamper-evident contracts
• autonomous agent execution
• legal/compliance advice
• production readiness
• empirical validation of AIR behavior across all models

AIR v0.2.3 remains a public prompt-native runtime hardening release.

VM4AI AIR Kit v0.2.2

AIR v0.2.2 — Beginner orientation, cooperative work and release notes

AIR v0.2.2 is a documentation and release-hygiene update for the public prompt-based AIR Kit.

This release updates the README and roadmap to match the latest Q1-D onboarding behavior. Q1-D is now documented as a beginner orientation path, not a project activation shortcut or generic tutorial branch.

Changes

• Updated Q1-D wording from “onboarding tutorial” to “beginner orientation.”
• Clarified that Q1-D is instructional only and must return to Q1 without activating a project.
• Added cooperative-work framing to the README.
• Documented that AIR is cooperative, not automatic: the user steers intent, constraints, corrections, and approvals; AIR protects scope, structure, evidence, blockers, continuity, and next actions.
• Documented that Q1-D should visibly offer an optional dynamic example AIR project before returning to Q1.
• Clarified that the example offer is required, but running the example is optional.
• Clarified that examples should be generated dynamically and interactively, not hardcoded as a fixed canned demo.
• Updated the roadmap to mark v0.2.1 as released.
• Added v0.2.2 as the next documentation/examples/release-hygiene track.

Why this matters

AIR depends on deterministic onboarding. The startup phrase “Start a new AIR project” may trigger the first activation flow, but it must not silently answer Q1 as “A. New project.”

This release makes the first-use path clearer:

1. AIR boots.
2. AIR asks Q1.
3. If the user chooses D, AIR explains AIR in beginner-facing language.
4. AIR explains cooperative work.
5. AIR offers an optional example project.
6. AIR returns to Q1.
7. The user chooses the actual project path.

That keeps onboarding deterministic while making AIR easier to understand for new users.

Scope boundary

This release does not add backend validation, runtime enforcement outside the model session, signed contracts, autonomous execution, or private AIR backend/client features.

AIR remains a prompt-native project runtime kit.

Prompt-side discipline is not backend validation.

Suggested smoke test

After updating, start a fresh model session with the AIR prompt files and type:

Start a new AIR project.

Expected behavior:

• AIR asks Q1.
• AIR does not infer Q1 = A.
• Choosing D starts beginner orientation only.
• The orientation includes cooperative-work framing.
• The orientation asks whether the user wants an example AIR project.
• If the user asks for an example, AIR generates a dynamic interactive example.
• AIR returns to Q1 without activating a project.

Release type

Documentation / release notes.

VM4AI AIR Kit v0.2.1

VM4AI AIR Kit v0.2.1

This release patches AIR's prompt-runtime behavior around deterministic onboarding, capability-layer need detection, and AIR Method Layer routing.

It builds on v0.2.0's public prompt-kit refresh and keeps the same scope boundary: AIR Kit remains a prompt-only, user-loadable framework for structured AI-assisted project work. It does not claim backend validation, runtime enforcement, signed contracts, autonomous agent execution, or empirical performance improvement.

Highlights

• Added deterministic onboarding non-inference doctrine.
• Clarified that Q1 is a branch selector, not an intent classifier.
• Prevented host models from inferring Q1=A from activation text such as "Start a new AIR project."
• Preserved Q1-D as an instructional tutorial branch that must return to Q1 before activation.
• Added capability-layer need detection for specialists, domain packages, and method packs.
• Clarified that AIR should request or offer capability layers when needed instead of expecting users to know.
• Added AIR Method Layer doctrine.
• Clarified that task-local procedure belongs in AIR_ARTIFACT.method by default.
• Clarified that reusable AIR_METHOD_PACK promotion happens only when justified by recurrence, low variance, portability, template need, or defect/rework history.
• Added Control Surface rendering for deterministic onboarding checks, capability-layer checks, and method-layer state.
• Updated Default Starter awareness for deterministic onboarding, capability-layer detection, and method-layer behavior.
• Updated Handoff Card Template to preserve onboarding, capability-layer, and method-layer state across sessions.
• Updated README, roadmap, and user guide documentation for the new behavior.

What changed

Deterministic onboarding

AIR onboarding questions are now explicitly protected from host-model inference.

Start a new AIR project may trigger first activation flow, but it must not silently answer Q1 as A. New project.

Q1 must be:

• explicitly answered by the user
• restored from a valid handoff card
• proposed visibly by AIR and approved by the user

This protects import flow, handoff flow, and tutorial-flow testing from being bypassed.

Capability-layer need detection

AIR now has explicit doctrine for detecting when the Default Starter is not enough.

AIR may recommend:

• a specialist profile for reusable capability posture and judgment
• a domain package for terminology, standards, evidence expectations, model/platform facts, and claim boundaries
• a method pack for reusable ordered procedure

AIR may recommend automatically, but generation still requires explicit user approval and binding requires validation/routing fit.

AIR Method Layer

The applied method for a task belongs in:

AIR_ARTIFACT.method

This keeps one-off procedures fitted to the active task.

Reusable AIR_METHOD_PACK files are promoted only when a method proves reusable, low-variance, portable, template-bearing, or defect-reducing.

A Method Pack standardizes procedure. It does not prove the procedure executed and does not provide backend validation.

Scope boundary

This release does not claim:

• backend enforcement
• signed AIR contracts
• runtime validation
• autonomous agent execution
• tool execution
• empirical AIR performance improvement
• provider-independent reliability

AIR Kit v0.2.1 remains a public prompt/profile/documentation kit.

Recommended use

Use the standard new-project boot bundle:

• prompts/AIR CORE RUNTIME.md
• prompts/AIR CONTROL SURFACE.md
• prompts/AIR DEFAULT STARTER PROFILE.json

Then type:

Start a new AIR project.

AIR should ask Q1 rather than infer it.

For continuation, attach:

• prompts/AIR CORE RUNTIME.md
• the previous AIR_HANDOFF_CARD

Optionally attach:

• prompts/AIR CONTROL SURFACE.md

Upgrade notes

Replace or pull the updated prompt files and documentation.

If you maintain your own AIR handoff templates, add fields for:

• deterministic onboarding state
• capability-layer need state
• method-layer state
• recommended method packs
• generated method packs pending validation
• validated available method packs
• active method pack

Suggested regression check

After loading the v0.2.1 prompt files, test:

Start a new AIR project.

Expected behavior:

• AIR begins first activation flow.
• AIR emits required boot evidence if configured to do so.
• AIR asks Q1.
• AIR does not infer Q1=A.
• If Q1-D is selected, AIR explains itself and returns to Q1 without activating a project.

VM4AI AIR Kit v0.2.0

VM4AI AIR Kit v0.2.0

This release refreshes the public AIR Kit as a prompt-only, user-loadable framework for structured AI-assisted project work.

It updates the public documentation, removes obsolete agent-bridge material, clarifies licensing/notice metadata, improves onboarding and ambiguity handling documentation, and aligns grounding profile doctrine across canonical JSON files and human-readable Markdown references.

Highlights

• Clarified AIR as a public prompt-only kit, not a backend-validated runtime.
• Removed obsolete agent execution bridge materials.
• Added public user guidance and model portability notes.
• Added workflow declaration, model portability, and handoff restoration doctrine.
• Updated AIR Core Runtime, Control Surface, starter profile, and handoff template.
• Updated Grounding Specialist and Grounding Domain Pack JSON profiles.
• Updated human-readable grounding profile references to prevent JSON/Markdown doctrine drift.
• Added NOTICE for Apache 2.0 attribution/notice hygiene.
• Updated the ambiguity case study to mark it as a historical diagnostic case study and regression seed.

Scope Boundary

This release does not claim backend enforcement, signed AIR contracts, runtime validation, autonomous agent execution, or empirical AIR performance improvement.

AIR Kit v0.2.0 remains a prompt/profile/documentation kit. Backend validation, signed contracts, runtime enforcement, package distribution, or empirical performance claims require separate implementation and evidence.

Recommended Use

Use the JSON files for model upload and machine-readable profile/domain loading.

Use the Markdown files for human review, GitHub browsing, doctrine inspection, and discussion.

Use the case studies as product narrative, diagnostic records, and regression-test seeds — not as canonical runtime specifications.

v0.1.0 - AIR Prompt Runtime

First public release of VM4AI-AIR.

AIR is a prompt-based VM4AI runtime for AI project work.
Instead of treating an AI session like a generic chat, AIR activates a structured project state with explicit onboarding, contract binding, roadmap-first execution, active-step artifact generation and handoff continuity.

Included in this release:

• AIR Core Runtime Prompt.
• AIR Control Surface Prompt.
• AIR Default Starter Profile.
• AIR Handoff Card Template.
• Updated README.

AIR is built to:

• start projects in a controlled way.
• keep the current active step clear.
• surface blockers, obligations, and missing coverage explicitly.
• avoid generating the whole future workflow at once.
• carry project state forward through handoff.

Validated on:

• ChatGPT 5.4
• Claude Sonnet 4.6
• Gemini Thinking