Platform
- Hull
- Structure
- Watertight integrity
- Stability
- Compartmentation
AI-native shipbuilding.Intelligence designed into the build, not bolted beside it.
Conventional digital transformation bolts tools next to a shipyard. AI-native means the company, the information system and — over time — the production system are designed around machine intelligence as an active participant in a vessel’s life, with people holding every consequential decision.
Long-term vessel intelligence
A machine-readable system of systems.
The destination is not a pile of disconnected subsystems or a magical “hive mind.” It is an authoritative vessel state in which identity, configuration, telemetry, operating context, bounded reasoning, and human authority remain connected across the lifecycle.
- 01
Identity
Long-termCan every consequential physical and digital asset identify itself?
- 02
Configuration
Long-termWhat should exist, what actually exists, and which revision governs it?
- 03
Telemetry
Long-termWhat is the bounded measured state of equipment where sensing is justified?
- 04
Operational state
Long-termHow do propulsion, power, cooling, controls, safety, and maintenance states interact?
- 05
Reasoning
Long-termWhat can bounded intelligence interpret or recommend from governed state?
- 06
Human authority
Human-authorizedWho may decide, override, verify, roll back, or escalate?
Long-term concept architecture only. Veldarium has not designed, built, classed, operated, or autonomously controlled a vessel, and no diagram on this page is an approval or certification claim.
What it actually means
Six ideas, one system.
Each carries its own honest maturity. One is working today; the rest are building, synthetic, concept, or target states.
- 01Building
A machine-readable vessel
Requirements, systems, zones, components, materials, suppliers, revisions, work packages, inspections and as-built state exist as connected objects — not as isolated documents a person has to reconcile by hand.
- 02Working
Evidence-bound build state
The system represents which source controls, which revision applies, what conflicts, and what remains unknown inside bounded records. The current public proof demonstrates the narrower three-valued readiness and human-authority contract.
- 03Concept
AI-assisted engineering
Agents help engineers see dependency impact, configuration conflict, change propagation, design-for-production feedback, historical rework and supplier constraint. They surface evidence; they do not become unaccountable engineering authority.
- 04Concept
Production-aware design
Fabrication, inspection, rework, material problems and supplier performance feed back into the next engineering decision, so the design learns from what the yard actually experienced.
- 05Target
Human + robotic execution
People stay responsible for consequential decisions and craft. Inspection, scanning, measurement, material movement and bounded fabrication assistance become increasingly machine-assisted, and eventually autonomous.
- 06Concept
Continuous industrial learning
Company thesis: each future build should return reviewed production evidence to later engineering and planning. Whether that produces a compounding advantage has not been demonstrated.
Where the intelligence works
Not a box beside the yard. A loop through it.
Engineering intent becomes steel; production reality returns to engineering. AI operates across the whole loop — reconciling, checking, surfacing what is about to hurt — rather than answering questions in a chat window off to the side.
- 01Engineeringrequirements, design, configuration
- 02Supplysourcing, material, long-lead
- 03Fabricationcut, form, weld, assemble
- 04Integrationblocks joined, systems connected
- 05Inspectiontest, measure, accept
- 06Deliverycommissioned, handed over
- 07Operationperformance, maintenance, wear
Operation feeds back into engineering. The loop closes, and the next hull starts from more than the last one knew.
The coupled vessel
Changing one system changes others.
A vessel is a coupled technical system. Power, cooling, weight, structure, controls, safety, layout, production sequence and maintenance cannot be optimized as independent boxes — the graph preserves those cross-system consequences for review.
Platform
Propulsion
Energy
Thermal
Fluid systems
Control
Navigation
Communications
Mission / payload
Safety
Digital
One example dependency cascade
- Higher-power sensor
- Electrical demand
- Generator sizing
- Cooling demand
- Cable routing
- Equipment layout
- Weight
- Stability
- Production sequence
- Maintenance burden
Modularity without the Lego fiction
Replacement starts with a declared interface contract.
Standardization is most plausible at bounded interfaces — racks, compute, sensors, batteries, power electronics, pumps, network nodes, and payload connections. A candidate replacement is not valid because it fits one dimension; it has to satisfy vessel-level mechanical, power, thermal, software, safety, maintenance, and approval constraints together.
Candidate module families
- Equipment racks
- Compute modules
- Battery modules
- Sensor packages
- Power electronics
- Pumps
- Network nodes
- Edge-compute devices
- Replaceable electronics
- Modular payload interfaces
If module A is unavailable, which approved alternatives satisfy the declared interface contract without breaking vessel-level constraints?
Every module must declare
- Identity
- Which approved module and variant is this?
- Mechanical envelope
- What three-dimensional space and service clearance does it require?
- Mounting interface
- How, where, and under what loads may it attach?
- Weight
- What installed mass enters the vessel model?
- Center of gravity
- Where does that mass act?
- Power
- What voltage, current, quality, peak, and normal demand apply?
- Thermal load
- What heat must be rejected in each operating mode?
- Cooling interface
- Which medium, flow, pressure, and temperature limits apply?
- Network interface
- Which physical link, protocol, data contract, and cyber zone apply?
- Software version
- Which approved software and configuration baseline controls it?
- Safety constraints
- Which interlocks, hazards, fail states, and separation rules apply?
- Maintenance requirements
- What access, intervals, tools, spares, and competence are required?
- Certification status
- What approval or class evidence exists, for which exact scope?
- Lifecycle state
- Is the module proposed, approved, installed, in service, obsolete, or removed?
Concept architecture. No interchangeable marine module, approved alternative set, or class acceptance is claimed.
Energy + reduced-crew trade space
Optimization cannot erase physics or responsibility.
Energy architecture and crewing choices propagate through the whole vessel. AI may eventually recommend within an approved model; it cannot create energy, certify architecture, replace protection logic, or make safety-critical release decisions.
- Diesel-electric
- Hybrid-electric
- Battery-assisted propulsion
- Modular energy storage
- Shore charging
- Vessel microgrid
Constraints stay explicit
- Hotel load
- Propulsion load
- Mission / payload load
- Thermal limits
- Redundancy
- Graceful degradation
- Protection coordination
- Forecast energy demand
- Recommend load allocation
- Recommend charging windows
- Estimate battery degradation
- Prioritize maintenance
- Recommend generator dispatch within approved constraints
It may not: create energy, certify an architecture, or override protection logic.
- Habitability volume
- Galley load
- Sanitation load
- Berthing
- Potable-water demand
- Some human interfaces
- Some HVAC and life-support burden
- Redundancy
- Remote diagnostics
- Autonomous recovery
- Remote command
- Fault isolation
- Cyber resilience
- Condition monitoring
- Maintenance architecture
- Docking and charging support
- Communications redundancy
The AI layer
Bounded agents. Named human authority.
Each proposed agent has a declared read boundary, allowed action, forbidden action, provenance obligation, failure state, and named human gate. These are concept contracts — not running production agents. That boundary is part of the design.
- Change-impact agentConcept
Watches: a component or governing revision changes.
- Reads
- approved configuration · typed dependencies · effectivity · change evidence
- May
- Trace and draft an evidence-linked impact set.
- Must not
- Approve the change or silently infer an unresolved dependency.
- Evidence
- Cite every traversed object, relation, revision, and source timestamp.
- Failure
- Return impact-not-established and escalate the missing or conflicting evidence.
Authorized engineer accepts or rejects the impact disposition.
- Configuration agentConcept
Watches: which revision governs, where it applies, and where sources conflict.
- Reads
- authority chain · revision history · effectivity · deviation and waiver state
- May
- Compare controlling candidates and prepare a conflict packet.
- Must not
- Select authority when the release chain is absent or contradictory.
- Evidence
- Preserve source identity, revision, applicability, and supersession path.
- Failure
- Abstain with cannot-establish and identify the unresolved authority edge.
Configuration authority establishes the governing state.
- Supply agentConcept
Watches: material readiness, long-lead risk, substitution, and supplier deviation.
- Reads
- material identity · purchase and receipt state · certificates · approved alternatives
- May
- Surface constraint, evidence gap, and candidate response.
- Must not
- Approve a substitution, supplier deviation, or material release.
- Evidence
- Bind recommendations to lot, serial, certificate, requirement, and source time.
- Failure
- Hold the material gate unknown or open and route the evidence gap.
Procurement and engineering authorities decide.
- Production-readiness agentConcept
Watches: whether a work package can start under the six readiness gates.
- Reads
- configuration · material · predecessor · access · quality · resource evidence
- May
- Compute and explain READY, NOT READY, or CANNOT ESTABLISH.
- Must not
- Turn unknown into ready or release work by model confidence.
- Evidence
- Return each gate result with controlling evidence and evaluation time.
- Failure
- Fail closed to cannot-establish when evidence is stale, missing, or conflicting.
Named planner or supervisor releases the work.
- Inspection agentConcept
Watches: evidence completeness, anomaly, tolerance, and acceptance state.
- Reads
- inspection plan · measurement · NCR · acceptance criteria · instrument identity
- May
- Flag an anomaly and assemble the review evidence.
- Must not
- Accept work, close an NCR, or substitute a model score for measurement.
- Evidence
- Bind every observation to method, instrument, operator, time, and requirement.
- Failure
- Preserve the quality hold and escalate ambiguous or invalid evidence.
Authorized inspector accepts or rejects.
The line that does not move
- AI detects a dependency changethe engineer decides.
- AI identifies a supplier conflictprocurement decides.
- AI projects a schedule impactthe planner decides.
- Vision flags a weld anomalythe inspector decides.
- AI assembles the evidence for a changethe authorized engineer approves.
The next proof
A number, not a slogan.
The first bounded task worth putting a model on is change-impact: given REQ-1847 moving Rev A → Rev B, identify the 10 downstream objects it touches — and the ones it does not — citing evidence and abstaining where the record is insufficient. The scoring contract exists in the repository; these are the metrics it measures.
- Impact recallDid it find every object the change actually touches?
- Impact precisionDid it avoid flagging objects the change does not touch?
- Unsupported-claim rateHow often did it assert impact with no cited evidence?
- Abstention rateHow often did it decline rather than guess?
- Provenance completenessDid every asserted impact carry evidence?
Evaluation protocol defined · no benchmark claimed. No external model is invoked in the current system. The harness scores a prediction against synthetic ground truth on VS-001; a model-backed result would be published only once it is actually measured.
Where this actually is
Ambition and accomplishment, kept separate.
A working deterministic governance foundation. Everything below it is building, synthetic, concept, target, long-term, or explicitly not claimed. No item becomes a capability because it appears in a diagram.
- Governed software foundationWorking
- Synthetic vessel + production modelSynthetic
- Vessel dependency & change-impact modelConcept
- Production-intelligence feedbackConcept
- Computer-vision inspectionTarget
- Robotic material movementTarget
- Fabrication assistanceTarget
- Maritime autonomyTarget
- Owned manufacturing capacityNot claimed