Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt

Use this file to discover all available pages before exploring further.

When a loan is approved, a patient is escalated, or a trade is executed by an automated system, something must answer for that decision. Not a log entry. Not a dashboard. Not a vendor’s uptime. Something cryptographic - something that cannot be altered, selectively deleted, or fabricated after the fact. That something is governance infrastructure. This document makes the case for treating AI governance as a first-class infrastructure primitive: deterministic, signed, and independently verifiable by any party, without access to the system that produced the decision.

​
The Problem: Governance as Afterthought

Most AI systems are governed in the same way most websites were secured before TLS became mandatory: intermittently, optionally, and badly. The current state of AI governance looks like this: a model produces a recommendation, an orchestration layer executes it, and a logging system records what happened. The log is the governance artifact. The log is what an auditor reviews. The log is what a regulator demands. This is audit theater. A log entry records that a decision occurred. It does not prove that the decision followed the policy that was in force at the time. It does not prove that the record itself was not modified after the fact. It does not prove that the policy evaluation was deterministic - that the same inputs, evaluated by the same rules, would produce the same outcome today. Logs can be altered. They can be selectively deleted. They can be generated retroactively by a system that never ran the evaluation in the first place. In a sufficiently adversarial environment - a regulatory inquiry, a lawsuit, a dispute between counterparties - a log is a claim, not a proof. Regulators increasingly understand this distinction. The EU AI Act requires record-keeping systems for high-risk AI that establish a complete audit trail. SR 11-7 (Federal Reserve model risk management) requires validation frameworks and ongoing monitoring that demonstrate model decisions are consistent with documented policies. HIPAA requires demonstrable controls, not assertions of controls. The shift is from “we have a policy” to “we can prove we followed it” - and that shift demands a different class of infrastructure.

​
The Governance Gap

Modern AI stacks have a structural gap between recommendation and governed action. An orchestration layer - LangChain, AutoGPT, a custom agent framework - controls when things happen. It routes signals, chains calls, manages retries. It is excellent infrastructure for coordination. It is not governance. Orchestration tools answer: “What should happen next?” They do not answer: “Can I prove this happened according to the rules, in a way that is verifiable by a party who has no access to my infrastructure?” The gap is between recommendation and governed action. A model recommends approval. An orchestration layer routes the approval to an action endpoint. But nothing in that pipeline produces a cryptographic proof that:
  • The specific policy version that governed the decision
  • The exact signals that were evaluated
  • The exact outcome and reason that resulted
…are bound together in a tamper-evident record that will remain independently verifiable in five years, in a different jurisdiction, by a party who never had access to the system. In financial services, this gap is the difference between a defensible model risk framework and a compliance liability. In healthcare, it is the difference between an auditable clinical decision support system and an unexplainable one. In insurance, it is the difference between a verifiable underwriting record and a contestable claim.

​
The Infrastructure Approach

Governance infrastructure treats the governance guarantee as a first-class primitive, not a plugin applied after execution. The properties of governance infrastructure are: Deterministic. The same inputs always produce the same decision, regardless of when or where the evaluation occurs. This is not a performance property - it is a correctness property. A governance system that produces different outputs for the same inputs is not a governance system. It is a probabilistic approximation of one. Signed. Every decision carries a cryptographic attestation over the exact inputs, policy, and outcome. The signature is computed over a canonical form of the payload - sorted keys, normalized strings, compact representation - so that any modification to any field invalidates the signature. Tamper-evidence is not a feature added later. It is the construction. Portable. Any party with the corresponding public key can verify any decision independently. No database access. No runtime access. No infrastructure dependency. The attestation is a self-contained proof. It travels with the decision - to a regulator, to a counterparty, to a compliance officer in a different organization - and verifies there without any connection back to the system that produced it. Replay-protected. Each governance decision executes exactly once. The execution fingerprint - a hash of the canonical input signals - is atomically reserved before evaluation and confirmed after signing. Duplicate execution of the same decision is blocked at the infrastructure level, not the application level.

​
The Three Properties of Governance Infrastructure

​
1. Determinism - Reproducibility Across Time and Systems

Reproducibility means: given the same signals and the same policy, any party can reconstruct the canonical payload and verify that the signature matches. This requires that nothing non-deterministic enters the signed payload. Wall-clock timestamps - if included in the signed content - make the payload non-reproducible. Random identifiers in the signed content make it non-reproducible. Non-normalized Unicode strings make it platform-dependent. Governance infrastructure enforces a canonical form: sorted JSON keys, NFC-normalized strings, CRLF-to-LF normalization, compact encoding. The same signals produce the same bytes on Windows, Linux, and macOS. The same bytes produce the same fingerprint. The same fingerprint, evaluated against the same policy, produces the same decision. This means a decision signed today is verifiable in fifty years. Not because the infrastructure survives. Because the algorithm - Ed25519 over canonical JSON - is stable, standardized, and widely supported.

​
2. Attestation - Cryptographic Binding of Decision to Policy

