Specification-First Verification.
Passing checks is not enough if the checks never represented what the work was supposed to achieve. AIR's SFV discipline defines the intended outcome and the evidence model before material execution, then tests whether the specification itself is adequate.
A green test suite can still certify the wrong thing.
If the planned checks omit a material part of the intended behavior, every check can pass while the result is still wrong. SFV moves that question earlier: before execution, is the specification strong enough to detect a materially incorrect outcome?
Could every planned verification pass while a material part of the intended behavior is still wrong? If yes, the specification or verification plan needs revision before AIR should treat implementation as ready to proceed.
Three pieces make the gate explicit.
For behavior-bearing coding work, AIR requires the intended behavior, the planned verification, and an adequacy state before code generation.
behavior_specificationWhat must be true
The intended observable or contractual behavior. It should describe the result that matters without unnecessarily locking in private implementation details.
verification_specificationHow it will be checked
The planned observations, tests, comparisons, reviews, expected results, and evidence classes that would justify accepting the behavior.
specification_adequacy_stateWhether the plan is sufficient
The pre-execution gate that asks whether the proposed verification could miss a material part of the intended outcome.
Specification before execution. Reconciliation after it.
SFV is not only a pre-coding checklist. The result has to come back through the same contract.
Resolve the task and intent
Establish goal, constraints, acceptance criteria, relevant sources, approval boundaries, and the current active task without silently replacing unresolved material intent.
Write the behavior specification
Define the externally meaningful result before choosing implementation details.
Write the verification specification
Choose checks that actually correspond to the intended behavior and identify what evidence their results must produce.
Gate on specification adequacy
Challenge the test plan with counterexamples, omitted conditions, failure cases, boundary cases, security or regression risks, and other task-relevant ways a wrong result could still pass.
Execute under the active contract
Implementation remains bounded by the active artifact, resource scope, approvals, and evidence requirements. The specification does not silently authorize unrelated work.
Evaluate the observed result
Run the available verification and preserve every evidence item the active claim and benchmark require. Evidence-presentation mode may change how much is displayed, but it does not reduce acquisition, preservation, evaluation, rigor, or approval obligations.
Reconcile back to original intent
Passing verification is evidence, not the definition of success. AIR compares the observed outcome back to the resolved original intent, behavior specification, and current acceptance criteria before closure.
The abstraction stays. The verification changes by domain.
AIR applies the same knowledge-to-execution discipline beyond software, but it does not pretend every domain has a unit test.
Evidence, triangulation, scenarios
Verification may involve source quality, provenance, contradiction checks, scenario testing, counterexamples, sensitivity analysis, or explicit uncertainty instead of executable tests.
Requirements, fidelity, human evaluation
Verification may involve source fidelity, requirement coverage, structural checks, user-visible outcomes, review criteria, or human judgment that is explicitly labeled as such.
What SFV does not claim.
Verification strength follows the evidence
SFV does not turn model judgment into deterministic proof. Formal verification, security review, production testing, operator checks, and external tools remain distinct evidence classes when the task needs them.
It governs the contract around them
SFV can incorporate unit tests, integration tests, regression tests, property checks, security checks, human QA, or other methods. It is the specification-and-evidence discipline around those checks, not a claim that one technique replaces all others.
Proportionality still applies
Low-risk work can stay light. The specification and evidence burden should rise with blast radius, irreversibility, uncertainty, and the cost of being wrong.
Prompt AIR is behavioral governance
The public AIR Kit is prompt-based. Backend or gateway enforcement must be supported by real backend evidence before AIR may claim it exists.