Intarsia - local pseudonymization for business documents

• GIF

Inspiration

We build AI solutions for European clients at a consulting firm and we kept hitting the same wall: legal texts, contracts, and client data would benefit enormously from LLM-assisted analysis and drafting, but data-protection reality means those documents cannot simply be handed to a cloud AI tool with names, organizations, and identifiers intact. Existing tools either over-pseudonymized (destroying the document's usefulness), under-pseudonymized (missing recurring values), or made cleanup so tedious that nobody used them. So the document stayed on the drive and the value was lost.

Intarsia is the tool we wished existed: strong automatic first-pass detection, and then a review workflow that makes fixing the rest fast instead of painful. The name comes from intarsia, inlay work: precise pieces are fitted into a larger whole so the overall picture stays intact.

What it does

Intarsia is a local-first workspace for pseudonymizing sensitive professional documents. Upload or paste .txt, .md, .docx, or text-based .pdf; Intarsia detects people, organizations, contact details, projects, contract and tax IDs, IBANs, credentials, and more, and proposes a fully pseudonymized version next to the original. It is optimized for German-language material today and runs English documents through the same review-first workflow.

The key is reviewability at three levels: accept or reject a whole category ("Contact, place & time — 42 hits", from our synthetic sample), a normalized term ("Beacon Ridge Migration — 2 hits"), or one exact occurrence. Add your own document-specific known values, apply changes, and every occurrence of the same value gets the same stable typed placeholder (<PERSON_0001>). A mandatory re-scan checks the result; critical residuals set a visible "review required" state instead of a silently "finished" export. The encrypted mapping stays local, so controlled reversal remains possible when explicitly needed.

How we built it

A local FastAPI backend and a React/TypeScript review workspace, with an optional Docker-free SwiftUI/WKWebView macOS shell and Python sidecar. Microsoft Presidio Analyzer orchestrates deterministic recognizers, user-supplied known values, and two exact, pinned Fastino GLiNER2 detector snapshots (fastino/gliner2-privacy-filter-PII-multi @ e5b59ed0…, fastino/gliner2-multi-v1 @ cc151f5b…). Detection, selection, replacement, mapping, and re-scan QA are separate stages; GLiNER2 detects but never owns replacement. Mappings are Fernet-encrypted in product mode. Runtime document processing defaults to offline mode after a one-time public-model provisioning step that never sends document text.

How Codex and GPT-5.6 accelerated the work

Intarsia existed before Build Week: commit 4d476f4f6dfc244efdb16f8591b542d7667e4393 is the imported pre-existing baseline, and we do not claim otherwise. What happened during Build Week is the real story of this submission, I am solo builder shipping like a team, with Codex and GPT-5.6 (gpt-5.6-sol, xhigh reasoning) as my team:

• Product & design. Codex built multiple UI design studies and app-icon families to choose from, implemented the selected direction as the integrated one-page review workspace — and designed the Intarsia logo and wordmark we ship today.

• The review workflow itself. Repository-grounded design exploration, implementation, and browser validation of category/term/occurrence review, finalized in commit db6d488a2f209a2a9027bf8fc5e03cc384d2a47e.

• Quality without a QA department. Codex expanded the focused regression coverage, ran real-browser Playwright click-throughs against the live app — with the full real-model flow validated separately in the browser — reviewed its own changes, and caught and fixed two bugs with new regression tests.

• Shipping infrastructure. Earlier in Build Week, Codex established the complete macOS packaging route — code signing and notarization included — researching Apple's process and completing the actual Apple developer click-path via computer use; a signed, notarized candidate DMG proved the route. It also automated an internal Docker lane and the license-complete, reproducible source export for judging, with exact model provenance.

The developer made the product calls: local-first processing, human review, separation of detection and replacement, the mandatory re-scan, and the boundary of what this submission claims. Primary Codex session: 019f84e6-d82c-7f90-ad7b-5f1a18b7a5e7.

Challenges

Two kinds of challenges shaped this project. The domain itself: repetitions and short forms must share one stable placeholder without swallowing ordinary words; review selections must match the exact inspected source text; and errors must never silently become an apparently finished export — hence the fail-closed re-scan.

And a newer discipline: learning to steer GPT-5.6 in a large codebase. What does it do brilliantly on its own, and where do explicit constraints, goals, and monitoring threads earn their keep? Left unguided, an agent patches more than it should; over-constrained, it quietly accumulates background rules that slow every later change without anyone noticing. Writing AGENTS.md and the documentation structure so that agents do exactly enough — and no more — turned out to be real engineering, and it is why a solo builder could keep this project coherent.

What I've learned

Pseudonymization is a workflow, not a model call. Detection quality matters, but so do offset fidelity, alias consistency, mapping ownership, human review, and a fail-closed result status — and product language must never turn local processing and technical assistance into legal or security promises.

Potential impact

Consulting, legal, and procurement teams across Europe know this dilemma: a contract would benefit from AI-assisted analysis or drafting, but data-protection obligations demand a careful, case-by-case decision before a document full of names and identifiers goes anywhere near a cloud AI tool. In practice that means: pseudonymize by hand at painful cost, skip the AI value, or accept a risk nobody wants to own.

Intarsia adds a better option: pseudonymize locally, with automatic first-pass detection, human review of every finding, and stable placeholders that keep the document readable and analyzable. It performs pseudonymization, not anonymization, and makes no legal guarantee but it turns "we can't use AI on this" into a reviewable, local workflow.

Current scope and what's next

The core work of this phase was calibration: automatic detection strong enough to carry the first pass, tuned against both over- and under-pseudonymization — and where the model gets it wrong, correction is part of the workflow: deselect a category, a term, or one occurrence, add a document-specific value, apply. Detection is currently strongest for German document conventions; English documents run through the same review-first workflow today, with structured US street addresses the top item for the next release, alongside richer DOCX coverage and more granular review controls. Every extension keeps the local boundary, human review, and the mandatory re-scan.

Built With

• appkit
• codex
• cryptography
• fastapi
• fernet
• gliner2
• hugging-face
• node.js
• playwright
• presidio
• pyinstaller
• pypdf
• pytest
• python
• python-docx
• react
• swift
• swiftui
• transformers
• typescript
• uv
• vite
• wkwebview