Predicate Packages

A measurement can survive its original session and still become difficult to interpret. In the hypothetical catalog, “puffy” is evaluated by dividing an item's volume ratio by a maximum taken from a reference set. The formula can remain unchanged while the reference set grows. Someone consulting the old score then needs more than the evaluator's name: which population supplied its denominator?

After the Session

The same question follows the predicate into a colleague's query. The colleague may use the old definition, revise it or ask to apply it more widely. To make those choices intelligible, the record must preserve what produced the earlier answer and which uses were admitted. If it retains only a current name and formula, the colleague must reconstruct the missing history or obtain new grounds. A maintained runtime and version record can preserve the distinction, whether it uses this package or another adequate representation.

Chapter 15 established the proposed admission obligations. A24 now specifies what travels with the admitted predicate: a seven-part package joining the definition to its execution conditions, evidence and scope. Its purpose is to keep the grounds available after the people who performed the first check have left the inquiry.

Anchor A24: Predicate Package

The proposed admission contract makes the package mandatory and specifies how its claims are checked. Documentation can also be mandatory and validated; the distinction is the obligation this contract enforces. A21 records the resources assigned to admission, promotion and versioning. It does not derive their cost from the name of the standing requested.

The package is the predicate's citizenship papers. It records what the predicate claims to do, how it does it, what evidence supports it, what constraints it promises to satisfy, who authorized it, and where it is valid. The recipient must be able to inspect the supplied evidence and perform the checks its contract requires; some claims also require evidence beyond the package.

Invariants: package vs substrate. Package invariants are claims about q (what the predicate promises). Substrate invariants are constraints in U (what the context requires). Admission checks both.

Substrate representation. A predicate package is represented in the context graph (A22) as a structured claim bundle, not a sixth node type. The predicate itself is an opaque entity token. The package components are claims about that token, supported by witness nodes (test results, calibration witnesses, authority attestations), constrained by constraint nodes (external invariants), and scoped to the admitting context via scoped_to edges. This keeps A22's five node types intact. A24 is a schema for organizing claims about predicate-tokens, not an additional node type.

The Proof-Carrying Paradigm

The paradigm is borrowed from Necula's Proof-Carrying Code¹: mobile code ships with a proof; the host verifies locally without trusting the sender. The host checks a proof against a specified safety policy and trusted checking basis. A predicate package borrows the separation between producing grounds and examining them, while retaining mathematical proof, statistical evidence and attestation as different warrants.

A recipient cannot accept arbitrary claims merely because the sender packages them. A supplied proof may spare it the work of discovery, but verification cost depends on the proof system and obligation. Running tests or checking a population can require work beyond the package’s length. A21 records those requirements rather than promising a universal linear validator.

The package can contain mathematical proofs as well as tests or attestations. Its admission record states which checks were completed under the receiving contract. The verifier is explicit:

Verify(q, U) → Valid | Invalid(reason) | Inconclusive(obligations):
  1. Type-check σ against substrate type system
  2. Check ι is evaluable with ρ in U (dependencies available, inputs present)
  3. Run ι under ρ on witness set τ; check the declared comparison and all applicable A29 discrimination, confounder and abstention requirements
  4. Check q against I_hard in U (package invariants + substrate constraints)
  5. Check authority chain in π permits admission to U
  6. If promotion: check agreement contract on overlap items
  7. Complete the remaining A29 operational and compatibility checks, including latency and cost budgets
  
  Return Valid only if all required checks pass.
  Return Invalid with evidence of a decisive failure, recording checks not run.
  Otherwise return Inconclusive with the unfinished obligations and reason.

Evaluation on τ contributes O(|τ| · C_eval(ρ)) when C_eval bounds each exemplar evaluation. Invariants, authority, dependencies and any promised generalization require their own checks; some may reach beyond τ. A21 budgets the declared procedure. A finite test suite cannot certify arbitrary inputs, and a wider scope does not determine a universal exemplar count or cost ordering.

