CORPUS Engine
Raw archives in.
Sellable data out.
Point CORPUS at your email, Slack, PDFs, scans and spreadsheets. Every person and company comes out as a consistent fake, scans are burned out, and every file is re-scanned before it ships. All inside your own cloud account.
Paid pilots
Opened in its own structure, not flattened to text.
CORPUS reads each format in its native structure and records the exact position of every value it might change: a Word XML node, an Excel cell, a CSV field, a Slack message, an email byte offset, a PDF glyph box. Text formats get the replacement at that position; in a PDF, that box is burned out of the page image.
- Email (.eml, .msg, mbox) with attachments
- Slack chat exports (Teams exports: in development)
- PDF: born-digital, scanned and photographed
- Word, Excel, CSV, TXT, JSON, XML, HTML and images
- In development: PowerPoint, audio transcripts, and Devanagari and handwriting read by a local document model


Rules check the formats. Labels give the context.
Identifiers are found by their labels and formats: form fields and table column headers tell CORPUS what each value is. In development: an ensemble of local PII models that reads context to find people and organizations in many languages, and a local second-pass model that reviews uncertain detections before anything changes.
- In development: an ensemble of local multilingual PII models
- In development: international phone numbers validated for 40 regions
- Names, emails, addresses, account, record and ID numbers, dates and ages
- Custom entity types, such as project codenames or internal account formats, plus custom languages and domain dictionaries
- In development: describe your policy in plain language, and CORPUS turns it into a label policy you review
'Erik', 'E.N.' and erik@… are one person.
When 'R.J.' could be two people, it stays unlinked.
A string matcher sees three strings. CORPUS links the full name in a header, the initials in a status note and the mailbox name to one persona, using evidence in your own files: email headers, chat profiles, mailboxes, initials and acronyms. That persona gets one synthetic name, so a reply still answers the right person after the swap.
Why it refuses
Linking is where de-identification goes wrong quietly. If 'R.J.' appears in a thread with both Rita Jones and Rob James, a guess merges two real people into one fake, and nothing downstream can tell. CORPUS refuses that link. The same rule applies when an acronym could belong to two companies.
- Full names, initials, nicknames and email addresses link to one persona
- In development: misspelled names linked to the right person when your files support it
- An initial or acronym with two candidates stays unlinked
- The same company name gets the same fake company wherever it appears
- Keys and mappings stay under your control
| Seen in your files | Linked to | Becomes |
|---|---|---|
| Erik Nilsson | Persona A | Tomas Vale |
| erik@fenmoor.example | Persona A | tomas@kelbro.example |
| E.N. | Persona A | T.V. |
| Erik | Persona A | Tomas |
| R.J. | Not linked: Rita Jones and Rob James both appear | Not merged with either persona |
Illustrative, on synthetic input.
Names become names, not <PERSON> tokens.
Bracket tokens break retrieval and leave a model answering "name not available". CORPUS writes a synthetic stand-in of the same kind at the exact native position, so the document still reads the way it did. Per entity type, you can choose redaction instead. In PDFs and scans, the value is burned out of the page image.
- Synthetic people, companies, emails and phone numbers in place of real ones
- Written back at the Word XML node, Excel cell, CSV field, Slack message or email byte offset
- PDFs and scans: each page rendered, values boxed, the page rebuilt as an image with no text underneath, then re-read by OCR
- Logos, signatures and stamps on scanned pages burned out
- Consistent keyed replacement is pseudonymization; the keys stay with you
Memo: renewal terms, Zenix Holdings
To: Daniel Okafor, Procurement
From: Priya Raman
Date: 17/07/2024
Daniel, Zenix (ZNX-51829) agreed to the renewal on the terms we discussed.
Send the signed copy to 1200 Maple Ridge Road, or call me on +1 (212) 555-0198.
Priya
Reopened and re-scanned before anything is written.
After rewriting, CORPUS reopens each output and searches it for every value found anywhere in the job: every text part inside Word and Excel files, including document properties, comments, headers, footers and hidden sheets, and a fresh OCR read of every PDF page. If one is still there, the file is held back with the reason, never shipped. An independent verifier must approve every file before release; held files go to your reviewers.
- Every output reopened and searched before it is written
- Word and Excel unpacked text part by text part, hidden sheets included
- PDF pages rebuilt as images with no text underneath, then re-read by OCR
- Held-back files go to a reviewer queue with their reasons; a per-file audit report lists what was found, replaced and held back
- What it can't see: a value nothing detected, or one too short or too common to search for
Every file gets an audit record, and nothing is released without independent verifier approval.

