7. Verify and audit

​

The records

​

Check a Trust Record offline

import { readFileSync } from "node:fs";
import { verifyExecutionTrustRecordOffline } from "@parmana/sdk";

const record = JSON.parse(readFileSync("trust-record.json", "utf8"));
const publicKeyPem = readFileSync("parmana-default.public.pem", "utf8");

const result = verifyExecutionTrustRecordOffline(record, {
  default: publicKeyPem,
});
// { valid, hashValid, legacySignatureValid, hybridSignaturesValid?, algorithmsChecked, errors }

import json
from pathlib import Path

from parmana.crypto import verify_execution_trust_record_offline  # pip install "parmana[verify]"

record = json.loads(Path("trust-record.json").read_text())
public_key_pem = Path("parmana-default.public.pem").read_text()

result = verify_execution_trust_record_offline(record, {"default": public_key_pem})

• Canonical form. Keys are sorted; the bytes must be exactly what Parmana signed. Serializing the JSON again through a tool that reorders keys or reformats timestamps breaks verification of an untampered record. Keep the JSON exactly as received.
• Large records. A record over 4096 bytes of canonical content may be signed by AWS KMS over a fixed 97 byte commitment: the bytes of PARMANA-ED25519-LARGE-MESSAGE-V1, one NUL byte, then the SHA-512 digest of the canonical bytes. Try the raw signature first, and the commitment only for a record over 4096 bytes. The SDK functions do this.
• Hybrid signatures. A record may also carry ML-DSA-65 signatures in signatures. The TypeScript verifier checks them; the Python verifier checks Ed25519 only.

​

Check with the server

​

What a record proves, and what it does not

​

When the outcome is unknown

1. List what needs attention: GET /execution-intents/unfinalized (or unfinalizedExecutionIntents()). Each entry has the signed intent and its state.
2. Decide by state.

   State	Meaning	Do
   RELEASED	The connector answered; the Trust Record was not stored	POST /execution-intents/{id}/finalize: rebuilds the record without calling the connector. Idempotent.
   PREPARED	Stored, and the release may or may not have happened	Check the system, then resolve
   ERRORED	The release raised an error; the action may still have run	Check the system, then resolve

3. Resolve after checking the system with the intent’s businessTransactionId, action and target: POST /execution-intents/{id}/resolve with { "resolution": "NOT_EXECUTED" | "EXECUTED", "note": "what you checked" }. The note is required. resolvedBy comes from your key.

​

Audit queries

select refusal_record_id, business_transaction_id, submitted_by, created_at,
       decision_json ->> 'reason' as reason
from refusal_records
where decision_json -> 'policy' ->> 'name' = 'customer-refund'
order by created_at desc
limit 50;

select occurred_at, caller_id, capability, type, reason
from caller_audit_events
where type in ('caller.rejected', 'caller.capability_denied', 'caller.principal_denied',
               'caller.non_human_denied', 'caller.structural_rejected')
order by occurred_at desc
limit 50;