Start with one occurrence, not a backlog command
Write down one expected occurrence and the effect it could create. Do not use a production queue simply to make the exercise realistic. A useful record names the schedule semantics you rely on, the ordering relationship to nearby work, and the evidence needed to reconcile the business outcome.
| Question | Why it changes the decision |
|---|---|
| Is the occurrence late enough to change its meaning? | A time-sensitive message can become misleading. |
| Could the effect duplicate, overwrite, or reorder work? | Replay may be unsafe even when the job normally succeeds. |
| Can the business outcome be checked separately? | A task completion signal is not proof of the intended result. |
| Who owns the decision? | A scheduler configuration is not operational authority. |
If an answer is unknown, hold the occurrence. “Try it and see” is not a reconciliation plan.
Use a declared decision receipt
Run the small local fixture test before using its structure in a real review. The copyable declaration below is deliberately synthetic; replace none of its values with production identifiers or treat its result as authority to replay:
const receipt = {
boundary: "synthetic-local-schedule-fixture",
fixture: "discardable-local-schedule-fixture",
occurrence: "declared-missed-occurrence",
effectBoundary: "effect-safety-unresolved",
ordering: "ordering-declared-or-unresolved",
lateStartPolicy: "hold-when-time-semantics-unknown",
decision: "manual-reconciliation",
owner: "operator:scheduled-work-owner",
reconciliationRoute: "local-reconciliation-record",
rollbackRoute: "restore-local-fixture-and-hold"
};
// Expected local validator result:
// { status: "declaration-ready-for-human-review" }
This page includes the declaration so a reader can inspect the evidence shape; the repository test remains a local editorial fixture, not a public service. Run the local fixture test if you have the accompanying source:
node --test sites/howtox.com/evidence/P216/missed-occurrence-receipt.test.mjs
The validator accepts only a synthetic local declaration with a discardable fixture, declared missed occurrence, unresolved effect-safety and ordering boundaries, an explicit hold when late-start semantics are unknown, a skip or manual-reconciliation decision, owner, reconciliation route, and rollback route. It intentionally rejects a queued catch-up while those safety boundaries are unresolved. It does not run a scheduler, find missed work, prove idempotency, replay anything, or contact a client.
Choose one of these deliberately narrow outcomes. The local receipt test covers only skip and record and manual reconciliation while its effect-safety and ordering fields remain unresolved; a queued catch-up needs separate, authorized evidence before it belongs in a real decision record.
- Skip and record when the original time window has passed and the independent business outcome needs no action.
- Queue one catch-up only outside this receipt, when an authorized process has established the effect and ordering boundary for this occurrence.
- Manual reconciliation when the record is incomplete, ordering matters, or a late effect could create a duplicate or stale outcome.
Keep recovery separate from execution
The recovery owner should record why the occurrence was classified, the next safe action, and what would make the decision unresolved. A later operator must be able to see that a skipped occurrence was intentional rather than silently lost. Do not report a catch-up as complete merely because a new task started.
For broad schedule testing, see Test a Scheduled Job Before Launch. For a bounded retry handoff, see Test a Retry-Safe Request Handoff Before Staff Rely on It. This receipt is a planning aid, not evidence that a live scheduler or business process is safe.