feat: improve sensitivity disposition calibration

[asteier2026]

Changes include:

• Refactor entity_categories to assign explicit sensitivity tiers (high/medium/low) for
  quasi-identifiers and latent identifiers, grounded in re-identification risk rather than content
  sensitivity
  • Add combined_risk_assessment block clarifying the distinction between sensitivity and
    combined_risk_level, and establishing that needs_protection follows from combined_risk_level
  • Add bundle over-protection guidance to prevent medium assignment to every element of an identifying
    bundle
  • Strengthen output_requirements to enforce combined_risk_level as the driver of needs_protection and
    require protection_reason to demonstrate persistence after high-risk anchors are suppressed

[greptile-apps]

Greptile Summary

This PR closes three previously-flagged P1 issues by adding StrictCombinedRiskLevel (constraining strict-mode entities to medium/high), wiring schema validators that enforce the combined_risk_level → needs_protection invariant, and fixing the misquoted strict-mode override string. It also refactors the LLM sensitivity-disposition prompt to ground protection decisions in re-identification risk rather than content sensitivity, and removes the now-obsolete sensitive_attribute and latent_sensitive_attribute categories from the detection and rewrite schemas.

• Schema hardening (rewrite.py): StrictEntityDispositionSchema now rejects combined_risk_level='low' at parse time, and EntityDispositionSchema._validate_protection_consistency enforces high→needs_protection=true and low→needs_protection=false as hard invariants.
• Prompt overhaul (sensitivity_disposition.py): Entity categories gain explicit sensitivity tiers (high/medium/low), a new combined_risk_assessment block clarifies the sensitivity-vs-combined_risk_level distinction and adds bundle over-protection guidance, and output requirements now name combined_risk_level as the sole driver of needs_protection.
• Category cleanup (detection.py, rewrite.py, qa_generation.py): sensitive_attribute and latent_sensitive_attribute are removed from all schemas with no remaining references in the codebase.

Confidence Score: 5/5

Safe to merge — all three previously-identified crash paths in the strict conversion flow are now closed.

The StrictCombinedRiskLevel enum prevents combined_risk_level='low' from ever reaching to_entity_disposition(), the new validators enforce both directions of the combined_risk_level → needs_protection contract, and no remaining references to the removed sensitive_attribute categories exist in the codebase.

tests/engine/test_schemas.py — the two new combined_risk_level invariants lack direct failure-path test cases.

Important Files Changed

Filename	Overview
src/anonymizer/engine/schemas/rewrite.py	Adds StrictCombinedRiskLevel enum (medium/high only) and wires it into StrictEntityDispositionSchema; adds combined_risk_level→needs_protection invariant validators to EntityDispositionSchema — all three prior P1s are closed.
src/anonymizer/engine/rewrite/sensitivity_disposition.py	Refactors entity_categories guidance to assign explicit sensitivity tiers, adds combined_risk_assessment block, strengthens output_requirements, and fixes the misquoted strict-mode override string.
src/anonymizer/engine/schemas/detection.py	Removes latent_sensitive_attribute from LatentCategory enum; no downstream references remain in src or tests.
tests/engine/test_schemas.py	Adds combined_risk_level='low' to fixtures that needed it; missing explicit tests for the two new combined_risk_level invariants (high→needs_protection=true, low→needs_protection=false).

_{Reviews (6): Last reviewed commit: "Update src/anonymizer/engine/rewrite/sen..." | Re-trigger Greptile}

[asteier2026]

I made the changes greptile-apps recommended Wed morning.

[lipikaramaswamy]

Q: in strict entity protection mode, should combined_risk_level="low" still be allowed?

I noticed StrictEntityDispositionSchema accepts combined_risk_level="low", but to_entity_disposition() always converts strict entities with needs_protection=True. With the new validator, that creates low + needs_protection=True, which raises because low combined risk now requires needs_protection=False.

I may be missing the intended strict-mode semantics here, but should strict mode either constrain combined_risk_level to high/medium, or handle this conversion differently?

[asteier2026]

Good catch Lipika, I made the adjustments.

[lipikaramaswamy]

Looks good. I rechecked the strict-mode edge case: combined_risk_level="low" is now rejected by the strict schema, and medium/high convert cleanly with needs_protection=True. Tests ran great, and I'm assuming the end-to-end pipeline works with the updated prompt/schema.