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.

Governance lineage is the immutable, deterministic history connecting governed signals, admissibility decisions, runtime provenance, replay semantics, and execution attestations. It is not a log. Logs are mutable and may not preserve the semantic identity needed for governance reconstruction. Governance lineage is a cryptographically bound chain of deterministic execution events.

​
Why logs are insufficient

Traditional systems record what happened. Governance lineage records that it happened correctly, under which rules, at which runtime version, and in a way that cannot be altered.
Traditional logsGovernance lineage
Mutable - can be overwrittenImmutable - signature invalidates on alteration
Records events after the factBinds decision to evidence at execution time
Unverifiable by third partiesIndependently verifiable with only the public key
No semantic identityexecution_fingerprint is derived from inputs
Runtime state may no longer existAttestation is self-contained
No policy version bindingEvery decision references exact policy version
When an auditor reviews a log entry, they cannot independently verify that governance was actually enforced. When an auditor receives a Parmana attestation, they can verify the signature, the runtime version, the signals hash, and the policy version without any access to the original system.

​
What makes lineage immutable

Every attestation is Ed25519-signed over a canonical payload that includes: 
{
  "execution_id":    "88a9db95-5f31-4f0d-84de-28a3ec9e3c83",
  "decision":        { "action": "approve", "requires_override": false, "reason": "..." },
  "execution_state": "completed",
  "runtime_hash":    "4ece56164e1a8809..."
}
Any alteration to any field - the decision, the state, the runtime hash - invalidates the signature. The attestation carries its own tamper-evidence. No external system needs to confirm integrity; the signature is the proof.

​
Replay lineage: semantic identity

The execution_fingerprint is the semantic identity of a governance decision: 
execution_fingerprint = sha256(canonicalize(signals))
This fingerprint is derived deterministically from the input signals - independent of who submitted the request, from where, or when. Two requests with the same signals under the same policy always produce the same fingerprint. The fingerprint is both:
  • The replay protection key - the replay store enforces that each fingerprint executes exactly once
  • The semantic identity - it proves that two attestations evaluated the same governance inputs
This means even years after a decision was made, you can verify that a claimed set of inputs would produce the same fingerprint. The governance identity survives outside the runtime.

​
Each execution is a permanent fact

Once an execution ID is consumed, it is consumed permanently. The replay store records it indefinitely. Retries create new execution IDs - there is no way to “redo” a governance event with the same identity. This is not a limitation - it is the mechanism by which governance history is maintained. Each governance event is a permanent, immutable fact. The history is append-only by construction.

​
Override lineage: continuity without mutation

When a decision has requires_override: true, the execution enters pending_override state. The original signed attestation is preserved entirely - its execution_id, decision, and runtime_hash are unchanged. When a human approver resolves the override, execution continues using the original attestation. The override resolution is a new governance event that extends the lineage, not a mutation of it. This preserves lineage continuity: the escalation path is part of the governance record. The full history from initial submission through human resolution is reconstructable from the attestations and override records.

​
Runtime provenance lineage

Every attestation contains a runtimeHash that pins the exact runtime version that produced it. As the runtime evolves:
  • Historical attestations remain verifiable against the manifest that was current at decision time
  • Runtime upgrades create explicit, detectable version boundaries
  • The chain of which runtime version governed which decisions is preserved in the audit log
You can always answer: which runtime version made this decision? The answer is cryptographically bound to the attestation.

​
Distributed systems lineage

In distributed deployments with multiple runtime nodes:
  • Each node can verify attestations produced by any other node - no shared mutable state required
  • Network partitions do not invalidate previously issued attestations
  • Replay protection is coordinated through a shared Redis store, not through shared governance state
  • Consensus on admissibility does not require coordination - each node independently verifies
Governance lineage is self-contained within the attestation. Distribution does not dilute it.

​
Long-term reproducibility

A governance decision made today must be verifiable in seven years. This requires:
  1. The attestation is self-contained - no external runtime access needed
  2. The runtimeHash identifies the exact runtime used
  3. The policyVersion is pinned in the execution identity
  4. The signature algorithm (Ed25519) is standardized and widely supported
  5. The canonical form is deterministic across platforms and time
Parmana attestations are designed for long-term archival. The lineage does not depend on any infrastructure still existing.

​
For regulated industries

Financial services - Each payment approval, rejection, and escalation decision is permanently bound to the exact policy rules that governed it, the exact inputs that were evaluated, and the exact runtime that produced the outcome. Seven-year retention requirements are met by storing the attestation alongside the public key. Healthcare - Patient escalation decisions reference the exact clinical signals that were evaluated and the policy version that governed the decision. Clinicians, auditors, and regulators can independently verify that protocol was followed. Insurance - Claim decisions reference the exact signals evaluated and the rules that matched. Override approvals are linked to the original decision with the approver’s identity and signature.

​
Fail-closed lineage semantics

Incomplete or unverifiable lineage is rejected, not accepted at reduced confidence:
  • Missing execution_id → reject
  • Invalid signature → reject
  • Unknown runtimeHash → runtime_verified: false
  • Broken audit chain → audit record invalid
Partial lineage is not degraded governance - it is a governance failure. The system requires complete, verifiable lineage or it rejects the claim.

​
See also