Key takeaways in 3 minutes
Approval is not the end of an AI decision. It is the handoff from proposal to organisational action.
The flow still needs to:
- execute the exact action that was authorised;
- reveal partial progress and side effects;
- stop, retry, undo or compensate safely;
- verify the operational outcome;
- support explanation, appeal and correction;
- preserve a decision record connecting intent to result;
- turn failures, overrides and outcomes into learning.
A log records events. An accountable decision flow preserves the relationships between them.
The manager reviews the proposal and clicks Approve.
The interface displays a green tick. The card slides politely out of the queue. Somewhere, a log entry records the event with a timestamp accurate to the millisecond.
Everyone goes home feeling governed.
Meanwhile, the action times out after updating two of three systems. A customer receives the new commitment. Finance retains the old amount. The retry runs tomorrow and sends the message again.
The approval worked perfectly.
The decision flow did not.
Approval is not the finish line. It is the moment an AI proposal becomes an organisational commitment.
The Green Tick Hides A State Change
Before approval, the system has a proposal.
After approval, the organisation owns an action.
That transition creates new design responsibilities:
- execute only what was authorised;
- show what has and has not happened;
- contain partial failure;
- preserve a route to interrupt or recover;
- record the decision in context;
- check the real outcome;
- allow affected people to challenge it;
- learn from the difference between intent and result.
Treating all of that as a backend concern creates a particularly polished form of user confusion.
Design Across Three Time Horizons
The Decision After Approval
Now: Execute And Verify
The action should match the approved payload exactly.
Show the target, scope, status and authority used. If the action contains multiple steps, reveal partial completion honestly. “Done” should not mean “the agent stopped talking”. It should mean the intended state has been verified in the relevant system.
Place checkpoints before side effects. Use idempotent operations so a resumed workflow cannot send, pay or delete twice. Keep the probabilistic model in the work of interpretation and planning while deterministic services enforce identity, permissions, schemas and execution.
Next: Recover And Contest
Failures do not always need a Retry button.
The responsible response may be to resume from a safe checkpoint, roll back, apply a compensating action, hand off to an operator or stop entirely.
The interface should show:
- what succeeded;
- what failed;
- what remains unchanged;
- what is still reversible;
- how long the recovery window remains open;
- who now owns the problem.
Contestability belongs here too. An affected person may need to challenge incorrect evidence, policy application, process or outcome. A credible route identifies the decision owner, accepts supporting evidence, tracks review and shows whether downstream effects were corrected.
Contestable AI by Design treats contestability as a lifecycle property rather than a complaints form added after deployment. That is the right product lens.
Later: Monitor And Learn
One reviewer cannot see the pattern across hundreds of decisions.
Monitor outcomes, overrides, reversals, repeated exceptions, ignored alerts, recovery time and appeals. Compare what the system intended with what actually happened.
The purpose is not to create a dashboard of AI activity. It is to notice when the decision system is changing in a way that requires intervention.
The NIST AI RMF Core explicitly connects production monitoring with appeal, override, incident response, recovery and change management. That combination matters: visibility without a response path is simply an excellent view of a problem.
A Trace, An Explanation And A Decision Record Are Different
These artefacts overlap, but they serve different people.
Trace
A trace captures system events: model calls, tool use, policy checks, timing, errors and state changes. It helps engineers inspect how the system ran.
Explanation
An explanation helps a particular person understand what happened and why it matters in context. It should be appropriate to their role and grounded in evidence.
Decision record
A decision record connects the organisational story:
`text
Intent → evidence → proposal → uncertainty → authority → human decision →
authorised action → execution → outcome → appeal, recovery or learning
`
It should preserve the brief as presented, not a cleaner reconstruction created after the facts changed.
A log can prove that an event occurred. A decision record helps an organisation explain why the chain was reasonable, what broke and what it did next.
Example: The Half-Completed Supplier Change
Suppose an AI proposes moving an urgent order to a backup supplier.
The decision is approved. The ERP order updates. The transport booking fails. The customer notification succeeds.
A weak flow displays Supplier updated because the first tool returned success.
A responsible flow moves to Partially completed and shows:
- ERP supplier changed to Vale Components;
- transport capacity not booked;
- customer message already sent;
- original supplier release not yet issued;
- automatic retry paused to prevent duplicate booking;
- recovery owner: Supply Operations;
- recommended next action: secure transport or roll back the supplier change;
- decision record updated with the failure and handoff.
This is not edge-case design.
It is the product showing the truth about the state it created.
The Practical Move: Design The Unhappy Continuation
Take one approved AI action and draw what happens after the green tick.
Include five branches:
- Complete: how is success verified?
- Partial: how does the user see the mixed state?
- Failed: what is the retry limit and safe stop?
- Wrong: what can be undone or compensated?
- Contested: who can challenge it and how are downstream effects corrected?
Then ask what record each branch creates.
If every branch ends with the same event log, the product is losing the information the organisation will need most.
The Accountability Lab Connection
This is where the Accountability Lab idea of an Accountability Chain Review becomes practical.
The review does not stop at “Was approval required?” It follows the chain from evidence and authority through execution, recovery, outcome and learning.
The decision record becomes the connective tissue between the interface, the operating control and the evidence an organisation can inspect later.
Accountability is not a retrospective report explaining why the product looked responsible.
It is the product's continuing ability to stop, show, correct and learn from what it changed.
Sources And Further Reading
- NIST AI RMF Core — voluntary reference framework; version 1.0 is under revision.
- Alfrink et al., Contestable AI by Design.
- OWASP AI Agent Security Cheat Sheet.
- Anthropic, Building Effective Agents — vendor-authored practical guidance.
- ICO Tech Futures: agentic AI risks.
