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.

Version

v1 · 2026-08-24 · History

Solution archetype #

771

Problem family

Correctness, Conformance & Formal Validity Failure

Problem subfamily

Logical Claim & Derivation Validity

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}

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A system needs to decide whether an object, case, state, action, or claim has some property, but the property is left as ordinary-language intention, unstated intuition, inherited practice, or scattered examples. Without an explicit truth-valued criterion, different actors apply different tests, edge cases drift, membership boundaries become hidden, and downstream rules, constraints, classifications, queries, proofs, or interventions inherit the ambiguity.

Applicability expression6 distinct conditions

Named-property decision boundaryandImplicit operative conditionandReusable decision subtestandAsymmetric classification errorsandComposable condition logicandFalsifiable claim criterion

Algebraic1∧2∧3∧4∧5∧6

groundedpartly groundedopen

6 conditions, all required.

6Required in every casenumbered 1–6

These hold no matter which pattern applies.

1

Named-property decision boundary · grounded

A rule, gate, query, claim, or eligibility boundary depends on whether a candidate has a named property. more

primePredicate— A testable yes-or-no property of an object, returning a truth value.

and — also required

2

Implicit operative condition · open

Cases are disputed because the operative condition is implicit or example-driven. more

and — also required

3

Reusable decision subtest · grounded

A classification, constraint, or decision requires a reusable sub-test rather than a one-off judgment. more

primePredicate— A testable yes-or-no property of an object, returning a truth value.

and — also required

4

Asymmetric classification errors · open

False positives and false negatives have materially different consequences. more

and — also required

5

Composable condition logic · grounded · any one of 2

The condition may compose with other conditions through Boolean, quantifier, threshold, or exception logic. more

a

primePredicate— A testable yes-or-no property of an object, returning a truth value.

or — any one of these establishes this case

b

primeQuantifier— Specifies the scope of a claim over a domain — all, some, none, most, or exactly N.

and — also required

6

Falsifiable claim criterion · grounded

A claim must expose observations that would refute it. more

primeFalsifiability— A claim is scientific only if it could in principle be empirically refuted.

Other requirements and context (2)

Why these sit outside the expression

Application gate — it governs whether applying the archetype is appropriate or material, rather than defining the structural problem itself.

Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.

• Application gateThe same condition will be applied repeatedly by multiple actors, systems, reviewers, or time periods.

• Supporting contextEvidence can be missing, stale, noisy, contested, or impossible to observe directly.

Coverage

4 of 6 conditions grounded · 2 open.

Read the methodology · Download the trigger-logic data

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

10 documented mechanisms across 6 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Analysis, Modeling & Optimization · 1 mechanism

• SQL WHERE Clause or Query Filter — Selects the subset of a population that satisfies the predicate, turning a criterion into set membership over stored records.

Assessment, Review & Assurance · 1 mechanism

• Eligibility Criteria Checklist — Turns a qualifying condition into an ordered list of evidence-backed criteria a reviewer applies to one candidate at a time.

Control, Automation & Runtime · 2 mechanisms

• Boolean Guard Clause — Blocks an operation at its entry point unless the predicate's preconditions evaluate true, failing closed when it cannot decide.
• Unknown-State Routing Rule — Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it.

Record, Log & Register · 2 mechanisms

• Counterexample Register — Keeps a running log of the cases that falsify or strain a criterion, turning refutations into the trigger for revising it.
• Predicate Version Registry — Preserves each past version of a criterion so a decision made under an old rule can still be read against the rule that made it.

Representation, Specification & Plan · 3 mechanisms

• Policy Definition of Terms — Fixes the meaning of a labeled term by stating its domain and the property behind the label, so the same word can't drift across a document.
• Test Case Matrix — Pins a grid of inputs to their expected verdicts so a predicate's implementation can be validated and re-checked for regressions.
• Truth Table — Enumerates every combination of boolean inputs to make the predicate's composition behavior — how negation, AND, and OR change the result — explicit.

Rule, Policy & Commitment · 1 mechanism

• Decision Table — Lays out every combination of conditions as rows mapped to a single action, with a mandatory default so no case falls through.

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.

Editorial Notes

Problem Classification

Classification: Correctness, Conformance & Formal Validity Failure → Logical Claim & Derivation Validity

Problem kernel: property membership lacks an explicit truth-valued predicate

Rationale: Earliest causal condition: A system needs to decide whether an object, case, state, action, or claim has some property, but the property is left as ordinary-language intention, unstated intuition, inherited practice, or scattered examples. Without an explicit truth-valued criterion, different actors apply different tests, edge cases drift, membership boundaries become hidden, and down

Independent corroboration: The earliest necessary condition in the frozen evidence is: A system needs to decide whether an object, case, state, action, or claim has some property, but the property is left as ordinary-language intention, unstated intuition, inherited practice, or scattered examples. That is a logical claim and derivation validity problem because Claims or conclusions fail because quantifiers, predicates, premises, inference moves, modal scope, contradiction handling, narrative consistency, or self-reference are not logically sound.

Review outcome: Independent reviewer agreement; high confidence.