Open Mercato Document and Attachment Management Guide

Evidence legend and terminology

Keep released behavior, this develop revision, project controls, provider capabilities, absent proof, narrative drift and recommendations separate.

• 1. released
• 2. reviewed current develop
• 3. implementation-dependent
• 4. external or provider control
• 5. not established
• 6. documentation drift
• 7. editorial recommendation

Define its authority, identity, lifecycle, copies, evidence and excluded meanings. A binary can support several business meanings, while one document can have several versions or renditions.

• 1. file or binary object
• 2. attachment
• 3. business document
• 4. record
• 5. DMS
• 6. ECM
• 7. DAM
• 8. electronic archive
• 9. correspondence system
• 10. e-signature or trust service

Four-tier document-capability ladder

Capability-state matrix

Classify as native, configured, project module, provider or external, or not established. Record exact source, owner, limitation, acceptance evidence and escalation.

• 1. upload
• 2. record link
• 3. shared library
• 4. metadata
• 5. tags
• 6. assignments
• 7. custom attributes
• 8. image preview
• 9. original download
• 10. image resizing
• 11. OCR and extraction
• 12. filename search
• 13. full-text search
• 14. document versions
• 15. approval workflow
• 16. signature creation or validation
• 17. retention schedule
• 18. legal hold
• 19. immutability or WORM
• 20. malware scan or CDR
• 21. backup
• 22. restore
• 23. export or portability
• 24. read-access evidence
• 25. external exchange
• 26. recycle bin or recoverable delete

Current attachment row and missing document controls

Current stored properties

• entityId
• recordId
• organizationId
• tenantId
• partitionCode
• fileName
• mimeType
• fileSize
• storageDriver
• storagePath
• storageMetadata
• url
• content
• createdAt

Not established in the reviewed row

• stable document number
• document class
• version family
• current version
• draft, approved or superseded state
• check-in or check-out
• approval evidence
• signature validation
• retention schedule
• disposition event
• legal hold
• immutable rendition
• checksum
• OCR status and confidence
• page coordinates
• malware-scan status
• classification label
• access-history ledger

entityId and recordId link an attachment by identifiers. Tags and assignments live in JSON metadata, and attachment custom fields extend metadata. Assignments carry type, id, optional label and href. Evidence for foreign keys, referential constraints and target-record permission checks is absent.

Document-control contract and responsibilities

• business owner
• information owner
• application owner
• security and privacy owner
• records or legal owner where applicable
• infrastructure operator
• implementation team
• storage provider
• OCR or model provider
• external DMS or signature provider
• acceptance owner

Start discovery with purpose and authority. Address file format and folder afterward. Create a separate decision for every materially different document class.

Assign source, owner, rule, evidence, failure behavior and review trigger.

• 1. purpose
• 2. business owner
• 3. information owner
• 4. system of record
• 5. document class
• 6. owning entity and record
• 7. stable document id and numbering
• 8. original versus working copy
• 9. authoritative rendition
• 10. file formats and size
• 11. naming
• 12. metadata and tags
• 13. assignments and relations
• 14. custom attributes
• 15. version, replace and supersede rule
• 16. state and approval
• 17. signature, seal and timestamp need
• 18. tenant and organization scope
• 19. read roles
• 20. write roles
• 21. delete roles
• 22. public roles
• 23. sensitivity and classification
• 24. storage partition and driver
• 25. provider and region
• 26. encryption and keys
• 27. malware and quarantine
• 28. OCR formats and model
• 29. OCR status, quality and review
• 30. search, index and freshness
• 31. preview, download and share
• 32. external integrations
• 33. event, audit and access evidence
• 34. retention trigger and disposition
• 35. legal hold
• 36. backup, restore, RPO and RTO
• 37. export and portability
• 38. orphan reconciliation
• 39. acceptance owner
• 40. evidence date

Lifecycle, versions and failure windows

Record whether core, project module, provider or external authority owns the stage and its terminal evidence.

1. 1

   capture or upload

2. 2

   technical validation

3. 3

   classification

4. 4

   link to owner

5. 5

   text extraction

6. 6

   human or automated review

7. 7

   use and share

8. 8

   revision

