> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Occurrences and replay description: >- An occurrence keeps one identity for its whole life. Replaying a trigger returns the earlier result; creating new work is a separate act with its own quote and charge. route: /docs/compute/automation/occurrences-and-replay page_id: docs-compute-automation-occurrences-and-replay page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Teams recovering an automation that appears to have missed or repeated a run voice: D reader_question: If I replay a trigger, do I get the old result or a new charge? primary_action: Pause, revoke and recover a schedule source_locale: en-US source_status: APPROVED source_version: docs-compute-automation-occurrences-and-replay-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What an occurrence is An occurrence is one intended run of one schedule at one intended time. It is not the job, and it is not the attempt. Its identity is derived from the schedule, the schedule version and the intended occurrence. That identity is fixed the moment the occurrence is defined, and it never changes because you retried. So a job can be attempted, refused, retried and finally succeed, all under a single occurrence. The occurrence is the unit you reason about; the job is what actually ran. ## Replay returns, it does not repeat Replay is an operation on the schedules family. It re-presents an occurrence that already has an identity. An exact replay returns the prior result. Same identity, same payload digest, same answer, no second charge. The same identity with a different digest is refused as equivocation. Two different requests cannot both be the same occurrence, and the refusal tells you which fact to correct. ## When you actually want new work If you want the workflow to run again on current data, you are not replaying. You are creating a new occurrence, and that is a different act. New work gets a new identity, a fresh quote and a separate charge. It also re-reads current policy, so a spend ceiling or an approval that changed since the original run applies to it. Deciding between the two is easy if you ask one question. Do you want the answer you already bought, or do you want a new answer? See [how idempotency scopes a retry](/docs/compute/jobs/idempotency-and-retries) if you are unsure which one your client is sending. ## Authority is read again, never remembered An occurrence does not carry the authority it was set up with. It reads current authority at the moment it runs. That means four things can change between occurrences and will be respected. - The spend ceiling and any approval that gates it. - The profile values the schedule references. - The credential the source or destination resolves. - The workflow release the schedule is pinned to. This is deliberate. A schedule you approved in January must not spend against a policy you replaced in March. ## Confirm success Read the occurrence back rather than trusting the response you got. The read-back names the occurrence identity, its current state and the job it produced. A replay you expected to be free shows the earlier result and no new job. A deliberately new run shows a new identity, a new quote and a new job. If you see a new job where you expected a replay, your client changed the payload. Compare digests before you change anything else. ## When a replay refuses Every refusal carries a safe reason and a concrete next action. Read both before retrying. - **Equivocation** — the identity is reused with different content. Send it as new work, or correct the payload to match. - **Budget exhausted** — the current spend authority cannot admit it. Renew the ceiling, then replay again. - **Replan required** — the workflow, snapshot or policy moved since the original run. Plan again and decide whether you still want the same answer. - **Expired** — the occurrence is past the window in which it could start. Create a new occurrence instead. None of these needs a support ticket to diagnose. The occurrence events show which fact changed and when. [Pause, revoke and recover a schedule](/docs/compute/automation/pause-revoke-and-recover)