## TL;DR
Phone numbers slip through redaction because the patterns cover one country's format while tickets contain the world's: international prefixes, local groupings, and numbers embedded in prose. Broaden patterns to international formats, test against real-world samples from your ticket stream, and sample exports weekly for misses. Redaction is a control you verify continuously, not one you configure once.

## The query

```text
agent redaction pass missing phone numbers in ticket exports
```

## Use this when

- Exports contain unredacted phone numbers
- Redaction misses international formats
- You are hardening PII redaction
- Auditing export safety

## Not for

- Designing a full PII program
- Redacting names, emails, or card numbers
- Export access control
- Data retention policy

## Steps

### 1. Inventory the phone formats in your ticket stream

Sample real tickets and list every phone format present: international with plus prefix, local groupings, extensions, numbers in prose ("call me at ..."). Your patterns must cover what your customers actually write.

Expected output: a format inventory from real tickets.

### 2. Broaden patterns to international formats

Write patterns for the inventoried formats: variable digit groupings, plus prefixes, common separators (spaces, dashes, dots, parentheses). Test each pattern against the inventory. One country's pattern is not a phone pattern.

Expected output: patterns covering the inventoried formats.

### 3. Handle numbers embedded in prose

Phones appear mid-sentence, in signatures, and in quoted replies. Patterns must match within text, not just standalone fields. Test against full ticket bodies, not just structured fields.

Expected output: in-prose numbers detected in testing.

### 4. Decide the extension and short-code policy

Extensions, short codes, and partial numbers: redact or keep? Decide explicitly per use case and document it. Ambiguity here is where inconsistent redaction comes from.

Expected output: a documented policy for edge formats.

### 5. Sample exports weekly for misses

Pull a sample of redacted exports and hunt for surviving phone numbers. New formats appear as the customer base grows; the sample catches them. Track the miss rate; it should stay at zero.

Expected output: a weekly sample with miss-rate tracking.

## Template: the checklist

```text
Phone redaction coverage:
[ ] Format inventory built from real tickets
[ ] Patterns covering international formats
[ ] In-prose numbers detected in full bodies
[ ] Extension and short-code policy documented
[ ] Weekly export sampling with miss-rate tracking
```

## Variant phrasings

### phone numbers not redacted in export

Steps 1 and 2. Inventory, then broaden patterns.

### international phone redaction

Step 2 as the core work.

### pii missed in ticket export

Steps 1 and 5. Know your stream, sample continuously.

## Why it happens

Redaction patterns get written for the formats the author knows, usually their own country's, and tested on synthetic examples. Real ticket streams are global and messy: customers write numbers how they speak them. The gap between the author's formats and the world's formats is where the misses live.

## Edge cases

- Numbers split across lines: line breaks inside a number defeat naive patterns. Normalize whitespace before matching.
- Fake example numbers in templates: redacting 555-numbers is harmless but noisy. Decide whether to exempt them.
- Numbers in images: screenshots of phones need OCR to redact. Scope this explicitly; it is expensive.
- Over-redaction: order numbers and ids that look like phones. Tune patterns to minimize false positives that destroy useful data.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N1GP81knn4OL0j6K6pwEiQ