Platform concepts.

The prevailing approach to AI security treats governance as an application-layer concern: an API proxy inserted before the model, a prompt filter on the input pipeline, or a dashboard aggregating post-hoc telemetry. These approaches share a structural weakness — they operate on voluntary cooperation. An autonomous agent is not obligated to route its traffic through your proxy.

InvarOS starts from a different premise. Governance belongs in the same category as networking, storage, and compute — it is a property of the infrastructure, not a policy applied on top of it. InvarOS Runtime runs directly on host network interfaces. Evidence is generated at the hardware level. The enforcement surface is the substrate on which agents run, not a wrapper around them.

Infrastructure-layer governance produces evidence that is structurally more difficult to circumvent, because circumventing it requires circumventing the underlying operating environment. Application-layer governance produces advice that a sufficiently sophisticated agent can route around. This is the category InvarOS is building: Infrastructure Governance.

A Topology Bill of Materials is a formal, machine-readable artifact that represents the operational topology of an AI system — not merely its network configuration. A TBoM may span multiple layers of an AI deployment: physical and logical infrastructure, execution topology, agent and tool composition, capability registrations, governance boundaries, data paths, and trust relationships. It is a pre-execution structural artifact — it does not execute agents, sign, load keys, or contain solver output. Commitments, recognition records, receipts, and evidence chains are separate governance artifacts that reference a TBoM's fingerprint; they are not fields inside it.

The scope of a TBoM is determined by the deployment context. At minimum, the TBoM produced by the Runtime Topology Plugin contains a graph of discovered network interfaces, bridges, tunnels, and physical links, together with their operational state and a cryptographic fingerprint. In a full enterprise deployment, the TBoM extends to model the entire AI operational environment: which agents are present, what tools and capabilities they have access to, what policies govern their operation, and what evidence has been produced.

Governance cannot be meaningful if it is blind to what it is governing. A TBoM that captures only the network layer cannot reason about whether a particular AI agent has access to an unauthorised capability. A TBoM that captures the full operational topology can. The TBoM is not a configuration file, not a CMDB entry, and not a discovery scan. It is a formal representation of what is present and how it is connected, at a measured instant.

Each TBoM carries a cryptographic fingerprint over the state it declares or observes; the exact identity model is defined per profile. Two TBoMs with different fingerprints represent topologically distinct environments, regardless of whether the difference was intended. TBoMs are durable governance objects — they persist as verifiable artifacts, can be compared to detect drift, and serve as anchors for downstream evidence. Receipts, attestations, and recognition records all reference the TBoM that was current when they were produced.

TBoM is published as an open, Apache-2.0 specification — the open topology standard for Infrastructure Governance — with JSON Schemas, a reference validator, and conformance vectors. See the TBoM standard →

A Proof of Excluded Functionality is evidence that a declared operating envelope excluded a capability or pathway before execution was attempted. It is the inverse of a capability claim. Where a capability claim says "this agent can do X," a Proof of Excluded Functionality says "this operation fell outside the agent's declared and governed envelope, and here is the structural evidence."

Conventional software verification focuses on what code does. Proof of Excluded Functionality addresses what a governed system did not permit. In AI governance, this matters because the safety-critical property is often a negative: the agent must not be able to exfiltrate data over unauthorised channels, initiate unapproved network connections, or invoke capabilities that were not present at policy compilation time.

InvarOS constructs a Proof of Excluded Functionality from the combination of four things: topological exclusion (undeclared edges and endpoints are non-discoverable and refused pre-execution), capability exclusion (a bounded capability registry), policy exclusion (canonical policy forbids the pathway), and evidence (a refusal receipt carrying a refusal code and layer). This is not a universal mathematical impossibility proof — it holds within the governed execution paths, the declared topology, and the stated capability and policy assumptions. Within an InvarOS-governed topology, undeclared capabilities and pathways can be excluded before execution and recorded as structured refusals; InvarOS can produce evidence that a given operation was outside the agent's declared and governed operating envelope.

In most AI systems, a refusal is an ephemeral event — a negative response that disappears into logs, if it is recorded at all. The agent declined to act, an error was returned, and the system moved on. This approach discards information that is structurally important for governance.

InvarOS treats refusals as first-class governance artifacts. When the governance system declines to authorise an operation — whether due to policy violation, failed attestation, unverified topology, or missing commitment — that refusal is not discarded. It becomes a structured, classified record: a durable governance object that can be inspected, cryptographically linked to the evidence that produced it, compared against prior refusals, audited, and referenced by future policy decisions.

Refusals belong to defined governance classes. A refusal produced by a policy evaluation is categorically distinct from one produced by a failed attestation check, which is in turn distinct from one produced by a topology mismatch. These classes are not arbitrary error codes — they represent different failure modes of the governance model, each with different implications for what corrective action is appropriate and what evidence should accompany the record.

