GET /trust-records/:id is the only endpoint that returns a transaction’s complete history in one call — every other read endpoint (GET /verification/:id, GET /receipt/latest/:id) returns only the single most recent entry from the corresponding array.
Fetch the full record
What to look at
Verification entries, not one overwritten five times.
What an audit can and can’t currently confirm
- Can confirm: the record hasn’t been altered since it was written (
POST /replayorPOST /verify— both run the same hash check today, see Deterministic Replay). - Can confirm: exactly which Decision, Execution, Verification(s), and Receipt(s) exist for this transaction, in the order they were appended.
- Cannot yet confirm, through this API: whether the recorded Decision matches what the referenced Policy would produce today, given the recorded signals — that’s what
@parmana/replay’sReplayEnginedoes, but it isn’t wired into any endpoint (see Deterministic Replay). - Cannot yet confirm, through this API: whether a human Override was recorded — the array exists on the type, but there is currently no way to create one over HTTP or through either SDK (see Human Override). An empty
overrides: []today does not distinguish “nothing was overridden” from “the platform has no way to record an override yet.”
examples/04-trust-record’s run.ts is currently an unimplemented stub (console.log("Parmana Example 04 - Trust Record")) — there’s no runnable example of this flow in the monorepo yet.Related
Trust Records (REST API)
The endpoint reference.
Execution Trust Record
The full model.
Deterministic Replay
What auditing can’t yet confirm on its own.
Human Override
The other gap in what’s confirmable today.