AIIR for Regulated Engineering Teams

Public overview for teams that need declared-AI evidence to survive release review and still verify later without a hosted dependency.

Current fit: AIIR is open source and early. The best near-term use is technical evaluation, not a procurement shortcut.

The narrow problem

Once AI-assisted changes are allowed under policy, the next question is not whether AI was used. The question is whether a team can later show that the declared AI-assisted change still matches the released bytes in a repository that matters to audit, safety, or control review.

AIIR is designed to support that declared-AI evidence gap with tree-bound receipts, signed release artifacts, and deterministic verification that can run offline against archived materials.

What AIIR proves and does not prove

Surface What it gives you Limit
Receipt integrity Content-addressed proof that the receipt payload has not changed. Unsigned receipts prove integrity, not signer identity.
Declared AI context Binds declared AI context to the commit tree and related metadata. Does not recover undeclared AI use.
Signed release evidence Supports stronger provenance claims through Sigstore-signed release artifacts. Does not replace your QMS, MRM process, or audit opinion.
Independent verification Reconstruction can run offline against archived bundles and trust material. Runtime behavior still needs separate test and release evidence.

Three evidence surfaces

Commit attestation

AIIR generates deterministic receipts for declared AI-assisted commits and binds them to the commit tree so later tampering breaks verification.

pip install aiir
aiir --pretty
aiir --verify .aiir/receipts.jsonl

Release evidence

At release time, receipts can be bundled with signatures, trust roots, and release artifacts so the evidence survives beyond the live repository.

Audit reconstruction

Verification is designed to be deterministic and offline. The goal is that an auditor or internal review team can reproduce the same answer later without calling back to a hosted AIIR service.

Regulatory lenses AIIR is designed to support

These are evidence-shape mappings, not compliance guarantees.

Regime Evidence question AIIR surface
SR 11-7 Can model-adjacent changes be tied back to declared AI use and later reviewed? Tree-bound receipts plus archived release evidence.
FDA SaMD / 21 CFR Part 11 Can electronic engineering records show integrity and authorship context? Content-addressed receipts and optional signing.
DO-178C Can declared AI-assisted changes sit beside existing CM evidence? Deterministic receipts and offline-verifiable release bundles.
SOC 2 Can change evidence remain durable after release? Signed release evidence that verifies against archived materials.

Conservative rollout

  1. Define what must be declared under engineering policy.
  2. Start on the CLI path and verify receipts locally.
  3. Add CI policy checks only after the local path is understood.
  4. Sign release evidence in CI when stronger provenance is required.
  5. Archive the verifier command and trust material with the release record.

Public website, controlled follow-through

For regulated evaluation, the public website is the disclosure surface, not the delivery surface.

  • Public apex: use invariantsystems.io for public docs, proof boundaries, and request paths.
  • Controlled access: move partner packets, operator workflows, and NDA material onto authenticated subdomains in the same .io namespace.
  • No public mirror of private material: do not publish T1+ packets from this public GitHub Pages repo just to keep URLs neat.

If a same-host nested path is ever introduced later, it needs authenticated edge routing and a protected origin instead of static public hosting.

Next steps

Use the trust page for the exact proof boundaries, the demo for a public verification walkthrough, the docs for install and interface details, and the spec for the receipt contract.