One platform.
Two implementation layers.

The authoritative native C++ Governance Engine. It normalizes a governance request, pins one immutable Snapshot (policy IR, capability catalog, topology, and constraints), evaluates capability / topology / policy gates, and resolves a categorical Decision — ALLOW, DENY, DEFER, or ERROR. Every created transaction carries a signed Decision Receipt; an ALLOW issues a single-use Authorization Lease consumed through a claim → complete / abort / expire lifecycle. Governance is the sole authorization authority; the mathematical core evaluates but never authorizes. Reached against real agent tool calls at the OpenClaw gateway. Governance milestones 0–6 implemented and committed. Deterministic governance →

invaros-authority is the deployable process that hosts the Governance Engine and is the sole issuer of Decisions, Decision Receipts, and Authorization Leases. It owns Snapshot validation, activation, rollback and retirement, session and transaction lifecycle, signer and journal custody, and the peer-authenticated Governance Protocol endpoint. It calls the Enterprise Math Provider when a Snapshot declares a constraint. Mathematics evaluates; Authority decides. InvarOS Runtime and other trusted clients reach it through the Authority Client; no client may issue a decision of its own.

A proprietary C++20 verification core built on continuous-time Markov chain (CTMC) methods. It produces deterministic verdicts about a system's structural and trajectory properties — not probability scores. The core is organized as a three-level architecture (below). It is exposed to the platform through a C ABI isolation boundary; the solver implementation is confidential. 573/573 native tests passed (July 2026).

The CANONICAL_POLICY is the single source of truth for governance rules. The PolicyToZKCompiler dynamically translates this policy into ZK-ready compliance JSON schemas (zk_compliance_claim.v1.schema.json), generating deterministic policy fingerprints. Schema correctness is verified in CI with zero-drift compile gates. "ZK-ready" describes the schema format; it is not a production zero-knowledge proving system.

The TBoM represents the operational topology of an AI system: capability boundaries, communication lanes, data routing constraints, agent composition, and trust relationships. It is defined by the open TBoM standard (Apache-2.0), with an Agentic Topology profile and an Edge Network Topology profile. Commitments, recognition records, and receipts are separate governance artifacts that reference a TBoM's fingerprint — they are not fields inside it. TrustManifest, SkillCard, and LocalRegistryCatalog structures are validated with sha256 canonical hashing. The Runtime Topology Plugin produces Edge Network Topology Profile 3.0.0 artifacts per observation epoch — a measured record, not a configuration blueprint.

Intent-to-Settlement lifecycle management via CommitmentArcClient. Commitment schemas cover intent, consent, refusal, settlement, envelope, proof packet, verification report, and ZK compliance claim. Native Temporal Micro-Chain implementation provides cryptographic chain append and verification. Hardware attestation descriptor validation is structural (live TPM quote-chain verification is deferred to roadmap).

Non-blocking hook on the orchestrator generates, per accepted result: a CycloneDX 1.6-compatible CBOM tracking event sequences and digests; an in-toto Statement v0.1 in an unsigned structural envelope or a signed DSSE envelope (when an HMAC key is present); and a ZK-ready ComplianceClaimEnvelope. Thread-safe with lock-based sequential versioning.

Enterprise-grade ValidatingAdmissionWebhook handler (K8sAdmissionHandler). Validates SLSA claims in pod annotations, checks attestation descriptor registration (structural validation, not live TPM/SGX/SEV hardware verification), assesses cross-tenant namespace trust contracts, and evaluates pod capability requests via the orchestrator. Fail-closed with failurePolicy: Fail and 10-second timeouts. The invaros-mcp-gateway Helm chart packages this Python FastMCP/ASGI integration surface with a rootless security context, liveness probes, and cert-manager TLS. It is separate from the native Runtime.

Federation operates on three pillars: Governance (Rule), Commitment (Proof), Federation (Recognition). The FederationRecognitionAdapter handles recognition asynchronously via ThreadPoolExecutor, returning Future handles immediately to decouple verification latency from solver logic. No decentralised consensus. No WAN broadcast. All recognition is local and offline, relying on fingerprint-only structural matching.

MCP stdio server, InvarOS MCP Gateway (the FastMCP HTTP service) with /k8s/admission routing, an OpenTelemetry offline evidence sidecar (local span/metric mapping, no live export), a local LangChain tool/runnable adapter (InvarOSToolkit), a Kubernetes manifest generator, and the invaros-mcp-gateway Helm chart. Nine offline evidence adapters in total — no live credentials or network calls in verified test paths. LangChain and MCP commitment tools are exposed via typed input schemas.