Trace integrity

• Tamper-evident means any alteration after recording breaks hash links or external anchors — the change is detectable, not invisible.
• We do not claim traces are tamper-proof or that model outputs are always correct. Cryptographic chaining attests to ledger continuity, not business truth.
• Pre-cutover events may be marked pre-chain and are outside the ledger.

• Each tenant has an append-only ledger of canonical JSON payloads.
• Each entry hash is SHA-256(prev_hash + payload) with sorted JSON keys; genesis uses a fixed zero prev-hash.
• Runs sealed after cutover receive a run_seal entry linked to the prior head.
• Norcaster runs an hourly integrity job that re-verifies hash continuity per tenant.

• Completed segments are batched into Merkle trees; segment roots are published to Sigstore Rekor (public transparency log).
• Optional OpenTimestamps calendars provide a secondary time-stamping path when enabled.
• Anchoring matters because it binds Norcaster's internal ledger to an independent, queryable record — useful for audits and incident response.

• When signing is enabled for your organization, every entry after the key is activated is signed with an ECDSA P-256 key that belongs to that organization alone. The public key is committed to the chain itself (a signing_key_activated entry) and to the Rekor log, so a verifier learns which key is authoritative from the ledger, not from a Norcaster API.
• Segment roots published to Rekor are signed with the same key. The public log then carries the organization's public key — a pseudonymous identifier, never a name.
• Honest limit: in this release Norcaster holds the private key, encrypted at rest. A signature proves the entry was signed with the key Norcaster holds for your organization. It rules out forgery by anyone else and makes rewrites detectable before anchoring, but Norcaster remains the custodian until customer-held keys ship. We do not describe this as non-repudiation without that caveat.
• Entries recorded before activation stay hash-chained but unsigned. Verifiers report them as unsigned — never as verified by omission.
• Bring your own root key. Where enabled, an organization can register a key in its own AWS KMS as the root that certifies every signing key Norcaster uses for its chain. The grant is limited to signing 32-byte digests; each certification is a kms:Sign event in the customer's CloudTrail, and with owner approval on, no signing key is certified without the customer's act. Norcaster still holds each short-lived signing key for its validity window.

• In the portal, open a run or enforcement event and download the integrity proof bundle (JSON).
• Proof bundles verify with the @norcaster/verify CLI (Apache-2.0; pending npm publication — until it ships on the registry, use the path below).
• Available today with no Norcaster software or credentials: generate an audit-bundle export and run the standalone verifier that ships inside every zip:

  python verify_audit_bundle.py bundle.json

• The script checks the manifest content digest and integrity references, then confirms segment Merkle roots against the public Rekor log (or verify manually via the Rekor lookup URLs in HOW_TO_VERIFY.txt). For signed chains it also checks that the Rekor entry embeds the organization's public key and a valid signature over the root.
• Proof bundles (version 2) carry the entry signature, the public key, and where on the chain that key was activated. The @norcaster/verify CLI verifies the signature offline and reports verified, invalid, or unsigned.

How proof works → · Verification algorithm → · Verifier source →

PDF and CSV exports ship as zip files containing audit-bundle.pdf or section CSVs, plus HOW_TO_VERIFY.txt, bundle.json, and verify_audit_bundle.py — no Norcaster login required.

• Content digest — confirms evidence sections match the digest recorded in the manifest (internal consistency). To prove the artifact has not changed since export, compare that digest with a trusted external copy (Norcaster export history, a separately shared digest, or another trusted channel).
• Chain snapshot — confirms the org trace head and anchor references in the manifest are internally consistent.
• Rekor anchors — when present and passing, listed segment Merkle roots match public Rekor log entries (checkable without Norcaster software).
• Governing configuration — each pinned decision's deployment policy version and snapshot hash resolve to an unmodified snapshot in the bundle.
• Approval provenance — versions produced by a config proposal name an approver in change history (SKIP when no proposal-produced version is in scope).

Manual Rekor step (browser or curl): open the lookup URL listed in HOW_TO_VERIFY.txt for each anchor UUID and confirm spec.data.hash.value matches the segment Merkle root in the manifest. Reviewers without network access can use embedded rekor_entry_b64 snapshots in the manifest or run --offline.

pip install httpx
unzip audit-bundle.zip
python verify_audit_bundle.py bundle.json
python verify_audit_bundle.py bundle.json --json
python verify_audit_bundle.py bundle.json --offline

Verification checks internal consistency of the exported bundle and, when Rekor anchors are present and passing, public-log anchoring of listed segment Merkle roots. It also checks that each pinned decision's deployment policy version and snapshot hash resolve to an unmodified snapshot in the bundle, and that versions produced by a config proposal name an approver in change history. It does not prove completeness of your AI estate (see the bundle Coverage section), legal compliance, or export authenticity from a passing digest check alone. When no Rekor UUIDs are present, the Rekor check reports SKIP (not PASS). Full hash-chain replay requires Norcaster governance tools or run integrity proof bundles.

Organization admins can view chain head, latest anchor, and integrity job status at Dashboard → Integrity. The badge on a trace never shows "Verified" unless an anchor covers that sequence and the integrity monitor is current. Signing is shown as a separate badge (Signed, Unsigned, Key revoked, or Signature invalid), and the Signing key card lists the active key, its public half, and previous keys.