Expand description
Neutral runtime optimization policy and evidence vocabulary (spec 017).
These types describe behavior that is part of a plan and observations that belong to a run. They do not perform I/O or grant authority. Spec 017 covers runtime-planned batching and bounded memory caching; spec 044 adds shared calls and the persistent tier.
Structs§
- Batch
Policy - Memory
Cache Policy - Bounds apply to one plan’s cache namespace; no plan’s policy evicts another plan’s entries.
- Optimization
Policy - Plan-identified controls for reusable semantic work.
- Optimization
Record - Per-logical-request runtime observations. Secret key material and cached content are deliberately absent.
- Persistent
Cache Policy - The persistent tier’s bounds and the host store’s declared terms (spec 044, 3.1 and 3.4).
- Shared
Call Policy - Bounds of shared calls (spec 044, 3.1 and 3.2).
- Shared
Record - One waiter’s view of a shared call. Waiter ids are opaque and runtime-generated, never decision ids, so a tenant-only scope exposes no principal’s decisions to another (spec 044, decision 5).
- Store
Contract - The host store’s terms, each a declared string recorded as given. Rustev checks only that each is stated and that the store reports the same contract; it owns none of them (spec 044, 2.1).
Enums§
- Batch
Charge Allocation - Deterministic settlement of one observed batch charge across its logical members. Member order is the runtime-recorded batch index order.
- Eviction
Order - Expiry
Basis - Optimization
Admission - Optimization
Mechanism - Optimization
Outcome - Shared
Charge Allocation - Shared
Leave - Why a waiter left before the shared attempt ended.
- Shared
Role - Store
Failure Policy
Constants§
- MAX_
OPTIMIZATION_ DIAGNOSTICS - Most diagnostics one request’s optimization record keeps. Later ones are dropped and the last kept entry says so.