What we have tested, and how.
On 14 public synthetic development workspaces (2,915 files of email, Slack, PDFs, Office files and scans), rules-only mode wrote about 97.8% of files and held the rest for human review. Internal run, not an independent audit.
The pilot kit was deployed, run and torn down in our own Azure test subscription: the job runs inside your Azure subscription with no internet access during processing. The same container image also ran on a plain Linux server with networking off.
What CORPUS does, area by area
What CORPUS does today, what is still in development, and the areas we focus on, marked "ours".
| Area | Capability |
|---|---|
| Detect | People, companies, emails, phones, addresses, account, record and ID numbers, dates and ages |
| Detect | In development: an ensemble of local multilingual PII models; phone numbers validated for 40 regions |
| Detect | In development: a local second-pass model reviews uncertain detections before anything changes |
| Detect | Scanned pages and photos read by OCR. In development: handwriting and Devanagari read by a local document model |
| Detect | Form fields and table columns tell CORPUS what each value is |
| Tune | Custom entity types, custom languages and domain dictionaries |
| Tune | In development: describe your policy in plain language, and CORPUS turns it into a label policy you review |
| Tune | Per entity type: replace with a consistent fake, or redact |
| Link (ours) | Names, initials, nicknames, mailboxes and acronyms linked only on evidence in your files |
| Link (ours) | An initial or acronym with two candidates stays unlinked rather than guessed |
| Link | In development: misspelled names linked to the right person |
| Replace | Same name, same fake, wherever it appears; the same company name gets the same fake company |
| Replace | Fakes written at the Word XML node, Excel cell, CSV field, Slack message or email byte offset |
| Replace | PDFs and scans burned out and rebuilt as image-only pages; logos, signatures and stamps included |
| Verify (ours) | Every output reopened and searched for every value found in the job before it is written |
| Verify (ours) | Every text part of Word and Excel files re-scanned, hidden sheets and comments included; an OCR re-read of every PDF page |
| Verify (ours) | A file with a hit is held back with its reason, never shipped |
| Verify (ours) | An independent verifier must approve every file before release; held files go to your reviewers |
| Review | Preview any file with detected values highlighted; reviewer queue for held-back files |
| Review | Per-file audit report: what was found, replaced and held back, and why |
| Build | Command line for batch runs. In development: API, Python SDK and scheduled runs |
| Build | In development: a local MCP tool for Claude Code, Gemini CLI and OpenCode; prompts never carry raw PII |
| Connect | Reads from and writes to blob storage in your own cloud account: Azure Blob for pilots, S3 and GCS next |
| Deploy | Runs inside your own cloud account on a private network, with no internet access during processing. Azure for pilots now; AWS and Google Cloud next |
| Deploy | You apply our Terraform yourself on a guided call. Keep it running, or destroy it |
| Boundary (ours) | No network calls during processing; models run locally in a sandbox |
| Boundary (ours) | No hosted version. We never hold credentials in your account; your files, keys and mappings never come to us |
Rows marked "ours" are where we focus. Rows marked "In development" are not yet demonstrated. The development run on this page covered email, Slack, PDFs, Office files and scans.
The formats CORPUS takes in
- .eml .msg mboxEmail with attachments
- SlackChat exports
- .pdfBorn-digital PDF
- .pdf .png .jpgScans and photos
- handwrittenHandwriting · in development
- .docxWord
- .xlsxExcel
- .pptxPowerPoint · in development
- .csvDelimited data
- .txt .json .xml .htmlText and markup
- TeamsChat exports · in development
- transcriptsAudio transcripts · in development
The development run covered email, Slack, PDFs, Office files and scans. Formats marked "in development" are not yet demonstrated.
Runs in your cloud account. Sends nothing to us.
Network
Processing makes no network calls; models run locally in a sandbox. No document, value or mapping is ever sent to us.
Where it runs
Inside your own cloud account, on a private network with no internet access during processing. Azure for pilots now; AWS and Google Cloud next. Keep it running, or destroy it.
Storage
Reads from and writes to blob storage in your own cloud account (Azure Blob for pilots). Files never pass through us.
Setup and access
You apply our Terraform yourself during a guided call. We never hold credentials in your account and never receive your data.
Output gate
Every file reopened and searched before it is written. A file in which a found value survives is held back, never shipped.
Audit and keys
A per-file audit report of what was found, replaced and held back, and why. Keys and mappings stay under your control.
Bring the questions
security will ask.
We walk through the sandbox, the re-scan and a held-back file on synthetic data, and answer the questions your review will ask.
Paid pilots only; we run a few at a time. Join the waitlist