Determinism

Why determinism matters for governance, how Parmana Systems achieves it, and replay protection

Why governance requires determinism

Probabilistic systems — ML models, heuristics, A/B test allocations — are designed to produce different outputs for the same inputs under different conditions. That is a feature for prediction. It is a fatal flaw for governance.

A governance system has one requirement that probabilistic systems explicitly violate: given the same inputs and the same policy version, the decision must always be the same — and that sameness must be provable.

Without determinism you cannot:

• Re-run a historical execution to verify it produced the correct outcome
• Prove to an auditor that a specific decision was made by a specific policy
• Detect whether a decision was modified after the fact
• Replay an execution for forensic investigation

Parmana Systems achieves governance-grade determinism through three mechanisms: input canonicalization, policy version pinning, and replay protection.

---

Input canonicalization

Raw JavaScript objects are not stable. { b: 2, a: 1 } and { a: 1, b: 2 } are semantically identical but produce different JSON strings. Parmana Systems’s canonicalization recursively sorts all object keys before hashing or signing:

function canonicalize(obj: any): any {
  if (Array.isArray(obj)) return obj.map(canonicalize);
  if (obj !== null && typeof obj === "object") {
    return Object.keys(obj).sort().reduce((acc, key) => {
      acc[key] = canonicalize(obj[key]);
      return acc;
    }, {} as any);
  }
  return obj;
}

This means:

• The execution_fingerprint is a stable identity for a logical decision
• The signature over the attestation is reproducible
• Anyone can independently recompute the expected fingerprint from original inputs

---

Policy version pinning

The policyId and policyVersion are embedded in every attestation. This means:

• A decision made under claims-approval/v1 cannot be retrospectively claimed to have been made under claims-approval/v2
• Policy evolution is explicit — new version, new ID, new decisions
• Historical attestations remain verifiable even after policies are upgraded

Policies are treated as immutable once published. The policy:immutability CI check enforces that existing policy files are not modified — only new versions are added.

---

Replay protection

The execution_fingerprint is the SHA-256 of (policyId + policyVersion + canonical signals). The replay store tracks which fingerprints have been executed.

If the same (policyId, policyVersion, signals) tuple is submitted a second time, the runtime rejects it with a replay violation before any evaluation occurs.

// What the replay store checks:
const fingerprint = sha256(JSON.stringify({ policyId, policyVersion, signals }));
replayStore.markExecuted(fingerprint);
// Throws if already seen

Why this matters: Without replay protection, an attacker or buggy client could re-submit the same approved decision multiple times. In a payment system, this could trigger double-spending. In an AI pipeline, it could re-execute an action that was intended to run exactly once.

Replay store implementations

Implementation	Use case
MemoryReplayStore	In-process; appropriate for unit tests and single-process development
RedisReplayStore	Distributed; appropriate for multi-instance production deployments

Both implement the same ReplayStore interface — you can swap them without changing any other code.

---

Runtime provenance

Every attestation includes runtimeVersion and runtimeHash — a hash of the runtime binary state at execution time. This means:

• An attestation produced by runtime version 1.65.0 can be verified to have come from that specific runtime
• If the runtime is replaced or tampered with between execution and verification, the runtimeHash mismatch is detectable
• Independent verification does not trust the runtime — it verifies the attestation standalone

---

What determinism does NOT cover

Parmana Systems guarantees determinism within the governance pipeline. It does not govern:

• The process that produces input signals (your application code, AI model, external APIs)
• The downstream action taken after a completed attestation (your system’s responsibility)
• The security of the signing key itself (use AWS KMS or equivalent HSM in production)

Determinism means “same inputs, same decision, same proof.” It does not mean “the inputs themselves are correct.” Validate your signal sources before passing them to the governance pipeline.