# Glossary (/glossary) The terms below are the vocabulary of the Zumik object model and metrics. Each links to the concept page where it is defined fully. ## State objects [#state-objects] **Artifact**: A reusable, immutable unit of content: a policy, tool bundle source, response schema, document, retrieval chunk, or checkpoint. Addressed by an opaque ID, never by its content hash. [Read more](/concepts/artifacts) **Bundle**: An immutable, ordered list of artifact references. Ordering is semantic and is never re-sorted after creation. [Read more](/concepts/bundles) **Session**: A causal state container for an agent workflow. Not a cache entry: it holds the logical history that branches extend. [Read more](/concepts/sessions) **Branch**: An append-only line of events within a session, updated with compare-and-swap so concurrent appends cannot silently clobber each other. [Read more](/concepts/branches) **Snapshot**: The compiled, ordered logical state for a branch head. It pins artifact versions, ordering, the prompt-compiler version, and the branch head, so a response runs against an exact state. [Read more](/concepts/snapshots) ## Identity and reuse [#identity-and-reuse] **Materialization**: The exact model-visible rendering of a snapshot, keyed by prompt-compiler, tokenizer, chat-template, and serialization revisions. Two requests can share a snapshot but need different materializations. [Read more](/concepts/handles-and-fingerprints) **KV realization**: The physical runtime cache representation of a materialization on a specific model, engine, and GPU topology. A logical artifact can be reusable even when no compatible KV realization exists. [Read more](/concepts/handles-and-fingerprints) **HMAC fingerprint**: A tenant-scoped keyed hash (HMAC-SHA256) used only inside the isolation boundary for deduplication and trace analysis. Rotating the key intentionally breaks equality linkage. [Read more](/concepts/handles-and-fingerprints) **WRS (Workload Reuse Score)**: A 0-to-100 score computed from trace data that weighs opportunity, recurrence, retention locality, TTFT sensitivity, session continuity, and payload redundancy. It replaces a single prompt-length heuristic. [Read more](/concepts/workload-reuse-score) **Reuse opportunity vs. realized reuse**: Opportunity is how much input could have been reused; realized reuse is how much the provider or runtime actually reused. A reusable handle is not proof of a cache hit. [Read more](/concepts/reuse-metrics) **Evidence level**: The strength of a realized-reuse signal: `provider_reported`, `runtime_confirmed`, `router_inferred`, `trace_estimated`, or `unknown`. Every realized number carries one. [Read more](/concepts/reuse-metrics) ## Routing and reproducibility [#routing-and-reproducibility] **Alias release**: An immutable, reproducible resolution policy for a model alias. A live alias points at one release; changing a provider-model revision creates a new release rather than mutating a frozen one. [Read more](/concepts/model-aliases) **Agent hints**: A vendor-neutral, versioned contract that expresses intent (reuse preference, QoS class, region policy) without exposing provider-specific knobs. Hints are not guarantees, and Zumik reports which were honored. [Read more](/concepts/agent-hints) **Capability manifest**: A versioned record of what a provider and profile support: cache type, minimum tokens, discount, batch support, service tiers, context window, region support. Used for routing and for honest purge claims. [Read more](/concepts/capability-manifests) **Execution profile**: The lane a request runs through: `managed_provider` (default), `byok`, `byoc`, or a hybrid of these. [Read more](/concepts/execution-profiles) ## Outcomes and deletion [#outcomes-and-deletion] **QoS outcome**: A formal result for a request, reporting admission (`admitted`, `queued`, `rejected`, `expired_before_start`), completion, whether the target was met, latency, and a machine-readable reason code. [Read more](/concepts/qos) **Purge guarantee class**: How strong a deletion is, from `access_revoked` through `best_effort_expiry`, `verified_namespace_invalidation`, `verified_physical_purge`, to `cryptographic_purge`. Each purge receipt states the class it achieved. [Read more](/concepts/retention-and-purge) How these objects and metrics fit together end to end.