Predicate Acceptance: From vibe to citizen

Most striking at first is this appearance of sudden illumination, a manifest sign of long, unconscious prior work. The role of this unconscious work in mathematical invention appears to me incontestable.

This chapter formalizes the acceptance gate for predicate admission, defining Anchor A29 (Predicate Acceptance). A29 specifies six checks -- discrimination, abstain coverage, confounder rejection, invariant satisfaction, operationality, and scope authority -- that a proposed predicate must pass before entering a context's vocabulary. The chapter also defines the promotion pathway from local admission to wider scope, with obstruction artifacts when promotion fails. A29 operationalizes the predicate packaging obligations of A24, the predicate invention machinery of A17, and the version compatibility discipline of A26. The narrative motivation for this formal gate appears in Volume I, Chapters 7 and 8, where the need for accountable predicate minting is grounded in the witness protocol.

The Dress That Demanded a Dimension

A buyer types "puffy dresses" into the search bar. The system returns results ranked by embedding similarity and filtered by available attributes: color, size, price, brand. None of these captures what the buyer wants.

"Puffy" is not a color. It is not a size. It is a property of silhouette: volume from fabric structure, the architectural drama of tulle and organza, the way a ball gown occupies space. The buyer knows it when she sees it. The system has no way to represent it.

This is T6: Predicate Invention. Chapter 3 diagnosed it as schema rigidity. Chapter 5 named it as a flagship touchstone. Chapter 15 operationalized predicate invention via A17. Chapter 22 specified the predicate package via A24. The machinery exists to mint "puffy" as a predicate.

The question that remains: what makes a minted predicate safe to deploy?

The answer is not "it works on some examples." The answer is not "the merchandiser approved it." The answer is: it passes an acceptance test. A29 defines that test.

The Acceptance Gate

A predicate is a claim about the world that the system can evaluate. "This dress is puffy" is a claim. If the system admits this claim into its vocabulary, queries can use it, results can be filtered by it, and downstream processes can depend on it.

The cost of admitting a bad predicate is not just incorrect results. It is vocabulary pollution: a term that means nothing stable, a filter that accepts everything or nothing, an invariant violation waiting to surface in production.

A29 is the gate. A predicate must pass six checks before the system admits it to a context. If it fails, it is either rejected with remediation guidance or routed to an alternative standing (preference signal, soft boost) where its obligations are different.

The gate operationalizes "predicates ship with obligations" (A24). Without the gate, predicate invention is a write-access exploit: whoever proposes a term controls what it means.

Anchor A29: Predicate Acceptance

Admitted(q, AdmissionReceipt)
| Rejected(reason, failing_checks, alternative_standing?)
| Provisional(q, conditions_for_full_admission)

The checks are ordered by cost. Discrimination and abstain coverage are cheap (run exemplars through evaluator). Confounder rejection is medium (requires curated hard negatives). Invariant satisfaction and operationality are expensive (require regression tests and budget validation). Scope authority is administrative. A predicate that fails early checks does not incur the cost of late checks.

What the Receipt Contains

AdmissionReceipt(puffy) = {
  predicate_id: pred_puffy_v1,
  package_hash: 0x8f3a...,
  admitted_to: U_fashion_catalog,
  admitted_at: 2026-01-15T11:00:00Z,
  admitted_by: substrate_admission_service,
  
  test_results: {
    discrimination: { positive_correct: 3, negative_correct: 2, boundary_in_zone: 1 },
    abstain_coverage: { boundary_count: 1, in_zone: true },
    confounders_rejected: 2,
    invariants: [
      ("range [0,1]", PASS),
      ("monotonicity", PASS),
      ("logical_conservativity", PASS),
      ("operational_conservativity", PASS)
    ],
    operationality: { latency_p99_ms: 47, cost: $0.002/eval }
  },
  
  standing: "org",
  promotion_eligibility: true,
  expiration: "indefinite",
  revalidation_triggers: ["3d_model_service version change", "calibration drift > 0.1"]
}

The receipt is the predicate's proof of citizenship. Queries can cite it. Auditors can inspect it. When someone asks "why is 'puffy' a valid filter?", the system can produce the receipt.

The Puffy Lifecycle

