Redaction Quality and Prompt Integrity

[sergeyenin]

Problem / use case

Dativo Talon currently supports two input-redaction formats before provider dispatch:

• Legacy flat placeholders (for example: [PERSON], [EMAIL])
• Enriched semantic placeholders (for example: <PII type="email" domain_type="corporate"/>)

Recent A/B evaluation artifacts show malformed transformed prompts in both formats, especially on email-heavy prompts. Representative shapes include:

• An email [PERSON] received. [PERSON] [PERSON] [PERSON] a [PERSON] [PERSON]?
• Equivalent enriched variants with repeated <PII type="person".../> placeholders replacing large semantic chunks.

This is not only a detector-labeling issue. The same failure shape appears across both output styles, which indicates upstream pipeline weaknesses in one or more of:

• Span arbitration and overlap resolution
• Structural-entity atomicity (for example, EMAIL and IBAN surfaces)
• Prompt reconstruction integrity
• Evidence fidelity between transformed text and what is actually sent downstream

Observed impact:

• Prompt meaning can collapse and become unanswerable
• Model responses shift toward refusal, clarification, and low-utility fallbacks
• Benchmark outcomes become hard to interpret causally
• Compliance assurance weakens if evidence views are not guaranteed to be exact provider payloads

Current architecture already has strong building blocks (scanner, enrichment, policy adapter, renderer), but lacks explicit contracts for deterministic span precedence, structural claim-locking, and pre-dispatch prompt-integrity checks.

Compliance requirement (if applicable)

This issue intersects multiple Talon compliance objectives (GDPR, EU AI Act, ISO 27001 controls) beyond pure model quality:

• Data minimization and purpose limitation: Talon must remove raw PII before model input, but over-redaction that destroys operational utility can create pressure to disable controls, which is a governance risk.
• Accuracy of derived data: enriched attributes (for example, country_code, domain_type, scope) are compliance-relevant metadata. Incorrect span survival or malformed reconstruction can produce inaccurate derived data.
• Auditability and evidence integrity: evidence should support defensible claims about what the model actually received. Summary-only or truncated representations are useful, but they should be clearly distinct from exact dispatch payload evidence.
• Risk management under EU AI Act controls: malformed prompt transformations can materially change system behavior (for example, refusal spikes), which should be treated as a reliability and control-effectiveness risk, not only an NLP quality issue.

Compliance posture requirement:

• Raw PII must never reach downstream providers when policy requires redaction.
• Transformations must preserve sufficient semantic integrity for intended purpose.
• Evidence artifacts must distinguish clearly between:
  • normalized summaries for human review
  • exact payload evidence used for forensic verification

Proposed solution

Proposed options are ordered by implementation scope.

Option A: minimal hardening (fast)

• Tighten high-noise fuzzy recognizers (especially PERSON patterns and context boosting).
• Add overlap-heavy regression tests for mixed prompts (person + email + phone + location).
• Remove report ambiguity by failing evaluation views when evidence-backed input capture is unavailable (no silent simulation fallback for "actual seen").

Pros:

• Fast risk reduction with limited refactor.

Cons:

• Does not fully solve structural overlap or payload-evidence fidelity contracts.

Option B: medium-term pipeline hardening (recommended near-term)

• Introduce Talon-owned canonical span resolver with explicit precedence rules:
  • structural entities (EMAIL, PHONE, IBAN, IDs) claim spans first
  • fuzzy entities (PERSON, LOCATION) cannot fire inside claimed structural spans
• Keep one-pass rendering from original text offsets only.
• Add pre-dispatch prompt-integrity validator:
  • malformed placeholder detection
  • excessive placeholder density threshold
  • fallback strategy (coarser but stable placeholders) on integrity failure
• Strengthen evidence contract:
  • retain summary views for observability
  • add exact final payload hash (and optional sealed payload snapshot under policy)

Pros:

• Addresses root causes across detector, span, rendering, and observability layers.
• Fits current Talon architecture without full detector migration.

Cons:

• Requires targeted refactor and new invariants/tests.

Option C: robust target architecture (future-ready)

• Keep Talon deterministic recognizers for exact-format entities.
• Add Presidio (or equivalent) only for fuzzy NER entities.
• Keep Talon-owned:
  • canonical span resolver
  • renderer
  • enrichment and policy filtering
  • prompt-integrity gate
  • final payload evidence guarantees

Pros:

• Best long-term balance of precision, flexibility, and compliance defensibility.

Cons:

• Highest integration and operational complexity.

---

Recommended direction: implement Option B first, then layer Option C as an incremental detector upgrade path.

[sergeyenin]

Reorganized into the Talon 2.0 backlog. This work is now tracked in #137 (milestone M1).

See the north-star demo #107 and the milestones for the full plan (internal_docs/talon-2/). Closing here to keep the board aligned with the 2.0 roadmap — history is preserved and this can be reopened if needed.