9. 9

   supersession

10. 10

    retention

11. 11

    legal hold

12. 12

    disposition

13. 13

    export or exit

14. 14

    reconciliation

15. 15

    evidence closure

A new upload creates a new attachment row. Metadata editing does not prove content replacement, a version family, a new document, a controlled rendition, or supersession. Define each separately.

The object can be stored before the attachment row and custom attributes commit, so a persistence failure can leave an orphan object. Deletion removes the row before best-effort driver deletion; local and S3 driver errors can leave an orphan object. Require detection, alerting, retry, cleanup, evidence and reconciliation for originals, thumbnails, OCR, indexes, backups and external copies.

Changing a partition driver routes future uploads only. Existing rows retain their driver. Test mixed-driver read, download, delete, OCR, backup, restore and exit. Treat the change as configuration; migration requires moving existing rows.

OCR and extraction format matrix

The image and scanned-PDF LLM path can send eligible content to configured OpenAI service. It runs through in-process setImmediate after persistence. A durable queue is absent, and failures are logged without first-class pending, failed, retry, confidence, coordinates or reviewed state. Define model classification, minimization, supplier terms, region, retention and training assumptions, secret handling, cost, rate, outage, deletion and incident review explicitly.

For consequential use, build explicit status and human review. Evaluate a representative sample against ground truth by class, language, scan quality, layout and tables; review false positives and negatives, exceptions and drift after model or source changes. No accuracy threshold is implied here.

Search, preview and retrieval

Reviewed library search matches fileName substring. For the other search paths below, verify scope, freshness, deletion, access denial and stale results in the deployment.

• 1. filename
• 2. tag
• 3. partition
• 4. assignment label or id
• 5. custom attribute
• 6. extracted content
• 7. global search or query index
• 8. attachment API
• 9. deleted item
• 10. denied role or scope
• 11. stale OCR or stale index

Extracted-content preview, generic query-index side effects and a manager-ready full-text search are different. Safe images can render inline and be resized; other original files are forced to download with defensive nosniff and sandbox headers. The preview does not validate content, create an archival rendering or validate signatures.

File-ingress controls

Mark the current product control, project or proxy decision, provider control, residual risk, test and owner. Current routes precheck content length then parse multipart formData in memory.

• 1. allowed business formats
• 2. extension
• 3. MIME and signature
• 4. safe name
• 5. file-size limit
• 6. tenant quota
• 7. total request limit
• 8. rate and concurrency
• 9. active content
• 10. executable segments
• 11. image dimensions and pixel bombs
• 12. archive bombs
• 13. parser isolation
• 14. malware and quarantine
• 15. content disarm and reconstruction
• 16. authentication
• 17. authorization
• 18. storage location
• 19. logging
• 20. incident response

Current source sanitizes names, rejects executable segments and active HTML, XML or SVG-like content, derives MIME from signatures, extension and client hints, enforces file and quota limits after parsing, constrains inline types, validates images and contains local paths. No first-party malware scanner or CDR result was established in the reviewed attachment paths. Recheck at execution and make malware, quarantine, archive-bomb, body, rate and incident controls explicit.

Authorization and publication surfaces

Keep feature grant, tenant and organization scope, partition visibility, owning-record permission and possession of an id or URL separate. attachments.view or attachments.manage and same-organization scope do not prove need-to-know access to the owning business record. Fully global rows in public partitions may be anonymous. Public is a publication decision. Storage convenience cannot justify it.

Test allowed and denied actor, wrong tenant and organization, owner-record denial, guessed id, stale URL, visibility mismatch, superadmin context and partial-null scope. Add a domain authorization hook when required.

• 1. library page and list
• 2. per-record list
• 3. metadata detail
• 4. upload
• 5. metadata edit
• 6. transfer
• 7. delete
• 8. original download
• 9. image preview and resize
• 10. OCR content
• 11. assignment enrichment
• 12. filename search
• 13. API key
• 14. direct S3
• 15. signed URL
• 16. superadmin
• 17. public anonymous
• 18. owning business record
• 19. partial-null or global scope

