Home / Guides / Forensic Chain of Custody
Evidence and Assessment

Forensic Chain of Custody: Assessor-Grade Evidence Lifecycle for AI Systems

Every witness anchor is an independently verifiable link in a tamper-evident evidence chain. This guide explains what makes that chain assessor-grade.

Who this is for: Compliance assessors (C3PAOs, Notified Bodies, auditors), legal and forensic teams, GRC leaders, and incident response personnel who need to evaluate, reconstruct, and present AI system evidence. No engineering background required.

Evidence, not logs: Traditional compliance systems produce logs. Logs are mutable, vendor-controlled, and self-attested. SWT3 witness anchors are cryptographically fingerprinted, independently verifiable, and tamper-evident. The difference matters when evidence must withstand regulatory scrutiny, legal discovery, or board-level inquiry.

Contents

1. What Makes Evidence "Assessor-Grade" 2. The Evidence Lifecycle 3. Tamper Evidence: How Fingerprints Work 4. Clearing Levels and What You See 5. Forensic Reconstruction 6. Evidence Export for Regulatory Submission 7. Verification Independence 8. Evidence Handling Checklist 9. References

1. What Makes Evidence "Assessor-Grade"

For AI system evidence to meet the standard required by compliance assessors, it must satisfy five properties:

Property Requirement How SWT3 Satisfies It
Independence Evidence must not be produced by the system being evaluated The witness protocol is an independent observer. It does not make AI decisions; it records them.
Tamper evidence Any modification must be detectable Each anchor contains a SHA-256 fingerprint. Changing any factor changes the fingerprint. The math is public.
Completeness Evidence must cover the full decision timeline Gaps in the anchor timeline are themselves findings. Reconstruction flags incomplete cycles.
Reproducibility Any party must be able to verify the evidence independently Verification requires only the factors and a SHA-256 implementation. No vendor tools, no API access, no proprietary software.
Provenance The origin and custody of evidence must be traceable Each anchor records tenant, procedure, timestamp, clearing level, and verdict. Export banners distinguish local vs. API-sourced evidence.

2. The Evidence Lifecycle

A witness anchor moves through five stages from creation to presentation:

  1. Minting: The SDK observes an AI inference or governance event and computes a SHA-256 fingerprint from the recorded factors: tenant, procedure, factor A, factor B, factor C, and millisecond timestamp. The fingerprint is the first 12 hex characters of the hash. This happens in real time, at the moment of the decision.
  2. Storage: The anchor is written to the local write-ahead log (WAL) immediately. It is then flushed to the compliance ledger (or stays local in air-gapped environments). Both copies are independently verifiable.
  3. Verification: At any point, any party can recompute the fingerprint from the factors and compare it to the anchor. A match proves the anchor has not been modified since minting. A mismatch proves tampering.
  4. Reconstruction: Anchors sharing a cycle_id are assembled into a chronological timeline. A cycle_id is a unique identifier assigned by the SDK when a developer opens a chain context (e.g., with witness.chain("workflow-name")). All anchors minted within that context share the same cycle_id, linking them into a single auditable sequence. The reconstruction shows which agent did what, when, in what order, with what authorization. Drift, overrides, and violations are flagged visually.
  5. Presentation: The reconstructed timeline is exported as a self-contained HTML report or JSON payload for regulatory submission, audit workpapers, or incident response documentation.

3. Tamper Evidence: How Fingerprints Work

Every witness anchor contains a 12-character fingerprint. Here is how it is computed, in plain language:

  1. The system concatenates six values into a single string: WITNESS:{tenant}:{procedure}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}
  2. That string is fed through SHA-256, a one-way mathematical function that produces a fixed-length output. Any change to any input character produces a completely different output.
  3. The first 12 hex characters of the SHA-256 output become the fingerprint.

The fingerprint is embedded in the anchor token:

SWT3-E-VULTR-INF-AIINF1-PASS-1774900000-a1b2c3d4e5f6
                                          ^^^^^^^^^^^^
                                          fingerprint

Why this matters for assessors: If anyone modifies the tenant, the procedure, any factor, or the timestamp after the anchor was minted, the fingerprint will no longer match when recomputed. This is not a policy control; it is a mathematical guarantee. SHA-256 has no known collisions. The formula is public. You do not need to trust the vendor to trust the math.

