Predicate Criterion Formalization

Make a vague condition usable by turning it into a domain-bound yes/no test with evidence, edge-case, and review rules.

Essence

Make a vague condition usable by turning it into a domain-bound yes/no test with evidence, edge-case, composition, and review rules.

Predicate criterion formalization treats a condition as a designed object. It does not merely ask whether a label feels right. It defines what kind of candidate the test applies to, what property is being tested, what evidence counts, how truth is assigned, what happens when the test cannot decide, and how the predicate behaves when composed with other predicates.

Compression statement

Predicate criterion formalization designs a truth-valued property test. It specifies the candidate domain, the property being tested, the evidence or observation required, the evaluation rule, how false, unknown, missing, borderline, and conflicting cases are handled, and how the predicate composes with other predicates without silently changing the claim.

Canonical formula: predicate_test = domain × property_definition × evidence_rule × evaluation_logic × indeterminate_policy → {true,false,review}

Why this is distinct

The nearest accepted neighbors are important but partial. Constraint Formulation designs binding limits and feasible spaces; a predicate may test whether a constraint is satisfied, but not every predicate is a constraint. Canonical Classification builds class systems; a predicate is the local yes/no criterion that may define one class boundary. Category Boundary Audit reviews hidden consequences of a boundary; this archetype constructs the checkable condition at the boundary. Threshold-Based Activation is a numeric cutoff response pattern; predicates can include thresholds but are more general. Self-Checking Operation embeds checks inside an operation; predicate formalization designs the check itself.

Key components

Component	Description
Candidate Domain Statement ↗	Every predicate needs a domain. A property that makes sense for people may not make sense for documents, transactions, locations, claims, or system states. The domain statement prevents the same words from being applied to unlike candidates.
Property Definition ↗	The property definition states what must be true of the candidate. It should not merely rename the desired downstream outcome. “Eligible,” “safe,” “valid,” and “material” are not enough unless the property behind the label is stated.
Evidence Basis Rule ↗	A predicate is only reproducible if the allowed evidence is clear. The evidence basis says which measurements, records, observations, declarations, documents, or inferences can be used before the truth rule is applied.
Truth Evaluation Logic ↗	The truth logic names necessary conditions, sufficient conditions, disqualifiers, exceptions, priority rules, and tie-breakers. Composite predicates should be split into sub-predicates so the system can see what failed.
Indeterminate Case Policy ↗	Many cases are not honestly true or false. Evidence may be missing, stale, noisy, conflicting, or out of domain. A good predicate keeps false, unknown, not applicable, and review-needed separate when consequences matter.
Boundary Case Library ↗	Predicates are tested at their edges. The boundary case library stores obvious true cases, obvious false cases, borderline cases, adversarial cases, and counterexamples. It becomes a regression suite for policy, code, and reviewer calibration.
Composition Contract ↗	Predicates rarely remain alone. They are negated, conjoined, disjoined, quantified, nested, or used to define sets and preimages. The composition contract prevents downstream formulas from silently changing the intended meaning.
Predicate Owner and Change Log ↗	A predicate can encode policy, ontology, evidence standards, and technical assumptions. When it is reused, it needs an owner, review cadence, version history, and revision rationale.

Common mechanisms

A criteria checklist applies the predicate in a human workflow. A boolean guard clause implements it before an operation or transition. A decision table exposes composite logic. A truth table clarifies negation and combination behavior. A test case matrix validates expected outcomes. A counterexample register stores cases that falsify or strain the criterion. A predicate version registry preserves the meaning of past decisions made under older criteria.

Parameter dimensions

The main design parameters are domain breadth, evidence burden, truth-state granularity, false-positive tolerance, false-negative tolerance, compositional complexity, reviewability, and revision cadence. Narrow domains and strict evidence rules produce stable predicates but may exclude relevant cases. Broad domains and soft evidence improve coverage but can hide inconsistency. High-consequence predicates usually need more truth-state granularity than a simple true/false return.

Invariants to preserve

The archetype must preserve a stated domain, a separately named property, an explicit evidence basis, a reproducible evaluation rule, differentiated false and unknown states where needed, tested boundary cases, stable composition behavior, and visible ownership. Without these invariants, the predicate becomes a label, hunch, hidden policy choice, or brittle implementation detail.

Target outcomes

A good predicate makes rules, filters, classifications, claims, and audits more reproducible. It lets a system explain why a case passed or failed. It distinguishes out-of-domain cases from failed cases. It makes universal claims easier to challenge with counterexamples. It allows implementation in code, forms, policies, and proofs without losing the conceptual criterion.

Tradeoffs

Sharper predicates improve consistency but can mishandle context. Richer evidence improves accuracy but raises cost and delay. Binary outputs simplify action but can erase uncertainty. Composition makes complex rules concise but hides which subcondition failed unless the predicate is decomposed. Stable predicates aid fairness across time but can become stale when the domain changes.

