Redact PII inside Postgres, by content

01 · Role in the system

What Jev does here

Candidate generation is deliberately dumb - tokenizing structured shapes, capitalized runs, and number-led runs. Each candidate becomes one choice question in a single parallel System One request, answered with a typed label - name, email, phone, address, id_number, or none - plus calibrated probabilities; only confident PII spans are kept. Content-awareness is the point: the front office stays visible while a phone number does not, because the decision is about meaning, not shape. Spans persist as JSONB beside each message, each PII type carries a sensitivity and each role a clearance, and a span is revealed only when clearance meets sensitivity. The API strips unauthorized values before they reach the browser, and the same rule is enforced in-database by a redact() function, so the demo shows what Postgres returns per role: Guest nothing, Support contact fields, Admin all.

02 · Control boundary

Where Jev sits

Dumb span candidates to one parallel typed classification; masking enforced twice - in the API and in a Postgres redact() function gated on clearance.

Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.

03 · Known limits

What this evidence does not prove

• Classification runs at write time on stored spans; content that changes meaning later is not re-decided.
• A live demo application to run on your own Neon Postgres with a server-side key, not a hosted service.
• Redaction quality was not independently evaluated here beyond the repository's own demo data.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• rishi-raj-jain ↗Community · github · public · checked 2026-09-23