Verification is free and permanent. You can verify any anchor at /verify/ or with any SHA-256 implementation on any machine. The verification formula will never change. Anchors minted today will be verifiable in 10 years with the same formula.

4. Clearing Levels and What You See

Clearing levels control what data is visible in each anchor. Higher levels hash or remove sensitive content while preserving the cryptographic proof. As an assessor, the clearing level determines what you can inspect directly versus what you must verify mathematically.

Level Name What You See What You Can Verify
0 Analytics Model name, prompt hash, response hash, latency, token count, guardrail names All factors are readable. Full visibility.
1 Standard Hashed inputs/outputs, model metadata, guardrail state Model identity, timing, guardrail presence. Input/output content is hashed.
2 Sensitive Procedure, verdict, hashed factors That a specific procedure was witnessed with a specific verdict. Factor content is opaque.
3 Classified Numeric factors, hashed model ID That a decision was witnessed. Nothing about what the decision was.

Key principle: The fingerprint is equally strong at all clearing levels. A Level 3 anchor is just as tamper-evident as a Level 0 anchor. The difference is in what an assessor can read, not in what the math proves.

5. Forensic Reconstruction

Reconstruction assembles individual anchors into a chronological narrative. There are three ways to perform reconstruction:

A. Audit Portal (Browser)

The audit portal Timeline tab provides an interactive reconstruction interface. Select a cycle from the dropdown, and the portal displays:

B. Command Line

# Reconstruct a specific decision cycle
swt3 reconstruct --cycle CYCLE_ABC123

# Reconstruct all activity from a specific agent in the last 24 hours
swt3 reconstruct --agent soc-detector-v3 --last 24h

# Find an anchor by fingerprint and reconstruct its full cycle
swt3 reconstruct --fingerprint a1b2c3d4e5f6

# Reconstruct a lifecycle chain (linked sequence of cycles)
swt3 reconstruct --chain LC-abc123def4567890

# Export as self-contained HTML for regulatory submission
swt3 reconstruct --cycle CYCLE_ABC123 --html > evidence-report.html

C. API

The reconstruction API (GET /api/v1/reconstruct) accepts the same query parameters and returns structured JSON. Authentication supports Bearer tokens, session cookies, and audit share tokens with scope control.

6. Evidence Export for Regulatory Submission

The --html export produces a self-contained HTML file suitable for regulatory submission, audit workpapers, or incident response documentation. The file has no external dependencies and can be opened in any browser or printed to PDF.

The export includes:

For assessors: When you receive an HTML export from a developer, check the attestation banner first. "Client-Generated" means the data was retrieved from the compliance ledger and is independently verifiable. "Self-Attested" means the data came from the developer's local WAL and has not been verified against the ledger. Both are cryptographically valid, but the provenance differs.

7. Verification Independence

A critical property of SWT3 evidence is that verification does not require the vendor, the platform, or any proprietary tool. You can verify any anchor with:

What Verification Looks Like

Using the CLI with a handoff file:

$ swt3 verify --file /evidence/c059eb5938c0.json

CERTIFIED TRUTH
  Anchor:      SWT3-E-LOCAL-INF-AIINF1-PASS-1774800000-c059eb5938c0
  Fingerprint: c059eb5938c0
  Recomputed:  c059eb5938c0
  Match:       YES

If any factor has been modified since minting:

$ swt3 verify --file /evidence/c059eb5938c0.json

TAMPERED
  Anchor:      SWT3-E-LOCAL-INF-AIINF1-PASS-1774800000-c059eb5938c0
  Fingerprint: c059eb5938c0
  Recomputed:  7f3a19bc02d1
  Match:       NO -- factors have been altered since minting

Document the result in your workpapers: which anchor you verified, the outcome, and the timestamp of your verification.

This independence is by design. If the TeNova platform goes offline, every anchor ever minted remains verifiable. If the developer's infrastructure is compromised, the anchors in the assessor's possession remain valid. The evidence outlives the systems that produced it.

8. Evidence Handling Checklist

Use this checklist when receiving, reviewing, or presenting SWT3 evidence:

9. References

SWT3 is an open protocol maintained by Tenable Nova LLC. Patent pending.
SWT3, UCT, and Witness Anchor are trademarks of Tenable Nova LLC.
tenova.io

This guide is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. Regulatory mappings and crosswalk interpretations reflect the publisher's analysis and may not address all obligations applicable to your organization. Consult qualified legal counsel before making compliance decisions based on this content.