Batch scoring (refreshes)

A refresh bulk-recomputes every entity state under a slot as of a cutoff: only events with timestamp <= cutoff may influence the written states.

{
  "cutoff": "2025-07-01T00:00:00Z"
}

Omit the body (or the cutoff) to refresh as of now. Poll GET /slots/{slot}/refreshes/{id} through queued → running → succeeded | failed; the record reports entities_scored, entities_skipped_stale, and partition progress.

Semantics worth relying on:

• Point-in-time honest. The job rebuilds each entity's window from the event store as of the cutoff and runs the bundle's model — the same tokenizer and forward code as training (gate G4 proves it).
• Resumable. Work is partitioned and checkpointed; a re-run resumes from the last completed partition instead of starting over.
• Never regresses. State writes are fenced on the event cursor: a refresh can never overwrite a state that already incorporates newer events (relevant once realtime scoring also writes the same rows).
• Idempotent to retry. A failed refresh may be retried automatically by its Job: the record returns to running with its error cleared. Only a succeeded refresh is final; re-dispatching it is a no-op, and a late failure of an earlier attempt never turns it back into failed.

Terminal states emit refresh.completed / refresh.failed webhooks — schedule refreshes from your orchestrator and subscribe rather than poll. If the Job retries a failed refresh, refresh.failed can be followed by refresh.completed for the same refresh_id; treat the latest event as current. Typical Phase 1 cadence: nightly refresh, then an export into the warehouse.