PII Masking Architecture

1. Overview

CaseFlow Automation processes insurer correspondence and case details using AI to generate legal analysis and draft responses. To support UK GDPR data-minimisation principles (Article 5(1)(c)), the platform implements a three-layer privacy architecture:

Temporary File Retention

The temp-pdfs storage bucket is private. Files are deleted by the application immediately after OCR completes. A scheduled pg_cron job (purge-temp-pdfs-daily, 03:00 UTC) acts as a safety net, removing any object older than 24 hours. In typical operation the bucket is empty.

2. Layer 1 - Local Processing and the OCR Path

2.1 Local-extraction path (typed documents)

• Typed, text-based PDF files are processed using pdfjs-dist (Mozilla's PDF.js) directly in the user's browser.
• Text is extracted locally and displayed in the UI for the user to review.
• No PDF file or extracted content is transmitted to any server during this step.
• The user then chooses to submit the text for AI analysis, at which point Layer 2 applies.

2.2 Document-upload / OCR path (scanned PDFs and images)

• A scanned PDF or photograph contains no embedded text, so there is nothing for the browser to extract and nothing to mask at this stage.
• The page is therefore read by the AI model (OCR) under zero-retention, no-training enterprise terms. Depending on the tool the file is either placed in a private temporary bucket and deleted immediately after OCR (safety-net purge at 24 hours), or held in memory for the length of a single request and never stored.
• The text returned by OCR is passed through the Layer 2 masking gateway before any analysis or drafting call is made.
• extract-loss-of-use-timeline uses the in-memory variant and writes nothing to any table or bucket.

3. Layer 2 - PII Masking Gateway

3.1 Architecture

The masking gateway (piiRedactor.ts) is a shared server-side module invoked by every AI-facing Edge Function before any text is sent to the language model. It operates as a mandatory processing step on the server.

3.2 Data Categories Detected

The gateway attempts to detect and mask the following UK-specific identifier types:

3.3 Processing Order

Patterns are applied in a specific sequence (most specific first) to prevent partial matches or false positives:

1. Emails → 2. NINOs → 3. Driving Licences → 4. VRMs → 5. Phone Numbers → 6. DOBs → 7. Bank Details → 8. References → 9. Addresses → 10. Titled Names → 11. Bare Personal Names. UK postcodes are deliberately not part of the masking sequence; they are preserved for locality/BHR analysis, and a separate output-side scrubber removes any postcode the AI introduces that was not present in the original input.

3.4 Logging

Each invocation logs the count and types of items masked (e.g., PII redaction: 3 items redacted (types: EMAIL, VRM, REF)). No original PII values are logged.

4. Integration Points

The PII Masking Gateway is invoked in the following backend functions:

All text reaching the model for analysis passes through the gateway. "No bypass path" means exactly that: every analysis, drafting and advice call is preceded by masking, and this includes text produced by OCR of a scanned page, which is masked on return before it is used for analysis. The only text the model sees unmasked is the raw image of a scanned page it is asked to read, which it processes under zero-retention terms.

5. GTA vs Case Law Data Separation

As of 13 February 2026, the platform enforces strict separation between GTA protocol data and case law:

This ensures GTA claims receive advice grounded solely in GTA protocol and rate tables, while non-GTA claims receive case law citations. The separation prevents cross-contamination of authority sources and reduces hallucination risk.

EV Handling Under GTA

Electric vehicles not listed in standard GTA rate tables are mapped to ICE equivalent groups with mandatory explanatory notes. Accident dates are preserved as non-identifying data.

6. Anti-Hallucination Controls

7. Limitations & Honest Framing

The platform UI and Privacy Policy use deliberately honest language:

• "attempts to mask" - acknowledges that pattern-based detection is a strong first layer rather than a perfect filter, so users are asked to send only the personal data the task actually needs.
• "where detected" - frames the capability as best-effort pattern matching, not absolute removal.
• Automated safety net - the masking gateway operates as a mandatory server-side step, removing the requirement for users to manually redact documents before upload.

Known Limitations

• Names: Titled names (Mr, Mrs, Dr, etc.) are always masked. Bare/untitled names are masked only in high-precision contexts: field labels (e.g. "Claimant:", "Driver:", "Insured:"), salutations ("Dear ..."), sign-offs, and "Re <name>" in email subjects. Guards protect case citations and company names. A bare first name and surname in free prose with none of those cues may not be caught. Coverage of unusual or ambiguous names cannot be guaranteed.
• Novel Formats: Unusual or non-standard reference numbers may not match existing patterns.
• Contextual Data: Information that is only personally identifiable in combination (e.g., "the claimant's blue Ford Focus") is not masked, as it requires semantic understanding beyond regex capability.

8. Data Flow Summary

9. Regulatory Alignment

10. Recommendations for Further Hardening

• Periodic Pattern Review: Review and update regex patterns quarterly as new identifier formats emerge.
• User Training: Reinforce during onboarding that the masking layer is a safety net, not a substitute for careful data handling.
• DPIA Integration: Reference this document in the platform's Data Protection Impact Assessment.