Flagship module · Records archive
Records archive: every volume's fate is agreed with its case file - and never decided silently
Long-term retention with a full lifecycle: file plan, volumes and case files, records appraisal, destruction acts. Your paper archive enters the system in batches - with a dry run and a discrepancy report before anything is written.
File plan
Hierarchy: fonds → section → inventory → case file → volume
Documents are filed into case files and volumes; when retention periods expire - closure and selection for destruction. Every level has its own code, year, and status.
01Organization records fonds01-01General OfficeApproved01-01/2024Case file inventory for 20242024Closed01-01/2024-01Incoming correspondence2024archived01-01/2024-01-1Volume 12024archived01-01/2024-01-2Volume 22024archived01-01/2024-02Outgoing correspondence2024archived01-01/2025Case file inventory for 20252025Closed01-01/2026Case file inventory for 20262026ApprovedFile plan screen schema. Workstation buttons: "Destruction act", "Retention schedule", "Storage audit", "+ Node".
- Records appraisal. Retention periods live in a reference schedule; once they expire, case files enter the appraisal queue - extend retention or select for destruction.
- Destruction by act only. Each volume is destroyed against its own line in an approved destruction act. No storage unit ever disappears silently.
- Multi-volume case files. Volumes are assembled correctly: each has its own code, status, and place in the inventory.
- Storage audit. A scheduled check that physical holdings match the records - right from the archivist's workstation.
Three storage layers
Cards in the database, files in storage, a long-term archive on top
Metadata and cards
PostgreSQL with tenant isolation via row-level security. The full-text index respects access rights.
Document and scan files
File system or any S3-compatible storage inside your perimeter. Roughly 0.5 TB per million pages.
Long-term archive
A layer on top of operational storage: volumes and case files with their own lifecycle, statuses, and acts.
Migrating an existing archive
Dry run before writing: discrepancies surface upfront, not after import
Paper case files, scans in network folders, registers in spreadsheets - all of it enters the system in batches. Re-uploading a batch never creates duplicates.
step 1
Batch
The existing archive is exported in batches: inventories, case files, volumes, files, links.
step 2
Dry run
The batch is validated as a whole: the entire link graph is checked before a single verdict is written.
step 3
Discrepancy report
Discrepancies are reported before writing: the archivist decides what to fix at the source.
step 4
Idempotent import
Written to the archive. Re-uploading the same batch creates no duplicates - imports can be safely restarted.
Scan recognition
Your paper archive becomes full-text searchable
The recognition engine was tested on a corpus of 160 benchmark runs - in Russian and Uzbek. We benchmark on your samples in the first week of deployment.
- Quality holds at 100 dpi, with noise, blur, and JPEG compression.
- Page skew is fixed by auto-deskew. Mandatory deskew brings the error rate back to 0.3 %; the angle was detected precisely in 32 of 32 test cases.
- Search strictly respects access rights. Recognized text is indexed the same way as cards and files: employees find only what their classification level and clearance allow.
We'll show the archive in a live environment
Tell us about your legacy volume and regulations - we'll prepare a commercial proposal and run recognition on your samples. The demo takes 40 minutes.