From Frozen Policy to a Real Model Call

This chapter follows one Experiential request across two boundaries: the learned router that selects among fit-time model identities, and the gateway that decides whether and how a provider call may occur. The focus is what survives from offline optimization when the request arrives with its own capabilities, identity, budget, and continuity requirements. The reader should be able to trace feature extraction, sticky selection, authorization, capability checks, certified fallback, reservation, settlement, and content-free accounting as one operating path.

A learned choice is still an untrusted runtime input

A policy name alone is not enough to activate a learned router. The policy was fitted against a particular evidence plan, bank, feature schema, pricing snapshot, candidate set, and embedder. If the runtime were to resolve “the same” aliases from a mutable catalog and proceed, it could produce a decision that looks like the fitted policy's output while actually using different models, prices, or feature semantics.

Experiential therefore activates the router as a bundle of identities. The sealed bank, policy, pricing snapshot, feature extractor, candidate aliases, and embedder snapshot must agree with the fit-time material. The runtime checks that the bank content and its manifest match the policy, that the candidate order and pricing candidates match, and that the feature implementation has not drifted. A mismatch is an integrity failure, not an invitation to guess which current object is close enough.

This is the online counterpart to the immutable evidence graph. Offline content addressing answers, “What evidence produced this policy?” Runtime activation adds, “Is the policy I am about to use still the policy whose evidence I inspected?” The two questions are different. A perfectly preserved policy can still be activated against a changed catalog if the serving layer does not verify the binding. Conversely, a strict activation check cannot prove that the policy will choose a high-quality answer; it can only keep the policy's identity and assumptions intact.

Once the bundle passes those checks, a request is turned into the feature representation used by the fitted bank. An embedding is obtained and the bank supplies a candidate decision. If embedding fails, the runtime uses a named fallback decision rather than returning a plausible-looking nearest neighbor from invalid data. The fallback is part of the decision evidence: it tells a later observer that selection did not follow the ordinary embedding path.

An episode identity adds continuity without becoming permanent global memory. Experiential can retain an episode-level decision and reuse it for later request variants, while also retaining request-specific decisions. The state is process-local, bounded by capacity, and subject to expiry. A session that lands on one candidate does not thereby create a fleet-wide guarantee that every future worker will share the same state. The bounded lifetime is a trade-off: it can keep a multi-turn episode from oscillating among candidates, but it also prevents an old selection from becoming an unbounded authority.

The repository's deterministic evidence reports two HTTP turns retaining one hashed episode identity and one sticky routed alias without exposing the raw episode identifier. That is a useful illustration of what the mechanism does and does not promise. The route can be stable for an episode within the tested bounded state, while the public record can avoid exposing the caller's raw identity.