An evidence-based ML constraint and admission plane¶

Research date: 2026-09-21 Status: research recommendation; proposed semantics, not an approved design or implemented contract.

Recommendation¶

Build a small contract compiler, an evidence evaluator, and a transactional permit ledger. Connect them with immutable identities and decision receipts. Product evaluators own measurements; the gateway owns transport; the backend owns execution. The platform decides whether a particular operation is qualified and can acquire its declared resources.

The opportunity is to make qualification and resource admission compose predictably. A request should carry a verifiable reference to why its artifact and operating mode are eligible, acquire capacity atomically, and produce one bounded explanation of the resulting decision. Novelty lies in this integration and its developer experience; partial evaluation, attestations, leases, and constraint intersection are established techniques. This review does not establish research novelty or that any implementation is universally best.

Starting points are constraint enforcement patterns, data-contract standards, and the serving landscape. The accompanying implementation evidence probes the stateful candidates.

Open source foundations and what to borrow¶

Foundation	Established capability	Design inference for this platform
CUE	Values and constraints compose by unification; contradictory values are inconsistent.	Make composition order-independent and narrowing-only. Start with intervals, enums, and typed predicates; CUE need not become a runtime dependency. Source
OPA	Partial evaluation resolves known inputs and leaves conditions over unknown inputs; bundles distribute policy and data.	Resolve artifact qualification outside serving and distribute a versioned plan containing the remaining request checks. Partial evaluation, bundles
Cedar	Schema validation detects policy errors before evaluation; authorization returns determining policies and errors. Its runtime skips erroneous policies.	Validate aggressively, preserve rule-level explanations, but explicitly block when a required ML gate is unknown or erroneous. Cedar's error semantics are not the proposed gate semantics. Validation, authorization
TFMA	Absolute and baseline-relative metric thresholds support model validation, including slices.	Keep statistical qualification in specialist evaluators and carry their typed evidence into the platform. Source
in-toto	Statements bind typed predicates to immutable subjects identified by digest.	Bind qualification evidence to exact artifacts; use an in-toto predicate for interchange if needed. A signature authenticates a claim's producer, not its scientific validity. Source
Kueue, Limitador, Envoy	Respectively provide workload admission patterns, reservation groundwork, and gateway enforcement mechanisms.	Borrow lifecycle separation and integration points; verify transactional and execution guarantees independently. See the source-level evidence.

These are complementary precedents. Adopting all of them would enlarge the operational surface without establishing the required end-to-end guarantee.

Three deep modules¶

Capability contract + deployment policies
                    |
                 compile
                    |
           immutable effective plan
                    |
stage measurements -> evaluate -> qualification receipt
                                      |
trusted request + selected mode -------+
                                      |
                           validate + atomic admit
                                      |
                            permit -> execution
                                      |
                               renew / finish

Contract module: compile capability and applicable policies into an immutable plan, then evaluate typed evidence against it. The interface hides normalization, unit checking, compatibility, applicability, cumulative checks, provenance validation, and deterministic explanations.

Admission module: admit(intent), renew(permit, progress), and finish(permit, outcome, cumulative_usage). The interface hides all-or-none reservations, idempotency, leases, budget accounting, and terminal-state reconciliation. Cancellation is a finish outcome, not permission to release capacity while execution continues.

Product adapter: produces measurements, selects an authorized operating mode, executes work, and reports progress. It must enforce permit requirements at dispatch and during long work. An HTTP gateway adapter can help with this but cannot guarantee backend cancellation by itself.

Initially these can be packages in one deployable with one authoritative transactional store. Static plans can be loaded from ordinary versioned configuration. A dedicated policy-distribution service, Kubernetes operator, plugin marketplace, and universal scheduler are unnecessary initially.

Advance 1: Compile qualification into a small request-time check¶

Separate evidence by what can invalidate it:

Artifact evidence: immutable measurements tied to the exact snapshot, model, preprocessing, evaluation protocol, and evidence-schema versions. Reusing them requires matching those identities.
Changing evidence: health, monitoring, authorization, and operational eligibility, with explicit freshness and version requirements.
Request facts: scope, selected mode, request shape, and authenticated descriptors.
Capacity state: reserved and consumed resources, checked transactionally at admission.

A qualification receipt records the artifact digest, full Commerce Scope, mode, effective-plan digest, evaluator version, evidence references, per-check results, and any expiry. Immutable artifact evidence need not arbitrarily expire; evidence about the current environment must. Protect receipts through trusted storage first; sign them when crossing independent trust domains.

The gateway validates the receipt's identity, current eligibility, and residual request conditions. It does not fetch merchant data or recompute data-quality metrics. A changed policy invalidates the receipt's policy binding, but compatible retained aggregate evidence can be evaluated again without retraining. An atomic eligibility generation at admission prevents a concurrent policy activation from admitting against an obsolete generation. Existing work follows an explicit drain or revocation policy; a distributed cache cannot promise instantaneous revocation without coordination.

This is a bounded application of partial evaluation, not a general compiler. Begin with fixed check categories and explicit evidence dependencies. Preserve the original rules behind normalized bounds so explanations still identify their authors and versions.

