One platform.
Two implementation layers.
InvarOS is a unified AI governance platform built in two complementary layers. The Enterprise platform provides mathematical verification, policy compilation, and compliance infrastructure. The invarosd runtime grounds those capabilities in physical, deployable reality.
Solid borders indicate implemented and operational components. Dashed borders indicate planned roadmap capabilities. Roadmap items are not yet available.
Enterprise governance platform
The enterprise platform provides the mathematical and orchestration substrate for deterministic AI governance. All components listed below are implemented and tested.
Mathematical Verification Core
Implemented · ProprietaryC++20 / Eigen-based proprietary mathematical solver for deterministic state and trajectory verification. Structural analysis, cycle verification, transient distribution computation, and entropy constraint enforcement. The pybind11 wrapper exposes the solver through a C ABI isolation boundary. Implementation is confidential and proprietary.
Policy-to-ZK Compiler
Implemented
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. 95 compiler tests pass.
Topology Bill of Materials (TBoM)
Implemented
TBoM v3 schema represents the full operational topology of an AI system: capability
boundaries, communication lanes, data routing constraints, agent composition, trust
relationships, and evidence chains. TrustManifest,
SkillCard, and LocalRegistryCatalog structures are
validated with HMAC-SHA256 canonical hashing. The invarosd topology plugin produces
live TBoM 3.0.0 artifacts per observation epoch — a measured record, not a
configuration blueprint.
Commitment Arc Engine
Implemented
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).
Continuous Attestation Pipeline
Implemented
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.
Kubernetes Admission Enforcement
Implemented
Enterprise-grade ValidatingAdmissionWebhook handler
(K8sAdmissionHandler). Validates SLSA claims in pod annotations,
verifies hardware attestation node registration, assesses cross-tenant namespace
trust contracts, and evaluates pod capability requests via the orchestrator.
Fail-closed with failurePolicy: Fail and 10-second timeouts.
Helm chart includes rootless security context, liveness probes, and cert-manager TLS.
Asynchronous Air-Gapped Federation
Implemented
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.
Enterprise Integrations
Implemented
MCP stdio server, FastMCP HTTP server with /k8s/admission routing,
OpenTelemetry exporter and log sidecar, LangChain adapter
(InvarOSToolkit), Kubernetes manifest generator, and Helm chart
deployment. LangChain and MCP commitment tools are exposed via typed input schemas.
Native runtime and plugin host
The invarosd daemon is the deployment and extension substrate for the enterprise platform. It operates without requiring a persistent cloud connection and has been compiled and deployed on heterogeneous hardware.
Demonstrated capabilities
| Capability | Status |
|---|---|
| Dynamic native plugin loading (.so) | Operational |
| Topology discovery (TBoM 3.0.0) | Operational |
| Topology fingerprint generation | Operational |
| Host fingerprint generation | Operational |
| Receipt generation | Operational |
| Dell x86_64 Linux deployment | Deployed |
| GL-MT3000 OpenWrt deployment | Deployed |
| Heterogeneous multi-target operation | Demonstrated |
| Air-gap autonomous operation (no cloud required) | Demonstrated |
| MCP Gateway Plugin (protocol interception) | Roadmap |
| Local ZK Policy Evaluator Plugin | Roadmap |
| TR-369 USP Telemetry Plugin | Roadmap |
Why native?
Performance on constrained hardware
The GL-MT3000 runs OpenWrt on a MIPS processor with limited CPU and memory. JVM, V8, and WebAssembly runtime overhead is not viable on this hardware. The native C daemon executes with minimal footprint, enabling governance capabilities that cannot be delivered by application-tier runtimes on constrained hardware.
IP boundary by design
The C ABI isolation boundary cleanly separates the open plugin host from proprietary compiled capabilities. Mathematical solver plugins can be distributed as protected binaries without exposing proprietary algorithms or solver internals to the open-core.
Substrate for enterprise capabilities
invarosd is not an independent product — it is the physical enforcement and evidence-gathering layer that grounds the mathematical enterprise platform in deployed reality. The enterprise platform's ZK schemas, policy fingerprints, and TBoM artifacts are designed to flow down to the native runtime as compiled plugins.
On roadmap honesty: InvarOS does not currently provide self-service software downloads, a hosted SaaS portal, an inline MCP Gateway plugin, or live TPM quote-chain hardware attestation. The current native runtime demonstrates topology discovery and receipt generation on two hardware targets. The enterprise platform's mathematical and compliance machinery is fully implemented and tested. What remains is the integration bridge between the two — a deliberately sequenced engineering path, not a gap.
See the architecture in detail.
The Architecture page shows the system layers, deployment diagrams, and authentic topology data from both hardware targets.