Execution ledger

Forge

The record of every execution, with its outcome and the person who authorised it.

What is a execution ledger?

A execution ledger is the record of every execution an automation has performed. Each entry holds the inputs the execution received alongside every action it took in another system. The outcome and the authorising identity are recorded against the same entry, which is what an auditor reads when asking what an agent did.

Why the ledger is the only thing an auditor can examine

An internal auditor examining an automated process does not examine the agent. They examine what it did, one execution at a time, with the authorisation attached to each. A system holding only the latest status for each item has nothing to offer that examination, because the question concerns an execution completed two quarters ago. The ledger therefore has to be written as the work proceeds, since nothing can be reconstructed afterwards from a status field.

  • A status field answers what is true now, never what happened then.
  • Every action in another system needs an entry naming the actor behind it.
  • An approval recorded apart from the execution cannot be tied back to it.
  • The ledger is what makes an automated decision answerable to a person.

How a execution ledger works

  • Each execution is assigned an identifier before its first action.
  • Inputs are captured at the version the execution actually received.
  • Every action against another system is appended with its request and its result.
  • Approvals are recorded against the execution identifier with the approver named.
  • The outcome is written with the step at which the execution finished.
  • Entries are made immutable and retained for as long as the process is answerable.

How a execution ledger is evaluated

A execution ledger is assessed on whether a stranger can reconstruct one execution from it alone. Examine the following on executions chosen at random from a closed period:

  • share of executions reconstructable end to end from the ledger
  • proportion of external actions with a recorded request and result
  • presence of a named approver on every action requiring one
  • retention period against the applicable audit window
  • elapsed time to answer a question about a single execution

Limitations, risks and common failure modes

  • Entries are written on completion, so an interrupted execution leaves no account.
  • Inputs are referenced by pointer to a document that was later edited.
  • Approvals live in a messaging tool that retains nothing beyond a short window.
  • The ledger is held in the automation platform, which the next migration replaces.
  • Logging volume is reduced for cost, removing the detail an audit needs.

Related terms

Decision recordThe complete account of a decision, from its inputs to its named author, retained for as long as the decision can be questioned.AI audit trailThe complete record of what a system did, on what evidence, and who authorised it, retained for the period the decision can be questioned.Completion recordThe record of who completed which module, on which version of the source, and when.Simulated executionExecuting a workflow with its effects suppressed, to confirm what it would do before it does it.Append-only logA record that can be added to and never amended, which is what makes a history worth presenting.Attended and unattended automationWhether an automation executes alongside a person at their desk or on its own against a schedule.

All 315 terms