The Witness Criterion (by Agreement Contract)

The witness criterion in acceptance criterion 3 depends on the agreement contract type:

For decidable predicates (Bool codomains), the criterion is strict: the evaluator must correctly classify every exemplar. For the displayed calibrated criterion, the difference between the group means must reach ε after the stated transform. That does not establish that every positive outranks every negative; a use requiring that stronger separation must check it. For learned predicates, the criterion requires both calibration and error bound witnesses.

This makes "witnessed" concrete rather than handwavy. The substrate checks a well-defined condition, not a vague "sufficient exemplars."

The Seven Components

Signature ($\sigma$). The signature declares the predicate's type: what it takes as input, what it returns, and how values from different evaluations are reconciled. For "puffy," the domain is Dress, the codomain is Score (a real number in [0,1]), the arity is 1. The agreement contract specifies how to handle disagreement: for Score predicates, the contract is typically calibrated(ε), meaning two evaluations agree if they are within ε of each other after a monotone calibration transform.

The agreement contract is part of σ because it determines glue semantics. When the substrate attempts glue(cover, target) (A22), it retrieves the agreement contract and runs the appropriate comparison. The contract determines an operational comparison. Only the exact case with the required sheaf hypotheses inherits A13’s unique-gluing guarantee; tolerant comparison or voting does not supply it.

Intension ($\iota$). The evaluation method may be a rule, a measurement, an oracle or a learned function. A17's local-grounding account develops their different evidentiary requirements. The package identifies which method was used and retains what interpreting its result requires. For the toy measurement, the reference set, positive denominator and domain bound belong with the formula. An oracle's judgment retains its attribution; a learned evaluation retains its model, calibration and stated error evidence. Neither becomes transparent merely because the package has a field for it.

Runtime spec ($\rho$). The runtime spec prevents "same predicate name, different code path." It contains:

RuntimeSpec {
  evaluator_id: hash of evaluation code or model weights,
  dependencies: [(predicate_name, version, hash), ...],
  required_inputs: [feature_name, ...],
  determinism: Deterministic | Stochastic(seed_policy) | External(oracle_id)
}

Reproduction requires the relevant environment as well as code, weights and inputs: dependencies, configuration, stochastic state and any external service must be pinned or their variability specified. A hash binds an identified artifact; it does not establish that the runtime record is complete or that another system has reproduced the result.

Tests ($\tau$). The witness set grounds the predicate's meaning. For "puffy": five dresses labeled high-puffy (score > 0.7), five labeled low-puffy (score < 0.3), each with provenance. The test set also includes boundary cases (items where the label is disputed) and confounders (items that might fool a naive evaluator, like a voluminous coat that is not a dress).

The declared agreement contract determines how these exemplars are assessed. The receiving use may require a stronger comparison than the package supplies.

Invariants ($I$). The package carries two kinds of invariants:

Internal invariants: constraints the predicate promises to satisfy. For "puffy": puffy(d) ∈ [0,1] for all d; puffy is monotone with respect to volume_ratio.

External invariants: constraints the substrate requires. Predicates must be conservative with respect to existing vocabulary (A17b). Learned predicates must carry calibration witnesses.

Admission checks both kinds in the admitting context. Package invariants are claims about q; substrate invariants are constraints in U.

Provenance ($\pi$). Who invented this predicate? When? Under what authority? With what derivation?

Provenance {
  author: "user_session_42",
  timestamp: "2024-01-15T10:30:00Z",
  authority: user | org | system | regulator,
  derivation: "measurement_from_volume" | "rule_composition" | "model_training" | ...
}

Authority levels constrain what you can claim. A user-level predicate cannot assert system authority. Promotion to higher authority requires additional approval.

Scope ($S$). Where is this predicate valid? A predicate starts local. It is admitted to a specific context, not to the entire substrate.

Scope {
  admitting_context: user_session_42_view,
  promotion_path: [user → org → global],
  current_standing: local
}

