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.
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 . When a rule changes: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.
The system flags the old version
Forge marks the prior version as superseded and identifies that a change has
occurred.
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.
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.