Advance 2: Qualify a few operating modes¶

One binary "model eligible" flag is too coarse when different operations require different evidence or resources. Define a small product-owned set of modes, each with its own qualification conditions, request limits, resource charge, and observable result contract.

For this repository, candidates could include bounded personalized reranking and an explicitly permitted snapshot-only operation. They remain distinct from Recommendation Strategy and Fallback Strategy, whose existing meanings must be preserved. A failed prerequisite for one mode never establishes another mode's eligibility automatically.

Each request names the selected mode and any product-authorized alternatives. Initially admit one mode at a time. A later bounded ordered list can support deterministic degradation, with one transaction selecting and reserving the first feasible qualified mode. The platform does not learn routing preferences or silently change product semantics.

This exposes a useful operating envelope: the combinations of artifact, scope, request bounds, and mode for which there is evidence. It also makes overload behavior explainable: "personalized mode lacks capacity; the requested snapshot-only alternative is qualified and admitted."

Advance 3: Make policy composition mechanically understandable¶

For a fixed scope, mode, and compatible measurement definition:

effective allowed values = capability values ∩ every applicable policy's values

Compile bounded intervals and allowed sets; retain unlike predicates cumulatively. Reject empty intersections, inconsistent units, unknown operators, unsupported schema versions, and unauthorized relaxation attempts. A policy that declares a wider bound would be redundant under intersection, but rejecting its misleading declaration is a useful authoring rule.

Tightening must account for applicability and evidence requirements too: removing a protected scope, lengthening evidence freshness, weakening an effect, or allowing a previously forbidden mode can relax behavior even if the numeric threshold tightens. Keep the supported language small enough to analyze these changes. Do not claim a complete implication checker for arbitrary expressions.

Operational policies may be rolled back to a less restrictive approved version while remaining inside immutable capability bounds. Monotonicity applies to combining protections, not necessarily to every successive operational policy version.

Separate measurement status (known, missing, stale, incompatible, error) from check result (pass, fail, unknown, not_applicable). Unknown required evidence blocks the corresponding gate. Diagnostics can warn without granting eligibility. Stage-specific actions remain outside the pure comparator.

Statistical evidence needs population, time interval, sample size, method, and uncertainty where appropriate. A measured embedding-success fraction needs its precise numerator and denominator; a zero denominator is not success. An estimate of future performance is different from an exact fraction over a completed artifact. Drift evidence is not proof of degraded recommendation quality. Specialist libraries already handle statistical concerns such as multiple-testing correction; retain those semantics rather than inventing a generic threshold substitute. Alibi Detect example

Advance 4: A small ledger with explicit guarantees¶

Resources require different accounting despite sharing one transaction:

Resource	On admission	On completion
Request rate	Consume from a specified window or bucket	Usually no refund; retain abuse-control semantics
Weighted concurrency	Hold capacity	Release after confirmed termination or an enforceable execution deadline
Usage budget	Reserve a justified amount	Charge cumulative actual usage once and release the unused reservation

Reserve all matching scope and pool limits together. Store an opaque operation identity, normalized intent digest, policy generation, exact counter identities, reserved vector, sequence, and outcome in the same authority as the counters. Repeated admission with the same identity and intent returns the original result; a different intent conflicts. Duplicate identical terminal operations return the saved result; conflicting terminal operations never apply a second charge.

Keep a bounded retry window and reject expired operation identities after tombstone retention ends. Otherwise bounded retention allows an old retry to become new work. Gateway/backend deduplication is also necessary: idempotent admission does not by itself make inference execute only once.

Renewal uses monotonic sequence numbers and cumulative usage. It can acquire more budget before more work occurs, subject to a maximum lifetime. Finishing after a timeout can reconcile late usage without creating a second release. Preserve original accounting identities across policy updates; settlement cannot rediscover them from whichever policies are current.

Two guarantees need special care:

Lease expiry does not terminate computation. A stale worker may still run. To bound real concurrency, enforce termination before recycling capacity, retain an uncertain hold, or use a proven execution-time ceiling. Fencing can prevent stale dispatch or writes only where checked; it does not reclaim a GPU executing an uninterruptible kernel.
An estimate is not a hard budget reservation. A hard usage cap requires an enforceable upper bound or incremental authorization before consumption. Otherwise advertise an accounting limit with explicit overshoot behavior. Post-response token accounting cannot undo spent tokens.

State the failure model. An atomic Redis script does not establish durable admission across failover; Redis documents asynchronous replication and potential loss of acknowledged writes. Hard limits require an appropriately durable authority and failover protocol, or explicit bounded-loss semantics. Redis replication, Sentinel

Make enforceability a compile-time requirement: an execution adapter declares whether it supports bounded termination, incremental usage authorization, and duplicate-dispatch prevention. Reject a deployment that requests a hard guarantee its adapter cannot provide. This makes the platform's own guarantees subject to the same discipline as model capabilities. Start with a fixed capability record checked at deployment; a general plugin negotiation protocol is unnecessary.

