8 min read
The Forge Ontology: A Single Source of Truth for Ship Design
How we turn a shipyard's rules, designs, decisions, and evidence into a single governed model, so AI can accelerate engineering without ever becoming unaccountable.
A modern vessel is one of the most regulated objects humans build. Before it ever touches water, its design must satisfy thousands of requirements from classification societies, federal authorities, owners, and yard standards each written in its own language, numbering, and logic. That knowledge lives across PDFs, CAD files, decades of contract archives, and too often, in the hard-won experience of the engineers who have done it before, where it can't be searched, shared, or checked.
The federal maritime action plan put it plainly: vessel acquisition today is "fragmented, overly complex, and often duplicative." Shipyards feel that fragmentation as lost time: re-deriving the same answers, re-checking the same rules, rebuilding the same knowledge on every program.
The obvious move is to point an AI at the pile and ask it questions. We believe that's the wrong move. A general-purpose model will give you a fluent, confident answer, with no way to know whether it's right, where it came from, or whether it just invented a requirement. A vessel that has to pass class and serve the fleet cannot be built on a guess.
So before we built any AI features, we built the thing the AI has to be accountable to. We call it the Forge Ontology.
What an ontology is, and what ours isn't
An ontology is a structured model of a domain: the real things that exist, and how they relate. The closest familiar idea is a digital twin, but more precise would be a governed digital thread: a faithful representation of the yard's world: its vessels, systems, equipment, rules, and the decisions made about them.
But a digital twin you can only look at isn't enough. The Forge Ontology is a governed operational layer: every object in it carries its provenance, its sensitivity, and its history, and every change to it is recorded. It deliberately avoids two tools people reach for instead:
It is not a database schema. A schema records fields; the ontology records what those fields mean: that this paragraph is a requirement, that it scopes to vessels over 500 gross tons, that this decision superseded that one.
It is not a document-search tool. Search hands back passages to read; the ontology hands back structured, citable rules an engineer can act on and a regulator can audit.
What's actually in it
The ontology connects four kinds of things that, in most yards, live in separate silos:
Vessels and design objects. The hull, compartments, systems, and equipment, all modeled as one coherent structure rather than scattered across tools.
Rules, as structured trees. We don't store regulations as documents. We parse ABS, USCG, and IACS text into addressable hierarchies (part, chapter, section, requirement, exception, note), where every individual requirement is independently citable. Ask about fuel-oil-tank drainage and the system can point to the exact paragraph (for ABS, something like 4-1-1/3.1) and the verbatim text behind it. The rules engine understands that ABS and IACS write requirements as "is to be," that the Coast Guard writes "must," and that "Except as provided" introduces an exception, because those distinctions change what a vessel actually has to do.
Engineering decisions, as a signed ledger. Every decision (a rule's applicability, a design exception, a material choice) is recorded with its rationale, its evidence, and its approver, then cryptographically signed. The "why" behind the ship becomes a first-class part of the model, instead of a comment lost in an email thread.
Evidence and sources. Measurements, drawings, and the regulatory sources every claim rests on, so nothing in the model is unattributed.
The five principles that make it trustworthy
Anyone can build a data model. However, this one can carry AI safely because of commitments we build into the architecture itself.
1. One source of truth. The ontology is the single place the yard's design intent, rules, and decisions come together. Faster design starts here: change a dimension once, and everything that depends on it can be re-checked, because the dependencies are explicit.
2. Citations are first-class. Every claim the system makes traces to a specific rule and a specific source, so an engineer can follow any answer back to the regulation behind it. An answer without a citation isn't one we'll surface.
3. AI proposes; people decide. When the system extracts a requirement or suggests how a rule applies, that output enters the ontology as a candidate: flagged for review, never asserted as fact. Only a human promotes a candidate into the canonical model. Model output is never treated as engineering authority on its own. Uncertainty is surfaced for review, never silently dropped.
4. Governed by construction. Shipyard work is sensitive, and some of it is defense-adjacent. Every AI invocation in the system declares a sensitivity class and passes through a single routing checkpoint. Restricted data cannot reach an external AI provider: the checkpoint blocks it, and we test that path exhaustively.
5. Auditable and replayable. Because every decision is signed and every input is recorded, a decision can be replayed and verified from stored facts alone, with no AI in the loop. Months later, you can ask "why was this approved, under which rule version, with what evidence?" and get an answer you can take into a class or regulatory review. “When a rule version changes, the ontology can identify which prior decisions were made under the older version and route them for grandfathering, engineer review, or reapproval.”
Why this matters for a shipyard
Put those principles together and the payoff is concrete:
Design ships faster. Rules, design, and decisions are connected instead of re-derived program after program.
Compliance you can defend. Every requirement check cites its source and every decision is auditable, so a class or regulatory review is backed by documented answers.
Knowledge that compounds. Institutional expertise is captured in the model instead of walking out the door with the people who hold it.
AI you can actually use on sensitive work. The guardrails are built into the foundation.
This is the first in a series on how we're building Forge. In the next pieces, we'll go deeper on the parts that make governed AI possible: how sensitivity routing keeps sensitive design data sovereign, and how the Engineering Decision Ledger makes every decision replayable.
Restoring American shipyards means building faster, and building in a way the people who depend on these ships can trust. That trust starts with the ontology.