A deployment's refusal history becomes an auditable corpus. An auditor examining past refusal records can determine not just that operations were declined, but under which class of governance rule, at what epoch, against what topology, and correlated with what other evidence. This is the difference between a governance system that enforces policy and one that can demonstrate that it enforced policy.

Deterministic governance produces a binary verdict — compliant or non-compliant — based on structural evidence rather than probabilistic scoring. It does not produce a confidence level, a risk score, or an anomaly threshold that requires calibration. A given topology either satisfies the policy or it does not.

Probabilistic approaches are suited to detection tasks where the signal is statistical — intrusion detection, fraud scoring, spam filtering. They are poorly suited to governance tasks where the requirement is categorical: the agent is or is not operating within its permitted boundary. A 94% confidence that an agent is compliant is not a governance guarantee.

InvarOS achieves deterministic governance through mathematical verification of structural properties. The governance policy defines permitted state transitions. The verification layer determines whether observed behaviour satisfies those structural constraints. There is no threshold to tune and no base rate problem — the verdict is derived, not inferred.

Governance that is unaware of topology cannot reason about connectivity, exposure, capability composition, or lateral movement. Most AI governance tools operate at the application layer — they see API calls, prompts, and responses. They have no visibility into which network interfaces are present, which agents have access to which tools, or whether an unexpected capability has been registered.

Topology-aware governance grounds policy in the actual structure of the environment. A policy that says "agents may not communicate outside the private subnet" can only be enforced — rather than merely monitored — if the governance layer has verified knowledge of what the subnet actually contains. A TBoM provides exactly this: a fingerprinted, epoch-stamped record of the actual operational graph.

When topology changes — a new interface appears, a capability is registered, an agent is scheduled, a trust relationship is modified — the topology fingerprint changes. This change can be detected, attested, and correlated against the expected topology derived from policy. Topology-aware governance makes the operational substrate a first-class input to policy evaluation.

Cryptographic evidence is a claim about system state that can be independently verified without trusting the party who produced it. InvarOS generates cryptographic evidence at each stage of the governance pipeline. Each stage produces a distinct governance object: topology observation produces a sha256-fingerprinted TBoM; execution events produce receipts fingerprinted with sha256 and signed with ES256/ECDSA, with an optional HMAC-authenticated DSSE envelope for in-toto statements; the attestation pipeline produces CycloneDX CBOM records and in-toto statement envelopes; policy compilation produces deterministic policy fingerprints; governance decisions produce classified refusal records or recognition packets.

The value of cryptographic evidence over assertion or logging is auditability under adversarial conditions. An assertion can be falsified. A log can be tampered with. A cryptographically signed artifact produced by a known key at a known time is structurally difficult to repudiate. When an auditor asks whether a particular governance policy was in effect at a particular time, the policy fingerprint in the evidence artifact provides a verifiable answer.

InvarOS aligns its evidence formats with established standards: CycloneDX 1.6 for CBOM, in-toto v0.1 statements in optional DSSE signed envelopes, and ZK compliance claim envelopes. Alignment with standards allows evidence to be consumed by third-party audit tooling without proprietary integration work.

Federation in InvarOS is the process by which a governance authority recognises that a remote deployment is operating within the bounds of a shared governance policy. Conventional federation is typically solved with consensus protocols — mechanisms that require all participating nodes to agree on state before any transition is recognised. This approach is incompatible with air-gapped environments where network connectivity between participants cannot be assumed.

InvarOS uses an asynchronous, non-consensus model. Recognition is local and offline: a governance authority processes cryptographic evidence packages — receipts, TBoM artifacts, commitment arcs — and issues recognition without requiring a live connection to the remote deployment. The remote deployment does not need to know that recognition has occurred. Transport of evidence is the operator's responsibility, which permits physically-mediated transport (removable media, courier) as well as network transport.

The model is structured around three pillars: Governance (Rule), Commitment (Proof), and Federation (Recognition). A rule defines the permitted space. A proof demonstrates that an action was taken within that space. A recognition record is the governance authority's cryptographic acknowledgement of the proof — a durable governance object that persists independently of the connection state between parties. No pillar requires a live connection to either of the other two.

A native runtime operates at the operating system level, compiled to native machine code for the target architecture, without an intermediate interpreter, virtual machine, or managed language runtime. InvarOS Runtime is a native C binary. This allows it to operate across the full deployment continuum — from enterprise server environments to constrained edge and micro-edge hardware — without architectural modification.

