Spec first. Then implementation.
For behavior-bearing software work, AIR uses a spec-driven sequence: resolve intent, define observable behavior and planned verification, test whether the specification is adequate, then implement and reconcile the result back to the original intent.
AIR is SDD-native for software work.
Spec-Driven Development is a family of development workflows in which the specification is established before material implementation and drives the downstream plan, tasks, implementation, and validation. AIR fits that category when it is doing software-development work.
AIR for software: spec-driven development. AIR as a system: specification-driven governed execution for sustained professional AI work. AIR is broader than software and should not be reduced to a coding-only SDD framework.
What the specification actually controls.
For material behavior changes, AIR does not treat “write code, then see whether tests happen to pass” as the default sequence.
Resolve intent
Fix the requested outcome, constraints, acceptance conditions, source set, approval boundaries, and what must not change.
Specify behavior
Describe the observable or contractual result the implementation must satisfy without unnecessarily prescribing private internals.
Specify verification
Define the checks, observations, expected results, and evidence classes that would justify calling the behavior correct.
Test adequacy
Ask whether every planned verification could pass while a material part of the intended behavior is still wrong. If yes, the specification is not ready.
Implement under contract
Generate or modify code only after the active task, scope, specification, evidence posture, and approval boundaries are bound.
Reconcile to intent
After verification, compare the observed result back to the original intent and current acceptance criteria instead of equating passing checks with success automatically.
SDD inside a governed project runtime.
AIR's software path is not only a specification format. The specification lives inside a broader execution contract.
One active execution center
The bound Orbit 0 artifact is the sole positive execution authority for material work. Queued or deferred tasks do not execute merely because they are known.
Approval and evidence stay explicit
Specifications do not grant unlimited authority. Tool use, source claims, external actions, verification claims, and closure remain subject to the active evidence and approval rules.
Changes revise the contract
If the requested behavior, source set, acceptance criteria, or approval boundary changes materially, AIR revises and rebinds state instead of silently letting the implementation drift away from the current specification.
Handoff carries the governed state
The specification can travel with the recorded project state through Handoff, then be validated and rebound in another compatible AIR session.
The discipline generalizes; the verification object changes.
Research may use source quality and triangulation. Analysis may use scenarios, criteria, counterexamples, and decision thresholds. Documents may use requirements and source fidelity. Design may use user-visible outcomes and human evaluation. AIR keeps the specification-first discipline while adapting the evidence model to the domain.
Specification-First Verification
See the behavior specification, verification specification, adequacy gate, and reconciliation loop in detail.
Open SFV →Where AIR fits
See how governed execution differs from raw chat, SDD harnesses, agentic engineering environments, and agent runtimes.
See the map →AIR is prompt-based in the public kit. It can materially shape how a compatible host model scopes, specifies, implements, verifies, and reviews work, but it does not independently guarantee tool execution, backend enforcement, or correctness. External claims still require matching external evidence.