Advance 5: Explain and simulate policy changes with the same semantics¶

Every decision returns a bounded receipt: allowed mode or rejection, blocking rule IDs, safe observed/expected values, missing evidence, artifact/plan identity, and reservation outcome. Full trusted evidence remains access-controlled; public diagnostic projections are audience-safe. Do not expose internal capacity or other scopes through diagnostic detail.

The same pure evaluator supports policy previews: what artifact qualifications change under a new policy, which constraints conflict, and what additional evidence is needed. With interval checks, explanations can identify conflicting bounds without a SAT solver.

For stateful behavior, replay requires ordered synthetic arrivals, durations, resource demand, and an explicit alternative capacity model. Re-evaluating independent historical decisions cannot predict a changed queue or contention trajectory. Use the Commerce Simulation Harness for controlled scenarios and bounded derived evidence; do not retain raw interaction rows or Shopper identifiers.

Shadow evaluation never reserves real capacity or executes a second model. Start with qualification and decision differences; add contention simulation only when the input evidence supports it.

Distribution, fairness, and simplicity¶

Start with one admission cell. All dimensions of a hard atomic admission must share one transactional authority. Commerce Scope isolation remains mandatory for model evidence; shared capacity accounting may aggregate resource charges without combining model evidence or exposing another scope's data.

If cells become necessary, preallocate disjoint budgets whose sum is bounded by the parent budget. Transfers require draining or fenced ownership changes. Unused capacity can be stranded; accepting that cost is simpler than pretending a global hard counter can remain fully available during a partition. Rate allocations additionally require explicit window/refill semantics. Defer elastic borrowing until measurements justify it.

Immediate rejection plus explicit retry is the smallest initial overload behavior. Priority labels and quotas alone do not guarantee fairness or prevent starvation. If guaranteed shares and borrowing become requirements, use a bounded scheduler with a declared fairness policy; batch workloads can use Kueue rather than duplicating a cluster scheduler inside this platform.

Build-versus-adopt revision¶

The previous landscape recommends adapting Limitador first. Source inspection raises the bar: reservation and settlement are distinct correctness problems, and a separate idempotency table cannot atomically repair partial charging in another store. Treat Limitador as a candidate whose internals must pass the same conformance suite as an owned ledger, rather than assuming a thin wrapper is sufficient. The implementation evidence records the specific paths and limitations. This is a new research recommendation, not a silent edit to the earlier note.

Reuse Envoy integration where already operationally useful. Adopt ODCS as an interchange adapter only when a real consumer requires it. Keep serving_limits independent of recommendations; product-specific measurements and mode selection enter through adapters. Do not add a new language, database, or runtime solely because an inspiring upstream project uses one.

Smallest convincing delivery and proof¶

Qualification slice: fixed checks, one capability contract, one deployment policy, one Recommendation Snapshot receipt, deterministic diagnostics, and publication gating. Rejection preserves the last successful serving head. No new standalone platform deployment is required.
Admission slice: one cell, one mode, one rate rule and one concurrency hold, atomic admission, retry-safe finish, and an enforced execution lifetime. Reuse an existing transactional store if measured latency and contention allow it; select alternatives through the same conformance tests.
Integrated slice: bind permit, artifact, scope, mode, and policy generation; reject stale receipts; requalify from compatible evidence after policy changes. Add one explicit cheaper mode.
Only as justified: budget reservation, renewal, statistical adapters, external gateway, bounded fairness queues, and multi-cell budget allocation.

Define release evidence before calling the platform state of the art:

Property checks for order-independent composition, no capability relaxation, scope isolation, unknown-evidence handling, and equivalence of full versus precomputed evaluation.
A reference state machine and adversarial histories covering duplicate admission, conflicting payloads, lost responses, crashes during finish, expiry/renew races, late usage, policy activation, failover, and worker execution after permit expiry.
Conservation checks per resource type; no partial acquisition, double charge, or premature release.
Comparison with the same backend protected by the simplest limiter: incremental p50/p95/p99 latency, sustainable throughput, hot-scope contention, memory per outstanding operation, cleanup cost, and recovery behavior. Set budgets against the product SLO before implementation; no latency or scale claim is established by this research.
Operational measurements of explanation usefulness and integration effort, plus bounded-cardinality diagnostics and evidence-retention checks.

The distinguishing result should be a developer who can answer, from one receipt: what is this operation qualified to do, why was this mode selected, which capacity was acquired, and what happens under retry or failure? Keeping those answers exact is more valuable than a larger rule language.

Handoff¶

Objective/state: research complete; recommendation ready for discussion, not implementation approval.
Authority: existing product specifications and CONTEXT.md remain unchanged; proposed terms here are provisional. No deployments, hosted changes, external mutations, or source changes authorized.
Changes: this note and the companion implementation-evidence note only; pre-existing work preserved.
Validation: primary-source browsing, local document reads, new-file diff/whitespace inspection. Application, migration, and performance tests not run because no executable behavior changed.
Next work: agree on required hard guarantees and target latency, then produce an implementation design and conformance spike with explicit backend failure assumptions.