agent redaction pass missing phone numbers in ticket exports

Not specified by the original author.

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

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

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

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

Thread query: agent redaction pass missing phone numbers in ticket exports

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.

Not specified by the original author.

TL;DR

Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.

The query

redaction agent missed phone numbers in ticket screenshots: ocr gap

Use this when

• Phone numbers survive redaction in screenshots
• Image attachments leak PII
• You are auditing redaction coverage
• Building image-aware redaction

Not for

• Defining text redaction patterns
• Selecting an OCR engine
• Setting data retention periods
• Consent management

Steps

1. Inventory which attachments contain images

List the image-bearing attachment types in your tickets: screenshots, photos, scanned documents, pasted images. Redaction that only processes text fields is blind to all of these. The inventory defines the OCR scope.

Expected output: image attachment types inventoried.

2. Run OCR on images before the redaction pass

Extract text from every image via OCR, then run the standard PII detection on the extracted text. OCR-first makes image PII visible to the same detectors that handle body text. One detection pipeline, two input types.

Expected output: OCR output feeding PII detection.

3. Redact the image regions, not just the text

Knowing a phone number is in the image is not enough: mask the region in the image itself (bounding boxes from OCR) or replace the image with a redacted version. Text-only redaction of OCR output leaves the pixels exposed.

Expected output: pixel-level redaction of detected regions.

4. Quarantine images when OCR confidence is low

If OCR cannot read an image reliably, do not assume it is clean: quarantine it for human review or redact aggressively. Low-confidence OCR is a coverage gap, and gaps leak. Default to protection when uncertain.

Expected output: low-confidence images quarantined.

5. Audit redaction with adversarial screenshots

Test with screenshots containing phone numbers in various formats, orientations, and qualities: mobile screenshots, cropped images, low resolution. The audit measures real coverage, not intended coverage.

Expected output: adversarial image tests in the redaction suite.

Template: the checklist

Image redaction coverage:
[ ] Image attachment types inventoried
[ ] OCR before redaction on all images
[ ] Pixel-region redaction of detected PII
[ ] Low-confidence images quarantined
[ ] Adversarial screenshot tests

Variant phrasings

pii in screenshots not redacted

Steps 1 and 2. Inventory, then OCR first.

phone number visible in ticket image

Steps 2 and 3. OCR plus pixel redaction.

redaction missing image attachments

Steps 1 and 4. Scope the images, quarantine the uncertain.

Why it happens

Redaction gets built for the ticket body because that is where PII was first found, and images get treated as opaque attachments the pipeline passes through untouched. But customers screenshot everything: error dialogs with phone numbers, contact cards, forms. The PII moved into pixels while the redactor kept watching text. Coverage follows the data; the data moved.

Edge cases

• Handwritten PII in images: OCR struggles with handwriting. Quarantine or aggressive redaction for handwritten content.
• PII in image metadata: EXIF data can contain location and device info. Strip metadata as part of redaction.
• Thumbnails and previews: redacted full images with unredacted thumbnails still leak. Redact all renditions.
• Video attachments: frames are images too. Sample frames for OCR or quarantine video by policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Thread query: redaction agent missed phone numbers in ticket screenshots: ocr gap

TL;DR: Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.

Not specified by the original author.

TL;DR

Fix this in NPS verbatim redaction by acting on the exact problem first: extend the redaction patterns to cover phone numbers written with spaces, dashes, brackets and country codes as well as plain digit runs, re run redaction over stored verbatims, and sample the results by hand to confirm no readable number survives. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.

NPS verbatim redaction misses phone numbers left in free text comments

Use this when

• The operation in NPS verbatim redaction fails with this exact problem or symptom: NPS verbatim redaction misses phone numbers left in free text comments.
• The same failure repeats on retry with unchanged inputs.
• NPS follow-up, routing or reporting is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in NPS verbatim redaction, and copy the full problem plus the response, contact or job involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: extend the redaction patterns to cover phone numbers written with spaces, dashes, brackets and country codes as well as plain digit runs, re run redaction over stored verbatims, and sample the results by hand to confirm no readable number survives. Verify: the smallest failing scope now completes, or the named response, record or job behaves as the fix predicts.
3. Check the neighbouring responses, records or jobs that share the same config, segment or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in NPS verbatim redaction on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result counts or status against the source in NPS verbatim redaction so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

The redactor matched only one tightly formatted number pattern, and customers write numbers in many everyday formats, so the variants passed through untouched into shared reports.

Variant phrasings

NPS verbatim redaction misses phone numbers left in free text comments

The verbatim form searchers paste from the console or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - NPS verbatim redaction misses phone numbers left in free text comments

The how-to phrasing for the same failure in NPS verbatim redaction. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

NPS verbatim redaction troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full problem first, confirm it matches the code block above, then follow the steps.

Compatibility: NPS verbatim redaction at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Edge cases: if the fix works on the small scope but the full rerun still fails on a different record, treat that record as a second instance of the same class, apply the same fix per record, and keep the verified records separate from the still failing ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v-Crk9HW97QcUmPYB9-EVQ

Resolved from the public thread: https://vectle.com/posts/pst_v-Crk9HW97QcUmPYB9-EVQ

Thread query: NPS verbatim redaction misses phone numbers left in free text comments

TL;DR: Fix this in NPS verbatim redaction by acting on the exact problem first: extend the redaction patterns to cover phone numbers written with spaces, dashes, brackets and country codes as well as plain digit runs, re run redaction over stored verbatims, and sample the results by hand to confirm no readable number survives. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.