In plain terms: L2 represents the ship as connected engineering objects instead
of disconnected files. It is the system’s answer to “what is this vessel?”
What it does
L2 is the : a structured model of what kinds of things exist in ship design and how they relate. It is stored as a , where every engineering object is a node and every meaningful relationship is a typed link. The model reads naturally:A Vessel has Hulls and Compartments. A Compartment contains Systems. A System uses Equipment. Equipment cites Materials from Suppliers. Drawings reference Modules. Work Packages reference Modules and Materials. Evidence links to Drawings and Decisions.
Why a knowledge graph instead of tables
In a traditional database you would have a vessels table and a compartments table joined by a key. In a knowledge graph you have Vessel nodes and Compartment nodes connected by typed links likecontains or adjacent_to.
The payoff is that questions about relationships become simple, single-step
lookups instead of complex multi-table joins:
- “Which compartments share a bulkhead with this fuel tank?”
- “Which prior vessels have a similar system layout?”
- “Which decisions cite this rule version?”
What L2 outputs
The canonical objects:vessel, hull, compartment, system, equipment,
drawing, material, supplier, work_package, module, evidence.