Membership-Predicate Audit¶
Verification audit — instantiates Shared Subset Intersection Mapping
Inspects each collection's inclusion rule before any intersection runs, checking that the predicates are documented, compatible, and mean what their labels claim.
Membership-Predicate Audit is the read-only check that runs before the intersection is computed. An intersection is only meaningful if the collections' membership rules are compatible: two lists both labelled "active users" are worthless as a common subset if one means "logged in this week" and the other means "has ever registered." This mechanism examines each participating collection's inclusion predicate — what it actually requires, how it is defined, when it was last changed — and certifies that the rules line up well enough for their intersection to carry the meaning the decision expects. It produces no result set and touches no members; its output is a judgment about the rules, delivered before anyone trusts a count.
Example¶
A hospital network is preparing to launch a quality-improvement program for patients who are simultaneously in the diabetes registry, the hypertension registry, and the care-management registry — the patients each registry independently flags as needing attention. Before computing that intersection, the audit examines each registry's inclusion rule.
It finds three problems. The diabetes registry admits anyone with a single elevated lab value ever recorded, so "in the diabetes registry" includes long-resolved cases. The hypertension registry requires two elevated readings in the last year — a much stricter, time-bounded rule. The care-management registry's predicate was silently loosened six weeks ago to hit an enrollment target, so its current membership is not comparable to its own history. The audit does not fix these; it documents them and flags that the intersection, as specified, would blend a lifetime-ever rule with a recent-and-repeated rule and a rule that just changed. That finding lets the program owners align the predicates — say, a common "active in the last 12 months" clause — before a misleading patient list is generated and acted on.
How it works¶
The audit works down each participating collection's predicate and asks a fixed set of questions: Is the rule documented at all, or only implied by whatever query populated the list? Is it compatible with its peers — same time window, same thresholds, same underlying quantity — or do two identically-labelled predicates encode different criteria? Has it changed version recently in a way that breaks comparability with prior runs? Does the label mean what it says — is "verified customer" actually a verification, or just an unenforced flag? The output is a compatibility report: which predicates are safe to intersect as-is, which need harmonizing first, and which are too under-specified to trust. It is explicitly a pre-flight inspection, not a computation — it certifies the rules and then hands off.
Tuning parameters¶
- Audit depth — a light check that each predicate is documented, or a deep check that its implementation matches its stated definition. Deeper catches more but costs analyst time.
- Compatibility strictness — how closely predicates must align to pass. Demanding identical rules is safest but often infeasible; allowing "close enough" needs a documented tolerance.
- Re-audit trigger — audit once at setup, or re-audit whenever a source's predicate version changes. Frequent re-audits catch silent rule drift.
- Scope of review — every predicate, or only the ones the decision is most sensitive to. Focusing effort where consequence is highest, at the risk of missing a quiet incompatibility elsewhere.
- Pass/fail vs. advisory — whether a failed audit blocks the intersection or merely annotates it. Blocking is safer; advisory keeps velocity.
When it helps, and when it misleads¶
Its strength is that it catches the most insidious intersection error — rules that look comparable but are not — at the cheapest possible moment, before any list exists to be trusted. It enforces operational definitions: the requirement that a category be pinned to a concrete, checkable criterion rather than an intuitive label.[n1]
Its failure mode is a false sense of security: an audit confirms the rules are documented and mutually compatible, not that they are correct or that the data faithfully implements them. A predicate can be perfectly specified and still admit the wrong members if the underlying data is dirty. The classic misuse is signing off on an intersection because "the audit passed," when the audit only ever examined rule definitions on paper. The guarding discipline is to treat a clean audit as a necessary precondition, not a warrant — pairing it with identity reconciliation and, after the compute, a look at provenance and cardinality before the result is relied upon.
How it implements the components¶
collection_scope_registry— the audit enumerates the participating collections with their owners and predicate versions; producing that inventory is half its job.membership_predicate_set— it inspects, documents, and certifies each collection's inclusion rule, which is the component's whole content.
It does not execute the intersection_operation_rule or produce the common_member_result_set — it only certifies the inputs; those are the work of conjunctive_filter_pipeline, which is its nearest twin because both center on the same predicates: the pipeline actually applies those rules to compute the intersection, whereas the audit only inspects them and never runs.
Related¶
- Instantiates: Shared Subset Intersection Mapping — it guards the semantic validity of the inputs the compute step will trust.
- Sibling mechanisms: conjunctive_filter_pipeline · identity_key_normalization · n_way_intersection_query · empty_result_review_gate
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Membership-Predicate Audit operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it inspects each collection's inclusion rule before any intersection runs, checking that the predicates are documented, compatible, and mean what their labels claim.
Independent corroboration: The frozen evidence defines Membership-Predicate Audit as 'Inspects each collection's inclusion rule before any intersection runs, checking that the predicates are documented, compatible, and mean what their labels claim', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Auditing documented inclusion predicates before set operations is a data and software correctness control. Set theory supplies predicate and intersection semantics, while information science supplies controlled-definition and metadata discipline.
Related originating lineages:
- Library & Information Science — Classification practice contributes semantic auditing of inclusion rules and labels.
- Mathematics — Retained as a formative lineage independently identified as primary: Explicit membership predicates and set intersections originate in formal set theory and logic.
Review resolution: Formal set membership comes from mathematics, but the mechanism's characteristic act is inspecting machine- or data-operationalized predicates for compatibility before computation. That makes computer science primary and the other two lineages formative. The alternates are retained only as formative or independently established origins, not because the mechanism can be applied there. origin_mode=cross_disciplinary_synthesis states the provenance relationship; domain_reach=universal separately records breadth because the operating pattern is portable across essentially any subject domain. confidence=high reflects the strength and specificity of the evidence; encyclopedia_synthesis=true because the entry deliberately composes those documented lineages into this exact artifact.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://www.w3.org/TR/shacl/ — The W3C SHACL standard is a primary specification for validating data against explicitly declared constraints and shapes.
- https://plato.stanford.edu/entries/set-theory/ — Authoritative reference documents the mathematical membership and set-operation foundation.
Notes¶
[n1] An operational definition specifies a concept by the exact, repeatable procedure used to measure or detect it, rather than by an intuitive description. The audit is essentially a demand that every collection's membership be operationally defined and that those definitions be mutually compatible. ↩