Globality is a promotion outcome, not a creation-time attribute. The predicate must earn broader scope by passing promotion criteria.

Intension Types and Their Obligations

Different intension types have different validation requirements and different constraints on scope widening (rebase).

A short rule can depend on expensive observations. An oracle may already serve the target context. The intension identifies what needs examination; it does not by itself rank the cost or difficulty of that examination.

This is where T9 (schema evolution) bites. Learned predicates are especially prone to drift because the model changes. When you retrain, you get a new evaluator_id. The package makes this visible; without it, the drift is silent.

T6: Puffy Dress (Full Package)

PredicatePackage(puffy) = {
  signature:   Dress → Score, calibrated agreement
  intension:   volume_ratio / max_volume_in_reference_set  // positive denominator; declared domain bounded by it
  runtime:     deterministic evaluator, pinned dependencies
  tests:       positive, negative, boundary, confounder exemplars
  invariants:  score ∈ [0,1], monotone w.r.t. volume, conservative extension
  provenance:  author, timestamp, authority level, derivation method
  scope:       admitting context, promotion path [user → org → global]
}

A later query can now identify the definition it used and the conditions under which the displayed results were obtained. It must still distinguish what those results establish: a mean-separation result, a pointwise exemplar check and a population error bound support different conclusions.

These five package checks establish well-formedness, evaluability, the declared witness comparison, invariant satisfaction and authority within scope. Full admission also requires all applicable A29 checks, including its pointwise discrimination, confounder, abstention, operational and compatibility requirements, specified in Appendix I, Operation 8. A package that exceeds its latency budget has not passed that gate even if these five conditions hold.

The admitted package can be queried and versioned, and can seek promotion under the additional gates. The contract requires changed definitions to receive new versions and adequate grounds. An implementation must enforce that requirement; the record’s existence cannot prevent an undeclared substitution.

T9: Schema Evolution

The reference set changes. New items enter the catalog. The max volume in the new catalog is larger than before.

Version 1: puffy_v1 uses reference_set catalog_v3_2024Q1. Max volume: 1200 cubic units. Version 2: puffy_v2 uses reference_set catalog_v4_2024Q4. Max volume: 1500 cubic units.

A dress with volume 900 cubic units:

• Under puffy_v1: score = 900/1200 = 0.75
• Under puffy_v2: score = 900/1500 = 0.60

Same formula. Same dress. Different scores. Same name would mean different things.

If the receiving operation keeps neither the reference version nor an adequate change record, the current formula cannot explain the old score. The threshold result can change even when both evaluations correctly apply their respective denominators.

With packages, the drift is explicit. puffy_v2 is a new package with a different reference_set binding. The evaluation code, and hence its code hash, may remain unchanged. The system computes a compatibility witness:

Is puffy_v2 ⪯ puffy_v1? That is: does puffy_v2(d) ≤ puffy_v1(d) for all d in the overlap? For the same nonnegative volume numerator and these positive denominators, yes: division by 1500 gives no larger value than division by 1200. This pointwise inequality does not preserve an unchanged threshold query. The illustrated dress passes 0.7 under v1 and fails it under v2. A sampled comparison elsewhere would establish only its tested cases unless additional evidence supports the wider inference.

The version(q, Δ) operation emits a migration artifact:

MigrationWitness(puffy_v1 → puffy_v2) = {
  compatibility: refinement (v2 ⪯ v1),
  change: { reference_set: "catalog_v3_2024Q1" → "catalog_v4_2024Q4" },
  affected_invariants: ["puffy > 0.7" thresholds shift downward],
  consumer_action_required: true,
  options: [
    "translate_threshold: prove and approve the conversion for each affected query",
    "pin_version: continue using v1 with frozen reference_set",
    "fork: maintain both versions with explicit scope separation"
  ]
}

The substrate does not choose. It surfaces the options with their costs (A21). The consumer chooses. But the choice is recorded, witnessed, and auditable. Silent drift is replaced by governed evolution.

