# From Drawings to a 3D Model
Source: https://www.docs.forgeshipyard.com/concepts/from-drawings-to-3d
How a stack of legacy 2D sheets becomes a structured, inspectable 3D model without inventing what the drawings do not say.
**In plain terms:** Reconstruction is not tracing. It is working out what a set of
2D sheets actually establishes about a ship, building only that much geometry, and
recording everything the sheets leave unresolved as a named question instead of
filling it in.
## The problem reconstruction solves
There are two established ways to get a 3D model of a ship, and neither works for
most vessels in service.
* **Scan it.** Laser scanning and LiDAR capture the ship as it is today, but only
the surfaces a scanner can see. Structure behind a bulkhead, inside a tank, or
under insulation does not appear. It also requires physical access to the vessel,
which usually means it is already in dock, which is exactly when you needed the
model.
* **Use the design model.** This assumes one exists, is complete, is editable, and
still describes the ship after decades of repair. For an in-service vessel, at
least one of those is almost always false.
Reconstruction takes the third path: build the model from the record that does
exist. Drawings, survey sheets, and inspection reports describe the whole ship,
including everything a scanner cannot reach, and they exist for vessels that were
never modeled at all.
## What a drawing sheet actually establishes
The central discipline is separating what a sheet **shows** from what a reader
might **assume** from it.
Take a main hatch. A plan sheet may establish the hatch perimeter clearly. That
same sheet says nothing about coaming plate thickness, cover layout, attachment
detail, or present condition. A longitudinal profile sheet may establish the
hatch's envelope in profile without defining its transverse section.
Both facts are real and useful. Neither is a complete description of the hatch.
Forge records that distinction explicitly. Each sheet contributes what it
establishes, scoped to what it establishes, and the reconstruction is built from
the intersection of those contributions rather than from one reader's overall
impression of the drawing set.
## The pipeline
Every drawing sheet, survey record, and report enters as a with its
version, its authority, and where it came from attached. Sources are locked
once admitted. They are never quietly edited to make a later result work.
Each sheet is interpreted into scoped claims: this perimeter, this station
spacing, this profile envelope. Every claim stays attached to the sheet and
region it came from, which is applied to drawings.
Plan, profile, and sectional views have to agree about the same physical thing.
Where they agree, the reconstruction is well supported. Where they conflict,
the conflict is recorded as a conflict. It is not averaged away, and neither
view is silently preferred.
Geometry is generated for what the sources establish. Where they do not
establish a shape, no shape is generated. The reconstruction is deliberately
bounded by its evidence rather than completed for appearance.
Every unresolved region becomes a selectable identity carrying its evidence
envelope and the specific question that would close it: which drawing, survey,
measurement, or observation is needed. Gaps are inventory, not absence.
Reconstructed components are checked against the vessel's own type and class
precedent. This is a consistency check that surfaces suspect results, not a
source of geometry. Precedent can flag that something looks wrong; it is never
used to invent what the drawings did not say.
A reconstruction is a proposal until an accountable person accepts it. Nothing
becomes approved engineering geometry on import.
## Why gaps stay visible
A reconstruction with no visible holes demonstrates better and is worth much less.
Once invented geometry is in a model file, it is indistinguishable from
evidence-backed geometry. Someone will eventually plan a repair against it, order
steel to it, or hand it to a surveyor. The failure surfaces at the worst possible
moment, and by then nobody can tell which parts of the model were ever real.
So an unresolved region in a Forge model does not disappear and does not get
filled. It stays as a question with a boundary around it. That makes the model
honest in both directions: it tells you what is supported, and it tells you
precisely where it is not.
It also makes collaboration concrete. A named gap is a specific research brief. A
partner with a better drawing, a current survey, or direct observation can close
one and see exactly what it changed.
## Time states stay separate
A ship's record spans decades, and different records describe different moments:
original construction, a later modification, one survey, a different scan years
later.
Forge does not merge these into a single confident model. Each remains a distinct,
labeled evidence state. One configuration serves as the primary assembly, and the
others stay available for comparison. Two records can both be accurate without
describing the same side, surface, date, or physical reference.
This is what makes it possible to ask a question that matters in repair work:
**what changed, and when.**
## From reconstruction to reconciliation
Reconstruction produces a model of the ship as the record describes it.
Reconciliation is the ongoing job of keeping that model true as inspection
findings, repairs, and retrofits change the vessel.
The same discipline carries across. A thickness measurement that disagrees with
the model is recorded as a located conflict, not an overwrite. A completed repair
updates the model through the same review gate as everything else.
A complete 1886 ship reconstructed from its historical drawing set, with all
of its open questions still visible and selectable.
What separates a picture of a measurement from a traceable engineering claim.
# How a Decision Gets Made
Source: https://www.docs.forgeshipyard.com/concepts/how-a-decision-gets-made
A worked example, from a drydock planning question to a signed decision.
**In plain terms:** Here is the whole life of one decision, start to finish.
Suppose a superintendent is planning an availability six months out. The last
survey recorded thickness readings in a ballast tank that look thinner than the
reconstructed shell plating suggests they should be. Does that section need steel
renewal?
## Why this example
This is the shape of most repair-planning decisions. It is not one clean lookup.
It requires reconciling a measurement against a model, working out which rule
governs, knowing how confident to be in each input, and getting a human to own the
answer. Getting it right six months early is worth a great deal. Getting it wrong
means either unnecessary steel work or a finding at survey.
## The walkthrough
The superintendent opens the affected tank in the model and asks Forge for a
renewal assessment against the applicable Class requirement.
Forge pulls together the reconstructed shell plating in that region and the
drawing sheets that established it, the thickness measurement records from the
most recent survey, the repair history for that area, the governing Class rule
at its current version, and any prior decisions recorded for the same
structure.
The measured readings are compared against the modeled plating. Where they
disagree, the disagreement is recorded as a located conflict tied to specific
components. Neither record silently overwrites the other. A reading taken last
year and a drawing from decades ago are both real, and the difference between
them is the finding.
The AI drafts an assessment: which rule applies and at which version, which
measurements support the diminution claim, which components are affected, and
what prior decisions on this structure it is relying on.
If it cannot support the assessment, it **stops and asks** rather than
producing a number. Perhaps the readings do not cover the frames in question,
perhaps the plating in that region is one of the reconstruction's open
questions rather than established geometry, perhaps two drawing sheets
disagree about the original scantling. Each of those is reported as the
specific thing that needs resolving. This is working as
intended.
The proposal then passes through an ordered set of checks. Fast, automatic checks
establish the evidence first; human and external review enter where required.
in action:
| Gate | Question it asks | What that means here |
| ---- | ------------------------------------------------------ | ------------------------------------------------------------------------ |
| T1 | Does every claim cite a source or evidence object? | Cite the Class rule, the survey report, and the drawing sheets |
| T2 | Is the rule applicable to this vessel context? | Confirm the rule fits this vessel type, service, and structural location |
| T3 | Are assumptions explicit and confidence usable? | Show which plating is established by evidence and which is assumed |
| T4 | Does the numeric claim cite a real measurement record? | Trace each thickness figure to the reading and the modeled component |
| T5 | Does the responsible engineer approve? | Human engineering review |
| T6 | Is Class or regulatory review required and complete? | External review where the decision requires it |
| T7 | Is the approved decision signed and recorded? | Create the final accountable ledger record |
Once the responsible engineer approves, with Class review included where
required, T7 records the decision with an , preserving the
full reasoning and evidence behind it. The renewal scope goes into the work
package with its justification attached, so the yard receives the reasoning and
not only the instruction.
Months later the vessel is in dock and the steel is exposed. The actual
condition is recorded against the decision. Did the assessment hold? Was the
renewal scope right, too large, or too small? Did the surveyor agree? That
outcome is captured as evidence, and it also updates the model for the next
cycle.
## If any gate fails
If the proposal fails any gate, it simply does not become a decision. The failure
is logged with its reason, and the engineer sees exactly what was missing. Nothing
half-checked ever slips through into a work package.
## Why the order matters
Running the automatic checks first means most incomplete proposals are caught early,
before they consume engineering or surveyor time. High-risk output requires
responsible-engineer review, and Class review is included whenever the decision
requires external authority. The final gate records the approved result; it does not
replace those reviewers.
## What the record is worth later
Two years on, a different superintendent at a different yard can open that same
structure and see that the section was renewed, under which rule version, on the
strength of which readings, approved by whom, and whether the outcome matched the
assessment.
That is the difference between a repair history and a folder of work orders.
# How CAD Becomes Engineering Evidence
Source: https://www.docs.forgeshipyard.com/concepts/how-cad-becomes-engineering-evidence
How Forge turns a 3D model into measurements that engineers and reviewers can trace, inspect, and trust.
**In plain terms:** A 3D model can show what a ship looks like, but a picture alone
cannot prove a clearance, a thickness, or a clash result. Forge preserves the chain
from the source, whether that is an imported CAD file or geometry reconstructed
from drawings, to the number, the rule, the reviewer, and the final decision.
## The difference between a picture and evidence
A 3D viewer is valuable for understanding location and context. It helps a reviewer see
which compartment, component, or opening is being discussed. But the triangles used to
draw a fast picture on a screen are an approximation of the engineering shape.
Forge therefore keeps two related representations:
| Representation | What it is for | What it is not allowed to do |
| ------------------------ | --------------------------------------------------------- | ------------------------------------------------- |
| **Engineering geometry** | Calculating measurements from the imported CAD shape | It is not silently altered to make a result pass |
| **Display model** | Fast viewing, highlighting, annotation, and collaboration | It is not the authority for an engineering number |
The display model helps people see the issue. The engineering geometry supplies the
evidence.
## The evidence chain
For an imported file, Forge records the file, its format, its digital fingerprint
(a hash that distinguishes that exact file version), its units, and how it entered
the system. For STEP assemblies, it also preserves each component occurrence and
its position in the assembly.
For geometry reconstructed from drawings, the source is the drawing set itself.
Forge records which sheets and which regions of those sheets established the shape,
so a reconstructed component is traceable in exactly the same way an imported one
is. See [From Drawings to a 3D Model](/concepts/from-drawings-to-3d).
A geometry kernel is the software that reads and calculates over the underlying CAD
shapes. It computes the requested result, such as a volume, a principal dimension,
or the clearance between two components.
Forge stores the result as a measurement record rather than passing around a loose
number. The record includes the value, unit, method, source model, import, and exact
geometry objects involved. This is applied to geometry.
Any formal claim such as “the clearance is 8 mm” must cite the identifier of that
measurement record. Forge can then verify that the record exists and belongs to the
same vessel and model scope.
The cited claim moves through the verification ladder and responsible human review.
Once approved, the final decision preserves the evidence chain that supported it.
## Clearance, contact, and clash
These terms sound similar but lead to different engineering actions:
A positive distance exists between two components. The stored result states the
distance, unit, measured objects, and source model.
The calculated clearance is zero: the components touch. Whether that is intended is
an engineering question, so the context remains visible.
The components overlap. Forge raises a review flag rather than inventing a negative
clearance or presenting an uncertain result as settled.
## Evidence state travels with the geometry
In repair work the same model holds components of very different standing. A frame
established clearly by two agreeing drawing sheets is not the same kind of object as
one inferred from a single ambiguous profile, and neither is the same as a region
that remains an open question.
Forge keeps that standing attached to each component rather than flattening
everything into one uniform-looking model. Selecting a part shows what supports it,
what was assumed, which moment in the vessel's life it describes, and what would have
to be resolved to strengthen it.
This is what makes the difference between a model you can plan a repair against and a
model that merely looks complete.
## What happens when the source is uncertain
Imported CAD is not automatically authoritative. Units can be missing, scale can be
ambiguous, and some files require repair before they can be read. Repair can also change
the shape. Drawings carry their own version of this problem: a scanned sheet can be
illegible in the region that matters, and two sheets can contradict each other.
When that uncertainty could affect a measurement, Forge stops before creating the
measurement record and identifies what needs review. Once the source or import question
is resolved, the calculation can run from a known basis.
This is an important trust behavior: **Forge does not allow the precision of a displayed
number to hide uncertainty in the model that produced it.**
## Why this matters to different reviewers
See whether readiness claims are supported by evidence and where review effort is
concentrated, without needing to inspect the model themselves.
Move from a flagged issue to the exact components, measurement, model version, and
governing requirement behind it, while there is still time to plan around it.
Follow a claim back through its cited measurement and source instead of receiving an
unexplained number or screenshot.
Keep the source model and its evidence chain inside the approved environment, with
access and processing governed by sensitivity.
The next step in the chain is the governed decision itself. See
[How a Decision Gets Made](/concepts/how-a-decision-gets-made).
# Where Humans Stay in Control
Source: https://www.docs.forgeshipyard.com/concepts/human-control
The decisions that always belong to a person, by design.
**In plain terms:** Forge's AI can do a lot of the legwork, but certain decisions
always belong to a human. This is built into the structure of the system, not left
as a setting someone could turn off.
## The three operating principles
Every design choice in Forge maps back to one of three principles:
Every document that enters Forge is graded by trust level before it is used. A
claim that a rule applies must cite that rule and its version. A reconstructed
component must cite the drawing sheets that established it. Nothing the system
says is ungrounded, and nothing is generated to fill a gap the sources left
open.
Every engineering decision is recorded with the inputs it was made from, the
rule version it was made under, the evidence it cited, who made it, and a
signature that makes it tamper-evident. When a rule later changes, the system
can find every decision that needs re-checking.
The AI can reconstruct, reconcile, measure, retrieve, compare, draft, flag, and
propose. It cannot be the engineering authority. Decisions touching Class,
Coast Guard rules, or safety always pass through a human approval gate. This is
not a setting that can be disabled.
## What humans always own
The system is intentionally designed so that humans remain authoritative on:
Every decision touching Class or Coast Guard rules requires human approval at
the final gate, by structure.
Reconstructed geometry is a proposal until an accountable person accepts it. It
does not become approved engineering geometry by being imported, rendered, or
looking convincing.
When a drawing, a scan, and a survey disagree, Forge surfaces the conflict with
its evidence. Which record governs is an engineering judgment, and a person
makes it.
Every change to the underlying model of what kinds of things exist is governed
by humans, never by the AI.
Every change to the catalog of allowed AI moves goes through a review checklist
before it ships.
Every sign-off that a work package is ready to execute is a human decision.
## Abstention is a feature, not a bug
A key part of keeping humans in control is that the AI is built to **stop when it
is unsure.** is treated as a quality behavior. If the AI cannot find
the evidence it needs, it asks for more rather than guessing. The system is held to
a high bar for doing this well (a target of better than 98%).
The result is an AI that is **boxable, auditable, and reversible.** If a behavior
turns out to be wrong, it gets rolled back like any other versioned software
change, never patched on the fly. For the full list of limits, see
[What Forge Will Not Do](/start-here/what-forge-wont-do).
# Keeping Your Data Yours
Source: https://www.docs.forgeshipyard.com/concepts/keeping-data-yours
How Forge protects sensitive vessel data and keeps every customer isolated.
**In plain terms:** Structural drawings, survey records, and condition data are
among an owner's most sensitive assets, and some are defense-related. Forge is
built so that sensitive data is processed on your own infrastructure and never
leaves your environment, and so that no customer can ever see another customer's
vessels.
## Why this is the hardest constraint
Reconstruction requires the sensitive material by definition. To rebuild a ship's
structure you need its drawings, its survey history, and its condition data. That
is precisely the material an owner is least willing to hand to a shared cloud
service, and reasonably so. It describes the vessel's weak points.
So Forge treats data sensitivity as a **versioned policy, not a runtime preference.**
It is enforced by the system, not left to good intentions.
## Where it runs
Deployment is designed so the sensitive path can stay inside your own environment:
* **On-premise.** Forge runs on your infrastructure, and the drawings, model, and
evidence chain never leave it.
* **Private cloud.** A dedicated environment under your own controls, for teams
that would rather not host it themselves.
Models export to open formats, STEP and glTF, with OCX for structural exchange, so
what Forge produces belongs to you and moves wherever you need it.
## Four sensitivity classes
Every source and every AI request carries one of four sensitivity classes, and the
class decides where it is allowed to be processed:
| Class | What it covers | Where it can go |
| ---------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **Public** | Reference rule text, public datasets, published papers | Any model provider |
| **Internal** | Forge's own schemas, prompts, evaluations | Any provider |
| **Confidential** | Customer-provided non-defense data: commercial vessel drawings, survey and repair records | Local (your own infrastructure) by default; external only with explicit redaction and a fidelity check |
| **Restricted** | Coast Guard, Class, defense-adjacent, and IP-sensitive implementation specifics | **Local only. Never external.** All outside providers blocked. |
Every model call records a policy evaluation: the sensitivity class, where it was
routed, whether redaction was applied. A sensitive payload reaching an outside
provider against policy is treated as a top-severity incident, the same level as a
fabricated result.
> "Zero bytes of restricted data crossed the boundary" is something you can check,
> not just something you hope.
## One customer never sees another
Forge serves many customers from the same software, but with rigorous
. Each one sees only its own vessels, drawings, decisions, and
outcomes.
This isolation is enforced at the **database layer**, not just in the application
code. Even a bug in the application cannot leak data, because the database itself
refuses to return rows that do not belong to the current customer. The standard it
holds itself to: any hand-crafted attempt to retrieve another customer's data must
fail by construction, no matter who runs it.
This matters more than usual here, because vessels move between yards constantly
while the data has to stay with the owner. A yard working on your ship sees the
scope it has been given for that job. It does not see the rest of your fleet, and
another owner's yard never sees any of it.
## Nothing trains on your fleet without permission
Reconstruction improves with data, which creates an obvious temptation. Forge does
not act on it. A customer's vessels, drawings, and decisions are not used to train
or improve anything without that customer's explicit consent, and consent is
recorded rather than assumed from a terms-of-service line.
## Every value traces back to its origin
Forge also keeps full . A thickness or clearance value is not just a
number; it traces back to the service that computed it, to the geometry it was
computed from, to the drawing sheet or file that geometry came from, to the version
of that source, and to the engineer who committed it. Combined with the
cryptographic signature on every decision, this is what makes a Forge result
defensible in front of a surveyor, an owner, a regulator, or a court.
# Sources vs. Decisions
Source: https://www.docs.forgeshipyard.com/concepts/sources-vs-decisions
The two kinds of things Forge handles, and why keeping them separate is the point.
**In plain terms:** A **source** is something that comes in (a drawing sheet, a
survey report, a Class rule). A **decision** is something the system reasons out
from those sources. Forge keeps them in separate places on purpose.
## Sources: what comes in
A is any input: drawing sheets, survey and inspection reports,
thickness measurement records, Class rules, CAD files, repair histories,
datasheets. Two things are always true of a source:
* It is **immutable once ingested.** Once a source is in the system, it is locked.
It is never quietly edited to make a later result work out.
* It carries its **version, authority, provenance, and moment in time.** The system
always knows which edition of a rule this is, which survey this came from, how
much weight it carries, and exactly where it came from.
That last property matters more in repair than in design. A 1994 drawing and a
2024 thickness report both describe the same ship, and the difference between them
is frequently the whole point.
## Decisions: what gets reasoned out
A **decision** is what the system concludes *from* sources: that a reconstructed
component is supported by the drawings, that a rule applies, that two records
conflict, that a repair changed the structure, what it replaced.
Decisions are first-class objects. They live in the with their
own structure, their own life cycle, and their own . And
critically, a decision is **replayable**: given the same sources at the same
versions, the same decision should be reconstructable from scratch.
## Three trust levels for sources
Not every source carries the same weight. Every source in the registry is tagged
with one of three trust levels:
| Trust level | What it means | Example |
| ------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Authority** | Binding for this vessel, jurisdiction, or scope | Class rules, USCG CFR sections, flag state requirements, owner standards within their domain |
| **Evidence** | A factual record about this vessel, but not itself binding | Measured drawings, survey and inspection reports, thickness measurements, completed repair records, scans |
| **Reference** | Informational only, never sufficient on its own | Sister-ship records, rules not applicable to this vessel, research datasets, vendor literature |
Note where drawings land. A drawing is **evidence about the ship**, not authority
over it. It records what someone measured or intended at one moment. When a
drawing and a recent survey disagree, that is a conflict between two pieces of
evidence to be resolved, not a rule being broken.
This trust grade is also **separate from the document type.** The same Class rules
can be *authority* for one vessel and *reference* for another under a different
society or flag. A sister ship's records are evidence when reasoning about that
hull and reference when reasoning about this one.
## The rule that ties it together
Every claim the system makes must cite its source. A claim that a rule applies
cites that rule and its version. A claim about a dimension cites the measurement
record. A claim that a component is supported by the drawings cites the sheets and
regions that support it.
> Nothing the system says is ungrounded.
That is what makes a decision defensible later: you can always trace it back to the
exact sources, at the exact versions, that produced it.
# The Two-Clock Problem
Source: https://www.docs.forgeshipyard.com/concepts/two-clock-problem
The single idea that the whole system is built around.
**In plain terms:** Most software can tell you *what a ship is supposed to be
today*. Almost none can tell you *how it got that way and what changed*. In repair
work, the second question is the expensive one.
## Two different clocks
Every vessel is really running two clocks at once.
Answers **"what does the ship consist of right now?"** The current model, the
current bill of material, the structure as it stands. CAD and maintenance
systems handle this clock reasonably well, as long as somebody keeps them
updated.
Answers **"how did it get this way?"** Which drawing established this
structure, what the last survey found, which repair replaced what, who
approved the change, what evidence supported it. Almost no system handles this
clock at all.
## Why the second clock matters more in repair
For a new build, the state clock is nearly enough. The ship is being created,
everyone involved was there, and the design intent is fresh.
For a vessel that has been in service for 20 years, the state clock is the part
you cannot trust. Nobody kept it updated. The drawings describe the ship as
delivered, the CAD file describes some moment in between, and the steel describes
today. The state clock has quietly gone wrong, and there is no way to tell where
without the event clock.
That is why the questions that actually come up in repair planning are event-clock
questions:
* "Was this section renewed in the last availability, or is that plate original?"
* "The scan disagrees with the drawing here. Which one is more recent, and which
one was measured?"
* "This structure was accepted under the previous rule version. Does the update
change it?"
* "Why was this repair done this way last time, and did it hold?"
None of those can be answered from a snapshot of current state. They need the
history of how the state came to be.
## Reconstruction needs both clocks
This is also why a reconstructed model cannot be just geometry.
If reconstruction produced only a state, you would have a ship-shaped file with no
way to tell which parts came from a clear drawing, which came from a contradiction
between two sheets, and which are still open questions. Every part would look
equally certain, and none of it would be checkable.
So Forge carries the event clock alongside the geometry from the very beginning.
Every reconstructed component keeps the sheet it came from, the interpretation
applied, the conflicts encountered, and its current evidence state. The
at the core of the system records the reasoning chain, not just
the result.
## What this buys you
Because the event clock is preserved, the model can answer questions a static
model cannot:
| Question | What answers it |
| ------------------------------------------------------------- | --------------- |
| What is on the ship today? | State clock |
| Which parts of this model are actually supported by evidence? | Event clock |
| What changed since the last availability, and why? | Event clock |
| A rule was updated. Which past decisions need another look? | Event clock |
| Where should the next survey or drawing effort go? | Event clock |
That is the whole idea in one sentence. The rest of the Concepts section unpacks
how Forge makes it work in practice:
How 2D sheets become bounded geometry with the gaps left visible.
The two kinds of things Forge handles, and why the distinction matters.
A worked example, step by step, from a drydock question to a signed decision.
How a model becomes a traceable measurement and a reviewable claim.
# When the Rules Change
Source: https://www.docs.forgeshipyard.com/concepts/when-rules-change
How Forge handles a rule update without forcing a manual re-audit of everything.
**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:
The new version comes in with its version information attached, so the system
knows precisely what changed and when.
Forge marks the prior version as superseded and identifies that a change has
occurred.
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.
Not every affected decision needs the same attention:
The new version does not change the outcome. The prior decision stands,
with a note.
The new version *might* change the outcome. An engineer needs to look.
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.
# Glossary
Source: https://www.docs.forgeshipyard.com/glossary
Plain-language definitions of every term used across the Forge docs. Look up a word here, then jump back to where you were.
**How to read this page.** These are the same terms you will see throughout the
docs. On most pages, the first time a term appears it is **underlined** and shows
this definition when you hover over it, so you rarely need to leave the page you
are on. This glossary is the full list, in alphabetical order, for when you want
to look something up directly.
## A
**ABS (American Bureau of Shipping)**
One of the major classification societies that publishes binding ship-design rules.
**Abstention**
When the AI declines to answer because it is not confident enough. In Forge this
is treated as a *good* behavior. A high-quality system abstains often when the
information it needs is missing, rather than guessing.
**Append-only**
Data that can be added to but never modified or deleted. Corrections happen by
adding a new record that supersedes the old one, so the full history is always
preserved.
**As-built / as-repaired**
The ship as it was actually constructed, and as it actually stands after repair
work. Both routinely differ from the drawings, which is the gap Forge exists to
close.
**Audit signature**
A cryptographic proof (Forge uses a scheme called Ed25519) that a specific
decision was made by a specific person at a specific time, and has not been
altered since.
**Authority level**
The trust grade given to a source. Three values: **authority** (binding),
**evidence** (a factual record about the vessel), and **reference**
(informational only).
**Availability**
A scheduled period in which a vessel is taken out of service for repair and
maintenance work. The planning window Forge is designed to serve.
## C
**Calibration**
Whether the AI's stated confidence matches its actual accuracy. A well-calibrated
system that says "90% confident" is right 90% of the time. Forge tracks this
explicitly.
**Capability**
A named, versioned, rule-bound move the AI is allowed to make (for example,
"retrieve prior similar designs" or "draft a rule applicability assessment").
Each one has a defined input, output, confidence threshold, and autonomy limit.
The AI cannot invent new moves on the fly.
**CAD (Computer-Aided Design)**
The software used to author drawings and 3D models (ShipConstructor, AutoCAD,
CADMATIC, Rhino, AVEVA, and others).
**CFR (Code of Federal Regulations)**
Where USCG rules are written down in law.
**Class / Classification society**
An organization that sets and verifies structural and safety standards for
vessels, and surveys ships against them on a fixed cycle. ABS, DNV, and Lloyd's
Register are examples. A ship out of class is generally uninsurable and
uncharterable.
**Cost-asymmetric verification**
Running fast, automatic evidence checks first, then bringing in engineers, Class,
or regulators once the proposal is ready for their attention. This protects
specialist review time without reducing human authority.
## D
**Dead CAD**
A 3D file that can no longer be used as a model: a format nobody supports, a
frozen export, or a single fused solid with no part boundaries or structure. You
can look at it, but you cannot change or decompose it.
**Decision ledger**
The append-only record of every engineering decision and the reasoning behind it.
**Diminution**
Loss of material thickness over time, usually from corrosion or wear. Measured
against original scantlings to decide whether structure needs renewal.
**Drydock**
Taking a vessel out of the water so underwater and structural work can be done.
The most expensive and most schedule-sensitive part of most repair work, and the
point at which unknown scope becomes costly.
## E
**Ed25519**
A modern, fast, well-studied cryptographic signature scheme. What Forge uses for
audit signatures.
**Evidence**
A source that records a fact about the vessel but does not by itself authorize an
engineering choice (for example, a measured drawing or a survey report).
**Evidence state**
What stands behind a particular component in the model: which sources support it,
what was assumed, which moment in the vessel's life it describes, and what remains
unresolved. Carried per component rather than assumed for the model as a whole.
## G
**glTF**
A lightweight standard format for display geometry. Used for fast viewing and
sharing, never as the authority for an engineering number.
## I
**IACS (International Association of Classification Societies)**
The umbrella body for the classification societies, including ABS.
**Idempotent**
Safe to retry. An idempotent operation produces the same result whether it runs
once or five times, so a network hiccup that causes a retry does not create
duplicate decisions.
**IMO (International Maritime Organization)**
The UN body that publishes international maritime conventions.
## K
**Knowledge graph**
Data stored as connected, typed objects (nodes and the relationships between
them) rather than as rows in tables. Forge's model of a vessel lives as a
knowledge graph.
## L
**LiDAR / point cloud**
Laser scanning of a physical space, producing a dense cloud of measured points.
Captures current condition accurately, but only for surfaces the scanner can see,
and only once the vessel is physically accessible.
## M
**Measurement result**
A record of a numeric geometry value computed by the geometry service. Any
numeric geometry claim in Forge must point to one of these.
**Multi-tenancy**
One software system serving many customers, with each customer's data rigorously
isolated from the others.
## O
**Observe-only mode**
The starting posture for a new deployment. The AI reconstructs, reconciles, and
flags, but nothing it produces is treated as authoritative. Lasts about 90 days
minimum.
**OCX (Open Class 3D Exchange)**
An open format for exchanging ship structural data between systems without
flattening it into plain geometry. Forge supports it so structural information
stays structural on the way out.
**Offhire**
Time a vessel spends unable to earn because it is out of service. A drydock
overrun driven by unexpected scope is offhire.
**Ontology**
A structured model of what kinds of things exist in a domain and how they relate.
For ships: "a Vessel has Hulls; a Hull has Compartments; a Compartment contains
Systems," and so on.
**Open question**
An unresolved region of a reconstruction, kept in the model as a named, selectable
identity with its evidence envelope and the specific question that would close it.
Forge records these rather than generating geometry to cover them.
## P
**Port engineer**
The person on the owner's side responsible for a vessel's technical condition,
repair planning, and budget. One of the primary users of Forge.
**Provenance**
Knowing where every piece of data came from and what was done to it along the way.
**Pydantic**
A Python tool for defining and checking the shape of data. Used inside Forge.
## R
**RAG (Retrieval-Augmented Generation)**
Giving an AI the relevant documents to ground its answer, instead of letting it
rely on memory.
**Reconciliation**
Keeping the 3D model true to the ship as repairs, retrofits, inspections, and
drydock work change it. The continuing half of Forge's job, as opposed to the
one-time reconstruction.
**Reconstruction**
Building a structured 3D model of an existing vessel from the record that exists:
legacy 2D drawings, dead CAD files, and inspection reports. Bounded by what the
sources establish, with everything unresolved recorded as an open question.
**Reference**
A source that is informational only and never sufficient on its own to make a
decision.
**Row-Level Security (RLS)**
A database feature that enforces who can see which rows at the database itself.
How Forge keeps each customer's data isolated even if the application has a bug.
**Rule supersession event**
What gets created when a new rule version replaces an old one, triggering a
re-check of past decisions.
## S
**SHACL**
A standard for validating knowledge-graph data. The graph-layer counterpart to
Pydantic.
**Scantlings**
The dimensions of a ship's structural members: plate thicknesses, frame sizes,
stiffener spacing. What diminution is measured against.
**Sensitivity class**
The four-tier classification (public / internal / confidential / restricted) that
controls where a piece of data is allowed to be processed.
**Sister ship**
A vessel built to the same design as another. Sister ships share structure, so a
component resolved on one hull can inform the next instead of being reconstructed
from scratch.
**Source**
Anything that comes into the system as input: drawing sheets, survey reports,
rules, CAD files, datasheets. Sources are locked once ingested and carry their
version, authority, and moment in time.
**Special survey**
The major Class inspection, carried out on a five-year cycle, at which a vessel's
structural condition is examined in depth. The event most repair planning is
organized around.
**STEP / IGES**
Standard file formats for exchanging engineering CAD geometry. Forge reads and
writes STEP in both directions.
**Superintendent**
The person managing a vessel's repair work in practice, often on site at the yard
during an availability. Along with the port engineer, a primary user of Forge.
**Supersession**
Replacing a prior decision or rule version with a new one while keeping the link
back to what was replaced.
**Survey cycle**
The mandated five-year rhythm of Class inspection every commercial vessel runs on.
It is what makes reconciliation a continuing need rather than a one-time project.
## T
**Tenant**
One customer in a multi-tenant system.
**Tenant ID**
The field on every record that says which customer owns it. Enforced at the
database layer.
**Thickness measurement**
A recorded reading of remaining material thickness, typically taken by ultrasonic
gauging during survey. Compared against original scantlings to assess diminution.
## U
**USCG (United States Coast Guard)**
The US regulator for commercial vessels in US waters.
## V
**Verification ladder**
The ordered sequence of checks that runs on every AI output before it can become
an authoritative decision, ending in human sign-off when required.
## W
**Work package**
A defined scope of repair work handed to a yard for execution. Forge attaches the
evidence and reasoning behind a scope to the package, so the yard receives the
justification and not only the instruction.
# Reconstructing Balclutha
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-evidence-workbench
We rebuilt an 1886 ship in 3D from its original drawings.
**The short version:** We took the original drawings of a ship built in 1886
and rebuilt it as a 3D model you can open in a browser, pull apart, and put
back together. Where the drawings were clear, we built the part. Where they
ran out, we left a labelled question instead of inventing something that looks
right. You can click on any piece and see which drawing it came from and what
we still do not know.
## The research question
Can a historical ship record become a vessel that people can inspect, take apart, reassemble, challenge, and correct without turning gaps in the record into false certainty?
That question led to several smaller ones:
* Can we keep the source drawing, our interpretation, the generated geometry, and the review decision separate?
* Can a person trace any visible part back to its evidence and see what remains uncertain?
* Can the vessel be decomposed and recomposed without losing identities or relationships?
* Can the system stop safely when a file, unit, source, or claim is unsupported?
* Can another researcher reproduce the bounded result from a clean starting point?
## Why an 1886 ship proves something about a modern one
The obvious question about this research case is what a Victorian sailing ship has
to do with a tanker in drydock next quarter.
The answer is that the hard part of reconstruction is not the era of the vessel. It
is the state of the record. Balclutha's record has exactly the properties that make
a modern in-service ship difficult: drawings produced by different hands at
different times, later modifications that were never fully documented, surveys taken
decades apart that do not describe the same physical reference, and regions where
the sources simply run out.
Those are the same conditions a 20-year-old commercial vessel presents. Working
from a historical record also let us test the pipeline against a rich, complete,
publicly available source set, and publish the result openly, which we could not do
with a customer's fleet.
What Balclutha demonstrates is therefore transferable: that a legacy 2D drawing set
can become a structured, decomposable 3D model, and that the parts the drawings do
not support can stay visible as questions instead of being quietly invented.
## Why this ship
Balclutha is a three-masted steel sailing cargo ship built in 1886. She is
complex, historically significant, and very well documented.
The [survey held by the Library of Congress](https://www.loc.gov/pictures/item/ca1493/)
contains **71 measured drawings and 240 pages of written records**, plus
photographs. It was produced by the Historic American Engineering Record, a US
government programme that documents historic structures in detail. All of it is
public.
That gave us drawings covering the whole ship rather than one isolated part: the
hull, the decks, the structure inside, the openings, the fittings, and the rigging.
It also gave us the contradictions and missing details that any real project has.
## What we worked from
We used those 71 drawings and 240 pages, and we listed every one of them up front
so the set could not quietly grow later.
The important thing is that these records **do not all describe the same ship.**
The vessel changed over the decades, and the records were made at different moments:
| When | What it is |
| ---- | ------------------------------------------------------------------------------------- |
| 1886 | When she was built |
| 1988 | The full measured survey. The most complete record, so we used it as the main version |
| 1998 | A survey of the left-hand side only, taken with a surveying instrument |
| 2020 | A laser scan of the hull |
We keep these separate rather than blending them together. A 1988 measurement and
a 2020 scan can both be correct and still disagree, because the ship changed in
between. Averaging them would produce a confident number describing a ship that
never existed.
**About the online viewer:** it loads simplified versions of the shapes so it
stays fast in a browser. The full-resolution drawings and the precise
engineering geometry stay in our own records. Partly that is for speed, and
partly because we are only cleared to publish some of the original material.
## What we built
The finished model covers four parts of the ship:
1. **The hull**, the outer shape of the vessel.
2. **The structure inside it**: decks, bulkheads, framing.
3. **Everything above deck**: deckhouses, hatches, openings, equipment.
4. **The rigging**: masts, spars, and the ropes and wires that hold them.
The assembled vessel carries 114 selectable items. 65 are parts of the ship; the
other 49 are gaps, places where the drawings ran out and we recorded a question
rather than building something. A further 136 recorded relationships describe how
those items connect to each other.
Of the 114, forty-four own an actual 3D shape, built from 307 individual solids.
The remaining 70 have no shape, because the sources do not establish one. They stay
selectable, and selecting one shows what is established and what still needs
answering. A gap is not a hole in the picture; it is a labelled item you can read.
### The test slice at Frames 60-62
A ship has ribs, numbered from front to back. "Frames 60 to 62" means the section
between rib 60 and rib 62: **one slice of the ship, near the middle, a couple of
metres long.**
We reconstructed that slice first and reconstructed it exhaustively, as the
controlled case for the whole method. Every piece traces back to the drawing it
came from. It holds 32 components and 18 recorded connections between them. We then
took it apart and rebuilt it, to confirm nothing was lost in the process.
The verified slice now sits inside the full-vessel assembly without being reduced
to match its less-verified surroundings. The slices either side of it, Frames 58-60
and Frames 62-64, have not passed the same checks and are shown as unverified until
they do. Frames 62-64 is our current gate.
## What the Workbench proves
The Workbench proves that a research vessel can be more than a picture. A reader can:
* browse the complete vessel hierarchy;
* select reconstructed geometry or a named unresolved identity;
* isolate, hide, and restore parts and families;
* inspect cutaway and exploded presentations;
* move from vessel to system, assembly, and part;
* review evidence state, assumptions, measurements, and correction questions;
* recompose the governed inventory without losing its 114 identities or 136 relationships.
An unresolved selection does not disappear. It shows the evidence envelope and the question that must be answered before stronger geometry can be claimed.
The full-screen viewer, where you can inspect, filter, isolate, cut open, and
reassemble the ship.
## Where partners can take the work further
The vessel is visually complete because unresolved regions remain represented and selectable instead of disappearing. Each one is a practical research brief for the next drawing, survey, restoration record, or expert review.
The strongest opportunities for collaboration include:
* extending the complete visual assembly toward exact as-built geometry;
* adding present-condition surveys and direct observations;
* completing plate, connection, scantling, and material schedules;
* resolving drawing-to-drawing relationships with stronger survey control;
* connecting the research vessel to hydrostatics, structural analysis, class review, and production workflows;
* closing local evidence boundaries, beginning with the next Frame 62-64 gate;
* separating and comparing original, surveyed, modified, restored, and present configurations.
Every added source can strengthen a named part of the vessel instead of disappearing into an undocumented model update.
## How we built confidence in the result
We tested more than whether the vessel looked plausible on screen. Four checks stand behind the result.
We rebuilt the complete vessel in a clean, empty environment from the declared drawings alone, then compared that rebuild against the original in detail. The two matched, which places the result in the recorded process rather than in undocumented manual correction along the way.
We ran both a valid STEP file and a deliberately malformed one. The valid file produced geometry that stayed within its evidence. The malformed file stopped before it could emit geometry, measurements, or downstream work, rather than producing a partial assembly that still reads as finished.
We checked the finished ship against a complete part list. Before assembling the vessel, we listed every component the 71 drawings mention, then verified the assembled model against that list. Every listed part had to end up in one of two states: reconstructed, or carried as a labelled question. Parts that were absent, duplicated, or unclassifiable failed the check, so nothing could silently go missing.
We ran mutation tests against the inputs. Removing a source, corrupting a component's identity, concealing an omission, stripping a publication approval, and promoting a research result to approved status were each required to fail and stop. Publication approval here is copyright clearance, held item by item, with anything unapproved or ambiguous withheld by default. Approved status is the boundary this vessel does not cross: no engineer has certified it, and the process cannot present it as certified.
This gives collaborators a dependable starting point: the research record is inspectable, its replay is reproducible, every declared part is accounted for, and unsupported changes cannot quietly become accepted engineering output.
## What this means for a fleet owner or a shipyard
Forge is built to deliver four things: [faster drydock planning, no Class surprises, less office workload, and a trusted record](/start-here/why-it-matters). All four depend on one thing being possible first: that a reliable 3D model can actually be built from the messy records a real ship has. That is the claim this case tests.
Balclutha's records have the same problems as any working ship's. The drawings were made by different people at different times. The ship was modified without the drawings being updated. The surveys disagree with each other. We rebuilt her anyway. Each outcome below points to the part of the finished model that demonstrates it, so none of this is taken on trust.
**Faster drydock planning.** The reason drydock jobs blow up is that the real condition of the ship is discovered after the hull is opened, when the schedule is already fixed. This model shows the alternative: before any work starts, it already tells you which parts are established and which 49 are unknown. On a paying job, that list of unknowns is the drydock surprise, found during planning instead, while there is still time to order a survey or adjust the scope.
**Less office workload.** Reconciling the records was the work of this project: 71 drawings and 240 pages of survey notes, cross-referenced into one model, with records from different decades kept separate instead of blended. That cross-referencing is exactly what a technical department does by hand before every planning cycle today. Balclutha shows the system doing it.
**No Class surprises.** A surveyor's finding is only a surprise if you did not know the state of your own vessel and its documentation. In this model, every part shows what supports it and every gap is declared. An owner with that picture knows what the surveyor will find before the surveyor arrives.
**A trusted record.** Nothing in the model is unsourced. Every part traces to the drawing that established it, every gap is admitted rather than papered over, and the four checks above prove the whole thing can be rebuilt and audited. That is what makes the model something you can put in front of a surveyor or a yard, rather than one more document that might be wrong.
One caution: this is a research reconstruction, not certified engineering. Using it for design or fabrication still requires qualified engineers to review and sign it, and Forge keeps that step explicit.
## What we are building next
The immediate research gate is the next slice along, Frames 62 to 64. Three larger pieces of work sit behind it.
**Internal structures and machinery.** The hull is only the envelope. Most repair scope lives inside it, in the piping and the machinery spaces. We are extending the same drawing-to-3D route to those systems.
It is harder than hull structure. Hull geometry is continuous and heavily constrained by naval architecture, which gives a reconstruction something to check itself against. Piping has none of that. It is densely packed, and every draughtsman drew it differently. It also gets altered constantly without anyone updating the sheet.
**Dead CAD into editable models.** Plenty of vessels do have a 3D file. It just cannot be used, either because the format died or because the whole ship arrives as one fused solid with no part boundaries in it. The work here is recovering those boundaries and handing back geometry an engineer can edit. You cannot plan a steel renewal against a model you can only rotate.
**Back out to 2D.** The reverse direction matters as much as the forward one. Fabrication does not run from a model, it runs from drawings. A shop that cannot get a usable drawing out of a system will not adopt the system, whatever the model is worth back in the technical department.
So we are building the return path: sections and part drawings generated from the reconstructed model, each still carrying the source behind it. That is what gets this work past the office door and onto the plate.
From the complete vessel down to the hull, the structure, the fittings, and
the rigging.
How 2D drawings become 3D shapes, and why the gaps stay visible.
How a figure stays connected to the drawing, the model, and the person who
approved it.
The public Library of Congress survey we worked from.
# Seven Balclutha Reconstruction Studies
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies
Seven governed views of one complete visual research vessel.
These seven studies show how one evidence-backed vessel can be explored at different levels, from the complete sailing ship to a bounded structural bay. Each view highlights what Forge can already reconstruct and where a design or data partner can help us go further.
## One vessel, seven research views
The complete Balclutha research vessel is easier to question when its evidence can be viewed at different levels. These seven studies keep the same governed identity register while changing only the presentation.
Assembly and exact recomposition.
Exterior form hypothesis.
Sectional organization and reference lines.
Governed cutaway and isolation.
Bounded decomposable assembly.
System-level research view.
Hierarchical decomposition and explosion.
## A shared path from research to design
The studies are interactive research views built for exploration, comparison, and correction. Their display-ready data keeps the experience fast and accessible, while deeper source material and engineering transitions remain governed. With additional drawings, surveys, and accountable review, each study can become a stronger input to design and restoration decisions.
Switch between all seven views in the Evidence Workbench and see how the same vessel changes from assembly to structure, systems, and rigging.
Read the full story, source foundation, evidence model, and collaboration opportunities behind the vessel.
# Above-Deck and Outfitting
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/above-deck-outfitting
System-level views of openings, superstructure, accommodation, and visible outfitting.
## What you can explore
Openings, closures, superstructure, accommodation, and visible outfitting appear as separately inspectable systems. The view shows how above-deck features give the vessel its operational and historical character.
## What Forge has demonstrated
Each represented system retains its evidence state, source references, historical state, and correction question. A viewer can move from the full silhouette into the evidence behind an individual feature.
## What a partner could unlock
Arrangement drawings, equipment records, photographs, restoration documentation, and current surveys could add hidden interiors, fitting detail, configuration history, and present condition.
Open the interactive studies and choose Above-deck and outfitting.
# Complete Vessel
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/complete-vessel
Assembly and exact recomposition of the complete visual research vessel.
## What you can explore
The hull, internal structure, above-deck systems, and rigging come together as one complete visual research ship. You can move from the vessel to its systems, separate the layers, and return to the recomposed assembly.
## What Forge has demonstrated
The study retains all 114 governed identities and 136 relationships. Exact reset restores the accepted identity register, giving collaborators a stable vessel-scale foundation for review and correction.
## What a partner could unlock
Additional as-built records, current surveys, and accountable engineering review could strengthen the visual assembly into a more exact statement of configuration, condition, and structural intent.
The complete vessel shows how evidence, geometry, questions, and corrections can stay connected while a research reconstruction matures toward an approved engineering model.
Open the interactive studies and choose Complete vessel.
# Frames 60 to 62
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/frames-60-62
The bounded decomposable assembly nested inside the complete vessel.
## What you can explore
The Frames 60 to 62 assembly provides a detailed structural anchor inside the complete vessel. It can be selected, decomposed, inspected, and recomposed as a smaller research case with tighter evidence control.
## What Forge has demonstrated
The 32 accepted component identities, 18 typed relationships, and exact recomposition registry remain unchanged. This gives the project a reproducible structural reference for expanding into adjacent bays.
## What a partner could unlock
The Draft 2015 Historic Structure Report, associated restoration records, and accountable boundary evidence could verify the transition into Frames 62 to 64 and support the next connected structural reconstruction.
Open the interactive studies and choose Frames 60 to 62.
# Hull Envelope
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/hull-envelope
The bow-to-stern exterior form hypothesis.
## What you can explore
The exterior study presents Balclutha's bow-to-stern form as a complete, navigable visual envelope. It lets viewers understand the vessel's scale and shape before opening the hull to inspect the systems within it.
## What Forge has demonstrated
The envelope follows the best-documented primary survey state while later observations remain available as separate evidence layers. This keeps the visual assembly coherent without losing the history of how the vessel was recorded.
## What a partner could unlock
Offset tables, higher-resolution surveys, shell records, and current-condition data could turn the visual envelope into a more exact hull definition and support future hydrostatic and engineering evaluation.
Open the interactive studies and choose Hull envelope.
# Internal Structural System
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/internal-structural-system
A governed cutaway and isolation view of the internal research structure.
## What you can explore
The internal study opens the vessel to reveal decks, bulkheads, framing, shell structure, connections, and repeated details. Viewers can isolate structural families and see how they contribute to the complete ship.
## What Forge has demonstrated
Named structural families remain connected to stable identities, source citations, evidence states, and correction questions. The result is a cutaway that can be reviewed as evidence rather than treated as a decorative render.
## What a partner could unlock
Scantling schedules, material records, connection details, inspection data, and engineering review could strengthen the system from a visual structural reconstruction into a richer model of load paths and physical condition.
Open the interactive studies and choose Internal structural system.
# Rigging System
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/rigging-system
The governed mast, spar, bowsprit, and rigging hierarchy.
## What you can explore
The major mast, spar, bowsprit, standing-rigging, running-rigging, and attachment families appear as a navigable hierarchy. Viewers can separate the rig into systems and see how those systems recompose into Balclutha's complete sailing silhouette.
## What Forge has demonstrated
The represented elements decompose by family and recompose to the complete sailing silhouette while keeping identities and evidence states attached.
## What a partner could unlock
Rig plans, sail plans, fitting schedules, restoration records, and specialist review could refine dimensions, lead paths, fittings, terminations, configuration dates, and current condition.
Open the interactive studies and choose Rigging system.
# Survey and Reference Skeleton
Source: https://www.docs.forgeshipyard.com/research-cases/balclutha-reconstruction-studies/survey-reference-skeleton
Sectional organization and accepted visual reference lines.
## What you can explore
The reference skeleton makes station rhythm, centerline, deck references, and sectional organization visible. It gives technical and non-technical viewers a shared way to understand how the ship is organized from bow to stern.
## What Forge has demonstrated
The displayed references belong to the accepted canonical coordinate skeleton. The view brings together 327 reference edges and 5,559 sampled points as an inspectable framework for positioning and comparison.
## What a partner could unlock
Additional sectional drawings, restoration records, and survey control could connect more reference lines to physical members, construction details, and verified transitions between structural bays.
Open the interactive studies and choose Survey and reference skeleton.
# Week of July 7, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jul-07
The first post-baseline expansion: a broader regulatory evidence graph, labeled evaluations, rules visible on the vessel model, and work-package readiness.
## Summary
Since closing the M0-M6 baseline, we have focused on four connected outcomes:
broadening the regulatory evidence Forge can work with, evaluating that evidence path
against labels created from the source material, showing rule-backed issues directly on
a representative vessel model, and carrying those issues into work-package readiness.
These are not separate experiments. The regulatory corpus supplies the requirements;
the evaluations test whether Forge reads and applies them faithfully; the model viewer
shows where an issue exists on the vessel; and the readiness board shows which part of
the build is responsible for resolving it. Together they move Forge from a completed
technical baseline toward a workflow a yard can inspect, challenge, and use.
## What we shipped
**A broader, traceable regulatory corpus**
* **The initial small-passenger-vessel fire-protection scope is connected end to end:**
the relevant sections of 46 CFR Parts 114, 116, 118, and 164 now join the acquired
Coast Guard Plan Review Guides. A Plan Review Guide, or PRG, explains the evidence a
reviewer expects to see for a particular plan or system. Forge preserves the guide's
relationship to the regulation rather than treating the guide itself as law.
* **More kinds of interpretive material now fit the same evidence graph:** Marine
Technical Note 01-13, Navigation and Vessel Inspection Circulars, a Coast Guard policy
letter, and selected Marine Safety Manual chapters can be read with their own
source-native structure. “Source-native” means a reviewer can return to the section,
item, enclosure, or chapter as it appears in the original document.
* **Additional CFR sections activate previously recorded citations:** Parts 72, 76, 95,
159, and 161 were added where the interpretive documents pointed to them. Forge can
preserve a citation before its target is present, show it as unresolved, and connect
it later when the governing text enters the corpus.
* **Scanned and historical material has a governed route into Forge:** local
optical-character recognition, or OCR, can make scanned documents searchable while
preserving how the text was produced. Original editions and later changes remain
distinct, so a 1997 circular is not silently replaced by its amended version.
* **Terminology begins connecting the corpus:** defined phrases such as “Area of
refuge” can link a CFR definition, Coast Guard guidance, applicable rules, and the
vessel space using that term. The relationship is based on exact recorded language,
not a guessed synonym.
**Evaluations that improve the system before partner use**
* **The first citation evaluation failed usefully:** the initial run scored 62 out of
80 and exposed 18 genuine document-reading gaps, including nested bullets, table
references, and citations distributed across a sentence. We corrected the
source-grounded reading rules rather than weakening the labels, and the same set then
passed completely.
* **Labels come from reading the source, not from asking Forge for its own answer:** each
example records what a human reviewer can verify in the document. The evaluation then
joins that source-native label to the system output, making a missing or incorrect
join visible.
* **The evaluation surface now reaches beyond citation extraction:** Forge also checks
rule-applicability precision and recall, whether it refuses for the correct reason
when vessel information is incomplete, and whether it identifies required evidence
that has not been supplied.
* **New document families are evaluated when they enter:** representative examples are
labeled during onboarding, so corpus breadth and quality evidence grow together. A
new parser is not treated as complete merely because it produced output.
**Rules and evidence become visible on the model**
* **The CAD-aware viewer now has a real web application:** the browser viewer and the
Forge API share one published data contract, which means the model, measurements,
citations, and issue rows are described consistently rather than being redefined by
the interface.
* **Engineering measurements appear beside the geometry they describe:** principal
dimensions and per-component volumes are calculated from the engineering geometry and
shown as cited overlays. The viewer helps people inspect the result; the underlying
[measurement record remains the authority](/concepts/how-cad-becomes-engineering-evidence).
* **A representative vessel model demonstrates the complete rule-to-part join:** a
synthetic small-passenger-vessel assembly provides named spaces and components without
exposing partner designs. A real Part 116 requirement, carried through its PRG
evidence chain, produces an open fire-protection gap on the Area of Refuge. Selecting
the issue highlights the affected space and shows the citation chain.
* **The view responds to governed decisions:** when the compliance gap is resolved
through its signed decision path, it clears from the open-issue overlay. The model is
therefore showing the current governed record, not maintaining a separate issue list.
* **The demonstration is shareable without partner infrastructure:** the representative
vessel and public-domain model can be loaded as static demonstrations, allowing
prospective partners and reviewers to understand the workflow before connecting yard
data.
**Readiness reaches the work-package level**
* **Engineering records can be connected to the work they affect:** Forge now has a
governed link between a compliance gap, reapproval, or other readiness record and the
relevant work package. The link is explicit because the yard, not an algorithm, knows
which module or production package owns the work.
* **The module-readiness board uses those recorded links:** each work package shows its
open blocker counts and readiness state. Vessel-level concerns remain visible, while
package-specific issues appear where production teams can act on them.
* **Resolving the underlying record updates readiness:** when a cited gap is resolved,
the board reflects the governed resolution instead of requiring a second manual status
update.
* **Operators have a controlled linking action:** authorized users can connect a record
to a work package without turning the read-only dashboard into an uncontrolled editing
surface.
## What we learned
* **Corpus depth and product usefulness reinforce each other.** A viewer becomes more
valuable when it can show a real requirement, and the corpus becomes more valuable
when a reviewer can see where that requirement lands on the vessel.
* **An evaluation earns confidence by being allowed to fail.** The first citation run
exposed real weaknesses because its labels were independent of the system being
tested. Correcting those weaknesses gave us stronger evidence than a first-run pass
would have.
* **Labeling at onboarding is the scalable discipline.** Evaluating each new document
family when it enters prevents quality work from becoming a separate cleanup project.
* **An unresolved citation is useful information.** Preserving the citation as printed
gives a reviewer an honest research task. Guessing its intended destination would turn
uncertainty into false authority.
* **Historical editions must remain visible.** Regulatory and guidance documents change
over time. Keeping editions distinct allows a future decision to cite the material
that actually governed it.
* **Work-package readiness depends on recorded ownership.** A blocker becomes useful to
production when the project explicitly connects it to the package responsible for
resolving it.
## Blockers & open questions
* The corpus is ready for partner and class review of its labels, applicability
assumptions, and interpretation relationships. That feedback will expand coverage
while preserving the distinction between binding authority, guidance, and yard
practice.
* The representative vessel proves the full workflow without exposing proprietary
designs. Partner onboarding will map the same evidence flow onto the yard's CAD
structure, naming conventions, work packages, and approved deployment environment.
* Regional interpretations and Officer in Charge, Marine Inspection (OCMI) practices
are often learned through operational experience rather than a single published
document. Forge will capture those qualifiers through partner walkthroughs and
accountable review instead of inferring them from incomplete text.
* Rich model selection and in-viewer authoring will be introduced when partner use
identifies the interactions that create the most value. The current read-only
foundation keeps the authority boundary clear while those needs are observed.
* We will not fine-tune models ahead of the evidence. Production-scale labeled material,
approved decisions, and confirmed outcomes will determine when a specialized model is
justified. The governed corpus and evaluation record come first.
* Some lower-quality scanned sources remain useful at the document level even when their
structure cannot be extracted reliably. Forge keeps that limitation visible rather
than creating false precision from noisy text.
## Next week
* Complete the remaining acquired Plan Review Guides, deepen the policy-letter structure
where the source quality supports it, close the remaining document-segmentation
questions, and clearly separate work Forge can complete independently from features
that should be shaped by a partner walkthrough, real pilot data, or observed
interaction needs.
# Week of June 2, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jun-02
Foundations first: the governed data backbone, rules as data, local AI search, and the first real correction from a shipyard owner.
## Summary
We built the foundation the whole system stands on before adding any AI: a governed
data backbone where each customer's data is walled off, every engineering decision is
signed and replayable, and AI is fenced in by design. By the end of the week we were
reading three real, structurally different rulebooks (ABS, US Coast Guard, IACS) and
turning them into clean, citable structured rules, and a shipyard owner corrected a
core assumption: the regulation on the page is not the whole rulebook.
## What we shipped
Milestones M0 and M1.
* A **multi-tenant backbone** where customer data is isolated at the database level,
not only by application code, so one yard's work can never surface in another's (M0).
* The **Engineering Decision Ledger**: every decision recorded with its rationale and
cryptographically signed, so it can be replayed and verified later (M0).
* A **capability catalog**: instead of free-form AI agents, every AI capability is a
defined, versioned entry with an explicit ceiling on how much it is allowed to do (M0).
* A **sensitivity checkpoint** every AI call must pass through, with
restricted-data-never-leaves enforced and tested exhaustively, so defense-adjacent data
can never reach an outside provider (M0, M1).
* A **source registry** that separates public regulatory sources (ABS, USCG, IACS)
from yard-private sources, so shared reference material and a customer's own data are
never mixed (M1).
* A **data model for a rule as a tree** (part, chapter, section, requirement, exception,
note), each requirement individually addressable, plus the structure for "which
vessels does this apply to" (M1).
* **Local AI search**: a local embedding model running behind the governance checkpoint
with weights that never leave the machine, a structure-aware chunker that keeps each
requirement whole, and a full audit trail for every AI run (M1).
* **Three parsers**, one per authority (ABS Steel Vessel Rules, USCG 46 CFR, an IACS
international requirement), each handling that body's own citation style, mandatory
language, exceptions, definitions, and tables, preceded by a written grammar
specification signed off before any parser code (M1).
* A **review queue**: confident results become canonical rules; anything uncertain
becomes a candidate flagged for a human, never silently dropped. Verbatim citations
(e.g. "4-1-1/3.1") are preserved on every requirement (M1).
* A **cost-efficient extraction cascade** for applicability: a fast rule-based pass,
then a local model, escalating to a stronger model only for uncertain cases, all
behind the governance checkpoint (M1).
## What we learned
* **Build the guardrails before the AI forces clarity.** You cannot fence in an AI you
have not first defined, so the capability catalog and sensitivity checkpoint came
first, deliberately.
* **"Which rules apply to this vessel" is its own problem,** separate from the rule
text. It depends on vessel type, size, service, and flag, so we modeled those as
structured fields rather than loose text tags.
* **Even local, internal model use has to be governed and logged** the same way an
external one would be. Treating "local" as a free pass would quietly undermine the
audit story, so local calls go through the same checkpoint.
* **The three regulators differ enough that a single generic parser would have failed.**
Reading the real documents before writing code caught conventions we would have
guessed wrong.
* **The biggest input of the week came from the field.** A shipyard owner told us that
much of what the Coast Guard actually enforces is *not* in the CFR text. It lives in
interpretive guidance (NVICs), technical notes, policy letters, and the Marine Safety
Manual. His example was structural fire protection, where reading the CFR alone gives
the wrong answer and NVIC 9-97 is what is actually applied. A system trained only on
the codified text would be confidently wrong exactly where it matters most.
## Blockers & open questions
* How strictly to separate shared reference data (public regulations, identical for
everyone) from customer-private data. We decided to treat them as two distinct
categories from day one rather than retrofit the split later.
* What to do when vessel data is missing during an applicability check. We chose to
abstain and flag for review rather than guess.
* Requirements embedded in tables (common in the IACS material) are a different parsing
problem. For now we capture the whole table for later rather than guess at its cells.
* We are now scoping the **full interpretive layer**, not just the CFR. We committed it
to the near-term roadmap and started acquiring NVIC 9-97 as the first proof case.
## Next week
* Finish the rules-and-retrieval layer so the work shows up in front of an engineer:
citation-checked rules search, prior-vessel memory, and the start of governed
decisions.
# Week of June 9, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jun-09
From rules to governed decisions: compliance-gap analysis, closing the propose-approve-sign loop, handling rule changes, and the interpretive layer as structure.
## Summary
We turned the rules-and-retrieval foundation into governed engineering decisions. The
system can now answer "which rules apply to this vessel," with citations, and record
that answer as a signed, auditable decision. We shipped compliance-gap analysis that
only ever proposes findings for a human, closed the loop from AI proposal to
human-approved signed record, built the safeguard for when a rule changes, and started
turning the interpretive layer a shipyard owner described into real structure. With
that, M2, governed decisions, is complete.
## What we shipped
Milestone M2.
* A **citation manager** that guarantees every rule claim links back to its source,
enforced as a gate, plus **rules search** that returns the likely-applicable rules for
a vessel ranked by relevance, each with its citation and confidence, completing the
Rules & Retrieval milestone.
* **Prior-vessel memory**: a yard's own past vessels captured as private, searchable
precedent, the basis for "we have built something like this before."
* The **decision ledger** made append-only and tamper-evident, with a gate runner that
blocks rather than silently skips and a single choke point for emitting a decision.
* **Compliance-gap analysis**: the AI compares what a rule requires against the evidence
a vessel actually has and flags the gap as a possible finding for review. It never
issues a compliance verdict on its own. A companion **evidence-matching** capability
lines up existing evidence against what each requirement asks for. Both are review-only
and citation-checked.
* A **review queue and promotion path**: a proposal lands in a yard-owned staging area,
a person reviews it, and only an approved item becomes a permanent record and signed
engineering decision, written through the single choke point that enforces the gates,
the human approval, and the signature together.
* The **first operator signing tool**: a command-line surface where a real person
enrolls as a signer, signs an approved decision, and verifies that it replays exactly
from what was stored. **Local key custody** keeps each signer's keys on disk behind a
swap-able seam (for managed or hardware-backed storage later). One signature covers the
whole record: who decided, who approved, and what was approved.
* A **supersession record and re-evaluation queue**: when a rule is superseded, every
signed decision that relied on it is found and flagged for re-approval, matched by a
stable citation path that survives renumbering. The original signed decision is never
edited. Its as-approved state is kept forever and the change is recorded alongside it.
Routing is graded: some superseded rules grandfather automatically, others raise an
engineer-review task, others force a re-approval.
* The start of the **interpretive layer as structure**: authority tiers on every source
(codified regulation, NVIC, marine technical note, policy letter, Marine Safety Manual),
interpretation links recording that one document interprets or clarifies another, and
an interpretive-guidance reader that parses a Coast Guard circular into citable rules.
## What we learned
* **A confident "this complies" answer the system cannot actually prove is the exact
failure we are building against.** Deciding whether a rule is satisfied is a matter of
judgment, so we deliberately avoided producing a tidy automatic compliance verdict.
* **The official MSC Plan Review Guides are "unofficial cheat sheets"** a reviewer leans
on, useful as an index into the rules, never legally binding. So the structure keeps
the cheat sheet and the actual authority clearly apart.
* **Keeping the signed record immutable shaped the whole design.** The current status of
a decision lives in a separate projection, so a later change never overwrites the
history of what was approved and why.
* **A code review caught a cross-tenant leak** where a global rule change was about to
expose one yard's list of affected decisions to others. We fixed it before it could
matter and extended the immutable-isolation tests to cover the new tables.
* **A design-basis letter**, the engineering justification a yard writes for a novel
vessel with no prescriptive rule, is already expressible as one of our signed
decisions, so it needs no new artifact type.
* **A second field meeting** (Conrad's design and estimating leads) gave the interpretive
layer back in their own words and added that local Coast Guard offices interpret the
same rule differently by region, so an interpretation can depend on the issuing office,
not only on the vessel.
## Blockers & open questions
* The compliance-gap capability is built and tested end to end but has little real data
to work on until the Plan Review Guides are ingested and the vessel side is populated,
and the vessel side depends on the geometry work in M3. Connecting evidence to the
vessel it belongs to is left for M3, where design objects and CAD data live.
* **Production key custody** (managed key services, hardware-backed signing) is
deliberately deferred. The local keystore fits the current local workflow, and the
swap-able seam is what keeps a development shortcut from quietly becoming the
production path.
* The signing tool consumes an already-approved decision rather than offering a full
review screen. The richer review-and-approve interface waits for the structured web UI
in a later milestone.
* The **NVIC 9-97 proof case** (structural fire protection, where reading the regulation
alone gives the wrong answer) is still gated on a walkthrough with the owner. We built
the structure and tested it on synthetic interpretive text; we will not claim the
finished regulation-to-guidance proof until the source and walkthrough are in hand.
* How to represent regional office differences is still open. The link model has room for
an office qualifier; the decision waits until the interpretation graph is actually
traversed in M3.
## Next week
* Begin the geometry baseline (M3), starting with the breakdown the yard actually works
in: the work package against a product-oriented structure, then the data backbone
for measurements.
# Week of June 16, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jun-16
The geometry baseline begins (M3, in progress): the yard's real unit of work, the evidence-to-vessel resolver, and a citable home for every measurement.
## Summary
We began M3, the geometry baseline, and this milestone is in
progress. We started with the ontology the yard actually works in (the product-oriented
work breakdown) and the data backbone geometry needs: a resolver from evidence to vessel,
a home for measurement results, stable identities for CAD parts, and the contract a
measurement service will write through. We have not touched a geometry kernel yet, by
design. We are laying the contracts and citation targets first.
## What we shipped
Milestone M3 (in progress).
* **The yard's real unit of work**: a product-oriented breakdown (blocks, zones, units,
work packages) added alongside the vessel view, because a yard builds in interim
products and work packages rather than whole vessels at once. Each work package links
back to the system view so the two reconcile.
* **The evidence-to-vessel resolver**: a way to walk from a piece of evidence, through
the design objects it attaches to, up to the vessel, so the compliance-gap capability
from Week 2 can finally take real inputs.
* **The measurement record**: a data home for a numeric geometry fact (a distance or a
clearance), so no number about the ship can be stated without pointing back to the
measurement it came from.
* **Stable CAD identities**: each part imported from drawing metadata gets a stable
identity with its source and provenance preserved, so a measurement can cite exactly
which parts it came from. Re-importing the same file does not create duplicates.
* **The measurement-service contract**: the typed seam a future geometry service will use
to write measurement records, which checks that every referenced part belongs to the
same yard, vessel, and source file before it writes anything.
## What we learned
* **Modeling the work package against a product-oriented breakdown puts compliance and
estimating on the same backbone.** The same model that answers "which rules apply" is
the one that will later answer "what will this cost to build."
* **Resolve identity and keep provenance early:** a lesson carried in from recent
extraction research. A measurement is only trustworthy if you can trace it to the exact
part, file, and import it came from.
## Blockers & open questions
* This is the data backbone. The **geometry engine itself is not built yet**: we have not
parsed a STEP or IGES file, computed a clearance, or run a clash check. We are laying
the contracts and citation targets first, on purpose.
* The estimating win the yard most wants, turning drawings into a bill of materials,
depends on their drawings being structured CAD. Whether that path is on track is gated
on confirming the format Conrad uses at the estimating stage; if those are flat 2D
prints, it becomes a separate document-reading problem.
* We are holding off on a **geometry kernel dependency** until the database guarantees and
the rule that numeric output must cite a measurement are locked down.
## Next week
* Harden the geometry data guarantees and build the first real measurement: a
deterministic clearance or distance computed over imported parts and written as a
citable measurement record.
# Week of June 23, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jun-23
The geometry and verification baselines close: CAD models become traceable engineering evidence, and every formal output follows the same checks.
## Summary
We completed M3 and M4: the geometry and verification
baselines. Forge can now read a STEP assembly, preserve the identity of its parts,
calculate measurements from the engineering geometry, and keep a traceable record of
where every number came from. Those facts then pass through one ordered verification
process before they can support an engineering decision.
In plain terms, Forge has moved from understanding *what a CAD file contains* to showing
*why a geometry claim can be trusted*. A clearance is no longer just a number on a
screen. It carries the source model, model version, units, measured parts, calculation
method, and review path behind it. We explain that chain in
[How CAD Becomes Engineering Evidence](/concepts/how-cad-becomes-engineering-evidence).
## What we shipped
Milestone M3 (complete).
* **A real STEP geometry path:** STEP is a neutral exchange format used to move 3D
engineering models between CAD systems. Forge now reads STEP assemblies locally and
preserves each occurrence of a component as its own traceable object. This matters
when the same part appears in several locations: each installed occurrence can have a
different relationship to the surrounding ship.
* **Measurements with receipts:** volume and component-to-component clearance are
calculated from the model and stored as measurement records. A measurement record is
the engineering equivalent of a receipt: it preserves the value, unit, source file,
model version, measured objects, and method used.
* **Clearance, contact, and clash kept distinct:** a positive clearance means space
exists between two parts. Zero means they touch. An overlap is raised as a clash for
engineering review rather than being converted into a misleading number.
* **Known-shape verification:** before relying on imported vessel geometry, we checked
the calculation path against shapes and assemblies with known dimensions and answers.
This gives the geometry service a repeatable reference point.
* **Import uncertainty stops the measurement:** if units are missing or contradictory,
scale is ambiguous, or repairing the file could change the shape materially, Forge
pauses measurement emission and asks for review. It does not turn an uncertain model
into an authoritative number.
* **A deliberately narrow IGES path:** IGES, an older CAD exchange format, is supported
as a compatibility route for single solids. STEP remains the primary assembly path
because it preserves the structure and identity needed for governed engineering work.
Milestone M4 (complete).
* **One verification ladder, T1 through T7:** every formal output follows the same
sequence of checks. T1 confirms sources and citations; T2 checks whether the rule fits
the vessel context; T3 makes confidence and assumptions explicit; T4 confirms that
geometry claims cite real measurement records; T5 is responsible-engineer review; T6
brings in class or USCG review where required; and T7 records the final signed
decision. See [How a Decision Gets Made](/concepts/how-a-decision-gets-made) for a
worked walkthrough of the same ladder.
* **Confidence is visible:** T3 requires a usable confidence value and clearly stated
assumptions. This allows reviewers to distinguish a well-supported conclusion from
one that depends on information the project has not yet confirmed.
* **Geometry claims remain attached to evidence:** T4 checks that every cited
measurement exists, belongs to the same vessel and model scope, and supports the claim
being made. A bare number or an unrelated measurement cannot pass.
* **Quality targets now govern capability:** citation accuracy, applicability,
missing-evidence detection, refusal quality, geometry grounding, isolation, and
replayability are measurable requirements. They determine how much responsibility a
capability can earn.
## What we learned
* **A geometry engine alone does not create trust.** Trust comes from the full chain:
file identity, units, assembly position, calculation method, measurement record,
citation, and accountable review.
* **The visual model and the engineering evidence serve different purposes.** A light
display model helps people inspect and discuss the ship. Measurements must continue to
come from the engineering geometry and remain linked to their source.
* **Uncertainty is most useful when it is explicit.** Pausing on ambiguous units or
risky model repair gives the engineer a clear question to resolve before uncertainty
travels into downstream work.
* **A shared verification sequence creates a common language.** Engineers, naval
architects, class reviewers, and program leaders can see which checks have passed,
which review is next, and what evidence supports the result.
## Blockers & open questions
* The geometry baseline is ready to be exercised with partner model conventions. Each
yard names assemblies, parts, zones, and revisions differently, so partner onboarding
will map those conventions into Forge while preserving the yard's existing source of
truth.
* STEP is the primary governed path. ShipConstructor, AutoCAD, CADMATIC, and other
system-specific connections will be enabled with each partner where access and
permissions allow, rather than assuming that one connector fits every yard.
* We are committed to enlarging the rule and interpretation corpus as the product
surface grows. This lets each new workflow be exercised against a broader range of
regulatory and yard-specific evidence while keeping every interpretation traceable.
* The verification ladder creates a consistent review path. Partner and class feedback
will help us calibrate how that path appears in day-to-day workflows without changing
who holds engineering authority.
## Next week
* Bring the geometry and verification foundations into the controlled DesignOS pilot:
turn cited gaps into build-readiness views, show recorded change impact, prepare
review packages, and place the evidence directly on a CAD-aware review surface.
# Week of June 30, 2026
Source: https://www.docs.forgeshipyard.com/research-log/2026/week-of-jun-30
The controlled DesignOS pilot and CAD-aware engineering workspace reach their baselines, bringing readiness, change impact, review, and approval into one traceable flow.
## Summary
We completed M5 and M6: the controlled DesignOS pilot
baseline and the first CAD-aware engineering workspace. The pieces built in earlier
milestones now work as one flow. Forge can identify a cited readiness issue, show which
recorded parts of the project it affects, place the evidence in the model-review
experience, route the proposed action through human approval, and prepare a traceable
review package.
This baseline is designed for partner use and feedback. It currently uses governed
public and synthetic examples so a yard can inspect the workflow without exposing
proprietary vessel data. For each partner deployment, Forge adds authenticated,
yard-specific access; production key custody, meaning clear control of the signing keys;
an agreed deployment or protected-enclave model; and the yard's permitted data and CAD
connections.
## What we shipped
Milestone M5 (complete as a controlled pilot baseline).
* **A governed pilot posture:** a pilot is more than early access to software. It is an
operating agreement about what the system may do, who must review its work, how long
the pilot runs, and what evidence demonstrates readiness to expand. Forge caps pilot
capabilities at **propose with review**: it can prepare an action, but an accountable
person remains the decision-maker. The pilot can only advance after both the agreed
time window and the required human-confirmed outcomes.
* **Build readiness based on cited blockers:** Forge brings open compliance gaps, cases
where it stopped because evidence was incomplete (abstentions), and decisions awaiting
reapproval into vessel-level and work-package views. Rather than inventing a single
readiness score, it shows the state, the counts, and the evidence behind each blocker
so program leaders can see what requires action.
* **Change impact based on recorded relationships:** when something changes, Forge
follows the relationships the project has actually recorded, including design objects,
drawings, evidence, rules, and decisions. Where a relationship has not been recorded,
Forge says so. This gives teams a defensible impact view without presenting a guess as
project knowledge.
* **A partner-ready issue package:** readiness blockers and change-impact findings can
be prepared as structured, machine-readable JSON and familiar spreadsheet files,
preserving their citations for the people and systems that receive them.
* **Feedback that becomes learning through review:** partner feedback is captured as a
structured event. When a responsible person confirms the result, it can become a
signed outcome. That outcome is the evidence Forge uses to understand whether a prior
decision held up in practice.
* **One readiness view across surfaces:** the same governed readiness information is
available through the command line, a reviewable HTML report, and a read-only local
dashboard. Each surface reads from the same underlying record.
Milestone M6 (complete).
* **A CAD-aware engineering workspace:** “CAD-aware” means the review surface understands
which vessel objects, measurements, issues, and decisions belong together. It does not
replace the yard's CAD authoring tools; it adds the evidence and decision context those
tools were not designed to preserve.
* **A model viewer with a clear authority boundary:** Forge converts imported geometry
into a lightweight display model for fast viewing, highlighting, and annotation. The
displayed mesh helps people see the issue, while engineering measurements continue to
come from the source geometry. The distinction is explained in
[How CAD Becomes Engineering Evidence](/concepts/how-cad-becomes-engineering-evidence).
* **Evidence placed in context:** cited measurements can appear beside the relevant
geometry; clashes remain visible review flags; annotations remain scoped to the yard;
and change-impact highlights appear only when a recorded design relationship supports
them. An issue without a geometry link stays visible in the review panel rather than
being attached to an arbitrary part.
* **Structured geometry acceptance:** an engineer can review a proposed geometry
acceptance, resolve the measurements it cites, run the required verification gates,
and sign the resulting decision. Viewing the model does not silently create
engineering authority; the structured approval action does.
* **A repeatable review package:** Forge prepares the viewer, issue files, and a
manifest, which is a contents list with digital fingerprints for the included files,
in one package. The recipient can confirm exactly which files and evidence were included,
making the handoff easier to review, reproduce, and defend.
## What we learned
* **A pilot is a governed operating state.** Clear capability limits, review roles,
outcome measures, and exit conditions give both Forge and the partner a shared
definition of responsible use.
* **Readiness is more useful when it is explainable.** A program leader needs the
blocker, responsible work area, and cited reason rather than a score whose meaning
changes from one project to another.
* **Honest impact analysis builds confidence.** Following recorded relationships and
showing where project knowledge needs strengthening gives teams something they can
verify and improve.
* **The model becomes more valuable when evidence is visible beside it.** Naval
architects and engineers can inspect the affected geometry, while class, compliance,
and program reviewers can follow the cited reasoning without becoming CAD operators.
* **Human approval is strongest when it is part of the workflow.** Keeping proposal,
review, external-authority involvement, signature, and outcome as distinct steps makes
responsibility visible.
* **Provenance must survive the handoff.** A review package is trustworthy when the
receiving team can trace its issues and measurements back to the same governed records
seen inside Forge.
## Blockers & open questions
* The controlled baseline is ready to move into partner use and feedback. For each
partner, Forge will provide authenticated, yard-specific access; clear custody of the
production signing keys; the agreed choice of where Forge runs and how its environment
is protected; and a defined pilot window with confirmed outcomes.
* ShipConstructor, AutoCAD, CADMATIC, and other yard-system connections will be enabled
with each partner where permissions and system contracts allow. This keeps integration
aligned with the yard's existing tools, security posture, and data ownership.
* Work-package readiness already shows where attention is required. The next layer of
partner configuration will strengthen the direct links between engineering records
and the work packages they affect, supporting clearer module-level planning.
* The read-only review foundation establishes the authority boundary. Rich model
selection, browser-based approval, and hosted collaboration can then be introduced
alongside authenticated identity and the partner's review process.
* We are committed to enlarging the rule and interpretation corpus as the product
surface improves. Each addition will remain versioned, cited, and evaluated so broader
coverage strengthens trust rather than trading it for speed.
## Next week
* Move from the completed M0-M6 baseline into evidence depth and product proof: expand
the real regulatory corpus, evaluate how accurately Forge reads and applies it, place
rule-backed issues directly on a representative vessel model, and connect those issues
to the work packages responsible for resolving them.
# Research Log
Source: https://www.docs.forgeshipyard.com/research-log/overview
Our weekly progress updates, newest first.
**What this is.** A running record of what we are building and learning, updated every week. It is meant to be skimmable: every entry follows the same template, so you always know where to look for what shipped, what we learned, and what is next.
## How to read an entry
Every weekly entry has the same five sections:
Two or three sentences. If you read nothing else, read this.
Concrete progress this week, tied to a build milestone where possible.
Findings from interviews, experiments, or the work itself. Often the most useful part for a shipyard reader.
What needs partner configuration, validation, or a decision next. We keep this
clear so readers can distinguish shipped capability from the path into use.
What we are focused on next.
## Entries
The first post-baseline expansion: a broader regulatory evidence graph, labeled evaluations, rules visible on the vessel model, and work-package readiness.
From controlled pilot to CAD-aware review: build readiness, change impact, governed approval, and a shareable review package (M5-M6).
CAD becomes traceable engineering evidence, and every formal output follows the same verification path (M3-M4).
The geometry baseline begins (M3, in progress).
From rules to governed decisions: compliance gaps, signed decisions, and rule changes (M2 complete).
Foundations first: the governed backbone, rules as data, and the first field correction (M0-M1).
## Where this fits
The roadmap view: what is demonstrated today, what is in progress, and what we
are only exploring.
The results you can inspect yourself, rather than read about.
## Research log vs. blog
This log is the **specifics of our work**, week by week. Our [blog](https://www.forgeshipyard.com/blogs) is for longer narrative articles and argument (like the founding essay). When in doubt: progress updates go here; essays and opinion go on the blog.
# How Forge Fits Your Existing Tools
Source: https://www.docs.forgeshipyard.com/start-here/how-forge-fits
Forge produces the model your tools were missing. It does not replace them.
**In plain terms:** Forge does not ask you to replace anything. Your CAD tools
still author geometry and your maintenance system still runs the work. Forge
supplies the thing none of them can produce on their own: a reliable model of a
ship that already exists.
## Forge sits upstream of your tools
Design and analysis tools all assume you already have a usable model. For a
vessel in service, that assumption is usually wrong. Forge is the step that comes
before them.
| Your tool today | What it does | What Forge adds around it |
| ------------------------------------------------ | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| ShipConstructor, AutoCAD, CADMATIC, Rhino, AVEVA | Author and edit geometry | Hands them an editable, structured model of the existing ship instead of a scanned drawing or a file that will not open |
| NAPA and structural or stability analysis | Run engineering calculations | Supplies reconciled geometry that reflects the vessel's current state, not its as-designed state |
| Laser scan and LiDAR point clouds | Capture as-is condition | Reconciles the scan against the reconstructed structure, so a discrepancy becomes a located, named question |
| Class rules and survey records | Define required condition and compliance | Connects a requirement or finding to the specific component it affects on the model |
| Planned maintenance systems, ERP, Excel BOMs | Track work and materials | Links each work item back to the component and the evidence that justified it |
The principle is simple. Forge does not compete for the authoring seat. It
produces and maintains the model, and it keeps the evidence attached to it.
## Open formats, no lock-in
A model you cannot take with you is not an asset. Forge reads and writes open
formats:
Standard exchange of engineering geometry, in and out. Your model goes back
into your own tools whenever you want it.
Lightweight display geometry for fast viewing, review, and sharing without
shipping the engineering model around.
The open structural exchange format for ship design, so structural data moves
between systems without being flattened.
There is no proprietary format that holds your ship hostage. If you stop using
Forge, you keep the model.
## A phased rollout, not a rip-and-replace
No fleet halts operations to overhaul its systems, so adoption is incremental.
Each phase produces something usable on its own and builds the data the next one
needs.
Start narrow. Reconstruct and reconcile a single bounded scope where the result
can be checked against something you already know. Lowest risk, fastest
verification.
Extend to a complete drydock scope. Reconcile the model before the work package
goes out, so planning happens against real condition rather than assumed
condition.
Keep the model reconciled between availabilities. Inspection findings, repairs,
and retrofits update it as they happen instead of being reconstructed later.
Roll out across sister ships and repeat part families, where resolved
components carry forward instead of being rebuilt hull by hull.
## Where it runs
Ship structural data is sensitive, and some of it is defense-adjacent. Deployment
is built for that:
* **On-premise or private cloud.** The model and its sources can stay inside your
own environment.
* **Database-level isolation.** Each customer's data is isolated at the database
itself, not just in application code, so no customer's data is visible to
another.
* **Sensitivity-aware processing.** Where a piece of data is allowed to be
processed is a recorded policy, not a runtime preference.
See [Keeping Your Data Yours](/concepts/keeping-data-yours) for the full detail.
## It starts in observe-only mode
When Forge first arrives it runs in **observe-only mode**. It reconstructs,
reconciles, and flags, but nothing it produces is treated as authoritative. This
phase runs for at least 90 days. It lets the system learn your vessels, your
drawing conventions, and your naming, and it lets your engineers build confidence
before any output influences real repair work.
# The Problem We're Solving
Source: https://www.docs.forgeshipyard.com/start-here/the-problem
Why a ship arrives at drydock with no reliable model of itself.
**In plain terms:** Decades of 2D drawings, dead CAD files, and survey records
describe a ship that no longer exists. Nothing keeps any of it in sync with
the steel. So every repair job starts blind, and the real scope of the work is
discovered only after the hull is opened.
## What the industry told us
The same problem came back in different words from every part of the industry:
> "Still using 2D drawings and Excel for checking compliance."
>
>
>
> *American Bureau of Shipping*
> "A laser scan once came back four inches off the drawing."
>
>
>
> *Shipyard A*
> "Doing constant rework because the documents aren't accurate enough."
>
>
>
> *Shipyard B*
None of these are software-adoption problems. They are all the same problem seen
from three angles: the record of the ship and the ship itself have drifted apart,
and no one can tell by how much.
## Where the drift comes from
Older vessels were documented on paper. Newer ones were handed over with CAD
files that are now locked in formats nobody can open or edit. Either way,
what survives is a picture of the ship, not a usable model of it.
A ship is repaired, retrofitted, re-plated, and re-piped across its whole
service life. Each of those jobs changes the vessel. Almost none of them
update the drawings. The gap compounds every availability.
Drawings say one thing, the CAD file says another, the work order says a
third, and the survey report describes a condition none of them mention.
There is no authority that resolves the conflict.
Classification rules, survey history, and the reasoning behind past repairs
are scattered across paper, PDFs, and the memory of individual
superintendents and port engineers. When they move on, the context goes with
them.
## Two versions of the same problem
The starting point differs by fleet, but the destination is the same.
| Fleet type | What exists today | What is missing |
| --------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Older and legacy fleets** | Paper drawings, scanned sheets, dead CAD, and decades of undocumented refits | A model at all. It has to be reconstructed before anything can be reconciled. |
| **Recently built fleets** | A handover model from the newbuild design and production tools | Anything that keeps that model true as the vessel operates. Design-phase tools are not lifecycle tools. |
A newly delivered ship is not automatically safe from this either. Handover
documentation often does not match what was actually built, so a "clean" vessel
can enter service with a reconciliation gap already in it.
## Where the cost actually lands
The drift is invisible right up until it is expensive:
* **Scope is discovered in drydock, not in planning.** The job is priced and
scheduled against drawings, then re-priced against what the yard finds. That is
what the contingency line in every drydock budget is really paying for.
* **Rework because the documents were not accurate enough.** Parts are fabricated
to a drawing that no longer describes the ship.
* **Class findings arrive as surprises.** Condition and compliance questions land
at survey rather than months earlier, when there was still time to plan for them.
* **Engineering time goes to reconciliation instead of engineering.** Technical
departments spend planning cycles manually cross-checking records that disagree.
## Why software has not fixed it
The problem is not a shortage of CAD tools. The existing stack is built for
**designing and building new ships**, and it does its job well there. What none of
it does is maintain a true model of an **existing** ship across decades of repair,
by people who were not involved in the original design, working from sources that
are incomplete and in conflict.
That is a different problem, and it is the one Forge is built for.
The longer argument, including the strategic and competitive case, lives on
our blog.
# What Forge Will Not Do
Source: https://www.docs.forgeshipyard.com/start-here/what-forge-wont-do
The limits we deliberately build in, so you can trust the result.
**In plain terms:** Forge can reconstruct, reconcile, measure, compare, draft,
and flag. It **cannot** be the engineering authority, and it **will not** invent
geometry to cover a gap in the record. Anything touching Class, Coast Guard
rules, or safety passes through a human. This is structural, not a setting.
## It will not guess at missing structure
This is the limit that matters most in reconstruction work, and it is the easiest
one to get wrong.
When the drawings do not resolve something, the tempting move is to generate
geometry that looks right. A model with no visible holes is more impressive in a
demonstration. It is also actively dangerous, because a plausible invented frame
is indistinguishable from a documented one once it is in the file.
Forge does the opposite. An unresolved region stays in the model as a **named
open question** with the evidence envelope around it. It remains selectable and
inspectable, and it carries the specific question that has to be answered before
stronger geometry can be claimed:
> Gaps get flagged, not generated.
That means a reconstructed model tells you two things at once: what is supported
by evidence, and exactly where it is not. A partner with a better drawing, a
current survey, or direct observation can close a named gap. Nobody can close a
gap that was quietly filled in.
## It will not be the design authority
> AI proposes; humans decide; the gate is structural.
Forge is allowed to do the legwork: read the drawings, build the geometry,
compute the measurement, find the conflict between two records, draft an
assessment, propose an interpretation. It is **not** allowed to be the final word.
Decisions touching classification society rules, Coast Guard compliance, or safety
require a human to approve them before they become authoritative.
This is not a configuration a customer could accidentally disable. It is built
into the every output has to pass through.
## Where humans stay in charge
Every decision touching Class or Coast Guard rules requires human approval, by
structure.
A reconstructed component becomes accepted engineering geometry only when a
responsible engineer or surveyor accepts it, never on import.
The catalog of permitted moves goes through a review checklist before any
change ships. The AI cannot invent new moves at runtime.
Every sign-off that a work package is ready to execute is a human decision.
## When it is unsure, it stops
Forge is designed to **abstain rather than guess**. If it cannot read a drawing
reliably, if a file's units or scale are ambiguous, or if it cannot find the
evidence a claim requires, it does not produce a number and hope. It stops before
creating the record and says what needs resolving.
Refusing to answer when the evidence is insufficient is treated as a quality
behavior, and the system is held to a high bar for doing it well.
The same applies to malformed input. A corrupted or unsupported file stops before
it can emit geometry, measurements, or downstream work, rather than producing
something partial that looks complete.
## It will not silently merge different moments in time
A ship's record spans decades. The original construction drawings, a later
modification, a survey from one year, and a scan from another do not all describe
the same vessel state.
Forge keeps those as distinct, labeled evidence states rather than averaging them
into one confident-looking model. Two records can both be useful without
describing the same side, surface, date, or physical reference.
## Why build it this way
The point is to make behavior **boxable, auditable, and reversible**. If a
behavior turns out to be wrong, it is rolled back like any other versioned
software change, not patched on the fly. That is what makes a Forge result
defensible in front of a surveyor, an owner, or a regulator.
See [Where Humans Stay in Control](/concepts/human-control) for the full detail,
and [Keeping Your Data Yours](/concepts/keeping-data-yours) for how sensitive
designs are protected.
# What is Forge?
Source: https://www.docs.forgeshipyard.com/start-here/what-is-forge
The one-paragraph answer, in plain language.
**In plain terms:** Forge rebuilds a ship's real structure as a 3D model from the
legacy 2D drawings, dead CAD files, and inspection records you already have, then
keeps that model true as the ship is repaired, retrofitted, and surveyed for the
rest of its life.
## The short version
A ship coming in for repair usually has no reliable model of what is actually
inside it. What exists instead is decades of paper drawings, CAD files nobody can
edit anymore, survey reports, and work orders that contradict each other and no
longer agree with the steel.
Forge reconstructs a structured 3D model from those legacy sources, reconciles it
against current inspection and Class records, and flags every conflict **before**
the ship reaches drydock. That is the difference between planning a job and
discovering its real scope after the hull is opened.
This is not a one-time conversion. Every commercial vessel runs a mandated
five-year survey cycle, and every repair, retrofit, and steel renewal pushes the
model further from the ship. Reconciliation is the part that has to keep running.
## What Forge does
Builds the 3D model from legacy 2D drawings, STEP files, dead CAD files, and
inspection records. It works from what you have, not from a model you were
supposed to receive and never did.
Keeps the model updated as repairs, retrofits, and drydock work change the
ship, so the model still describes the vessel that is actually in the water.
Pulls paper drawings, dead CAD, Excel bills of material, and work orders into
one live state instead of four records that disagree.
Every change passes through your engineer, superintendent, or surveyor before
it is approved. Nothing becomes authoritative on the AI's say-so.
## What you get out of it
Forge is built for the technical departments that manage repair, drydock, and
Class compliance. The practical results are:
* **Drydock planning against real scope.** Conflicts surface during planning
rather than after the yard cuts the ship open.
* **No Class surprises.** You know the vessel's real condition before the surveyor
does.
* **Less manual reconciliation.** Stop hand-checking paper drawings, dead CAD, and
conflicting work orders before every planning cycle.
* **A record that holds up.** Every part of the model traces back to the drawing,
survey, or measurement it came from, and to the person who approved it.
## What makes it trustworthy
Two commitments shape everything else in these docs.
The first is that **gaps stay visible.** When the drawings do not resolve
something, Forge marks it as an open question with the evidence envelope around
it. It does not generate plausible geometry to fill the hole. An unresolved region
stays selectable and inspectable, so it becomes a research task rather than a
false certainty.
The second is that **the reasoning is kept, not just the result.** The
records which source supported a choice, which rule version
applied, who approved it, and what it replaced. That is what makes a reconstructed
model defensible later, in front of a surveyor, an owner, or a regulator.
## Your data stays yours
Sensitive designs are isolated at the database level, so no customer's data is
visible to another. On-premise and private-cloud deployment are both supported.
Models export to open formats, STEP and glTF, with OCX support for structural
exchange, so there is no proprietary format holding your ship hostage.
## How to read these docs
The plain-language case: the problem, why it matters, and how Forge fits your
existing tools. No technical background needed.
How Forge thinks, one idea at a time. Starts with how a drawing becomes a 3D
model.
A complete vessel reconstructed from historical drawings, inspectable in your
browser.
Our weekly progress updates.
# What's Next
Source: https://www.docs.forgeshipyard.com/start-here/whats-next
Where the reconstruction work stands today and what we are building next.
**In plain terms:** We have reconstructed a ship's hull structure from 2D drawings
into 3D, end to end, on a real vessel. Next we are taking the same pipeline
inward, to the piping, engines, and smaller parts, and then outward, to reviving
dead 3D CAD files into editable ones.
## Where we are
The hull structure milestone is complete. We can take a real vessel's legacy 2D
drawing set and reconstruct its hull structure as an inspectable 3D model, with
the evidence and the open questions still attached.
Balclutha, an 1886 steel-hulled sailing cargo ship, reconstructed end to end
from the historical measured drawing set: 71 drawing sheets and 240 survey
data pages.
We extracted and verified the major public reference datasets for 3D ship
reconstruction and reproduced the field's key published work on turning 2D
ship drawings into 3D hull models.
Reconstructed components are checked against the vessel's own type and class
precedent, so unsupported regions get flagged as open questions rather than
generated.
The result decomposes and recomposes without losing identities, and every
numeric claim traces to the measurement record behind it.
You can inspect the result yourself in the
[Balclutha Evidence Workbench](/research-cases/balclutha-evidence-workbench).
## What we are building next
The hull is the structure. The work inside it is where most repair scope
actually lives. We are extending the same 2D-to-3D pipeline to internal piping
runs, machinery and engines, and the smaller components that populate a
machinery space.
This is harder than hull structure for a specific reason. Hull geometry is
continuous and heavily constrained by naval architecture, which gives a
reconstruction strong priors to check against. Piping and machinery are
discrete, densely packed, drawn in many different conventions, and frequently
modified without the drawings being updated. The evidence discipline matters
more here, not less.
A large share of vessels do have a 3D file. It is just unusable: a frozen
export, a format nobody supports anymore, or a single fused solid with no
structure, no part boundaries, and no way to change anything.
We are building the path from those dead files to fully editable and
deconstructable models: recovering part boundaries and identities, restoring
the assembly hierarchy, and returning geometry that an engineer can actually
modify rather than only look at.
The difference matters in repair. You cannot plan a steel renewal, a
modification, or a part replacement against a model you can only rotate.
The reverse direction matters as much as the forward one. Fabrication does not
run from a model, it runs from drawings. A shop that cannot get a usable
drawing out of a system will not adopt the system, whatever the model is worth
back in the technical department.
So we are building the return path: sections and part drawings generated from
the reconstructed model, each still carrying the source behind it. That is
what gets this work past the office door and onto the plate.
## An adjacent application
The dead-CAD capability is not ship-specific. The same problem exists anywhere
physical equipment outlives the software that designed it.
Machinery OEMs and suppliers hold large archives of exactly this kind of data:
legacy drawings and frozen CAD for parts that are still in service and still need
repairing, long after the original design environment is gone. Reconstructing that
data into editable, deconstructable models has the same shape as the ship problem
and the same trigger, a repair that cannot be planned without a usable model.
This is an adjacent direction we are tracking, not a near-term product. The
sequencing is deliberate: prove the reconstruction and reconciliation work with
real vessel operators first. Ships stay the focus.
## How to read progress claims in these docs
We try to keep three things clearly separated so the roadmap stays honest:
| Status | What it means |
| ---------------- | ------------------------------------------------------------------------------------------------ |
| **Demonstrated** | Built and shown on real source material, with the result inspectable and the method reproducible |
| **In progress** | Actively being built, with the approach settled but the result not yet verified |
| **Exploring** | A direction we believe in, without committed work behind it yet |
Hull structure reconstruction is demonstrated. Internal systems, dead-CAD revival,
and the return path to 2D drawings are in progress. The machinery OEM application
is exploring.
The [Research Log](/research-log/overview) tracks this work week by week, including
the parts that did not go as planned.
# Why This Matters for Your Fleet
Source: https://www.docs.forgeshipyard.com/start-here/why-it-matters
What changes operationally once the model matches the ship.
**In plain terms:** Every availability planned against records that no longer
describe the ship is a job priced twice: once from the drawings, and again from
what the yard actually finds. Forge moves that discovery forward, out of drydock
and into planning.
## The cost of the status quo
The drift between the record and the ship is not a documentation inconvenience. It
shows up as:
* **Scope discovered too late.** Work is planned from drawings, then re-planned
once the steel is exposed. Schedule and cost both move, and they only ever move
one direction.
* **Offhire and overruns.** A vessel sitting in dock past its planned window is
not earning. Extensions driven by unexpected scope are the expensive kind.
* **Rework from inaccurate documents.** Parts fabricated to a drawing that no
longer describes the ship have to be made again.
* **Compliance risk that surfaces at survey.** A condition or certification
question found by the surveyor is a much worse problem than the same question
found six months earlier.
* **Context that leaves with people.** When a superintendent or port engineer
moves on, the reasoning behind past repairs goes with them.
## What changes
Conflicts between drawings, CAD, work orders, and survey records surface during
planning, while there is still time to act on them. The yard receives a work
package built on the vessel's actual condition.
You know the ship's real condition before the surveyor does. Certification
questions and required work become scheduled items rather than emergencies
sprung on you mid-survey.
Technical departments stop manually cross-checking paper drawings, dead CAD,
and conflicting work orders before every cycle. That time goes back into the
engineering judgment only they can provide.
Every part of the model traces to the drawing, survey, or measurement behind
it, and to the person who approved it. The record survives staff changes,
ownership changes, and yard changes.
## Certainty compounds
The first reconstruction is the expensive one. After that, the model is an asset
that keeps paying:
Planning for the second drydock begins from the reconciled state left by the
first, not from the same pile of contradictory drawings.
Vessels of the same class share structure, and repeat part families recur
across a fleet. A resolved component does not have to be resolved again from
scratch on the next hull.
Inspection findings, thickness measurements, and completed repairs land in the
model as recorded evidence. The five-year cycle stops eroding the record and
starts improving it.
Once condition is known rather than assumed, repair and steel-renewal work can
be planned further out instead of being held as an unallocated buffer against
the unknown.
## What this does not solve
Forge does not repair steel, and it does not replace the judgment of a naval
architect, a superintendent, or a surveyor. It reconstructs and reconciles the
model those people work from, and it makes the evidence behind that model
inspectable so their judgment is applied to a true picture of the ship.
See [How Forge Fits Your Existing Tools](/start-here/how-forge-fits) for where it
plugs in, and [What Forge Will Not Do](/start-here/what-forge-wont-do) for the
limits we deliberately keep.