Governance you can deploy — deterministically, and prove it landed.
Governing AI is only useful if the governance itself is installed correctly, verifiably, and reproducibly. InvarOS ships governance through a deterministic, air-gap-capable deployment lifecycle: an immutable release, offline qualification, side-by-side install, activation, live health verification, and a read-only reconciliation that classifies exactly what is running.
First fully governed deterministic deployment completed. On 26 July 2026, InvarOS executed the full lifecycle — from release construction through deterministic reconciliation — on a real, privileged, systemd-managed server target. The deployment reached DEPLOYMENT_HEALTHY and its reconciliation was classified CANDIDATE_ACTIVE. Later qualification and promotion gates (below) remain deliberately open.
What the deployment actually produced.
These are properties of the recorded deployment run, bound to an immutable release manifest. We state exactly what was reached and what was not.
- result
- DEPLOYMENT_HEALTHY — live identity and readiness verified
- reconciliation
- CANDIDATE_ACTIVE — the candidate release is the running deployment
- release manifest
- immutable release-manifest/v2, 33 artifacts hash-bound
- target
- x86_64 server, systemd, air-gapped deployment profile
- authority
- Governance-authoritative · marker enforcement removed · Enterprise Math Provider required
- runtime
- Governance Host started first, then the adapter and agent gateway, under systemd supervision
Every transition is deterministic and evidenced.
Deployment state advances through compare-and-swap transitions written atomically (temporary file, fsync, atomic rename) with an append-only event journal. The default operator workflow ends at DEPLOYMENT_HEALTHY. Qualification and promotion are separate, explicit, gated steps.
reached states through DEPLOYMENT_HEALTHY. gate DEPLOYMENT_QUALIFIED and PROMOTED require operator-run rollback drills, a performance budget pass, and a soak run — not yet performed.
Immutable release
A release-manifest/v2 hash-binds a deployment layout, the governance authority, source commit state, and every artifact (path, hash, size, mode). Verification rejects missing, extra, symlinked, multiply-linked, writable, wrong-sized, wrong-mode, or wrong-hash files. The tarball is byte-reproducible.
Offline qualification
Before install, the artifact passes offline manifest, regression, packaging, and authority-boundary checks — with no network. Governance and adapter regressions and the canonical-authority checks must pass.
Side-by-side install & activation
Installed under a versioned, root-owned release directory via staging and atomic rename. Activation selects exact regular files (no symlinked host artifacts), starts Governance first, and commits ACTIVATED only after the candidate is published and services start.
Health verification
A separate, safely repeatable phase verifies installed identities, services, sockets, authenticated Governance health, the required Math Provider, adapter, plugin, and gateway before committing DEPLOYMENT_HEALTHY.
Transaction journal
Activation, rollback, and recovery each maintain a durable transaction record and append-only phase journal identifying the release, manifest, layout, generation, backup manifest, operation, and last completed phase.
Immutable evidence
Each phase writes uniquely named, no-clobber evidence. Partial evidence is never accepted or overwritten; a resumed workflow publishes a new observation rather than mutating an old one.
Read-only truth about what is running.
Reconciliation is a read-only observation. It compares lifecycle intent against release identity, installed artifacts, running executables, services, sockets, authenticated Governance readiness, Math Provider identity, backup evidence, and transaction phase — then publishes one immutable classification. A successful run means the observation completed; it does not by itself mean the candidate is active.
PREVIOUS_RESTORED
all restorable targets match the captured prior state
MIXED
a partial candidate or previous deployment is observed
UNKNOWN
safety / identity / evidence / observability insufficient — never auto-recovered
Rollback
Four separable rollback layers exist: a Snapshot canary rollback through the local protocol without restarting the agent gateway; Governance host/engine artifact rollback; adapter/protocol artifact rollback; and full deployment rollback from the activation inventory. Each verifies hashes, Snapshot and provider identity, and sockets, and confirms that pre-rollback ALLOW cache entries and leases are not reused. A rollback whose post-restore validation cannot complete commits DEGRADED — never a false ACTIVATED.
Recovery
Recovery is a separate, explicit operator action. It consumes a reviewed reconciliation, repeats the observation, rejects intervening changes, and performs only the selected candidate or previous recovery. An UNKNOWN classification is never recovered automatically, and every attempt preserves its input and result as immutable evidence.
What is proven, and what is not — yet.
The lifecycle is implemented and has run end-to-end to a healthy, reconciled, governed deployment on real hardware. Beyond that, we make no claim we have not earned.
- The full lifecycle executed from release construction to CANDIDATE_ACTIVE / DEPLOYMENT_HEALTHY on real hardware.
- The release is immutable, byte-reproducible, and hash-verified.
- Governance was the sole authority; the Enterprise Math Provider was required and present.
- Not DEPLOYMENT_QUALIFIED: the live rollback drills, approved performance-budget pass, and soak run are operator-run gates that have not been performed.
- Not PROMOTED: promotion additionally requires clean-source builds and an explicit operator promotion record.
- Not described as production-ready. This is a demonstrated, evidenced deployment, not a general-availability claim.