Close Run

What It Models

A run records a finance action and its outcome. A durable job carries out that action, and each retry adds an execution attempt to the same run. Staff can therefore follow one request through multiple jobs without treating recovery as another close.

Identity and Attributes

The database freezes the principal request identifiers, caller, time and acknowledgements. The note participates in replay comparison but is not frozen by the write-once trigger. Runtime status, readiness and outputs change as work proceeds. Outputs preserve domain results; job steps and events describe execution. Recognition and reversal use the run’s recorded output to avoid repeating committed financial work.

Relationships

Each run targets one period. Successful closes own one immutable snapshot; normal reopen runs own none. A reopen may identify the earlier close whose revenue it reverses. Jobs reference the run and must be deleted before it.

Invariants

The invariant rows distinguish database constraints, service transitions and task behavior. They do not guarantee that every task event commits with its domain work. Calendar generation is also outside that atomic boundary. Current-job checks in failure handling occur before the period lock, leaving a concurrency concern for recovery.

How It Is Stored and Shared

Run rows are workspace-scoped. Job roots retain workspace and customer context for cross-workspace execution infrastructure; their children belong to the job. Service operations assemble runs and execution history for the console. Customer exports include run data without command keys and omit operational job tables.

Open Design Questions

Replay must include requester identity to satisfy the recorded product direction. Recovery needs a response that tells the console whether retry or cancellation is allowed. Failure races, missing history events and long histories need explicit proof or correction.