Lightweight Admission: The Tag That Becomes a Citizen

The seven-tuple package is the full specification. But users do not arrive with seven-tuples. They arrive with gestures: "tag this as cool," "mark these as similar," "call this puffy." The system must bridge the gap.

When a user tags an item, the system infers a provisional package. The inference is explicit, not magical: the system applies defaults, records what it assumed, and marks the result as requiring verification before promotion.

PredicatePackage(cool) = {
  signature: {
    domain: Item,
    codomain: Bool,
    arity: 1,
    agreement_contract: decidable  // tagged or not
  },
  intension: Extension {
    type: "explicit_membership",
    members: [dress_A, dress_B, dress_C]
  },
  runtime: {
    evaluator_id: "membership_check",
    dependencies: [],
    required_inputs: [item_id],
    determinism: Deterministic
  },
  tests: {
    positive: [dress_A, dress_B, dress_C],  // the tagged items
    negative: [],                            // none declared
    boundary: [],
    confounders: []
  },
  invariants: {
    internal: [],
    external: [conservative_extension]  // default
  },
  provenance: {
    author: "user_session_87",
    timestamp: "2024-01-20T14:22:00Z",
    authority: user,
    derivation: "auto_inferred_from_tags"
  },
  scope: {
    admitting_context: user_session_87_view,
    promotion_path: [user → org → global],
    current_standing: local  // usable in session, pending verification for promotion
  }
}

The auto-inferred package has gaps. No negative exemplars. No invariants beyond the default. No calibration. These gaps are not hidden; they are recorded in the package and reflected in the promotion requirements.

Promotion requires filling the gaps. To promote "cool" from local to org level, the system requires at least one negative exemplar. For promotion beyond the checked membership list, this profile requires a rule or procedure that supports the new cases, with its boundary treatment. Membership itself is already a defined evaluation method. The package grows as the predicate's standing grows.

This is the Third Mode's answer to the cold-start problem. Users can gesture informally. The system interprets their gestures as provisional packages. Provisional packages are usable within their session but do not escape without earning their citizenship. The barrier to entry is low; the barrier to promotion is appropriate to the standing claimed.

The membership predicate means "belongs to this recorded list." That can be sufficient for a useful local collection. It does not establish a general criterion of coolness, and carrying the label into a filter for unseen items requests different grounds. The proposed promotion gate concerns that new reliance, not whether the earlier collection had meaning.

Rebase and Versioning

Admission is the first operation. A package proposes to enter a context. The substrate checks every applicable admission criterion and returns Admitted, Rejected(reason) or Inconclusive(obligations). A decisive rejection may stop further work; its receipt identifies checks not run.

Rebase is scope widening. A predicate admitted in context U wants standing in context V. The operation rebase(q, U→V, π_widen) checks promotion criteria:

• Does q satisfy hard invariants in V? (Promotion-invariant)
• Does the requester have scope-appropriate authority? (A21 budget applies)
• If U and V overlap, does the agreement contract hold on shared items? (Overlap agreement)

Rebase respects intension type. Retraining is neither universally necessary nor sufficient for use in another domain. The receiving task requires relevant validation and applicable authorization. The substrate enforces this: the promotion-invariant check asks whether the evaluator is valid in the target context.

Versioning is evolution over time. A predicate changes: new tests, new reference set, retrained model. The operation version(q, Δ) produces a new package.

If the change preserves the declared uses under A26, the system records the compatibility evidence and the permitted update. Calling a version a refinement or extension does not establish preservation. Unfinished compatibility checks remain explicit.

If the change is breaking (the new version is incompatible with the old), the system requires migration witnesses (A17b). Downstream consumers must acknowledge the breaking change, by an authorized migration, a still-supported pinned version or another justified course. A pin preserves an identity; it cannot restore withdrawn evidence.

