Intro & scope
Use cases that turn documents (PDF, scan, photo, Office, e-mail) into data, understanding or cleaned output. Patterns: DOC.CAPTURE (extract fields from recurring document types, e.g. invoices, IDs, forms), DOC.UNDERSTAND (read, compare and reason over long documents, e.g. contracts, tenders, drawings, rules checks) and DOC.TRANSFORM (convert, redact, verify or remediate documents).
Scope boundaries: - DOC-014 is the generic parsing layer (layout, tables, Markdown/JSON for RAG); the capture cases build on it and add domain schemas and validation. - DOC-008 routes and classifies before extraction; DOC-001..006, 017, 023, 024 extract after routing. - DOC-009 (portfolio extraction and comparison) vs DOC-010 (single-contract review, drafting, redlining) vs DOC-011 (data-room scale) vs DOC-015 (tenders) vs DOC-022 (LC presentations). - DOC-016 (rulebook checks on dossiers) vs DOC-027 (label proofing) vs DOC-019 (certificate verification). - DOC-018 (redaction) is a cross-cutting step before sharing or AI processing; DOC-021 uses it for DSAR and eDiscovery. - DOC-020 (courts) is the only family member with high AI Act risk (Annex III administration of justice), path C. - Gaps in numbering (DOC-025, 028, 029) are intentionally unused.
Overview
AI Act note: "depends" means the use case is minimal risk as a pure extraction aid but becomes Annex III (creditworthiness, essential services, public benefits, justice, employment) when the output feeds decisions about natural persons; keep a human decision step and document intended purpose.
Shared stack
Common layers for all DOC use cases (and reusable by KNOW, LANG, AGENT, ANOM): one document-parsing service (DOC-014 pipeline: Docling / Unstructured / Marker, Tesseract or PaddleOCR, VLM fallback for hard pages), one OpenAI-compatible inference gateway (vLLM or llama.cpp behind LiteLLM), one embedding + vector index per corpus (bge-m3 or multilingual-e5, pgvector or Qdrant), a PII/redaction and guardrail layer (DOC-018 / Presidio), a workflow engine (n8n, Temporal or Camunda) with human-review queue and audit log, and schema validation (JSON schema, Pydantic) with source-citation (page and bounding box) on every extracted value.
- HW1 (CPU/laptop): Tesseract/PaddleOCR, Docling, 3-8B quantised model via llama.cpp/Ollama, pgvector, n8n. Enough for receipts, simple invoices and classification pilots.
- HW2 (single 24-48 GB GPU): 7-32B instruct model plus a 7-32B VLM (Qwen2.5-VL / Mistral Small class) via vLLM, bge-m3 + reranker, Qdrant or pgvector, Presidio, n8n/Temporal. Covers invoices, forms, IDs, handwriting, logistics, SDS, accessibility remediation, anonymisation, label proofing, grant screening (DOC-001..006, 008, 014, 017, 018, 019, 023, 026, 027, 031).
- HW3 (multi-GPU 80 GB+ or EU-hosted API with DPA): 70B-class or reasoning model, large VLM for drawings, hybrid search (OpenSearch + reranker), knowledge graph (DOC-013), agent framework with approval gates, per-matter tenant isolation. Needed for long-context contract, data-room, tender, eDiscovery, trade-finance, medical, underwriting and court use cases (DOC-007, 009-013, 015, 016, 020-022, 024, 030).
- Path guidance: A = managed EU API or SaaS first; B = self-host/build when data sensitivity or volume requires it; C = only with public-body governance, DPIA and conformity assessment. Share one gateway, one parsing service, one vector index per corpus and one guardrail layer across use cases; keep HW3 workloads (legal, medical, court) in separate tenants with access control.