Failure modes

The most common failure is outcome smuggling, where the predicate name hides the desired decision. Another is domain slippage, where a predicate migrates to candidate types it was not designed for. Unknown-as-false collapse occurs when missing evidence is treated as failure without an explicit burden rule. Composition distortion appears when negation, and/or logic, or quantifiers change the meaning of the predicate. Predicate laundering occurs when contested value judgments are presented as neutral technical criteria.

Examples

In mathematics, a predicate P(x) can define a set of all x satisfying a property. In software, a guard predicate can block a transition unless safety preconditions are true. In policy, an eligibility predicate can decide whether a person qualifies while routing uncertain cases to review. In research, an inclusion predicate can decide which cases belong in an evidence set before analysis.

Non-examples

“Use good judgment” is not this archetype unless the property being judged can be made checkable. A whole taxonomy is not this archetype, though predicates may define its classes. A pure budget cap is constraint formulation. A hard threshold alert is threshold-based activation. A database filter copied from legacy code is only a mechanism unless the predicate’s domain, property, evidence, and edge-case policy are known.

Common Mechanisms

• Boolean Guard Clause
• Counterexample Register
• Decision Table
• Eligibility Criteria Checklist
• Policy Definition of Terms
• Predicate Version Registry
• SQL WHERE Clause or Query Filter
• Test Case Matrix
• Truth Table
• Unknown-State Routing Rule

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

• Boundary: Defines system limits.
• Constraint: Limits possibilities to guide outcomes.
• Decision: Committing to one alternative from a set under uncertainty and trade-off, collapsing open deliberation into a chosen path and foreclosing the others.
• Predicate: A testable yes-or-no property of an object, returning a truth value.
• Relation: Describes associations or dependencies.
• Set and Membership: Groups and categorizes elements.
• Validation: Confirming that an artifact actually solves the intended problem in its real operational context, as distinct from confirming it was merely built to specification.

Also references 9 related abstractions

• Classification: Sorting entities into discrete categories by explicit rules, turning unbounded variation into a finite, reusable map for downstream reasoning and action.
• Context: Surrounding state that selects which content a fixed focal signal carries.
• Formalization: Rendering informal practice into explicit, codified, rule-governed form.
• Function (Mapping): Relates inputs to outputs.
• Preimage: The set of all inputs that map to a given output under some mapping.
• Proof By Contradiction: Establish a claim by assuming its negation and deriving an impossibility.
• Quantifier: Specifies the scope of a claim over a domain — all, some, none, most, or exactly N.
• Rule of Law: No element of a system is exempt from its governing rules, including the element that generates or enforces them.
• Threshold: Safe vs harmful levels.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Eligibility Predicate · governance variant · recognized

A predicate that decides whether a case qualifies for access, benefit, status, permission, or review.

• Distinct from parent: It specializes the parent around eligibility and boundary crossing rather than any property test.
• Use when: Admission, access, benefits, permissions, or legal status depend on whether a candidate satisfies a condition; False exclusion or false inclusion has governance consequences.
• Typical domains: public administration policy, law governance, healthcare access, education policy
• Common mechanisms: eligibility criteria checklist, policy definition of terms, unknown state routing rule

Guard Predicate · implementation variant · recognized

A predicate evaluated before an operation or transition may proceed.

• Distinct from parent: It specializes the parent around blocking or admitting a transition.
• Use when: A process must prevent invalid, unsafe, unauthorized, or out-of-scope actions before execution; The predicate is part of a transition, function call, workflow, or state update.
• Typical domains: software engineering, workflow management, safety systems
• Common mechanisms: boolean guard clause, decision table, test case matrix

Diagnostic Predicate · domain variant · recognized

A predicate that determines whether evidence supports a diagnosis, flag, label, or finding.

• Distinct from parent: It adds evidentiary uncertainty and diagnostic error concerns.
• Use when: Evidence must support a yes/no finding before a downstream diagnosis, label, or intervention is assigned; Uncertainty, sensitivity, specificity, and false-result asymmetry matter.
• Typical domains: medicine healthcare, quality control, compliance audit, research methods
• Common mechanisms: decision table, test case matrix, counterexample register

Set-Comprehension Predicate · subtype · recognized

A predicate used to define the members of a set or local candidate collection.

• Distinct from parent: It specializes the parent around set definition rather than decision gating.
• Use when: The main work is naming a collection intensionally rather than listing all members; Membership must remain stable under later querying, proof, or filtering.
• Typical domains: mathematics, data governance, software engineering
• Common mechanisms: sql where clause or query filter, truth table, test case matrix

Near names: Predicate Specification, Truth-Valued Test Design, Membership Condition Specification, Boolean Condition Formalization.