Archive Overview

Talonic is a document extraction platform with an archive layer built for organizations that must keep records intact, retrievable, and accountable for years. An archive is a different product category from a document store: a store keeps files, while an archive makes promises about them. This page explains the promises the archive layer makes, what ships today, what is on the roadmap, and how the capabilities relate to the records-management regimes enterprise buyers evaluate against.

The archive capabilities are organized around six promises. Authenticity: what is stored is exactly what was ingested. Originals are stored byte-verbatim, and OCR output and other derivatives are stored separately and never replace the original. For email, the byte-identical RFC 822 original (.eml) is preserved as an asset alongside the rendered content. Integrity: content is provably unchanged over time. A SHA-256 hash is computed at ingest and persisted with the document, every stored document is re-hashed and re-verified on a rolling schedule (the full corpus within 30 days by default), stored objects are written once at the application layer with server-side encryption and bucket versioning, and a mismatch quarantines the document rather than passing silently. Retention: records are kept exactly as long as policy requires, no shorter and no longer, through duration-based or event-based schedules with grace periods and review-gated disposition.

The remaining three promises: Retrievability: records stay findable and readable for the whole retention period. Documents remain browsable, viewable, and downloadable with rich metadata until a disposition is approved and executed. Auditability: every access and lifecycle event is recorded server-side in a tamper-evident, hash-chained log that outlives the records it describes. Confidentiality: access is need-to-know, enforced by strict tenant isolation on every query, role-based access control that fails closed, and hashed, scoped API keys.

What ships today

• Retention policies and assignments. Tenant-scoped policies with fixed durations or event-based triggers, assigned at source connection, document type, or individual document level. The most specific assignment wins.
• Legal holds. Holds at tenant, source connection, or document set scope. Every deletion path checks for active holds and refuses to proceed while one applies.
• Review-gated disposition. Expired records enter a review queue, require explicit typed approval, and destruction produces a certificate recording what was destroyed, when, by whose approval, and the hash of the destroyed content.
• Archive mode with soft delete and tombstones. With archive mode enabled, deletion is a recorded state, not an erasure of history. After destruction, a tombstone retains the document identity, its content hash, and its audit linkage.
• Tamper-evident audit trail with daily anchoring. Views, downloads, exports, deletions, holds, retention changes, and dispositions are recorded server-side. Each event is chained to the previous one with a cryptographic hash, the chain head is anchored daily to external object storage, and verification checks both the chain and the anchors.
• Fixity at ingest and on schedule. Every document receives a SHA-256 hash at upload. A daily verification cycle re-reads stored content and re-checks the hash, covering the whole corpus within a configurable window; mismatches quarantine the document and are recorded in the audit trail.
• Write-once, encrypted, versioned storage. Stored objects are written once at the application layer (an overwrite of a stored key is rejected), every write carries server-side encryption, storage-level deletes require a recorded reason and pass the legal hold check, and production object storage uses bucket versioning with deletion protection at the infrastructure level.
• Access compartments. Named sub-workspace groups bound to sources, document types, or individual documents restrict what member and viewer roles can see, enforced in every document query path.
• SCIM provisioning and MFA. SCIM 2.0 user and group provisioning for identity providers, TOTP multi-factor authentication, and an optional step-up requirement (a fresh TOTP code) on high-impact archive actions such as hold release, disposition approval, and tenant export.
• Data-subject erasure and redaction. A locate, scope, approve, execute workflow for GDPR erasure requests, with per-document redact or destroy modes, retention and hold aware blocking, and execution certificates that report exemptions instead of silently skipping.
• Full-tenant export. A verifiable export bundle (originals, extracted content, values with provenance, audit log, per-file SHA-256 manifest) built asynchronously and downloaded through the API.
• Content search and storage quotas. Full-text search across stored document content in the library, and per-workspace storage quotas enforced at ingest admission.

Archive mode

Archive semantics are opt-in per workspace through a single setting: archive mode. With archive mode off, document deletion behaves as it always has. With archive mode on, ordinary deletes become soft deletes: the document is marked deleted and hidden from listings, but its content is not destroyed and its history remains intact. Actual content destruction then happens only through the review-gated disposition workflow. Workspace admins manage the setting in Settings under Archive, or through the API.

# Read the current setting (any role)
curl "$API_URL/records/archive-settings" \
  -H "Authorization: Bearer $TOKEN"

# Enable archive mode (admin only)
curl -X PATCH "$API_URL/records/archive-settings" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"archive_mode": true}'

{
  "archive_mode": true,
  "updated_at": "2026-07-18T09:14:02.511Z",
  "updated_by": "9f2c41d6-8a3b-4e0f-9c77-1d2e3f4a5b6c"
}

Retention and hold state is visible wherever you work with documents. The document list exposes an on_hold flag, the resolved retention state per document, and filters for hold and retention state, so you can verify hold coverage or find everything pending disposition without leaving the library. Changing the archive settings is itself recorded in the audit trail as an archive.settings_changed event.

Compliance orientation

The archive capabilities are designed with the major records-management regimes in mind: GoBD expects immutability, completeness, retention periods, and procedural documentation. SEC 17a-4 and FINRA expect WORM storage or an audit-trail alternative, defined retention periods, and prompt retrieval. GDPR expects the right to erasure coexisting with retention duties. SOC 2 and ISO 27001 expect evidenced access control, audit logging, and encryption. Talonic delivers the underlying capabilities listed above: fixity verification, retention schedules, review-gated disposition, hold enforcement, erasure with certificates, and the anchored, tamper-evident audit trail. A control-by-control mapping against SOC 2 TSC and ISO 27001 Annex A is maintained alongside the codebase and is available on request.

Roadmap

How the archive relates to extraction

Archive semantics are additive. Documents flow through the same ingestion and extraction pipeline; the archive layer adds record lifecycle management on top without changing how extraction works. A document can simultaneously be a working input to a pipeline, a managed record under a retention policy, and material preserved by a legal hold. Nothing about retention or holds changes extraction results, schemas, or delivery. The archive layer only governs how long the record exists and what is recorded about it.