01 · Logging
“What happened?”
“Another order left Server 8 at 9:30:01.” A log records the event. It does not establish whether the event was permitted.
// Replayability · One real example
What does it mean to replay a decision?
Imagine you are the CEO. Your automated trading system has just sent millions of unintended orders. The board asks one question: “Why did our controls allow this?”
Explainability helps show why a model produced an output. Audit logs record events. Data lineage shows where information travelled. Replayability combines these with the policy, rule version, context, authority and sequence that produced one specific institutional decision. It does not replace explainability, logging or audit — it connects them, so an institution can establish what it actually did at a particular moment, and whether it was authorised to do it.
Replayability means being able to reconstruct not only what the system did, but what it was authorised to do—and detect the difference while action is still possible.
It makes no claim about determinism and does not require an identical model output to be reproduced.
// The incident
Knight Capital, 1 August 2012
The institution deployed new trading software to seven of eight servers. The eighth server retained old code linked to a dormant function called Power Peg. A reused activation flag switched that old function on.
Once the market opened, the server repeatedly sent orders that no longer matched the institution’s intended instruction. In about 45 minutes, Knight accumulated more than $460 million in losses.
A simple way to picture one decision:
A client asks Knight to buy 1,000 shares. The authorised instruction is: buy 1,000, then stop. The faulty server behaves as though the instruction is: keep sending another order. The institution’s intent and the machine’s execution have separated.
The 1,000-share instruction is illustrative. The deployment failure, eight-server configuration, dormant code and activation flag are documented in the SEC order.
// What is different?
Four answers to the same CEO question
02 · Explainability
“Why did the software do it?”
“The Power Peg function was active, so the code generated another order.” This explains the mechanism, not the authority.
03 · Reconstruction
“What did investigators later find?”
“Server 8 was running old code that the release process had failed to replace.” This discovers the failure after damage has occurred.
04 · Replayability
“Did execution still match intent?”
A replay-ready control would have said: “The client’s 1,000-share instruction is complete. This next order comes from unapproved code and has no remaining authority. Isolate Server 8 now.”
// The crucial difference
A recording tells you what happened. A replay tells you where authority broke.
Logging says, “the machine acted.” Explainability says, “this code caused it.” Replayability says, “this action no longer matched the approved instruction—and here is the exact point where the chain broke.”
That is why replayability is a governance standard, not merely a technology feature. It binds the live decision to the instruction, rule, code version, data and authority that were valid at that moment.
// The 30-second board pitch
How to explain it to a CEO
“Your systems already tell you what they did. Some can explain why a model produced an output. Replayability goes further: it lets you prove that each important decision used the approved rule, current code and proper authority at that moment. If execution drifts from intent, you can see where it happened and intervene before one bad decision becomes a thousand.”
The three-question test
AuthorityWhat was this system permitted to decide?
StateWhich rule, data and code version were active?
IntegrityDid the action still match the institution’s intent?
If an institution cannot answer all three for a specific decision, it has evidence of activity—but not evidence of control.
From one example to an institutional capability
The Decision Integrity Chain™ identifies the eight layers required to replay a decision: Purpose → Strategy → Intent → Rules → Judgment → Decision → Outcome → Feedback.
For the broader governance argument, read AI governance: replayability, not explainability. Every term used here is defined once in the glossary.