NenoDoc Lexicon by Neno Technologies
Archive teams get cited answers in French and English on one client-owned GPU
NenoDoc Lexicon is Neno Technologies' knowledge workspace for government archives. We rebuilt it to run fully self-hosted on one client-owned GPU: scans read by OCR chosen through side by side tests, and answers that cite their passage or decline.
Government, Legal & DefenseArchive knowledge workspaceBuilt from zero
The challenge
Archive teams needed answers they could trace across sensitive French and English records, and nothing could go to an outside AI or OCR service.
What we did
We consolidated an inherited prototype on FastAPI, chose Surya OCR by side by side tests, scoped retrieval by tenant and clearance, and ran every model on the client's GPU.
The outcome
Teams get cited answers from their own records, and the client moved its own live pipeline to our Surya OCR service after it read reference numbers and headers better.
- Answers
- Cited to the passage, or a clear decline
- Languages
- French and English, accents kept
- Hosting
- One client-owned GPU host, portable to local hardware
- Tenancy
- Organizations kept apart, four roles each
The starting point
NenoDoc Lexicon is a knowledge workspace where archive indexers and officers upload government records, extract people, places, organizations and acronyms, and ask questions. Neno Technologies serves government institutions with large French and English archives.
What had to change
An early prototype existed, with two overlapping backends and failing endpoints. The client needed a portable, self-hosted system whose answers officers could trust and trace back to the page.
What could not break
- Self-hosted models and OCR only, no outside AI service
- The local footprint fits under 30 GB of GPU memory
- Any tenant can move from cloud GPUs to local hardware
- Permissions and clearance carry into every answer
- French accents survive every step
The calls we made
We treated trust as a chain: OCR, chunking, scoping, ranking and citation all had to hold, on modest models sharing one GPU.
- 01
One backend, settled first
We first settled who owned the architecture, removed the prototype's Supabase dependency and consolidated on one FastAPI backend, using the prototype as a guide rather than patching it.
Ruled outPatching a prototype with two overlapping backends.
- 02
OCR chosen by side by side tests
We compared self-hosted OCR engines on the client's documents, handwriting included, and Surya won, with a fast path for digital PDFs and PaddleOCR as a fallback.
Ruled outManaged OCR services and any outside AI service.
- 03
Portable by design
Models run through vLLM on the client's GPU with the database in Docker beside them, so a tenant can move to local hardware or a private cloud without a rewrite.
Ruled outA managed database or hosted models that would tie tenants to one cloud.
- 04
Scope before ranking
Retrieval is filtered by tenant, collection and clearance before reranking and generation, and the same scope applies to sources, citations and counts.
Ruled outFiltering after generation, where a restricted passage could already have shaped the answer.
- 05
Cite, or decline
Every answer cites the passage it came from, and when the records do not cover a question the system says so instead of describing a similar person or place.
Ruled outA near match presented as the answer.
How the system fits together
What we built
Tenancy and roles
JWT sign in with admin, supervisor, indexer and viewer roles, and organizations kept apart, each with its own admin who approves or rejects.
Document processing
Upload of PDF, Word and Excel files, adaptive OCR with a digital fast path and Surya and PaddleOCR, then chunking and multilingual embeddings.
Entity extraction
People, places, organizations and acronyms pulled from documents into an approval registry that reviewers manage.
Ask AI with citations
Questions in French or English answered only from the scoped passages, each claim cited, with a clear decline when the records are silent.
How it works
Upload
An indexer uploads PDF, Word or Excel files into the organization's workspace.
Read
Digital pages take a fast path, and scans go through self-hosted OCR.
Index
Text is chunked, embedded and indexed with its tenant, collection and clearance.
Ask
A user asks in French or English, and retrieval is scoped before ranking.
Answer
The model answers from the allowed passages with citations, or declines.
A closer look
[
{
"question": "Quand le bureau des archives a-t-il été créé ?",
"answer": "Le bureau a été créé par l'arrêté n° 12 [1].",
"citations": [{"source_id": "doc-2207", "page": 1}],
"declined": false
},
{
"question": "Who chaired the land commission?",
"answer": "The records do not cover this question.",
"citations": [],
"declined": true
}
]What changed
Archive teams get answers from their own records, cited to the passage, in French and English, with no outside AI service. The client's tests confirmed the system declines instead of inventing a name, and the client moved its own live pipeline to our Surya OCR service.
Under the hood
- Datics role
- Product built by Datics
- Data boundary
- Self-hosted models and OCR only. Retrieval is filtered by tenant, collection and clearance before reranking and generation.
- Models
- Qwen2.5-14B served by vLLM, multilingual embeddings and Surya OCR sharing one GPU within the client's memory budget.
- Deployment
- Docker Compose with Nginx and TLS on client-owned AWS EC2 GPU instances, built to move tenants to local hardware or a private cloud.
Data and retrieval
Apps and APIs
Also in the stack
How it shipped
Consultation and scope
We settled architecture ownership and scoped a portable, self-hosted system with cited answers.
Rebuild
Supabase removed, retrieval with citations, multi-organization tenancy, OCR chosen by tests and deployment on the client's GPU.
Client feedback rounds
Each client round became tracked findings that we fixed and rechecked, from extraction to ranking.
Hardening on real documents
Lists and tables in Word files, definitional questions, exact references and clear declines, tested by the client on purpose built documents.
Expert advice, not just tickets
We treated the client's prototype as a guide and advised what to build, from the backend to the OCR engine.
Their tests, our fixes
The client tested with purpose built documents and real users, and every finding was tracked, fixed and rechecked with them.
On the client's own GPU host
Everything runs in Docker Compose on client-owned AWS GPU instances, with CI/CD we set up.
What this unlocked
Next are the open retrieval items, such as lists and full table rows in Word files, a larger model if GPU memory allows, and moving tenants to local GPU hardware.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.