The provisional-to-final entry lifecycle

One entry, five moments — nothing is ever overwritten

• Provisional entry.created

  Every entry lands Provisional first and keeps one identity for its whole life. Creating one runs the same guards on every surface: balanced postings, a valid chart of accounts and dimensions, entity scope, and an accepted idempotency key. There is no separate draft object.

• Revision entry.revised · rev n+1

  Each material edit — amount, account, dimensions, dates, currency, lines — appends an immutable, addressable revision to the same object: revision number, content hash, actor, timestamp. Prior revisions stay retrievable exactly as written, and a material edit voids any open approval.

• Approval entry.submitted → entry.approved

  An approval binds to the revision it approves — entry, revision number, content hash, policy, tier, approvers, decision inputs — and is usable exactly once, for the hash it names. Reject and withdraw return the entry to Provisional, with a reason.

• Final entry.finalized · one-way

  Finalization is the only writer to the books, and it is irreversible: the same object is sealed with a permanent document number, its entry hash joins the chain by default, and preconditions — period state, locks, the approved hash — are re-evaluated at finalization, not only at approval.

• Correction entry.reversed · entry.corrected

  After Final there is no edit, no delete and no unpost. Later change flows through typed corrections — reversal, adjustment or restatement — each a new entry linked to the original, with both the mistake and its fix staying visible.

• Period states & higher tiers period.* · T2/T3 ◇ Roadmap

  Period states, close gates, auto-reversal accruals and the T2/T3 approval tiers are ledger-native by design and arrive with PH-2.

Phase legend: amber = Provisional state · green = Final · red = Correction · blue = Roadmap (PH-2). Labels are always present — colour is never the only signal.

Who may transition an entry

Guards are re-evaluated server-side on every transition; every transition appends one event. Agent credentials carry write and submit scopes only — approve, finalize, correct and restate cannot be granted to an actor of kind agent.

What every edit records — who, when, where, why

No write path is exempt — ingestion included — and a missing or incomplete envelope fails closed instead of defaulting to a system actor. Even autosave micro-edits emit one event per commit, in sequence; storage may coalesce their bodies, never their events. Trace FR-234–238, FR-208, FR-522 · PH-1

Every posting and every event carries three time axes — effective time (when it happened), insertion time (when the ledger recorded it), and knowledge time (a belief cut-off over the event sequence). The taxonomy is closed: exactly three axes, no fourth. Period assignment and scenario are stored attributes carried within those axes, never axes of their own. Backdated facts are appended as new events — never chain edits — and the effective date sits inside the hashed payload, so a retroactive change is detectable.

# the same read twice: a date's balance, and the belief at a past instant
→ tools/call get_balance
{
  "ledger":       "grp-eu",
  "book":         "group_ifrs",
  "scenario":     "actual",
  "as_of":        "2026-06-30",             # effective time (E)
  "as_believed":  "2026-07-15T18:00:00Z",   # knowledge time (K)
  "view":         "combined"
}

← 200 { "balance_minor": 18425000, "currency": "EUR",
        "resolved": { "knowledge_seq": 841223 },
        "restated": false, "stale": false }

Trace FR-500–515 · PH-1; period-state-as-of (Q7) labeled Roadmap · arbitrary-K replay is audit-class (NFR-3)

T0 is auto-post plus a post-hoc review control — not unsupervised

• Auto-approved entries are sampled into a review queue at a policy-configurable rate — no less than one daily sample by default.
• Anything outside the configured normal ranges is flagged for review, and review outcomes are recorded as events.
• The reversal path is reachable directly from a review outcome: a reviewer can raise a typed correction on the spot.
• Range definitions are policy data, versioned and recorded — no model runs in the core.
• Accountability is explicit: when a T0-approved entry is later restated, responsibility follows the policy author — the config owner who set the rule and its ceiling. The platform provides provenance only.

Trace FR-217, OI-25/OI-26, FR-218–220 · PH-1 (T0/T1)

Thresholds are derived and recorded, and duties are separated

The entity's materiality benchmark yields performance materiality and the clearly-trivial line — editable, versioned pack fields, not code constants. The evaluated tier, its inputs and the thresholds in force are stamped on the entry, together with the control type auditors scope: fully automated for T0, semi-automated for T1 and T2, governance for T3. Separation of duties holds as policy data: creator ≠ approver for agent-originated entries in all cases; an approval is content-hash-bound and usable once; and any material edit voids a pending approval. Changing the materiality benchmark itself requires dual control and a versioned policy record.

Provisional numbers carry their own honesty envelope

Depth on the finance-team view: for finance teams · agent write governance: MCP governance