Test the claim you actually want to make.
AIR records can make the working contract inspectable. They do not turn every statement into proof. Use the evidence source that corresponds to the thing you are claiming, then make only the claim that evidence supports.
Start with the claim.
Do not begin with whichever test or record happens to be available. Begin with what you need to establish.
What did AIR declare?
Evidence: surfaced AIR records and the current prompt contract.
Supports: bounded claims about what AIR declared about scope, state, approvals, blockers, evidence posture, or continuation at that point.
Does not support: hidden reasoning, proof that the underlying evaluation was correctly performed, external tool execution, deployment, or correctness by itself.
Does the implementation work?
Evidence: unit/integration tests, build output, deployment evidence, logs, operator observation, security checks, or another appropriate system test.
Supports: only the behavior actually exercised under the recorded conditions.
Is the statement supported?
Evidence: the relevant primary or authoritative source, with secondary sources used proportionally.
Supports: the proposition the source actually establishes, not a broader inference AIR finds plausible.
Was the work reviewed or accepted?
Evidence: the named reviewer, decision, review record, approval, or acceptance criteria used.
Supports: that a review or human decision occurred. It is not independent proof of facts the reviewer did not test.
Did recorded project state continue?
Evidence: source state, Handoff record, current receiver validation/alignment, artifact rebinding, and the receiving session's restored state.
Supports: a bounded continuity claim about recorded project state. It does not prove hidden-state transfer or identical inference.
Can this configuration sustain AIR?
Evidence: an observation tied to the named host/model configuration and AIR version actually tested.
Supports: compatibility for that tested configuration, not every model or future release on the platform.
Use the certainty word you earned.
Small wording differences matter because they imply different evidence burdens.
It happened in the stated run.
Use when you directly observed the behavior, result, or state in the identified test or project context.
A defined check established it.
Use when an appropriate test, source, tool, or review process actually checked the proposition and produced evidence.
The evidence points there, but does not directly establish it.
Keep inference visibly separate from sourced or tested fact when the distinction could affect a decision.
The evidence is not sufficient yet.
Unknown is a valid project state. AIR should not upgrade it merely because a plausible answer is available.
Behavioral and deterministic checks are separate on purpose.
AIR is partly a prompt-runtime system and partly a public release artifact. Those are different test targets and should not borrow each other's certainty.
Does a live host model sustain the AIR contract?
Run the relevant AIR version in an isolated project context and exercise the runtime behaviors being claimed. Record successes, failures, drift, recovery, and configuration details.
Repeated successful observations increase confidence; they do not make stochastic model inference deterministic. AIR Kit v0.6.0 does not claim fresh universal behavioral certification across every provider/model.
Does the public release match its sealed contract?
The current public repository uses deterministic distribution-integrity checks to verify the release's expected version and Foundation/distribution identities. Those checks can establish the package properties they actually inspect.
They do not prove deterministic LLM inference, universal host compatibility, or that every prompt-runtime behavior will be reproduced on every model.
Does the release make sense as a product?
Review documentation coherence, runtime behavior in use, website/repository consistency, regressions, copy, compatibility observations, and release readiness.
Do claims outside AIR have outside evidence?
Repository state, deployments, security behavior, tool calls, external sources, and real-world outputs require evidence from the corresponding external system or source.
A deterministic distribution check cannot prove model behavior. A successful model session cannot prove release integrity. A human approval cannot prove an external event the reviewer did not observe. Keep the evidence layers related but separate.