Posting

What It Models

A posting connects reviewed documents to a recorded accounting generation. The logical object includes the durable execution job and the account-resolution snapshots, because together they explain what ran and which configuration it used.

Identity and Attributes

Posting history and job identity answer different questions. The former tracks accounting generations; the latter identifies submissions and watched execution. The attribute rows distinguish their boundaries, including the separate HTTP and internal batch limits.

Relationships

Batches contain posting history, and each generation owns its entries and revenue plans. Platform presents the job records to the console. Snapshot columns remain physically on Transactions document lines while posting controls their accounting content.

Invariants

The invariant rows cover generation uniqueness, submission reuse, transaction boundaries and retained resolution. Dependent protection applies only to successfully read dependents; it is not a proved concurrency guarantee.

How It Is Stored and Shared

The Accounting database stores posting records under workspace security and job families under the durable-job storage contract. Job roots deliberately support cross-workspace operational views rather than sharing posting-record row policies. The console follows the Platform job interface.

Open Design Questions

Start reconciliation is missing. A settlement failure after accounting commit can produce a failed job beside completed accounting. Product also needs a reliable dependency check and a consistent submission-size policy.