Stage 1: Proposal

The buyer searches "puffy dresses" 847 times in January. On 12 of 50 clicked results, she marks "not what I wanted." The system detects a vocabulary gap: users are searching for a concept the schema cannot represent.

A merchandiser proposes "puffy" as a candidate predicate with initial intension: "dress with voluminous silhouette from fabric structure."

Stage 2: Grounding

The merchandising team gathers exemplars:

Positive (must be puffy):

• Ball gown with multiple tulle layers
• Bubble hem dress with organza
• Tiered skirt with voluminous sleeves

Negative (must not be puffy):

• Fitted sheath dress
• A-line dress with no volume

Boundary (uncertain, explicit):

• Dress with dramatic sleeves but fitted bodice (partial puffiness)

Confounders (look like puffy but aren't):

• Quilted puffer-jacket dress (volume from insulation, not fabric structure)
• Ruffled dress (texture, not silhouette volume)

The confounders are the precision gate. The quilted dress has volume. The ruffled dress has visual complexity. Neither is "puffy" in the intended sense. If the evaluator accepts them, the predicate fails.

Stage 3: Packaging

The predicate package assembles A24's seven components plus A29's acceptance apparatus:

PredicatePackage(puffy) = {
  signature: Dress → Score[0,1],
  intension: { method: "volume_ratio normalized to [0,1]", evaluation: "3D silhouette model" },
  runtime: { evaluator_id: hash("silhouette_volume_v1"), dependencies: ["3d_model_service@v2.1"] },
  tests: { positive: [...], negative: [...], boundary: [...], confounders: [...] },
  
  abstain_contract: { τ_low: 0.3, τ_high: 0.7, abstain_policy: "flag_for_review" },
  invariants: { internal: ["puffy ∈ [0,1]", "monotone"], external: { logical: [...], operational: [...] } },
  operationality: { latency_budget_ms: 100, cost_budget: "$0.01/eval", caching: "safe" },
  
  scope: { admitting_context: U_fashion_catalog, promotion_path: ["U_search_index"] },
  versioning: { compatibility_class: "conservative", deprecation_policy: "6-month warning" }
}

Stage 4: Acceptance

The substrate runs the acceptance test suite:

Check 1 (Discrimination): Positive items score [0.87, 0.91, 0.78], all above τ_high (0.7). Negative items score [0.12, 0.08], all below τ_low (0.3). Boundary item scores 0.52, in the gray zone. PASS.

Check 2 (Abstain Coverage): One boundary exemplar declared, correctly in [0.3, 0.7]. Abstain policy is "flag_for_review." PASS.

Check 3 (Confounder Rejection): Quilted dress scores 0.22, ruffled dress scores 0.18. Both below τ_low. Two confounders from two subclasses (insulated, textured). PASS.

Check 4 (Invariant Satisfaction): EntailmentRegressionSuite verifies. No existing queries affected (new predicate, no prior labels). PASS.

Check 5 (Operationality): Latency p99 is 47ms (budget: 100ms). Cost is $0.002/eval (budget: $0.01). Dependencies pinned. PASS.

Check 6 (Scope Authority): Merchandising team has org-level authority for U_fashion_catalog. PASS.

Result: Admitted. AdmissionReceipt issued.

Stage 5: Deployment

The predicate enters production. Queries can now filter by puffy > 0.7:

Query: "puffy dresses under $200"
Constraints: [puffy(d) > 0.7, price(d) < 200, category(d) = "dress"]
Predicate receipts: [AdmissionReceipt(puffy) ✓, ...]

Stage 6: Monitoring

After deployment, the system monitors for drift:

DriftMonitor(puffy) = {
  calibration_check: weekly,
  last_check: 2026-01-22,
  exemplar_scores: [within margin],
  result: STABLE,
  
  revalidation_triggers: [
    "3d_model_service version change" → recheck operationality,
    "calibration drift > 0.1" → recheck discrimination
  ]
}

Stage 7: Revision

User feedback arrives: "Why are some ruffled dresses showing up?" Investigation reveals the intension needs refinement: volume from tulle/organza/layering, explicitly excluding ruffles and quilting.

The revised predicate is puffy_v2. Compatibility check:

CompatibilityTest(puffy_v1, puffy_v2) = {
  v1_positives_under_v2: all still positive ✓
  v1_negatives_under_v2: all still negative ✓
  confounders_under_v2: rejected more strongly ✓
  
  compatibility_class: "refinement"
  witness: ∀x. puffy_v2(x) > 0.7 ⇒ puffy_v1(x) > 0.5
}

puffy_v2 is a refinement: stricter, not looser. Items satisfying puffy_v2 also satisfy puffy_v1. The reverse is not guaranteed.

VersionWitness = {
  from: puffy_v1, to: puffy_v2,
  direction: "refinement",
  transport: { v2_to_v1: conservative, v1_to_v2: approximate (requires review) }
}

This is T9 (Schema Evolution) resolved: predicate change with explicit compatibility witness. No silent drift. No broken queries.

What Rejection Looks Like

Not every proposal passes. Consider "stylish":

ProposedPredicate: "stylish"
Exemplars: { positive: [SKU_X, SKU_Y, SKU_Z], negative: [SKU_W], boundary: [], confounders: [] }

Check 1 (Discrimination): Positive scores [0.72, 0.68, 0.81]. Negative score 0.54. With τ_low=0.4, τ_high=0.6, the negative item is in the gray zone, not clearly rejected. FAIL.

Check 2 (Abstain Coverage): no_abstain_zone claimed without justification. No boundary exemplars. FAIL.

Check 3 (Confounder Rejection): No confounders provided. FAIL.

RejectionReceipt(stylish) = {
  rejected_as: "predicate",
  failing_checks: [
    { check: "discrimination", reason: "negative exemplar in gray zone" },
    { check: "abstain_coverage", reason: "no_abstain claimed without justification" },
    { check: "confounders", reason: "none provided" }
  ],
  
  alternative_standing: "preference_signal",
  alternative_contract: {
    type: SoftPreference,
    usage: "ranking boost, not hard filter",
    requirements: ["user attribution", "no global claims", "display as suggestion"]
  },
  
  remediation_if_predicate_desired: [
    "Add boundary exemplars for 'somewhat stylish' items",
    "Provide confounders from at least 2 subclasses",
    "Narrow scope: 'stylish_for_cocktail' may be tractable"
  ]
}

"Stylish" is not rejected as meaningless. It is routed to a different standing. Preference signals have different obligations than predicates: they can influence ranking but cannot be hard filters, they carry user attribution, and they make no global claims. The system offers a path forward, not just a gate.

Partial Backfill and Undefined Semantics

A predicate admitted to context U makes no claims about items in context V where U ∩ V = ∅. This is the partial backfill rule:

q is admitted to U.
Item r exists in V where V ∩ U = ∅.

q(r) = undefined (not false)

Why this matters: Without this rule, predicates silently return false on items they were never designed to classify. "puffy" was built for fashion; applied to furniture, it should return undefined, not false.

How undefined behaves:

Queries must handle undefined explicitly. Unknown items do not silently appear or silently vanish.

Promotion

Admission is local. Promotion widens scope. The checks are different.

Promotion is not automatic. A predicate that works in one context may conflict with another. The system produces obstruction artifacts when promotion fails, with the same remediation spirit as A28's sense obstructions.

Consequence

T6 is resolved. Predicate invention is safe when gated by acceptance tests.

The Third Mode does not prevent invention. It makes invention accountable. A predicate ships with exemplars, invariants, scope, and versioning rules. These are not documentation; they are machine-checked obligations that gate admission and track evolution.

The buyer who searched "puffy dresses" can now filter by puffiness. The predicate that enables this filter has a receipt. The receipt says: here are the exemplars that ground it, here are the confounders it rejects, here is the scope where it is valid, here is how it can change.

When someone asks "why did puffiness return these results?", the system can answer. When someone proposes "stylish" and it fails, the system explains why and offers alternatives. When puffy_v1 evolves to puffy_v2, the compatibility witness says what changed and what still holds.

Predicates are citizens with papers. A29 is the immigration office.

Chapter 28 takes up T7: Contextual Equivalence. When are two things the same? The answer is: sometimes, in some contexts, for some purposes. A30 formalizes scoped equivalence.