Predicate Satisfaction Filter¶
Filtering method — instantiates Preimage Set Characterization
Runs a stated membership predicate over the whole input population, keeping exactly the cases that satisfy the output condition and flagging the ones sitting on the threshold.
A Predicate Satisfaction Filter makes the membership rule the star of the show. Rather than retrieving inputs from an index or deriving them from constraints, it writes the output condition as an explicit, reviewable predicate — a testable is-this-in? rule — and applies it, one case at a time, across a population it is handed. Its whole discipline is putting the rule in the open where a human can inspect, argue with, and version it, and being scrupulously honest about the cases that sit right on the threshold, where a hair's difference in the predicate flips them in or out. It does not vouch that the population it filtered was complete; it vouches that this rule, applied to these cases, produced this membership — and shows its work at the edge.
Example¶
A company must produce, for a regulator, every employee record covered by a data-subject-access request — "all inputs mapping to the output this person's personal data is in scope." A Predicate Satisfaction Filter states the membership rule in reviewable form: include a record if it references the subject's national ID, OR their work email, OR a free-text field containing their full name AND a matching date of birth. That predicate is applied to every record in the HR system, and each is kept or dropped by whether it satisfies the rule.
The value is not only the kept set but the register of edge cases the rule forced into the open: a record with the subject's name but a different date of birth (dropped — is that right?), a shared shift-swap note mentioning them in passing (kept — too broad?). Those boundary cases are surfaced for a human to adjudicate before the disclosure goes out, so the rule can be tightened where it over-reaches and loosened where it misses — with a documented trail of exactly which predicate produced which decision.
How it works¶
- Write the predicate. Express the output condition as an explicit, human-readable membership rule over input attributes — the artifact this mechanism exists to make legible.
- Apply it case by case. Evaluate the predicate against each member of the supplied population, keeping the satisfiers and dropping the rest.
- Register the boundary. Identify cases near the predicate's threshold — just-included and just-excluded — and log them for review rather than letting the cutoff swallow them silently.
- Version the rule, not the result. When adjudication changes a decision, change the predicate and re-run, so the membership always traces to a stated rule.
Tuning parameters¶
- Predicate strictness — how demanding the rule is. Stricter predicates raise precision (fewer false members) but drop borderline true ones; looser predicates catch more but admit noise.
- Boundary band width — how far from the threshold a case still counts as "on the edge" worth registering. A wide band surfaces more for review but grows the adjudication queue; a narrow band is cheap but lets near-misses pass unexamined.
- Conjunction vs. disjunction structure — whether clauses are AND-ed (narrow, all conditions required) or OR-ed (broad, any condition suffices). This shapes the whole character of the kept set.
- Null / missing-value policy — how records with absent attributes are treated when the predicate can't be evaluated. Treating unknown as "exclude" versus "flag for review" changes who ends up in the set.
When it helps, and when it misleads¶
Its strength is transparency: the membership rule is written down, applied uniformly, and open to challenge — a selection predicate in the relational-algebra sense[n1], versioned like code, with the contested cases pulled to the surface instead of buried in a threshold.
Its failure mode is that a filter can only judge the population it is given, and it judges presence, not truth: a record that should be in scope but was never in the filtered table cannot be kept, because the filter never sees it. The classic misuse is treating the predicate's silence as coverage — reporting "these are all the matching records" when the honest claim is "these are all the matching records among the ones we filtered." A subtler misuse is quietly re-tuning the predicate until the result looks right, converting a membership rule into a rationalization. The guarding discipline is to fix the population's scope explicitly and separately, keep the predicate under version control so tuning is visible, and adjudicate the boundary register on the rule's merits rather than the desired count.
How it implements the components¶
preimage_membership_rule— its signature: the explicit, reviewable predicate that defines who is in the preimage and who is out.boundary_case_register— the log of near-threshold cases the predicate forces into the open for human adjudication.
It does not implement candidate_input_enumeration or completeness_evidence — constructing the members from scratch and certifying the set omits nothing is the job of Constraint-Solver Backsolve, its nearest twin; the filter tests a population it is handed and cannot vouch that the population itself was complete. It shares the membership idea with Witness and Counterexample Set, but that mechanism exhibits individual proven cases rather than sweeping the whole population.
Related¶
- Instantiates: Preimage Set Characterization — the filter supplies the explicit membership rule and the adjudicated boundary the characterization is built to keep reviewable.
- Sibling mechanisms: Inverse Lookup Query · Constraint-Solver Backsolve · Output-to-Input Traceback Map · Collision Analysis Matrix · Fiber Cardinality Count · Sensitivity-to-Mapping-Change Review · Preimage Table · Witness and Counterexample Set
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Predicate Satisfaction Filter operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it runs a stated membership predicate over the whole input population, keeping exactly the cases that satisfy the output condition and flagging the ones sitting on the threshold.
Independent corroboration: The frozen evidence defines Predicate Satisfaction Filter as 'Runs a stated membership predicate over the whole input population, keeping exactly the cases that satisfy the output condition and flagging the ones sitting on the threshold', so its operative form is Control, Automation & Runtime.
Nearest alternative: Decision, Gate & Allocation — Predicate Satisfaction Filter includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Selecting exactly the elements satisfying a predicate is a set-theoretic preimage construction.
Related originating lineages:
- Computer Science & Software Engineering — Computer science contributes executable filtering over finite data and explicit threshold handling.
Review resolution: Both blind reviewers agree that mathematics is the primary origin. Reconciliation resolves encyclopedia synthesis disagreement. Formative alternate lineages are retained as computer_science; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] In relational algebra, the selection operator (σ) returns exactly the tuples of a relation that satisfy a stated predicate — the formal ancestor of the SQL WHERE clause. Its power and its risk are the same: it is only ever evaluated over the relation it is applied to, never over the world. ↩