# CarryFrame offline audit review

This procedure verifies one exported orchestration against a separately trusted public key. It requires only the export and reviewer bundle, with Node.js 24 or later. It requires no CarryFrame account, database access, API token, npm installation or network connection.

## Establish the trust anchor

Obtain the expected signing-key fingerprint through an authenticated channel independent of the supplied export. Compare it with `verification-key.json`. A matching fingerprint supplied by the same untrusted party as the export is not independent authentication. `trusted-public-key.pem` contains only the public key, never the signing credential.

The bundle manifest lists SHA-256 digests for the procedure, schema, verifier and public key files. Authenticate the manifest digest separately if the distribution channel is not trusted. These hashes detect file changes relative to that reference; a manifest cannot authenticate itself.

## Verify the export

Keep the reviewer files together. Substitute the tenant and orchestration UUIDs expected for the review, rather than accepting arbitrary scope from the export.

```sh
node verify.mjs export.json trusted-public-key.pem APPLICATION_UUID ORCHESTRATION_UUID
```

A successful result exits 0 and reports `verified: true`, the scope, revision, event count, chain root, content digest and signing-key identifier. Any other result fails verification. The verifier rejects oversized files rather than reading a truncated prefix. The schema describes the envelope; signature and sequence verification are mandatory in addition to structural validation.

The event sequence must start at revision 1, contain one entry per revision through `through_revision`, and match the event projections. Each persisted source capture links to its predecessor. The Ed25519 signature covers the complete exported content and declared event root. `legacy_backfill` identifies captures made when chains were installed; it does not authenticate formerly unauthenticated history.

## Reconstruct the recorded workflow

Review `data.events` in revision order. Follow identifiers into the exported roles, role versions, lifecycle proposals, records and record versions, reviews, inbox messages, executions, contexts, successions, and provider request/response/validation artifacts. The export's `recording_boundary` is part of the signed content and describes exclusions.

For each applicable action, inspect `operator_identity` and `operator_request_id`. Match its request to started and completed receipts. Model and tool actions carry role and context references; record and lifecycle actions retain their actual role and evidence links. Bootstrap or administrative actions must not be assigned a fictional model context. A declared signing export may contain its own started receipt without a completion, because the snapshot precedes completion of that same HTTP response. Earlier unmatched requests must be explained, not silently treated as successes.

Inspect tool intent and outcome events using the same invocation identifier. The intent records the reviewed tool descriptor, arguments, authority decision, role version, authenticated principal and context. An `observed` outcome means CarryFrame observed a response, not that the tool's assertions independently prove downstream effects. Uncertain outcomes remain uncertain; neither a valid signature nor a later summary resolves them.

Approvals, overrides and escalations in the bounded integration example use existing proposal reviews, retained record versions and role messages. They are attributed to the authenticated owner's delegated credential. They do not prove that a person personally inspected a result, nor that the model autonomously decided to escalate. Halt/resume events record actual orchestration status changes. Compare predecessor and successor contexts to confirm which accepted record versions were supplied, without discarding earlier sources.

## Detect an altered record

Preserve the original export. Make a separate copy and change one event payload value without re-signing. Run the identical verification command on the copy. It must exit nonzero. Changing provider artifacts, omitting or reordering chain entries, replacing the signature, or substituting a different signing key must also fail.

## Limits and sensitive data

A valid export establishes integrity relative to the trusted signer and declared scope/revision, not completeness of unobserved activity, freshness, legal compliance, or the truth of a model or tool's statements. Calls outside CarryFrame's recording path are unobserved. Exact tool wire evidence refers to the CarryFrame-to-agentgateway boundary, not necessarily the tool server's original serialization. Partial or digest-only observations remain labelled.

A privileged operator controlling both database and signer could rewrite history and sign a new root. Retain authenticated earlier roots externally when comparing history over time. This release does not provide independent timestamping or a public transparency log.

Exports can contain sensitive raw prompts, records, tool arguments and responses. Keep them in an access-controlled review location and transfer them through an approved secure channel. Authentication tokens, API keys and signing secrets must not be submitted as task payloads; preserving raw sources is not a promise to detect or redact secrets inside customer content. Do not publish a customer's export as a sample. Use only the explicitly synthetic integration sample for demonstrations.