Skip to main content
In plain terms: Rules change. A classification society publishes an update, the Coast Guard amends a section, an owner 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.

​
The problem with rule changes

A vessel stays in service for 25 to 30 years. The rules it was built and repaired under do not stay still for anything like that long. Across a fleet, a single rule update can touch structures on a dozen hulls, each of which was assessed at a different time under a different version by a different person. Today the options are bad. Either you manually re-audit every prior decision that might be affected, or you find out at the next survey. The first is expensive and error-prone. The second is worse. This is one of the highest-stakes flows in Forge, and it is a large part of what makes a decision record worth keeping in the first place.

​
How Forge handles it

This process is called . When a rule changes:
1

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

The system flags the old version

Forge marks the prior version as superseded and identifies that a change has occurred.
3

It finds every affected decision

The 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.
4

Each decision is sorted into one of three queues

Not every affected decision needs the same attention:

Auto-grandfather

The new version does not change the outcome. The prior decision stands, with a note.

Engineer review

The new version might change the outcome. An engineer needs to look.

Forced reapproval

The new version definitely changes the outcome. The prior decision is invalidated until it is reapproved.

​
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”: someone 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.

​
Where this lands in the survey cycle

The practical value is timing. A rule update that arrives between availabilities is an opportunity: there are months to work out what it affects and to fold any resulting work into the next planned docking. The same update discovered during a survey is an emergency, priced and scheduled under the worst possible conditions. The ledger is what turns the first situation into the normal one.