What happened and when?
Comes up when a client faces a challenge or complaint and can't reconstruct what happened: who reviewed the case, when, in what sequence, and with what information available at the time.
Decisions are not moments: they are processes. A loan decision involves: data collection, model scoring, uncertainty assessment, caseworker review, override consideration, documentation, and communication. A content moderation decision involves: automated flagging, policy matching, human review (if any), and outcome. Each of these steps happens at a specific time, by a specific actor (human or AI), and with a specific rationale.
When users receive a decision, especially an adverse one, they often don't know any of this. Was the decision made by an AI or a human? Was there a review? Was additional information requested? Was there an appeal already in progress?
Decision Timeline makes this process visible. It answers not just "what was decided" but "how the decision was reached": a sequence of events that can be understood, audited, and, where needed, contested.
This is a governance pattern: its primary users are often auditors, regulators, and compliance teams who need to reconstruct a decision after the fact. But it is also meaningful for the people affected by decisions, who have a legitimate interest in understanding the process that affected them.
Provide a clear, chronological view of the key events in a decision's lifecycle, including data collection, model assessment, human review, overrides, and communications, in a form that supports both user understanding and audit.
A chronological list of events presented as a vertical timeline with: - Date and time - Event type (data received, model scored, caseworker reviewed, decision issued, etc.) - Actor (automated system, caseworker name or role, applicant) - Brief description of what happened
Visual differentiation between event types: - 🤖 Automated step - 👤 Human action - 📄 Document event (submitted, received, requested) - ⚠️ Flag or alert - ✓ Decision or resolution
Each timeline entry can be expanded to show more detail: what data was available at that point, what the model score was, what the caseworker noted. Primary view stays compact; detail is accessible.
A clear "where we are now" marker showing the current state of the case: useful when a decision is still in process (pending review, awaiting documents).
Visual emphasis on the specific moment a final decision was made and by whom: distinguishing the decision event from the surrounding process events.
For audit purposes: a downloadable record of the full decision timeline, including timestamps and actor references. Used by auditors and compliance teams.
A timeline that shows "assessment completed" without indicating whether this was automated or human is not auditable. Every event should have an identified actor: the system, the caseworker, the applicant.
A timeline entry that says "POST /api/score v2.3 returned 0.71" is not useful to the affected person. "Automated assessment completed: risk score generated" is.
The line between AI and human action is often the most important distinction in a decision process. Use consistent visual coding to make this clear throughout the timeline.
A timeline that only shows organizational events obscures the full picture. When the applicant submitted documents, requested review, or updated information: these are events too.
The full technical audit trail is for compliance teams. Affected persons need a simplified version: "Here's what happened with your application, in the order it happened."
Completeness vs. comprehensibility
A fully complete audit timeline can contain dozens of technical events. The display must be designed for two different audiences: affected persons (simplified, plain-language) and auditors (complete, technical). Consider two different views.
Transparency vs. confidential process details
Some process details should not be disclosed to affected persons: reviewer notes, internal escalation discussions, business rules. Design the disclosure boundary carefully.
Real-time vs. retrospective
Timelines are most valuable for retrospective review. But for cases currently in progress, a real-time status view (where is my application now?) is what users actually need. Design for both use cases.
Audit trail is the data collection layer. Decision timeline is the presentation layer: the human-readable view of the audit trail data.
The decision timeline is essential context for a contestability workflow. Users challenging a decision need to know the process that produced it.
Overrides are key events in the timeline. The timeline makes HITL visible: when a human intervened, who it was, and what they decided.
The appropriate view of the timeline differs by role. Affected persons see a simplified view; auditors see the full technical record.
Kroll et al. (2017) — Accountable Algorithms
argues that algorithmic accountability requires process transparency: the ability to trace how a decision was reached, not just what the decision was. The decision timeline is the design implementation of this accountability requirement
Diakopoulos (2016) — Accountability in Algorithmic Decision Making
examines algorithmic accountability from a computational journalism perspective, distinguishing transparency about a system's existence, inputs, logic, and outcomes. Supports traceable, reconstructable decision processes as a precondition for accountability. Published in Communications of the ACM, 59(2)
European Union (2024) — EU AI Act, Article 12
requires record-keeping for high-risk AI systems, including logging of decisions, to enable post-hoc audit