This matters for AI governance at the edge. Constrained hardware — network routers, embedded controllers, IoT gateways — is increasingly present in AI deployment environments. These devices cannot run a JVM or a Node.js process. A governance runtime that cannot operate on constrained hardware cannot enforce governance at the network boundary where it is most relevant.

Native runtime architecture also enables the C ABI plugin boundary. Capabilities are packaged as shared objects (.so files) loaded dynamically by the daemon without recompilation or service restart. This boundary allows proprietary mathematical solvers to be distributed as compiled plugins without exposing their implementation. The daemon remains open and auditable while the mathematical core remains confidential.

InvarOS Runtime also enforces that exactly one daemon instance may govern a machine's topology and network configuration at any time — verified before any plugin loads, so ownership of a device's governance surface is never ambiguous.

Plugin-based governance is the principle that governance capabilities should be modular, independently deployable, and capable of being updated without restarting the host process. InvarOS implements this through the C ABI plugin boundary in InvarOS Runtime. The Runtime is the host; capabilities are plugins loaded as shared objects at runtime.

The current operational plugins are topology discovery and Runtime evidence generation. Each capability is compiled to a separate shared object and loaded across a stable C ABI — a new topology plugin with support for additional interface types does not require modifying or recompiling the Runtime core.

The practical consequence is a clean separation between the Runtime's host responsibilities — process lifecycle, plugin loading, local service hosting — and the domain logic each plugin carries. In constrained environments where every code path on the device matters, that granularity of separation is architecturally significant.

InvarOS, a Yozi Systems platform, treats deliberate absence as a governance fact in its own right. Most systems document what they connect to; almost none formally document what they were built not to depend on. InvarOS Non-Dependency Mapping is the practice of declaring the absence of a dependency, path, import, service, tool, or external requirement as a first-class, verifiable governance object — not merely the lack of documentation about it.

The mapping is grounded in structural, declared facts rather than runtime inference: an absent edge in a TBoM is a declared non-connection, not just a gap in the graph. The metadata firewall's import restrictions are declared non-dependencies (governance code that may not import math internals, the native core, or an MCP SDK). Offline integration adapters declare zero live vendor-SDK, credential, or network dependence in their verified paths. The governance core itself declares zero required runtime dependencies, and Level 2 sparse validation is declared free of numpy/scipy by design.

This is a declarative, pre-execution mapping of boundaries the system was built to respect — not a runtime intrusion-detection system, and not a claim that every possible undeclared dependency has been exhaustively ruled out at runtime. Its value is the same as the rest of the TBoM family: it turns an architectural intention ("this component must never reach the network," "this boundary must never import that module") into a structural fact that can be inspected and referenced, rather than a claim that has to be taken on trust.

The InvarOS Unified Control Plane is the intended single point of policy authority, evidence aggregation, and governance verification for an InvarOS deployment — regardless of how many physical nodes, hardware targets, or deployment environments it spans. This is a direction, not a shipped capability: no live control-plane actions or live runtime telemetry are implemented today. It currently exists as a concept referenced in the enterprise shell navigation, in this concepts page, and in Runtime R&D planning.

The design intent is that each node produces governance objects locally, with no requirement for direct, persistent connectivity between the control plane and every governed node — the control plane would process governance objects as they arrive, evaluating evidence against the canonical policy to determine recognition status.

Until the Unified Control Plane ships, policy consistency across heterogeneous infrastructure — enterprise servers, edge routers, micro-edge devices — is maintained by operating each node against the same canonical policy, not by a live aggregating control plane.

InvarOS names components by what they are permitted to do, not by where they run. Two deployable processes carry the platform's governance behaviour, and they are not interchangeable.

InvarOS Runtime (invaros-runtime) is the portable native host for plugins and local platform services. It discovers topology, hosts the evidence plugin, exposes the local authorization API, and forwards governance requests. It holds no policy evaluator and issues no decisions. InvarOS Authority (invaros-authority) is the sole governance decision service. It hosts the Governance Engine, calls the Enterprise Math Provider when a Snapshot declares a constraint, and is the only component that issues Decision Receipts and Authorization Leases. Mathematics evaluates; Authority decides.

InvarOS MCP Gateway (invaros-mcp-gateway) is the separately packaged Python FastMCP/ASGI integration service. It is an application gateway, not the Runtime. Runtime and other trusted clients reach Authority through the Authority Client over the versioned Governance Protocol.

Earlier material used different names. invarosd is the legacy name for InvarOS Runtime and invarosd-v2 is the legacy name for InvarOS Authority; "edge daemon" and "Governance Host" are retired descriptions, and receipts.so is now evidence.so. Those names are retained as compatibility aliases and remain in published evidence, captured logs, and release records, where they are the legacy name at time of evidence. Recorded bytes are never rewritten to match current vocabulary; verification always uses the original data.