Audit Packet Export and Retention Management

The audit packet is the hand-over export of one study: a single ZIP that bundles the study record, the audit log, the ledger and the snapshots into a self-describing archive with integrity hashes. Retention management is its lifecycle partner — it decides when a study’s snapshots can go, and logs every purge.

What the packet contains

Plan feature: This capability requires the evidence_repository plan feature (see Plan Features).

The archive is assembled in memory at the moment you generate it, stamped with the generation time, then uploaded and hashed. It captures the study’s state at that instant — it is a fixed point in time, not a reproducible build: two packets of one study differ in their timestamps, so each has its own archive hash.

Location in the ZIP	Contents
study.json	The study’s record
audit_logs.json	The study’s audit-log milestones
timeline.json	The evidence ledger events, each tagged with its comparable id
manifest.json	The study identity, the company list with each decision, the generation timestamp, and a SHA-256 per captured file — the JSON record files above are listed by content, not hashed
companies/{company}/metadata.json	The comparable’s decision record: disposition, AI rationale, standardized category, website, financial metrics and qualitative data
companies/{company}/snippets/{nnnn}.txt	Text captures
companies/{company}/screenshots/{nnnn}.{ext}	Screenshot and document blobs
study/snippets/, study/screenshots/	Snapshots not tied to a comparable (study-level captures)

The {nnnn} numbers are a single running counter across the study’s snapshots, in the order the query returns them rather than strictly by capture time — use them to find a file in the manifest, not to reconstruct sequence. A capture whose stored blob cannot be fetched is written as its snippet text instead, so a missing object shows up as a .txt rather than failing the build.

On top of the manifest’s per-capture hashes, the packet record carries a SHA-256 of the whole archive — the tamper evidence. Packets are stored under the evidence/packets prefix in tenant-scoped storage, and downloads go through a presigned URL with a five-minute lifetime.

How to export

Partner, Firm Admin and Superadmin see the export controls. Generating a packet for a study takes the study’s current ledger, captures and snapshots and builds the archive; the row is recorded with its size and full SHA-256, and the packet table shows the short hash so you can copy it into the engagement file. The table lists recent packets — the page asks for the fifty newest and the endpoint accepts up to two hundred.

When to export:

• Pre-proceeding — before a TPO inquiry, litigation or MAP is anticipated, export the packet and file the hash. The archive is then a fixed point in time: what the firm’s record said, and that it was not touched afterwards.
• Annual file — at close of the study’s assessment year, export once as the contemporaneous evidence file, whether or not anything is in dispute.

Retention management

Retention is policy-driven, resolved at request time from the firm’s security settings (audit_retention_years, default 7 years). The clock per study starts at the study’s lock date (or last update, or creation if never locked) and runs for the configured years.

Status	Meaning
Retained	Inside the window — safe
Expiring Soon	Fewer than 90 days left in the window
Expired	Outside the window — eligible for purging

Purging (Partner and up only, with a confirmation step) deletes the snapshots of expired studies — both the stored blob and the database row — and always writes a purge-log row recording the policy applied (audit_retention_{years}_years), the number of items purged and the detail, even when nothing was purged. The summary lists the fifty most recent purge entries.

What purging removes: every snapshot row belonging to an expired study. The selection is by study, not by company, so a study-level capture filed against the study with no comparable attached is purged on exactly the same terms as a company’s screenshot.

What purging preserves:

• The ledger — event rows are append-only governance, not snapshots, and are never purged.
• The study record, the audit log, and packet archives already exported.
• The purge log itself — a record that the purge happened, under which policy, how many items it removed, and which storage keys went with them.

FAQ

How do I verify a packet later? Recompute the archive’s SHA-256 and compare it to the hash recorded on the packet at generation; that proves the ZIP is the one the platform built. Inside it, manifest.json carries a hash per captured file, so each screenshot, document and snippet can be checked individually — the JSON record files are verified by reading them, not by hashing. Do not expect a re-generated packet to match an older one: the archive embeds its own generation time, so a fresh packet of the same study has a different hash by design.

Does purging destroy the packet? No — packets are separate archives and are not touched by retention purging.

What if the retention window changes in firm settings? The window is resolved at request time, so a settings change re-evaluates every study’s status immediately.