Skip to main content
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.