Classify data before public use; test caching and CDN, search indexing, referrer and log leakage, revocation and stale copies. Do not create global public records for convenience. Signed URLs delegate time-limited operations from 60 seconds to seven days in reviewed source; forwarding, provider logs, clocks and revocation limits remain residual risks.

Metadata, storage and external authority

Free-text tags need normalization, language, rename and retirement rules. Assignments can go stale through deleted targets, label drift, href risk, transfer or multiple owners. Attachment custom fields extend metadata. They provide no workflow or referential integrity.

Record location, owner, access, encryption, retention, deletion, restore, reconciliation and evidence independently.

• 1. attachment metadata database
• 2. original object
• 3. thumbnail and image cache
• 4. temporary OCR files
• 5. extracted content
• 6. query index and search projection
• 7. logs and events
• 8. provider credentials
• 9. backups and replicas
• 10. exports and external copies

Local storage requires a durable mount, root and path ownership, permissions, capacity and inode monitoring, backup and restore, worker access, rolling-deployment behavior and orphan reconciliation. S3 attachment partitions and standalone storage_s3 APIs are separate contracts: direct routes do not create attachment rows, links, OCR, retention or domain ACLs. Driver defaults do not cover provider versioning, encryption, Object Lock, legal hold, lifecycle, replication, access logs or KMS.

For an external authority, contract stable external id, canonical metadata, deep link, working copy, signed URL, events, optional designed checksum or version token, deletion and hold authority, reconciliation, outage, conflict and exit. Application row deletion, provider object deletion, delete markers or versions, backup expiry and legal disposition are different events.

DMS, records, signature, DAM and AI boundaries

Record native evidence and the module, provider or specialist escalation. Absence in the attachment row supplies no legal conclusion.

• 1. document identity
• 2. classification and folders
• 3. version family
• 4. co-authoring or check-in
• 5. workflow and approval
• 6. templates
• 7. correspondence and capture
• 8. e-signature validation
• 9. records schedule
• 10. legal hold
• 11. immutable archive
• 12. access evidence
• 13. federation
• 14. bulk import and export

Storing a signed PDF provides no signature creation, validation, qualified signature, seal, timestamp or trust service. Retention, hold and disposition require policy, authority, controls and evidence. An S3 bucket or audit log alone does not provide a records system. Public product media and resize do not provide a full DAM with renditions, rights, approvals and channels. OCR-provider processing and AI-chat attachment delivery are separate external data flows.

Three synthetic scenarios and one anti-pattern

Load the structural row to review evidence state, tier, contract, responsibilities, stop and acceptance without document data.

Manager acceptance pack

Specify setup, actor, class, file state, scope, expected row and object, user-visible state, evidence, prohibited result, failure injection, cleanup, reconciliation, owner and pass criterion.

• 1. authorized upload
• 2. record link
• 3. metadata row and object
• 4. safe preview or forced download
• 5. filename search
• 6. tag and partition filters
• 7. metadata edit
• 8. transfer
• 9. delete reconciliation
• 10. text extraction
• 11. PDF text layer
• 12. scanned PDF OCR
• 13. image OCR
• 14. DOCX extraction
• 15. unsupported format
• 16. no key
• 17. empty result
• 18. provider failure
• 19. restart before OCR callback
• 20. deleted during processing
• 21. wrong tenant
• 22. wrong organization
• 23. owning-record denial
• 24. missing feature
• 25. guessed id
• 26. public and private mismatch
• 27. fully global public row
• 28. stale signed URL
• 29. direct S3 separation
• 30. create-side orphan
• 31. delete-side orphan
• 32. mixed storage drivers
• 33. thumbnail failure
• 34. stale search index
• 35. backup and restore
• 36. rows without objects
• 37. objects without rows
• 38. version distinction
• 39. signature not validated
• 40. retention and hold conflict
• 41. export and exit reconciliation
• 42. accessibility and print

Stop or defer

• no accountable information owner.
• no source of truth.
• unclear public or private choice.
• no owning-record authorization.
• unsupported or untested format.
• no malware or quarantine decision.
• no OCR exception path.
• no durable storage.
• no restore evidence.
• no retention or deletion authority.
• no legal-hold design.
• no version rule.
• no signature or trust design.
• no reconciliation.
• unaccepted high-impact gap.