Skip to main contentSkip to navigation

Brief / Foundations

Vessel delivery starts with controlled build state

The company’s thesis: before a yard can move faster, it must establish what governs, what changed, and who decides.

The real operating problem

A ship program rarely lacks information; it lacks one controlled account of it. The facts that decide what happens next are spread across requirements, drawings, PLM, ERP/MRP, schedules, work packages, quality records, supplier updates, email, and the memory of experienced people.

The failure is not “we need more AI.” The failure is that the build system cannot reliably establish current state: what governs, what changed, what material and work are affected, what conflicts, what remains unknown, and who must approve the consequence.

Why controlled state is a production feature

Veldarium’s thesis is that controlled build state may support better planning, automated comparison, production visibility, robotics, and bounded agentic work. It does not replace PLM, ERP, QMS, MES, or human authority. It connects evidence and state across them so downstream action is not based on an invented version of reality.

  • Governing source over newest file
  • Conflict and supersession remain visible
  • Unknowns stay labeled instead of filled in
  • Consequential action stays with a named human
  • Decisions update reusable program state

How the current proof stays bounded

A readiness result does not build a ship. It gives builders a bounded way to inspect state before planning, procurement, production, inspection, logistics, or machine work proceeds. Whether that improves elapsed time or safety must be measured on comparable real work.

VeldBuild is in development. Its current public proof uses the synthetic VS-001 vessel program and WP-019 work package to demonstrate one deterministic readiness contract. The larger vessel-delivery capability remains work for Veldarium to earn.