Data flow
A concrete map of where request text travels, what is returned, and which side channels operators must secure.
Keep raw customer text outside the model boundary.
A local API that detects, replaces, and records safely.
Run it, send text, pass only the returned text onward.
Request path
client
→ HTTP middleware: size, timeout, request id
→ auth + rate limit + idempotency
→ policy + detector(s)
→ overlap resolution + replacement
→ safe response: text + spans + keyed digest
→ your existing model callSide paths
Audit
Counts, entity types, timing, and request metadata. The current file event does not intentionally include original values; protect the files and verify your backend.
Metrics
Aggregated counters and timings. Never assume custom labels are safe: keep user text and credentials out of metric attributes.
Traces
Trace context and operation metadata may leave the process when OTLP is configured. Review exporters and sampling before enabling them.
Redis
Rate-limit, cache, idempotency, and job state depend on deployment configuration. Secure Redis and define retention before production use.
The important boundary
Only the returned redacted text should cross from Redax to a downstream model. Do not forward the request body, raw detected spans, or any re-identification map. If your application needs reversible workflows, keep that mapping in a separate, access-controlled system and make the choice explicit.
Verify before launch
Run a request with representative PII, inspect the response, audit event, trace exporter, metrics labels, Redis keys, and reverse-proxy logs, then repeat with model loading disabled and with the downstream provider unavailable. The data flow is only as private as the least-controlled hop.