Attestations

What an ExecutionAttestation is, all fields explained, and how to verify one

What is an attestation?

An ExecutionAttestation is the final output of every governed execution. It is a signed, tamper-evident record that proves:

• What decision was made (action, requires_override, reason)
• Which policy version made it (policyId, policyVersion)
• Against which inputs (signalsHash)
• By which runtime version (runtimeVersion, runtimeHash)
• Bound by an Ed25519 signature that any verifier can check

The runtime is not a trusted oracle — the attestation is self-contained. Any party with the corresponding public key can verify it without contacting the runtime.

---

Full type definition

interface ExecutionAttestation {
  executionId:           string;  // SHA-256 execution identity
  execution_fingerprint: string;  // Deterministic replay identity
  policyId:              string;
  policyVersion:         string;
  schemaVersion:         string;
  runtimeVersion:        string;

  signalsHash:           string;  // SHA-256 of canonical input signals

  decision: {
    action:            "approve" | "reject";
    requires_override: boolean;
    reason?:           string;
  };

  execution_state: "completed" | "blocked" | "pending_override";

  signature:   string;  // Ed25519 over canonical attestation JSON (base64)
  runtimeHash: string;  // Hash of runtime binary state at execution time
}

---

Field reference

Identity fields

Field	Description
executionId	SHA-256 of (policyId + policyVersion + canonicalized signals). Stable across replays with identical inputs.
execution_fingerprint	Deterministic semantic identity of this logical decision. Used by the replay store to prevent re-execution.

Policy fields

Field	Description
policyId	The policy that governed this execution (e.g. "claims-approval").
policyVersion	The exact policy version (e.g. "v1"). This is pinned at decision time.
schemaVersion	The policy schema version.
runtimeVersion	The Parmana Systems runtime version at execution time.

Decision fields

Field	Description
signalsHash	SHA-256 of the canonical signals JSON. Allows re-verification of inputs without storing them in the attestation.
decision.action	"approve" or "reject".
decision.requires_override	If true, a human escalation path must be resolved before execution can proceed.
decision.reason	The rule’s reason string (e.g. "standard_approval", "risk_score_exceeded_threshold").
execution_state	Derived from action + requires_override. See table below.

Cryptographic fields

Field	Description
signature	Base64-encoded Ed25519 signature over the canonical attestation JSON. 64 bytes, 88 base64 characters.
runtimeHash	Hash of the runtime binary state. Allows detection of runtime tampering between execution and verification.

---

Execution state derivation

action	requires_override	execution_state
approve	false	completed
reject	false	blocked
any	true	pending_override

---

Verifying an attestation

Verification is portable — it requires only the attestation and the public key.

import { verifyAttestation } from "@parmanasystems/core";

// Returns true if the attestation is valid; throws with a ViolationReport if not
const valid = verifyAttestation(attestation, verifier);

Under the hood, verification:

1. Reconstructs the canonical attestation JSON (fields sorted deterministically)
2. Decodes the base64 signature
3. Verifies the Ed25519 signature against the canonical JSON using the public key
4. Checks runtimeHash against the runtime manifest if runtime verification is enabled

Via the REST API

curl -X POST http://localhost:3000/verify \
  -H "Content-Type: application/json" \
  -d '{
    "executionId":     "a3f2b1c4...",
    "decision":        { "action": "approve", "requires_override": false },
    "execution_state": "completed",
    "runtimeHash":     "8f4a2e9c...",
    "signature":       "v4F7mK3n..."
  }'

{
  "valid": true,
  "checks": {
    "signature_verified": true,
    "runtime_verified":   true,
    "schema_compatible":  true
  }
}

Via the CLI

parmana verify artifact ./artifacts/reproducibility/verification.json

---

Canonical serialization

The signature is produced over a canonical JSON string — keys sorted alphabetically at every level, no whitespace. This means the signature is stable regardless of how the attestation is serialized, stored, or transmitted.

// Canonical form (simplified)
JSON.stringify(
  sortKeysRecursively(attestation)
)
// → '{"decision":{"action":"approve","reason":"standard_approval","requires_override":false},"execution_fingerprint":"...","executionId":"...","execution_state":"completed","policyId":"...","policyVersion":"...","runtimeHash":"...","runtimeVersion":"...","schemaVersion":"...","signalsHash":"..."}'

Do not compare signatures directly across serialization formats. Always verify using verifyAttestation or the /verify endpoint which handles canonicalization internally.