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