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.

Runtime provenance is the mechanism by which every governance decision is cryptographically bound to the specific runtime version that produced it. Every attestation carries a runtimeHash - a SHA-256 digest of the runtime’s content-addressed manifest - as part of the signed payload. This makes the execution environment itself part of the verifiable, tamper-evident record.

​
Why runtime provenance matters

Traditional systems record what a decision was, but not which version of the decision-making code produced it. This creates gaps:
  • Reproducibility - you cannot confirm that a re-evaluation would use the same logic
  • Auditability - you cannot prove which runtime version processed a historical claim
  • Compatibility validation - you cannot detect when a verifier is using a different runtime than the signer
  • Safe upgrades - runtime updates silently change behavior without a detectable version boundary
  • Long-term trust - years after a decision, it is impossible to know what code governed it
Parmana addresses this by making the runtime version an explicit, signed part of every execution result.

​
The runtime manifest

Every runtime instance exposes a RuntimeManifest derived from a hardcoded, content-addressed definition: 
const runtimeManifestDefinition = {
  runtime_version:           "1.0.0",
  supported_schema_versions: ["1.0.0"],
  capabilities: [
    "deterministic-evaluation",
    "attestation-signing",
    "replay-protection",
    "bundle-verification",
  ],
};
The runtime_hash is sha256(canonicalize(runtimeManifestDefinition)). Because the definition is hardcoded and never changes at runtime, the hash is stable across all executions on the same runtime version. 
import { getRuntimeManifest } from "@parmanasystems/core";

const manifest = getRuntimeManifest();
// {
//   runtime_version:           "1.0.0",
//   runtime_hash:              "4ece56164e1a8809...",
//   supported_schema_versions: ["1.0.0"],
//   capabilities:              ["deterministic-evaluation", ...]
// }

​
How the runtime hash is bound to attestations

At signing time, the runtime_hash is embedded directly in the attestation payload before signing: 
const message = JSON.stringify({
  execution_id:    payload.execution_id,
  decision:        payload.decision,
  execution_state: payload.execution_state,
  runtime_hash                            // ← inside the signed scope
});
const signature = signer.sign(Buffer.from(message));
The runtime version is not metadata added after signing - it is part of the signed payload itself. Any alteration to the runtime_hash field in a stored attestation invalidates the signature, which is detectable at verification time.

​
Verifying runtime provenance

When verifying an attestation, the runtime_hash in the attestation is compared against the local runtime manifest: 
import { verifyAttestation, LocalVerifier } from "@parmanasystems/verifier";
import { getRuntimeManifest } from "@parmanasystems/core";

const manifest = getRuntimeManifest();
const result   = verifyAttestation(attestation, verifier, manifest);

console.log(result.checks.runtime_verified);
// true  → attestation.runtime_hash === manifest.runtime_hash
// false → attestation was produced by a different runtime version
runtime_verified: false does not mean the attestation was tampered with. It means the attestation was produced by a different runtime version than the one currently running. Both are valid states - the distinction is important.

​
Capabilities: what the runtime declares it can do

The capabilities array is part of the manifest definition. Policy bundles declare their runtime_requirements - which capabilities they need. The runtime rejects any execution where requirements are not met:
CapabilityMeaning
deterministic-evaluationPolicy rules evaluate identically across environments
attestation-signingProduces cryptographically signed attestations
replay-protectionEnforces single-use execution fingerprints
bundle-verificationValidates policy bundle integrity before execution
Before execution runs, the pipeline checks that the runtime satisfies the bundle’s declared requirements. Any mismatch causes immediate rejection - fail-closed: 
Runtime 1.0.0 capabilities: [deterministic-evaluation, attestation-signing, replay-protection, bundle-verification]
Bundle requires:             [deterministic-evaluation, attestation-signing, replay-protection, bundle-verification]
→ all present → execution proceeds

​
Runtime upgrades: explicit version boundaries

When the runtime is upgraded, the runtimeManifestDefinition changes, which changes the runtime_hash. This creates an explicit, cryptographically detectable version boundary:
  • All future attestations carry the new hash
  • Historical attestations with the old hash remain valid - they verify correctly against the old runtime manifest
  • Verifiers must use the correct manifest version for the attestation being checked
This is the governance contract for runtime evolution: version boundaries are explicit and detectable, not implicit and invisible.

​
Distributed deployments

In a distributed deployment with multiple runtime nodes, provenance enforcement ensures:
  • All nodes sharing the same runtime version produce the same runtime_hash
  • An attestation produced on any node is verifiable by any other node with the same manifest
  • If a node is running a different runtime version, its attestations produce a different runtime_hash - distinguishable at verification time
  • No silent runtime drift: version discrepancies are detectable from the attestations themselves

​
For regulated industries

Financial services - Every payment governance decision is permanently bound to the runtime version that evaluated it. During a regulatory audit covering decisions made eighteen months ago, you can produce the attestations and the runtime manifest that was current at that time, and the auditor can independently verify that the specific runtime version they claim was in use actually processed those decisions. Healthcare - Protocol compliance requires knowing not just what decision was made, but which governance code made it. Runtime provenance makes this verifiable without any internal system access. Insurance - Claim dispute resolution may require proving that a decision was made by a qualified governance runtime - not by an ad-hoc script or an undocumented version. The signed runtime_hash is the evidence.

​
Provenance as defense against runtime tampering

The runtime_hash also serves as a defense against runtime tampering. If an attacker modifies the governance runtime to produce different decisions, the runtime_hash in their attestations will differ from the expected value. Any verification that compares against a known good manifest will flag runtime_verified: false. This is not a complete security guarantee - a sufficiently sophisticated attacker could also modify the manifest. But it raises the bar significantly: the attacker must consistently modify both the runtime and the manifest without breaking the signature.

​
See also