Why scanning and OCR for paperless digitization needs more than a scanner and Paperless-ngx
Paperless-ngx with Tesseract OCR and PDF/A output covers the capture pipeline: it ingests scans, runs optical character recognition to make text searchable, writes archival PDF/A files, and applies tags and correspondents through its consumption and matching rules. What it cannot decide for you is whether the output is evidence. Scan resolution, page order, blank-page handling, the classification taxonomy and the retention rules you attach to each category determine whether a digitized file can stand in for the paper it came from. A team digitizing a decade of supplier invoices and a team digitizing signed loan agreements may use the same server and still need very different controls.
The function differs by what is scanned. General correspondence and incoming post mostly need findability, so OCR accuracy on common fonts and a sensible tag set may be enough. Regulated records add requirements that the software does not settle alone: who approved the scanning, whether originals are retained, how a bulk back-scanning project is sampled for quality, and how exceptions such as illegible pages or misfed sheets are logged and re-scanned. Before the platform is chosen, define the record classes, decide which ones the scanned copy replaces the original for, and write a sampling method with an acceptance threshold. Confirm with your records officer or legal counsel which obligations apply to each class, since the answer changes the design more than the choice between platforms does.
Paperless-ngx stores documents in clear text on disk unless you add encryption at the storage layer, so a scanned archive containing personal or patient data needs disk or volume encryption, access controls and backup encryption planned from the start. DeployOpen plans, implements and documents these controls inside your infrastructure and prepares the evidence an assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the scanning procedure, quality records and access logs should be designed with the assessor's questions in mind. Ask any implementation partner to show, in writing, how they test OCR output, record scanning exceptions and document the validation of each capture workflow.
Which requirements shape the capture and OCR design
This table maps the regulatory and archival requirements that most often affect a scanning and OCR build to the specific design decisions they force, such as where files enter, who can touch import folders and how each file is tagged and checksummed. Read each row as a question to answer before configuring Paperless-ngx: the build column shows what the design must include, and the evidence column shows what an assessor or examiner will ask to see.
| Requirement | What it means for the build | Evidence to keep |
|---|---|---|
| Searchable output and PDF/A for long-term readability | Set OCR language packs and output mode deliberately, since Paperless-ngx uses Tesseract and PDF/A output must be confirmed per ingest path. Test OCR accuracy on sample pages from each document type before bulk runs. | OCR test set with accuracy results, documented OCR settings and a sample of archived PDF/A files opened in a validator. |
| Unique user IDs and audit controls where scanned files contain ePHI (45 CFR 164.312(b)) | Give each scanner operator and staff user a named account rather than shared scanner logins. Log uploads, edits, downloads and deletions, and make sure audit logs leave the application where they can be reviewed. | User account register, role assignments, sample audit log extracts and a documented log review routine. |
| Transmission protection for mail and scanner traffic (45 CFR 164.312(e)(1)) | Use encrypted transport for scanner-to-server and mail-to-archive paths, such as TLS for SMTP or SFTP ingestion. Restrict which network segments can reach the consume folder and mail ingestion account. | Network diagram of ingestion paths, transport configuration per path and scanner firmware settings. |
| Permissions on import and consume folders | Treat each import folder as a write-only drop point with its own service account. Separate folders for sensitive and general intake so that a misplaced scan does not land in an open queue. | Folder permission matrix, service account inventory and periodic access review records. |
| Three-year preservation floor for broker-dealer communications (17 CFR 240.17a-4(b)(4)) | Mail ingestion must preserve the original message as well as the captured copy, and retention tags must start from the message date. A general DMS typically needs a compliant archive or third-party arrangement, so confirm the design with counsel before ingesting regulated communications. | Retention rule definitions, original message preservation test results and the written archive arrangement. |
| Integrity of captured records | Compute and store a checksum for each original file at ingestion, and log the hash, source and timestamp. Keep the original scan separate from the OCR-derived copy so that alterations can be detected. | Checksum log, periodic integrity verification results and a documented method for comparing originals. |
| Automatic tagging and classification consistency | Define tag and document type rules before the first bulk run, since inconsistent rules create records that cannot be retrieved later. Review rule matches on a sample each time a rule changes. | Tagging rule catalog with version history and a sample review log. |
| Quality checks on bulk back-scanning | Plan sampling checks for page completeness, orientation, legibility and OCR text quality, with a rejection and rescan path. Record the batch identifier on every document so that errors can be traced to a source box. | Batch quality report, rescan log and reconciliation of page counts against the paper inventory. |
How the document mix changes the scanning design
Back-file archives are boxes of older paper records pulled from storage, often with mixed page sizes, carbon copies, faded toner, staples, sticky notes and pages that were filed out of order. Capture is usually a batch process: pages are prepared, scanned at a controlled resolution on a production scanner, and imported into Paperless-ngx from a watched folder, with each box or series kept as a separate batch so errors can be traced back to their source. OCR risk is driven mainly by image quality and language, since older typewritten or dot-matrix output and multilingual files can degrade recognition. Classification is best done in rounds: a few document types are tagged first, and the rest are sorted once the team has seen real samples.
- Batch identity: Record the box, series and original location in a tag or custom field so every digital page can be traced back to its physical origin.
- Image preparation: Agree rules for deskewing, despeckling and handling of blank or double-sided pages before scanning starts.
- Language packs: Confirm which Tesseract language packs are installed for the languages in the archive and test them on representative pages.
- Sampling: Check a random sample from every box, weighted toward pages with poor scan quality, and record the pass or fail decision per batch.
- Disposal of paper: Decide in advance whether originals are kept, and document the basis for any destruction.
Before a bulk project starts, ask your implementation partner to show the batch log, the sampling plan and the rework procedure for a failed box.
Incoming mail is a continuous flow rather than a one-time project, and it arrives in mixed quality: envelopes, cover letters, enclosures, forms returned by customers and occasional photographs taken on phones. Capture usually happens at a document scanner with a feeder, sometimes with a barcode or patch-code separator sheet, and the scanned files land in a consumption folder that Paperless-ngx reads. OCR risk is moderate for typed letters and higher for pages with handwritten annotations, folded or skewed pages, and content in several languages on the same page. Classification relies on correspondent, sender and document type rules, which work well only when the sender list is maintained by someone who owns it.
- Separation: Decide whether pages are split by barcode sheets, by a scanner profile, or by manual review before ingestion.
- Correspondent matching: Maintain a controlled list of senders and matching rules so new variants of the same name do not create duplicate records.
- Routing: Define who receives each category of post and how that routing is recorded when the document is tagged.
- Turnaround checks: Measure how many items wait in the consumption folder and who clears exceptions, rather than relying on the OCR result alone.
- Retention on receipt: Set a rule that attaches the retention class at capture, so incoming records are not left without a schedule.
Ask the partner how exceptions are routed back to a person and who owns the sender list after handover.
Scanned email attachments are usually PDF files sent by customers, suppliers or internal staff, often created by a multifunction device that scanned at low resolution or by a phone app that compressed the file heavily. Capture is not a scanner task at all: the usual method is mail ingestion, where a dedicated mailbox or a rule on the mail server forwards attachments to an import folder or to the document system. OCR risk comes from compression artifacts, embedded images that contain no text layer, and attachments that mix a scanned page with a native Word or Excel document. Classification can use sender address, subject line patterns and attachment type, but the subject line and sender alone do not identify document type reliably.
- Ingestion rules: Decide which mailboxes or folders are monitored and which attachment types are accepted, and exclude signatures and inline images.
- Duplicate handling: Expect the same attachment to arrive several times in a thread and define how duplicates are detected and tagged.
- Personal data in mail: Identify mailboxes that may contain personal or confidential content before any automated ingestion is enabled.
- Format checks: Confirm whether attachments are stored as received or converted to PDF/A, and whether the original file is kept.
- Spot checks: Sample converted attachments regularly to confirm that text extraction matches the visible content.
Confirm with the partner how mailbox access is granted and audited, and whether the mail platform retention settings are aligned with the document archive.
Multi-page forms with handwriting, signatures, stamps and marginal notes are the hardest material for OCR, and they often carry the content that matters most, such as approvals, dates of receipt and identifiers. Capture should keep colour where stamps or ink colour carry meaning, use a resolution suited to small handwriting, and avoid heavy compression that blurs strokes. Tesseract is designed for printed text, so handwritten fields and stamp impressions usually need to be read by a person or captured as images with metadata entered manually, rather than assumed to be searchable. Classification depends on the form template, which works well when the form layout is stable and poorly when staff use older or unofficial versions.
- Structured fields: Separate printed field values, which OCR can read, from handwritten entries, which should be transcribed or flagged for manual indexing.
- Colour and resolution: Set scanner profiles for stamped and coloured pages so the stamp remains legible in the archive copy.
- Form versions: Keep a register of form templates and versions so classification rules match the correct layout.
- Manual indexing: Define which fields are keyed by hand, by whom, and how the keyed value is checked against the page.
- Full-page review: Plan a fuller visual check for forms that drive decisions, not just a text sample.
Ask the partner to demonstrate how a handwritten field is indexed, verified and audited, and which pages are excluded from OCR-only processing.
Which open source platforms fit scanning and OCR work
Scanning and OCR projects succeed or fail on where documents enter the system and how they are classified once they arrive. The platforms below each cover a different intake path, from a dedicated document consumer to a content repository and mail or file sources that feed it. Choose by where your paper and digital originals already flow, then test OCR output against your own archive before committing.
Paperless-ngx as the core consumer
Paperless-ngx is the platform most often chosen for paperless office digitization. It runs Tesseract OCR on incoming scans, produces PDF/A output, ingests from folders and email, and applies tags and correspondents automatically through matching rules. Its limits matter as much as its fit: it has no built-in records retention schedule or legal hold, and it stores documents in clear text unless you add encryption at the storage layer. Check the languages, handwriting and low-resolution scans in your archive during a pilot, since Tesseract accuracy varies widely by document type.
Alfresco Community Edition for repositories
Alfresco Community Edition suits teams that need a broader content repository, with versioning, folder structures and integrations beyond scanned correspondence. OCR and text extraction are delivered through its own connectors and transformation services rather than a single built-in pipeline, so the capture design is more of an integration project. Confirm the edition's current support status and feature set with the vendor before you rely on it for regulated records. It fits best when scanning is one input among many business content sources.
Nextcloud for files already in sync
Nextcloud fits when scanned files already land in a file-sharing platform used across the organization. Its server is licensed under AGPL-3.0, and the current release line includes v33.0.10, published October 15, 2026. Scans stored there can be indexed and searched, but Nextcloud is not a dedicated scanning workflow, so OCR, barcode separation and tagging rules usually come from add-ons or a companion service. Confirm which OCR and classification apps your version supports and how they handle large back-file batches.
mailcow and Stalwart as mail sources
Incoming mail is a major share of paper and PDF intake, so the mail server is part of the capture design. mailcow-dockerized (GPL-3.0, release 2026-09a) packages a full mail stack with Dovecot, Postfix and webmail, which makes it a practical source for folder-based or IMAP ingestion. Stalwart (AGPL-3.0, v0.16.26) is an all-in-one server supporting IMAP and JMAP. Either one feeds Paperless-ngx through mailbox rules. Check that ingestion accounts, attachment size limits and mailbox retention match your records policy before scanned mail is treated as the record.
OCR accuracy tested per archive
No platform delivers a fixed accuracy rate for your documents, and OCR quality depends on scan resolution, skew, fonts, languages, stamps and handwriting. Build a sample set from each document class, such as invoices, consent forms and older typewritten files, and measure character and field accuracy before bulk conversion. Record the settings that worked, including the Tesseract language packs and the image preprocessing used. Plan a manual verification sample for each batch, since automatic tagging errors are often more costly than missing text.
How a back-scanning project moves from pilot to production
A back-scanning project moves through scoping, a pilot on a sample batch, measured OCR tuning, retention and permission design, a logged bulk run and a handover. Each stage closes with a written output that the client signs off before the next one starts.
Scope the archive and inventory the documents
The implementation partner and the client's records owner define which boxes, folders and mail streams are in scope, estimate page counts by document type, and record physical condition, languages, handwriting and special sizes. Ask the partner to produce a document inventory and a scope statement that names exclusions. The step is done when the client signs off the inventory, because every later quality number depends on it.
Run a scanner and ingestion pilot
Build the capture path on a representative sample batch: scanner profiles, resolution and color settings, duplex handling, blank-page detection, and the import folder or email ingestion that feeds Paperless-ngx. Confirm that PDF/A output and the stored originals behave as specified. The output is a signed test sign-off listing which configurations passed and which were rejected, with the reason for each.
Tune OCR and classification against a measured QA sample
Run Tesseract OCR with the language packs the archive needs, then measure accuracy on a random sample of pages that a reviewer checks by hand. Adjust preprocessing such as deskew and contrast, and tune the matching rules that assign correspondents, document types and tags. The output is a QA log showing sample size, error rates by document class, and the tagging schema the client approved. Ask the partner to show how the sample was drawn.
Design retention and permissions
Map each document class to a retention period, a disposal action and an owner, and translate the access model into Paperless-ngx users, groups and object permissions. Decide which records need a legal hold capability and whether originals are destroyed after scanning. The output is an approved retention and permission matrix. Confirm with the client's legal or records team, since this step sets the rules the platform will enforce.
Execute the bulk run with batch checksums and logs
Process the full archive in controlled batches. Each batch gets a manifest, a checksum for every output file, a processing log, and an exception list for pages that failed OCR or were rejected at capture. Spot checks follow the same sampling method used in the pilot. The output is a batch register where every batch shows its checksum, its QA result and its disposition, so any file can be traced back to its source box.
Cut over and hand over the runbook
Move users to the production instance, switch incoming capture from the pilot paths to live scanners and mailboxes, and freeze the paper flow for documents now handled digitally. The partner hands over an operations runbook covering backup and restore tests, OCR language updates, adding scanners, and exception handling, along with the batch register and QA logs. The step closes when the client's owner accepts the handover in writing.
Integration points and deployment pattern for capture
Capture rarely stands alone. Scanners, mailboxes, identity, backups and any existing records system all touch the OCR pipeline, and each connection needs an owner before the containers are deployed. The cards below cover the points to design and the questions to settle with scanner vendors and mail administrators.
Scanner network and drop folders
Multifunction devices typically push scans to an SMB share or an SFTP folder that the document system watches for new files. Confirm with the scanner vendor which protocols the device supports, whether it can authenticate with a service account, how it names files, and whether it can send PDF/A or only standard PDF. Each drop folder should map to one ingestion rule, so a scan from the front desk is not tagged as a claims file. Keep the folder inside the client network and restrict write access to the scanner devices and the service account.
IMAP mailbox ingestion
Paperless-ngx can poll an IMAP mailbox, pull attachments and apply rules by sender or subject. Ask the mail administrator which mailbox will be used, whether a dedicated account can be created, and whether the server supports the IMAP access method you plan to use. Confirm how the mailbox is protected, since attachments may contain personal data, and whether processed messages are moved, flagged or deleted. Ingestion from a shared mailbox also needs a clear owner for the rules that decide which messages become records.
Identity source for user IDs
Each uploaded document, tag assignment and edit should trace to a named person, which requires a stable user identity. Decide whether accounts are local to the document system or synchronized from a directory, and who approves joiners and leavers. Scanner and mail service accounts are non-personal, so their use should be documented and limited to ingestion. Confirm with the identity team how group membership will drive document permissions, because capture rules that depend on groups break quietly when group names change.
Backup target for originals and OCR output
Two artifacts need protection: the original scan and the searchable PDF/A derivative, along with the database holding tags, metadata and rules. Confirm the backup target lives in a separate failure domain from the containers, and that the restore procedure has been tested with a sample of documents. Ask whether the originals will be retained alongside the OCR output, since the OCR copy is not a substitute for the paper or the original file when evidence is disputed.
Existing records or retention system
If the organization already runs a records management or archive platform, capture must hand documents across without losing metadata or creating duplicates. Identify which system is the system of record, who decides retention, and whether the handover is a copy or a move. Paperless-ngx is a capture and search layer, so it should not be assumed to enforce retention schedules or legal hold on its own. Confirm this boundary with records and compliance owners before the first production batch.
Self-hosted container deployment
The usual pattern runs the document system, its OCR service, database and message broker as containers in the client's own cloud account, data center or private network. Confirm the host sizing, the storage volume for originals, and whether images can be pulled from an internal registry in restricted networks. Network rules should allow only the scanner, mail server and identity endpoints the design requires. Ask the implementation partner to document every open port, service account and volume so the security team can review the deployment before go-live.
What auditors and examiners ask to see from a digitized archive
This table maps each evidence item an assessor is likely to request from a scanned archive to what it proves and the component that produces it. Read the third column to see where Paperless-ngx produces evidence automatically and where the organization must write its own procedures and keep its own records. The main takeaway is that the platform can show what it did to a document, but the organization must prove the paper original was complete and that the process was followed.
| Evidence item | What it proves | Produced by |
|---|---|---|
| OCR and QA sampling records | Searchable text is accurate enough for retrieval, based on a documented sample reviewed against the paper original | Sampling log kept by the organization; Paperless-ngx stores OCR text per document but does not score accuracy |
| Batch manifests | Which pages or files belong to each scanning batch, how many were received and how many were imported | Scanner batch or separator sheet output and the organization's batch register; confirm what the scanner vendor exports |
| Checksums and file hashes | A stored file has not changed since capture, and the digital copy matches the file that was verified | Hashes generated at capture or import by the organization's script or tooling; confirm whether the chosen platform records them natively |
| PDF/A output records | Files were written in an archival format suited to long-term readability | Paperless-ngx produces PDF/A output when configured; the archive copy and original copy should be listed in the batch record |
| Tagging and retention rule configuration | Documents were classified and assigned retention periods under a written schedule, and the rules themselves are controlled | Platform configuration export and the organization's approved retention schedule; changes must be tracked in version control |
| Access and change logs | Who viewed, edited, deleted or re-tagged a document, and when, with permissions tied to individual users | Platform audit or log output, forwarded to a central log store; confirm which events the chosen version records |
| Backup restore tests | Digitized records can be recovered intact, including the OCR text and metadata | Restore test reports written by the operations team; backup tooling produces job logs but not proof of restore |
| Chain from paper original to digital copy | Each digital record traces to a specific paper source, who scanned it, when, and what happened to the original | Chain-of-custody procedure, scanning log and disposal or retention record for paper; the organization must document this |
What buyers ask before hiring help with scanning and OCR
What drives the effort of a back-scan project?
Effort is driven less by the number of pages than by how those pages are prepared, how clean they are and how much metadata must be assigned. Four factors matter most. First, page volume and batching, since a few large boxes behave differently from thousands of loose sheets. Second, document condition: stapled, folded, faded or handwritten pages need more scanner setup and more manual checks. Third, metadata quality: if correspondents, dates and document types must be extracted or confirmed by a person, labor rises sharply. Fourth, exceptions, such as pages that fail OCR, duplicates and documents with unclear ownership. Ask any partner to break its estimate into these four areas and to state what it assumes about each.
Can our own team run a scanning and OCR project internally?
Yes, many teams can run a small pilot internally, but a bulk back-scan usually needs skills and time that competing with daily work makes hard to sustain. The work involves scanner configuration, Paperless-ngx setup, consumption folders, OCR language settings, tagging rules, quality sampling and a steady stream of exception handling. Teams that handle this well typically assign a named owner, a staff reviewer for sample sign-off and a platform engineer who can maintain the ingestion pipeline. A partner can take on part or all of this, such as design, configuration, pilot and handover, while your staff keep decisions about retention and access. Decide early which parts you will own after the project ends.
How long does a scanning pilot take, and what sets the timeline?
A pilot's length depends on the sample size, how many document types it covers and how quickly reviewers can sign off results. It is usually the best place to test OCR accuracy, tagging rules and scanner settings before committing to the full archive. Timelines are set by four things: the number of document families in scope, the availability of scanner hardware and staff, the number of review rounds agreed in advance, and any approvals needed for retention or access rules. Because durations depend on your environment, ask for a timeline in the written scope with explicit assumptions and a list of client dependencies.
What does the project need from our staff?
Scanning projects depend on staff decisions that no implementer can make for you. Expect to provide:
- Physical access to the archive, scanners and a secure room or workspace for paper handling
- A business owner who signs off sample batches and the classification scheme
- Decisions on retention periods, disposal rules and who may see which documents
- Subject matter experts to resolve ambiguous documents and duplicates
Late or missing decisions are one of the most common causes of schedule slippage. Agree on who signs what, and by when, before work starts.
How is OCR accuracy tested on a back-scan project?
OCR accuracy is tested by sampling real documents rather than relying on a vendor's general claim. Paperless-ngx uses the Tesseract OCR engine and can produce PDF/A output, so the test should compare the OCR text against a manually transcribed reference for a representative set of pages. Include poor scans, mixed languages, tables, stamps and handwriting if they exist in your archive. Measure whether key fields such as names, dates and reference numbers are found, not just overall text similarity. Confirm the OCR language packs installed on your server match the languages in the archive, and record the settings used so results can be reproduced.
Is Paperless-ngx enough for regulated records?
Paperless-ngx can capture, OCR, tag and search documents, but it is a document management tool, not a complete records compliance system. Whether it is enough depends on the rules that apply to your records. Check what your regulator or auditor requires for audit trails, encryption at rest, retention enforcement, legal hold, signature evidence and independent archive storage. For example, the HIPAA Security Rule requires audit controls and transmission security for systems holding ePHI (illustrative of the kind of requirement to check), while SEC Rule 17a-4(b)(4) sets preservation periods for certain communications. Where gaps exist, the usual approach is additional controls around the platform, not a claim that the platform meets the rule by itself. Use the sector-specific pages in this group to map requirements before deciding.
What should a quote for back-scanning include?
A useful quote separates one-time work from recurring cost and states its assumptions. Ask for the scope in writing: archive volume and document types, scanning method, OCR and language settings, metadata and tagging rules, quality checks and sign-off steps, exception handling, migration of existing files, and handover documentation. Then ask what is excluded, such as scanner hardware, server capacity, storage growth, licences or long-term support. Recurring costs usually include infrastructure, backups and support. Compare quotes on the same assumptions, and ask how changes to volume or scope are priced. DeployOpen does not publish price lists and provides quotes based on written scope.
Questions to put to an implementation partner for scanning projects
Start by asking how the partner will measure OCR accuracy on your documents, not on a vendor sample. Ask for a test set drawn from your own archive that includes the worst material you have: skewed faxes, carbon copies, stamped forms and low-contrast receipts. Ask which Tesseract language packs they will install for your languages and whether they will compare OCR output against manually keyed ground truth for a defined sample. Ask how exceptions are handled: pages that fail deskew, blank pages, pages with handwriting that OCR cannot read, and documents that need a human to confirm a date or account number. The answer should name a holding queue, an owner for each exception type, and a rule for when a page is re-scanned rather than corrected by hand.
Then ask how quality assurance is designed and recorded. A credible answer includes a sampling method for each batch, acceptance thresholds agreed before scanning starts, and a log that ties each sampled page to its operator, scanner, batch and reviewer. Ask how mail and scanner sources are secured: which account or share the scanner writes to, how the import folder and email ingestion account are isolated, and who can read files while they wait in the consume directory. On storage, confirm in writing how the partner encrypts data at rest, because Paperless-ngx does not encrypt its stored documents by default. Ask for the design of volume-level or filesystem encryption, key custody and the restore procedure, and for a restore test on a scheduled basis. Finally, ask for runbooks, handover of configuration and a documented process for testing each Paperless-ngx upgrade in a staging copy before it reaches production, including how OCR results are compared after an upgrade changes the Tesseract or PDF/A pipeline.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Paperless-ngx capture pipelines for scanning and OCR. Each engagement starts from a written scope that defines which paper sources, mail flows and quality checks are included before any work begins.
How we scope
- Inventory paper sources, scanner models, incoming mail channels and email folders that feed the archive
- Define OCR language needs, expected document types and the PDF/A output standard for each stream
- Agree written acceptance criteria for OCR sampling, metadata accuracy and bulk back-scanning batches
How we build
- Configure Paperless-ngx consumption folders, email ingestion, Tesseract OCR and automatic tagging rules
- Build scanner workflows with barcode or patch-code separation and test them against representative paper samples
- Run sample-based quality checks on OCR text, page order and metadata before any bulk batch is released
How we hand over
- Document the capture pipeline, tagging rules, scanner settings and exception handling in a runbook
- Deliver test records, quality check results and a list of known limits such as handwriting or poor scans
- Train operators on rescanning, batch rejection and how to correct tags without breaking the audit trail
How we support
- Support ongoing operation, upgrades and monitoring of the capture pipeline as a retainer where you need it
- Review OCR language packs and Paperless-ngx releases before applying them to production
- Confirm retention and access settings with your compliance owner, since DeployOpen prepares evidence but does not certify it
