> ## Documentation Index
> Fetch the complete documentation index at: https://www.docs.forgeshipyard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# L2.5 · Engineering Decision Ledger

> Where the 'why' lives. The event clock of the whole system.

export const Supersession = () => <Tooltip tip="Replacing a prior decision or rule version with a new one while keeping the link back to what was replaced.">supersession</Tooltip>;

export const AuditSignature = () => <Tooltip tip="A cryptographic proof that a specific person made a specific decision at a specific time, and it has not been altered since.">audit signature</Tooltip>;

export const DecisionLedger = () => <Tooltip tip="An append-only record of every engineering decision and the reasoning behind it. Decisions are never edited, only superseded.">decision ledger</Tooltip>;

<Note>
  **In plain terms:** This is the heart of Forge. The <DecisionLedger /> records *why*
  every engineering decision was made, not just what the ship is. It is the event
  clock from the [Two-Clock Problem](/concepts/two-clock-problem).
</Note>

## What it does

L2.5 stores replayable engineering decisions. Every engineering decision (proposed,
drafted, approved, rejected, superseded) is recorded with its full reasoning
context:

* what triggered it
* which rule version applied
* what evidence it cited
* who approved it
* what it superseded
* its <AuditSignature />

## Append-only, not an audit log

The ledger is **append-only**: decisions are never edited or deleted. A wrong
decision is superseded by a new decision that explicitly references and replaces it,
so the full history is always preserved.

This is different from an audit log. An audit log records *what happened* ("user X
clicked button Y at time Z"). A decision ledger records *the reasoning chain*
("decision D was made under rule version R, citing evidence E, by approver A,
superseding prior decision D-prior").

## Why it is the most important layer

Because every decision records the exact rule version it was made under, the ledger
can answer the question that matters most when something changes:

> "Which decisions need to be re-evaluated, and in what order?"

That single capability is what turns a rule update from an open-ended manual audit
into a sorted to-do list. See [When the Rules Change](/concepts/when-rules-change)
for how <Supersession /> uses this.

## What L2.5 outputs

* `engineering_decision`
* `decision_supersession_chain`
* `decision_replay_context`

A decision is **replayable**: given the same sources at the same versions, the same
decision should be reconstructable from scratch. The system targets better than 95%
replay completeness for approved decisions.