feat: add excluded labels for entities in Anonymizer

[memadi-nv]

Summary

Adds excluded_entity_labels 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 excluded_entity_labels: 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 excluded_entity_labels 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 excluded_entity_labels 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 excluded_entity_labels field to AnonymizerResult and PreviewResult so evaluate() has access to the full detection scope
• Propagated excluded_entity_labels 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 excluded_entity_labels 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: excluded_entity_labels 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 excluded_entity_labels to the judge scoping list in evaluation.md
• Added excluded_entity_labels section and corrected the data_summary soft-exclusion claim in choosing-a-strategy.md
• Added excluded_entity_labels 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]

Confidence Score: 5/5

The PR appears safe to merge; the prior exclusion-bypass findings are resolved and no new actionable failure remains.

Summary

• Exclusions take precedence over explicit and default detection labels.
• Explicit and latent outputs are filtered using normalized label comparisons.
• Evaluation ignores denied labels while retaining permissive handling of novel labels.
• Configuration now rejects exclusions that eliminate the entire effective detector scope.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    C[Detect configuration] --> R[Resolve effective labels]
    X[Excluded labels] --> R
    R --> D[Seed detection]
    R --> A[LLM augmentation]
    D --> V[Validation]
    A --> V
    X --> V
    V --> F[Final entity filtering]
    X --> F
    F --> P[Replace or rewrite]
    X --> L[Latent entity filtering]
    L --> P
    F --> E[Coverage evaluation]
    X --> E

Loading

_{Reviews (22) · Last reviewed commit: "feat(config): also guard entity_labels=N..."}

[memadi-nv]

/nvskills-ci

[lipikaramaswamy]

/nvskills-ci

[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.

[memadi-nv]

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.

excluded_entity_labels is reasonable. Updated. Thanks!

[memadi-nv]

/nvskills-ci

[memadi-nv]

/nvskills-ci

[binaryaaron]

/nvskills-ci

[binaryaaron]

/nvskills-ci

[binaryaaron]

/nvskills-ci

[binaryaaron]

agent (review-pr): Blocking empty effective-label path remains

[P1] Reject exclusions that remove every default label

The explicit-overlap validator does not run when entity_labels=None. On the current head (f3cffb5), this remains valid:

Detect(
    entity_labels=None,
    excluded_entity_labels=list(DEFAULT_ENTITY_LABELS),
)

Both the standard and latent detection paths call _resolve_detection_labels(). It returns [], logs a warning, and the workflow injects that empty list into the detector configuration.

A local regression test confirms the missing guard:

Failed: DID NOT RAISE <class 'ValueError'>

With the bundled GLiNER server, this silently disables detection. Other detector endpoints may interpret an empty label list differently. Either outcome violates the intended fail-early behavior for an empty effective detection set.

Please treat this as blocking and ensure no workflow can send labels=[] to the detector.

Prompt for an implementation agent

Fix the remaining empty-effective-label defect in PR #243.

Requirements:

• Reproduce the defect with entity_labels=None and excluded_entity_labels containing every value in DEFAULT_ENTITY_LABELS.
• Reject that configuration with a clear ValueError before a detector workflow executes.
• Ensure both callers of _resolve_detection_labels()—the standard detection specification and latent-entity detection—cannot inject labels=[].
• Add a regression test for the default-label case. Update the existing warning test if the new invariant makes it obsolete.
• Preserve partial default exclusions, label normalization, deduplication, and explicit-label overlap behavior.
• Keep the invariant in the narrowest owning layer; do not duplicate the effective-label calculation across callers.
• Use astnav refs _resolve_detection_labels to verify the complete caller set before editing.
• Run the focused config and detection-workflow tests, Ruff format/lint, and git diff --check.

Report the changed files, the ownership decision, and the exact verification results.

[lipikaramaswamy]

/nvskills-ci

[lipikaramaswamy]

Small nit, but looks great overall!

[lipikaramaswamy]

Small mismatch: this says a partial overlap always logs a warning, but the validator only warns when entity_labels is explicitly set. Partial exclusions from DEFAULT_ENTITY_LABELS are accepted without a warning, which is also the common use case. Could we clarify that distinction here and in the matching warning in docs/concepts/choosing-a-strategy.md?