RFC: Review flag on filter strategies

[jzonthemtn]

Summary

Add an optional review flag to filter strategies. The strategy is applied as usual, and every span it produces is marked as needing human review.

Motivation

Detection and classification are probabilistic. Some decisions should go to a person even when a strategy applies: a name whose age cannot be determined, an address whose role is unclear, a detection below a confidence threshold. Review tools such as Arbiter currently decide what to queue on their own, from confidence alone, so the policy (the versioned record of intent) cannot say "redact this, but have someone check it."

Split from #48, which covers reasons only.

What does this change touch?

• Schema (review on strategies)
• Grammar, catalog, compile contract
• Phileas runtime (span output)

Proposed change (sketch)

• Optional boolean review on baseFilterStrategy and dateFilterStrategy, default false, and on document rules (RFC: Document rules applied to every span in a document #54) if those land.
• Explain output gains reviewRequired on each span produced by a strategy with review: true.
• review never changes the replacement text.

"surnameFilterStrategies": [
  { "strategy": "ABBREVIATE", "condition": "token is minor" },
  { "strategy": "SAME", "condition": "token is age-unknown", "review": true },
  { "strategy": "SAME" }
]

PhiSQL. A trailing REVIEW clause, matched contextually so it is not reserved:

REDACT SURNAME WITH SAME WHERE TOKEN IS AGE_UNKNOWN REVIEW;

Expected versioning impact

PhiSQL spec minor (new clause; no reserved keyword). Schema additive, edited in place.

Backward compatibility

Additive. Spans gain a field consumers must tolerate. A runtime embedding the schema from before this change rejects a policy using review.

Alternatives considered

• Leave review routing to applications. Works, but every tool reinvents it outside the versioned policy.
• A confidence threshold field instead. Covers only one reason for review; conditions already express thresholds.

Open questions

• Is the existing OPTIONS clause a better home than a new REVIEW clause?
• Should review carry a priority or category, or stay a boolean?

Acceptance Criteria

• The current schema/<version>/schema.json is edited in place to add review to base and date strategies.
• The catalog documents review and the reviewRequired span field, and that it never changes output.
• The grammar accepts the REVIEW clause on REDACT and DEIDENTIFY without reserving a keyword, and the compilers emit review: true.
• A worked example compiles and validates in CI; existing examples compile unchanged.
• Issues exist in philterd/phileas, philterd/phileas-python, and philterd/phileas-conformance and are linked here (Record reasons and review flags on spans phileas-dotnet#140 exists).
• The open questions are answered in this thread before the RFC is accepted.