Skip to main content

Deployment slots and promotion bundles

Bundles​

POST /models/{id}/bundles packages an evaluated model for serving — and is refused when any gate is blocking. Under the default warn policy, G1-G3 quality failures are advisory but require an exact acknowledgement with a reason; G4-G6 integrity failures are never waivable. A strict project policy blocks every failure. See Promotion gates.

The bundle pins, by fingerprint: the checkpoint, contract version, leakage policy version, encoder set, tokenizer version, dataset build, and eval report. It copies the measured gate results verbatim and, when a quality failure was acknowledged, records the reason and actor in an additive promotion block. It also carries the complete runtime block (model config, window, label heads) — scorers read only the bundle, never the original records.

A semantic.v2 model you trained also gets a representation_compatibility block, derived from the bundle's own pinned vocabulary, vocabulary vectors, tokenization and model config (you never supply it). If those inputs are missing or disagree, POST /models/{id}/bundles and POST /slots/{id}:activate refuse with failed_precondition and reason project_representation_invalid; allow_mismatch cannot override it. A semantic.v2 bundle created before this block existed is refused on a realtime slot with reason project_representation_missing: create a new bundle from the same model.

Slots​

A slot is the stable, API-addressable unit your integrations point at:

{
  "environment": "test",
  "name": "prod",
  "entity_type": "user",
  "mode": "live",
  "scoring": "batch_only"
}
  • name — per-project-unique and permanent; bundles rotate under it, URLs never change.
  • mode — live serves reads; shadow scores the same traffic into shadow state rows for candidate-vs-active comparison without exposure.
  • scoring — batch_only (states written by refreshes) or realtime: every ingested event for the slot's entity type triggers a rebuild of that entity's recent window and a fresh state write within seconds (target p95 event→state ≤ 2 s). Realtime slots — live and shadow alike — get their own serving deployment automatically; flipping a slot back to batch_only tears it down. Bursts queue and replay in order; a poison event is retried 5 times and then parked, and the entity's state self-heals on its next event or a batch refresh.

Activation, rollback, audit​

POST /slots/{id}:activate {bundle_id} re-verifies every pinned fingerprint against storage before the swap — a corrupted or altered artifact aborts activation (see Fingerprints). The override path (allow_mismatch: true + a reason) exists for break-glass moments and always leaves an audit record.

POST /slots/{id}:rollback returns to the previous bundle in the slot's history — the same verification applies. Activation history (who, when, which bundle) is part of the slot record, and every activation emits a slot.activated webhook.

Semantic models you trained​

A semantic.v2 model trained on your own project data is promoted and activated with the same controls. Its bundle also pins a representation_compatibility block that Tessera derives from the bundle's own vocabulary, vocabulary vectors, tokenization and model config; you never supply it. Activation and every scorer re-derive it and refuse a bundle whose block differs, with no override. It identifies your trained model's learned space within your project only: the model is never exported to or shared with another project.

When you activate (or roll back to) such a bundle on a live realtime slot, Tessera also replays the head of its source: the events that arrived before the activation are scored once per entity, within the bundle's window, so every entity gets a scored prefix without waiting for its next event. The replay runs only while the source is active, automatically onboarded, has no manual mapping and still uses the binding the bundle was trained with, and only while the slot keeps that bundle and activation generation; any change cancels it before it writes anything. If those conditions do not hold when you activate, the activation still succeeds and only new events are scored.