Skip to content

VM4AI AIR Kit v0.2.3

Choose a tag to compare

View all tags
@eddlev eddlev released this 16 Jun 17:03
v0.2.3
62331f3

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.

Assets 2
Loading