feat: add a deny list for entities in Anonymizer

[memadi-nv]

Summary

Adds entity_label_denylist to the Detect configuration, allowing users to explicitly exclude specific entity label types from detection. Denied labels are removed from detector scope, filtered from final explicit and latent entity outputs, and excluded from entity-coverage scoring.

Changes

Config

• Added entity_label_denylist: list[str] | None field to Detect with the same normalisation as entity_labels (strip, lowercase, deduplicate, reject empty)
• Added model validator that warns at config construction time when entity_labels and entity_label_denylist share labels that would never be detected.

Detection Engine

• Subtracted denied labels from the effective label set before GLiNER and LLM prompts run (_resolve_detection_labels)
• Added safety-net filter in _materialize_final_entities to drop denied labels from final entity output regardless of LLM output
• Threaded entity_label_denylist through all detection pipeline methods: run, detect_and_validate_entities, _build_detection_spec, identify_latent_entities
• Threaded through export paths: build_detection_config and build_detection_builder_for_seed
• Added warning when the denylist empties the effective label set (GLiNER returns no detections for an empty list, not defaults)
• Rewrite latent detection receives the denylist in its prompt and deterministically filters denied latent labels from its output.
• Final allowlist and denylist comparisons are case- and whitespace-insensitive.

Evaluation

• Added entity_label_denylist field to AnonymizerResult and PreviewResult so evaluate() has access to the full detection scope
• Propagated entity_label_denylist through evaluate() to EntityCoverageWorkflow and ReplacementWorkflow.evaluate()
• Explicit allowlists have denied labels removed. When entity_labels=None, coverage remains permissive so novel augmenter-defined labels are evaluated, while denied labels are independently excluded in the prompt and postprocessing.

Telemetry

• Added entity_label_denylist to _detect_config_metadata so it is captured in measurement records alongside entity_labels

Tests

• Config validation: field normalisation, empty list rejection, overlap warning
• Detection engine: label resolution, GLiNER injection, final entity filtering, combined allowlist + denylist, export paths
• Evaluation: _effective_entity_labels helper, coverage judge postprocess filter, coverage prompt scoping
• Telemetry: entity_label_denylist captured correctly when set and absent
• Case-insensitive denylist enforcement.
• Latent-entity filtering.
• Preservation of novel non-denied labels during coverage evaluation.

Docs

• Updated Detect fields reference table and added "Excluding labels with a deny list" section in detection.md
• Added entity_label_denylist to the judge scoping list in evaluation.md
• Added entity_label_denylist section and corrected the data_summary soft-exclusion claim in choosing-a-strategy.md
• Added entity_label_denylist as the recommended fix for systematically noisy label types in troubleshooting.md
• Updated skills/anonymizer/SKILL.md with denylist behavior and precedence rule

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring
• CI, release, or contributor workflow update

Contributor Checklist

• PR title follows Conventional Commits, for example fix: handle empty entity list
• Related issue is linked, or a maintainer-owned no-issue reason is documented above
• For non-trivial changes, a plan document is linked above, or the no-plan reason is documented above
• Public API impact checked; skills/anonymizer/SKILL.md updated if needed
• No real PII added to tests, docs, notebooks, fixtures, or artifacts
• No API keys, service tokens, private keys, credentials, or real endpoint secrets added

Validation

• Commands run:
• Skipped checks or known failures:

Documentation and Artifacts

• Docs updated, or not needed
• If docs changed: make docs-build passes locally
• If tutorial sources changed: notebooks regenerated with make convert-notebooks
• If e2e, benchmark, or model-provider behavior changed: relevant validation is listed above

closes issue #164

[greptile-apps]

Greptile Summary

The PR adds a normalized entity-label denylist and propagates it through detection, rewrite latent-entity handling, evaluation, result metadata, measurement records, documentation, and tests.

• Removes denied labels from detector and prompt scope and filters explicit and latent outputs defensively.
• Preserves permissive coverage evaluation for novel non-denied labels while excluding denied candidates.
• Carries denylist configuration through run, preview, evaluation, export, and telemetry paths.
• Updates the packaged skill documentation, publication metadata, benchmark evidence, and signature artifact.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the current code fixes the previously reported permissive-coverage, explicit-label normalization, and latent-entity denylist issues.

Important Files Changed

Filename	Overview
src/anonymizer/config/anonymizer_config.py	Adds normalized denylist configuration and overlap diagnostics without leaving the previously reported bypasses reachable.
src/anonymizer/engine/detection/detection_workflow.py	Propagates denylist scope through detection and latent workflows and now strips and case-folds labels in both final filtering paths.
src/anonymizer/engine/evaluation/entity_coverage_judge.py	Preserves permissive evaluation when no allowlist is configured while independently excluding denied labels from prompts and postprocessing.
src/anonymizer/interface/anonymizer.py	Carries denylist context consistently through run, preview, and both replace and rewrite evaluation paths.
src/anonymizer/interface/results.py	Retains denylist scope on result objects so later evaluation reproduces the original detection configuration.
src/anonymizer/engine/replace/replace_runner.py	Passes denylist context into replace-mode coverage evaluation.
src/anonymizer/measurement/records/run.py	Adds normalized denylist configuration to sanitized run metadata.
tests/engine/test_detection_workflow.py	Covers denylist resolution, explicit and latent filtering, serialization paths, and case-insensitive enforcement.
tests/engine/test_entity_coverage_judge.py	Verifies permissive novel-label coverage and independent denied-label filtering.
skills/anonymizer/SKILL.md	Documents denylist behavior and precedence for skill-assisted configuration.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  C[Detect configuration] --> R[Resolve effective labels]
  R --> D[GLiNER and explicit detection]
  R --> L[Latent detection]
  D --> F[Normalize and filter final entities]
  L --> LF[Normalize and filter latent entities]
  F --> O[Anonymization result]
  LF --> W[Rewrite sensitivity analysis]
  O --> E[Coverage evaluation]
  C --> E
  E --> P[Prompt scope and deterministic candidate filter]

Loading

_{Reviews (9): Last reviewed commit: "Attach NVSkills validation signatures" | Re-trigger Greptile}

[memadi-nv]

/nvskills-ci

[lipikaramaswamy]

/nvskills-ci

[binaryaaron]

[P1] Filter denied augmented labels before resolving overlaps

In permissive mode, the augmenter can still return denied labels. These labels enter overlap resolution before the final deny-list filter, so a denied span can replace an allowed span and then be removed, leaving the allowed PII undetected.

Please filter denied augmented entities before merging them, and add a regression test confirming an overlapping allowed span survives.

[lipikaramaswamy]

Yes, this is critical to fix. Do note that #238 will change the mechanism for overlap resolution in resolve_overlaps, but regardless of the resolution mechanism we should filter out undesired entity labels after.

[lipikaramaswamy]

The param name entity_label_denylist is not precise and is not likely to be intuitive to a user. excluded_entity_labels (preferred) or ignored_entity_labels sounds better to me; open to other suggestions. We should agree on the name before we make changes to the public API.

[lipikaramaswamy]

We should preserve the existing result constructor contract.

These result classes are public, so their constructor parameters and attributes form part of the user-facing API. Adding the new field before data_summary changes the positional signature, even though positional construction is probably uncommon.

Could we place the new optional field after data_summary to preserve the existing parameter order? Longer term, it may be worth grouping evaluation provenance into a dedicated context object, but replacing the existing fields would require a separately planned API change.