Rebase vs version: disambiguation. Rebase keeps the evaluator fixed and widens scope. Version changes the evaluator (or its inputs) and may or may not be promotable.

• puffy admitted in user_session_42_view → rebase(puffy, user→org, π_widen) widens scope with governance approval. Same evaluator, broader standing.
• puffy_v2 created because reference_set changed → version(puffy, Δ) produces a new package with the changed dependency recorded. The receiving threshold query needs the migration account even if the evaluator’s code hash is unchanged.

A wider organizational use may introduce additional obligations and witnesses. Their cost depends on what can be reused, what changes and what must be checked. Under an unchanged schedule, adding nonnegative charges increases the sum; a change of standing does not by itself specify that schedule. A21 makes the proposed expenditure available for examination.

Agreement Contracts and Gluing

When a predicate is evaluated in multiple contexts, the results must be reconcilable. The agreement contract specifies how.

For decidable predicates (Bool codomains), agreement means exact equality. Either the predicate holds or it does not.

For calibrated predicates (Score codomains), agreement means values are within ε of each other after calibration. If merchant A scores a dress at 0.8 and merchant B scores it at 0.75, they agree if calibration shows their scales are monotonically related and the difference is within tolerance.

For majority-attested predicates, the contract may choose the majority label. Two votes against one select an outcome; they do not establish agreement among the voters or the outcome’s correctness.

A probabilistic-bound contract may compare stated intervals, provided their quantities and coverage interpretation match. Overlap is not evidence of equality, is not transitive, and does not by itself constitute a test of agreement at a stated error rate. The intervals 0.7 ± 0.1 and 0.65 ± 0.1 overlap; any stronger inference requires a specified procedure.

An implementation must supply the comparison procedure its agreement contract requires. When the substrate attempts glue(cover, target) (A22), it retrieves the agreement contract from each predicate's package and runs the appropriate comparison. A calibrated predicate triggers calibration witness lookup. A probabilistic-bound predicate triggers confidence interval computation. The contract determines an operational comparison. Only the exact case with the required sheaf hypotheses inherits A13’s unique-gluing guarantee; tolerant comparison or voting does not supply it.

Mismatched contracts block gluing. If merchant A's "sustainable" uses decidable (Bool) and merchant B's uses calibrated (Score), the overlap check fails before values are compared. The types disagree. The substrate emits an obstruction witness naming the contract mismatch, not the value disagreement. This blocks the unqualified comparison. A justified threshold or other map could make the values comparable for a specified purpose; the contract mismatch does not prove that no such map exists.

What Packages Prevent

Enforced package contracts address three failure modes:

Drift. Meaning changes silently. The reference set updates, the model retrains, the oracle changes their mind. The version record makes a declared change inspectable; detection of an undeclared change requires additional observation and enforcement.

Escape. Scope expands silently. A user-level predicate becomes org-wide because someone copied it. Copying the package does not discharge the receiving scope's promotion criteria.

Forgery. Same name, different runtime. Two systems evaluate "puffy" with different code paths and get different results. The evaluator_id identifies the declared runtime. Checking that identity can expose a mismatch; it does not prove that the reported execution occurred as described.

Consequence

The package gathers the definition, its runtime and the evidence a later operation would otherwise have to recover separately. Its usefulness lies in keeping those dependencies examinable when the name is reused.

The package carries grounds that the receiver can examine. Some checks are mathematical, some statistical, and some depend on an authority whose assertion the receiver accepts. Passing admission establishes the declared scope. Demonstrated failure and unfinished checking retain different outcomes.

Reusable grounds can spare another operation work. The package must also show where that saving ends: a changed purpose, an uncovered population or a withdrawn witness may require new evidence. The cost belongs to the checks actually needed, not to the prestige of a wider standing label.

Chapter 23 asks what a query promises when it runs against this substrate. A query is also a contract: it declares what contexts it references, what predicates it uses, what witnesses it requires, and what uncertainty it tolerates. The predicate package is one half of the contract. The query contract is the other half.