Rigorous, open, and verifiable.

The Executable Reference Invariant (ERI) defines the mathematical boundaries of an operational capability. An ERI is a declarative state checker that defines what conditions must be true before a cloud operation or data transaction is allowed to commit. Unlike static documentation, an ERI is machine-readable and executable at compile or runtime.

Implementation Note: ERIs are written in standardized schemas (such as JSON Schema or Causal Chains) and evaluated natively by the trust kernel.

The Non-Invasive Runtime Adoption (NIRA) standard outlines the injection layer where capability controls are inserted into legacy environments. NIRA does not require developers to rewrite application code, modify database layers, or swap out cloud providers.

Instead, NIRA uses transparent network interceptors, sidecars, and reverse-proxy adapters to intercept target API actions at the virtual boundary—evaluating ERI invariants and issuing immediate approvals or denials.

The Containerized Executable Reference Invariant (CERI) specifies the deployment boundaries of enclaves. A CERI packages both the ERI policy definition and the secure sidecar interpreter into a standard container format.

CERIs are deployed directly alongside microservices in Kubernetes or Serverless environments, providing a localized, low-latency control gate that operates in milliseconds.

The Governed Motion (G-Tx) specification covers transactional alignment. It guarantees that an action in one system (e.g., releasing a payment in Stripe or exporting PII data from a medical database) cannot complete unless a corresponding cryptographic evidence receipt is generated at the source.

This prevents "dangling actions" where operations complete without audit trails, ensuring that state transitions and evidence generation are atomically locked together.

The Auditable Registry Index (ARI) defines the ledger layout of evidence. Every decision made by the Trust Kernel produces a signed receipt detailing the proposal vector, the ERI state check, and the commit result.

These receipts are accumulated into a tamper-evident hash chain, allowing internal and external auditors to perform mathematical traversal of the entire operational history without looking at underlying raw databases.

This specification details how Cloud Capable enclaves leverage AMD SEV-SNP (Secure Nested Paging) hardware layers. It outlines how the virtual machine memory is cryptographically sealed in silicon, preventing hypervisors or cloud host administrators from reading or altering code execution.

At startup, the CPU issues a signed attestation report containing the hash of the running trust kernel code, which is verified against key registry lists to prove enclaves are operating in a sealed, uncompromised state.