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

# When the Rules Change

> How Forge handles a rule update without forcing a manual re-audit of everything.

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 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:** Rules change. ABS publishes an update, the Coast Guard amends a
  section, a yard revises an internal standard. When that happens, Forge can tell you
  *exactly* which past decisions need a second look, and in what order, instead of
  leaving you to audit everything by hand.
</Note>

## The problem with rule changes

Today, when a rule changes, a yard's options are bad. Either you manually re-audit
every prior decision that *might* be affected, or you cross your fingers and hope.
Both are expensive and error-prone, and on a thin-margin build, neither is safe.

This is one of the highest-stakes flows in Forge.

## How Forge handles it

This process is called <Supersession />. When a rule changes:

<Steps>
  <Step title="The new rule version is ingested">
    The new version comes in with its version information attached, so the system
    knows precisely what changed and when.
  </Step>

  <Step title="The system flags the old version">
    Forge marks the prior version as superseded and identifies that a change has
    occurred.
  </Step>

  <Step title="It finds every affected decision">
    The <DecisionLedger /> is queried: which past decisions were made under the
    *old* rule version? This works because every decision recorded the exact rule
    version it was made under, at the time it was made.
  </Step>

  <Step title="Each decision is sorted into one of three queues">
    Not every affected decision needs the same attention:

    <CardGroup cols={1}>
      <Card title="Auto-grandfather" icon="circle-check">
        The new version does not change the outcome. The prior decision stands,
        with a note.
      </Card>

      <Card title="Engineer review" icon="magnifying-glass">
        The new version *might* change the outcome. An engineer needs to look.
      </Card>

      <Card title="Forced reapproval" icon="triangle-exclamation">
        The new version *definitely* changes the outcome. The prior decision is
        invalidated until it is reapproved.
      </Card>
    </CardGroup>
  </Step>
</Steps>

## Why this works at all

The reason this flow is even possible is the decision ledger combined with one
discipline: **recording the rule version on every decision, at the moment it was
made.**

Without that, a rule update is "good luck": the yard has to manually audit prior
work and hope nothing was missed. With it, the system tells you exactly which
decisions need attention and in what order. It turns a frightening, open-ended
audit into a sorted, finite to-do list.