> ## 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.

# The Two-Clock Problem

> The single idea that the whole system is built around.

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:** Most software can tell you *what a ship is today*. Almost no
  software can tell you *why it is that way*. Forge is built to answer the second
  question.
</Note>

## Two different clocks

Every engineering project is really running two clocks at once.

<CardGroup cols={2}>
  <Card title="The State Clock" icon="clock">
    Answers **"what exists today?"** The current drawings, the current bill of
    material, the design as it stands right now. Most CAD and ERP systems handle
    this clock well.
  </Card>

  <Card title="The Event Clock" icon="clock-rotate-left">
    Answers **"why are things the way they are?"** Which rule applied, what prior
    design was used, what evidence supported the choice, who approved it, what got
    replaced. Almost no system handles this clock at all.
  </Card>
</CardGroup>

## Why the second clock matters

The state clock is enough when nothing ever changes. But shipbuilding is nothing
but change: rules get updated, materials get substituted, prior assumptions turn
out to be wrong.

When that happens, you need to answer questions like:

* "Are we still compliant given the new rule version?"
* "What would change if we substituted this material?"
* "Which past decisions need to be looked at again, and in what order?"

You cannot answer any of those from the state clock alone. You need the history of
*why* every choice was made.

## Forge is the event clock

Forge is the event clock for engineering decisions. Everything else in the system
flows from that. The <DecisionLedger /> at its core records not just what the ship
is, but the full reasoning chain behind every decision that shaped it.

That is the whole idea in one sentence. The rest of the Concepts section unpacks
how Forge makes it work in practice:

<CardGroup cols={2}>
  <Card title="Sources vs. Decisions" icon="arrow-right-arrow-left" href="/concepts/sources-vs-decisions">
    The two kinds of things Forge handles, and why the distinction matters.
  </Card>

  <Card title="How a Decision Gets Made" icon="route" href="/concepts/how-a-decision-gets-made">
    A worked example, step by step.
  </Card>

  <Card title="How CAD Becomes Engineering Evidence" icon="cube" href="/concepts/how-cad-becomes-engineering-evidence">
    How a model becomes a traceable measurement and a reviewable claim.
  </Card>
</CardGroup>