An attestation is a signed record that binds:
  • The execution fingerprint (the “what” - a hash of the input signals)
  • The policy identifier and version (the “rules” - which policy version governed this)
  • The decision outcome and reason (the “result” - what was decided and why)
  • The runtime manifest hash (the “how” - which exact runtime version produced this)
The signature is computed over the canonical serialization of this payload using Ed25519. Ed25519 is deterministic - the same private key, signing the same payload, always produces the same signature. This property is load-bearing: it means the signature itself is reproducible, not just the payload. Any modification to any field in the attestation - the decision, the signals, the policy version, the reason - invalidates the signature. The attestation is tamper-evident by construction.

​
3. Portability - Verification Without Infrastructure Access

The verification operation requires exactly two inputs: the attestation and the public key. No database query. No API call. No access to the governance runtime. No connection to the systems that produced the decision. The verification is a pure cryptographic operation: reconstruct the canonical payload from the attestation fields, verify the Ed25519 signature against the public key. This portability property is what makes governance attestations useful in adversarial contexts - regulatory inquiries, legal disputes, counterparty audits - where the party verifying the decision has no relationship with the infrastructure that produced it.

​
Why Existing Approaches Fall Short

Logging records that something happened. It does not prove that it happened correctly. Logs are written by the same process that makes the decision, stored in the same systems, and controllable by the same operators. In an adversarial audit, a log is a claim made by the party being audited. It requires trusting the audited party’s infrastructure. Audit trails are better than logs - they are structured, often append-only, and sometimes cryptographically chained. But they typically require access to the audit system for verification. An auditor in a different organization, or a regulator without infrastructure access, cannot independently verify an audit trail. Portability is absent. Policy engines (Open Policy Agent, Casbin, Cedar) evaluate policies and produce decisions. They do not produce cryptographic attestations over those decisions. The decision is correct at evaluation time, but there is no cryptographic proof that this specific decision was produced by this specific policy version from these specific inputs. The governance claim cannot be independently verified after the fact. SaaS governance platforms introduce a vendor dependency at the governance layer. The decision data leaves the operator’s boundary. Regulated industries - financial services, healthcare, government - often cannot tolerate this. Verification depends on the vendor’s infrastructure being available. If the vendor is acquired, sunsets the product, or simply has an outage, the governance capability is interrupted. Long-term auditability depends on a vendor relationship surviving indefinitely.

​
The Parmana Model

Parmana treats governance as a protocol, not a service. Policy as a signed artifact. A governance policy is a JSON file compiled into a content-addressed bundle. The bundle hash is a cryptographic commitment to the exact policy content. Deploying a policy means deploying a specific bundle with a specific hash. The policy version in an attestation references this exact content - there is no ambiguity about which rules governed a decision. Decision as a signed attestation. Every execution of executeFromSignals produces an ExecutionAttestation - a JSON record containing the execution fingerprint, policy reference, decision outcome, reason, and Ed25519 signature over the canonical payload. The attestation is the governance artifact. It is self-contained, tamper-evident, and portable. Verification as a pure cryptographic operation. verifyAttestation requires the attestation and a Verifier implementation (typically LocalVerifier with the public key). It reconstructs the canonical payload, verifies the signature, and returns a verification result. No infrastructure access. No database query. No network call. Infrastructure as yours to control. The signing key never leaves the operator’s infrastructure. The replay store - whether Redis, DynamoDB, PostgreSQL, or custom - runs in the operator’s environment. The attestation database - PostgreSQL, S3, or any storage system - is the operator’s choice. Nothing leaves the boundary. The governance guarantee is in the cryptography and the protocol, not in a vendor’s infrastructure.

​
The Analogy to TLS

In the early web, encrypted connections were optional, expensive, and poorly adopted. HTTPS was for banks. HTTP was for everyone else. The governance equivalent is the state of AI decision systems today: cryptographic governance is for edge cases, logging is for everyone else. TLS became infrastructure when the cost of not having it became unacceptable. The web moved to HTTPS-everywhere because the alternative - unencrypted connections - became a liability too large to accept. The same shift is underway for AI governance. The EU AI Act, NIST AI RMF, SR 11-7, and emerging AI liability frameworks are the regulatory forcing function. Enterprises deploying consequential AI systems are discovering that “we have a policy” is no longer sufficient. The question is “can you prove you followed it?” - and the answer requires cryptographic governance infrastructure, not logging. Deterministic attestation is to AI trust what TLS is to web trust. It is the missing layer. Not because it is pleasant to have. Because the alternative - un-governed AI execution - is becoming a liability too large to accept.

​
Conclusion

Governance is not a dashboard. It is not a log. It is not a policy engine that evaluates but does not attest. It is not a SaaS platform that requires infrastructure access to verify. Governance is infrastructure: deterministic, signed, and portable by construction. The same way TCP/IP became the substrate for network communication and TLS became the substrate for web trust, deterministic attestation is becoming the substrate for AI decision trust. The organizations that build governance infrastructure now - rather than governance theater - will have the audit trails, the regulatory defensibility, and the cryptographic proof that the next decade will demand. The infrastructure is available. The protocol is standardized. The cost of adoption is low. The cost of not adopting is not.

​
See Also