How should the effective start, end, suspension, withdrawal, correction and superseding decision of an AI-assisted decision be recorded in machine-readable form?

Direct answer

Every decision has a persistent decision identifier and an immutable version. Creation, entry into force, suspension, withdrawal, correction, expiry and supersession are stored as added events without erasing the earlier record. Each event contains an event identifier, time, actor, authority, reason, prior state, new state, evidence and target version. The current state is derived from these authorised events; it does not replace the event history.

In plain language

Think of a bank statement. Today's balance appears as one number, but the credits and debits are preserved so that you can see how it arose. A decision's current state is calculated from its event history in the same way.

Why this matters

Overwriting a single status field destroys the evidence of who changed the decision and why. A system may then treat an old, suspended or withdrawn decision as current.

Do not confuse

A decision identifier denotes the same decision family; a decision-version identifier denotes particular content.
An event records an authorised change in the decision's state.
The current state is a view derived from events; the event history is the evidence chain.
Correction repairs inaccurate content; supersession shows that a new decision replaces an earlier one.
Suspension is a temporary operational state; withdrawal is an authorised ending of the decision.

What should you do?

Define a persistent decision identifier, immutable version identifier and explicit schema.
Record every lifecycle change under a separate event identifier and trustworthy timestamp.
Make actor identity, role, authority, reason, evidence, previous state and new state mandatory fields.
Constrain valid state transitions and prohibit invalid ones through machine-verifiable rules.
Link correction, withdrawal and supersession relationships in both directions without deleting the previous version.
Generate and recalculate the current-state view from the event stream using deterministic rules.
Publish the event to downstream systems and add delivery, application and read-back evidence to the decision.

How do you audit it?

Are decision and event identifiers unique, persistent and versioned?
Was earlier decision content or an event overwritten?
Does every event contain time, actor, authority, reason and evidence?
Are invalid or unauthorised state transitions blocked?
Can correction, withdrawal and supersession links be followed in both directions?
Can the current-state view be regenerated from the preserved events?
Did downstream targets actually reach the same current state?

Limit

An append-only record strengthens immutability and traceability; it does not by itself prove that an event was factually correct or authorised. Trustworthy time, identity, authority and integrity controls are also required.