VELDBUILD / FIRST SOFTWARE + SYSTEMS LAYER
Know what can start.Know what changed. Know what governs.
VeldBuild is the first software and systems layer Veldarium is developing: engineering authority, configuration, material, work readiness, production, inspection, quality and as-built evidence held as one connected, inspectable, human-governed model.
WP-019 · VS-001 · block B30 — Seawater cooling spool set
- Open gates
- 2
- Unknown
- 0
- Evidence
- 6
VeldBuild is in development. Every demonstration on this site runs on VS-001, a synthetic concept vessel, with hand-authored data. There is no shipyard deployment, no customer, no live production integration, and no relationship to any government program.
Trace what changed. See what work it affects.
Veldarium's operating thesis is that industrial autonomy should not act without authoritative build state that can be established. Robots should not manufacture from conflicting revisions, and AI should not accelerate planning when controlling authority is unknown. VeldBuild starts with trustworthy state, then earns the right to automate against trustworthy state. It is being developed internal-first and must be pressure-tested through bounded industry work before any deployment claim is possible.
A dependency graph of one synthetic work package and its neighbours. Introduce a controlled drawing revision and watch it propagate: known-affected work, work known not affected, and work whose impact cannot be established — held apart, never collapsed. The change invalidates WP-019’s readiness; VeldMind explains the hold; a named authority still decides.
DR-118 Rev C governing · stable
Dependency list (text)
- WP-022 — Pipe penetration & seat prep Downstream: WP-019.
- WP-019 — Seawater cooling spool set depends on WP-022 (requires predecessor), MAT-441 (requires material), DR-118-C (governed by). Downstream: WP-021.
- WP-021 — Cooling equipment installation depends on WP-019 (requires predecessor), MAT-442 (requires material), DR-220-A (governed by).
- WP-014 — Machinery foundation structure depends on DR-205-A (governed by).
- WP-030 — Adjacent zone electrical routing depends on DR-118-C (governed by).
WP-019 may proceed. Every required gate is positively established against governing evidence.
- Configuration
- Material
- Predecessor
- Access
- Quality
- Resource
WP-019 may be advanced to release review. Every required gate is positively established.
- Configuration: Rev D released; CFG-029 closed. The route the crew holds is the governing revision.
- Material: All 9 spools received and accepted at receipt against the kit.
- Predecessor: WP-022 complete and accepted; the upstream joint the spool set lands on is closed.
VeldMind recommends and explains; it does not release work. A named human authority decides.
M. OkaforProduction release authority · B30
- 15:04:00observedState observed — WP-019: all gates established
- 15:04:11evaluatedReadiness evaluated — WP-019 = READY
- 15:04:22recommendedVeldMind — advance WP-019 to release review
Introduce the controlled change to trace its propagation
The state of the build is scattered. The crew needs one answer.
The state needed to build a vessel is scattered across engineering, PLM, ERP, scheduling, material systems, quality records, drawings, suppliers and the physical work itself. The crew still needs one reconciled answer across those authorities: can this work start, and if not, exactly what is stopping it?
- Engineering
- PLM
- ERP
- Material
- Schedule
- Work package
- Quality
- Physical build
Each system is correct about its own slice. None of them answers “can this work start?”
One connected model. The Build Graph.
VeldBuild builds one connected model of the build — a Build Graph of the real objects and the relationships between them — so that readiness, change and evidence become things the system can compute and a person can inspect, rather than facts someone has to reconstruct by hand.
- RevisionRev C
- DrawingD-204
- Work packageWP-019
- Material kit2 of 9 spools short
- InspectionINS-124 · pressure test
The objects are obvious; every yard has them. The value is the relationships — because once the edges exist, readiness, change and evidence become computable instead of remembered.
Concept architecture with a synthetic VS-001 implementation subset. This repository does not contain a production graph database, yard integration, machine interface, or customer build record.
Product definition
SyntheticWhat is the vessel, and how is it decomposed?
- Program
- Vessel
- Variant
- System
- Subsystem
- Zone
- Compartment
- Block
- Module
- Assembly
- Part
- Asset
Engineering authority
BuildingWhat defines the object, and which definition controls?
- Requirement
- Specification
- Drawing
- Model
- Revision
- Configuration baseline
- Change order
- Release
Supply and material
SyntheticWhat was sourced, received, certified, and made applicable?
- Material
- Supplier
- Purchase order
- Material lot
Work and resources
SyntheticWhat must happen, in what sequence, with which bounded resources?
- Work package
- Operation
- Trade
- Resource
- Machine
- Tool
Quality and acceptance
SyntheticWhat proves the work, what exception remains, and who accepted it?
- Inspection
- Test
- Nonconformance
- Deviation
- Waiver
- Hold
- Acceptance
Physical and as-built state
TargetWhat physically exists, where is it, and what record survives delivery?
- As-built record
Every edge is typed — it states why one record can govern, block, release, affect, locate, source, inspect or accept another, with a direction a reviewer can challenge; every assertion carries its provenance; and state moves as recorded events, never a silent overwrite. That full grammar is made to be inspected node by node in the Build Room , not read as a table here.
Six planes, one system.
Each plane carries its own maturity. The build-state core and authority run through everything; the integration and physical planes are the honest edges. Ten domain layers sit behind this on Systems.
- Working
- Runs today, with evidence and a named owner on /trust.
- Building
- Under active development. Partially real, not finished.
- Synthetic
- Hand-authored demonstration data. Not a customer system, not live.
- Concept
- A design position about how this could work. Nothing is built yet.
- Target
- A capability Veldarium intends to earn next. Not started or not proven.
- Long-term
- Company direction. Years out, and dependent on everything before it.
- Not claimed
- Veldarium does not have this, and is not implying that it does.
Full definitions, evidence and owners on Trust.
- 01
Applications
SyntheticBounded operating workflows a person actually uses — each one answering a single question and handing its output to a human.
- Build readiness
- Change impact
- Configuration authority
- Material readiness
- Quality & acceptance
- As-built control
- 02
Reasoning layer
BuildingSpecific bounded jobs: retrieve, compare, reconcile, detect a conflict, prioritise and draft. Deterministic governance works today; model-backed services remain under development and attach to a human gate.
- Retrieve
- Compare
- Reconcile
- Detect conflict
- Prioritise
- Draft
- 03
Build-state core
BuildingThe connected model itself — the vessel, what governs it, the work, the material, what physically exists, the constraints and the evidence.
- Vessel model
- Configuration
- Work graph
- Material state
- Production state
- Constraint state
- Evidence
- 04
Authority layer
WorkingWho is allowed to decide, and whether it can be shown afterwards. Roles, approval, maker-checker review, acceptance and audit run through everything above.
- Roles
- Approval
- Maker-checker
- Stop-work
- Acceptance
- Audit & provenance
- 05
Integration plane
ConceptThe design intent is to connect and govern build state across the systems a yard already runs — not to replace them. No production connector exists today.
- PLM
- ERP
- MES
- QMS
- CAD / engineering
- Scheduling
- Supplier systems
- Document systems
- 06
Physical interface
ConceptThe far edge, where software meets steel: machine and sensor state treated as first-class inputs to the same model. A design position, nothing more.
- CNC
- Robotics
- Scanning
- Machine telemetry
- Computer vision
- Inspection systems
The operator surfaces it is built around.
VeldBuild is one application with a coherent set of operator surfaces, not a pile of concepts. Build graph, readiness and change impact run on the synthetic proof today; the rest are target architecture, marked as such.
- Build controlConcept
Overall governed state, and the exceptions that need a person now.
- Build graphSynthetic
The typed dependency and configuration graph for any object.
- Readiness queueSynthetic
What may start, what may not, and what cannot yet be established.
- Change impactSynthetic
What one revision affects downstream — and what it does not.
- Material exceptionsConcept
Shortage, wrong revision or lot, late arrival, and provenance gaps.
- Quality & acceptanceConcept
Hold points, inspections, nonconformances and acceptance evidence.
- ConfigurationConcept
Which revision and effectivity govern which object right now.
- Evidence ledgerConcept
Why the system believes the current state — the records behind it.
- Integration healthConcept
Which external sources are healthy, stale, conflicting or unavailable.
- As-builtLong-term
What was actually installed and accepted versus what was intended.
Can this work start?
A work package is not ready because someone set a status field. It is ready when the conditions required to start are actually true: governing engineering released at the correct revision, material present and certified, the predecessor accepted, the inspection plan applicable, the trade and the access available, and no open hold. VeldBuild resolves that to READY, NOT READY, or CANNOT ESTABLISH — and when it is not ready, it names the binding constraint.
WP-019 resolves to NOT READY: 2 of 9 spools short, and the route is not yet re-released at Rev D (CFG-029 open).
Syntheticsynthetic proof · VS-001READY = configuration ∩ material ∩ predecessor ∩ access ∩ quality ∩ resource
- Configuration
Is the controlling engineering known, released, and applicable to the current baseline and effectivity?
- Material
Is the correct material received, certified, released, and at point of use?
- Predecessor
Are dependent operations complete and accepted?
- Access
Is the workface physically available without conflicting work or an unresolved access hold?
- Quality
Are required inspections, hold points, nonconformance dispositions, and acceptance criteria established?
- Resource
Are the trade, tool, machine, and workspace available?
READY requires affirmative evidence across every applicable dimension. A missing or disputed authority never becomes ready through confidence, schedule pressure, or a green status field.
Two definitions the code actually computes.
Not notation for effect. Readiness is a three-valued conjunction over gates; change impact is reachability over a typed dependency graph, classified by evidence. Both map to functions the synthetic proof runs — and the reasoning layer that reads this state is VeldMind .
READY(w) ⟺ ⋀_{g ∈ gates(w)} state(g) = established
- gates(w)
- the six gates of work w: configuration, material, predecessor, access, quality, resource
- state(g)
- three-valued gate state ∈ { established, open, unknown }
READY only when every gate is established. Any known-open gate makes the verdict NOT_READY; otherwise any unknown gate makes it CANNOT_ESTABLISH. Unknown is its own state — never counted as established, never collapsed into open. This maps directly to the readiness engine.
impact(c) = { n ∈ V : n ⇐* family(c) } partitioned by assessment(c, n)
- G = (V, E)
- the typed build graph — governed objects and their relationships
- family(c)
- the drawing family the change c revises
- n ⇐* family(c)
- n is reachable from the change over typed dependency edges
- assessment(c, n)
- recorded impact evidence for n under c
Candidates come from topology — the nodes related to the change. Each is classified known-affected or known-not-affected by its assessment evidence; a related node with no assessment is impact-not-established, never silently "unaffected." This maps to the revision-impact engine.
Change, configuration, material, production, evidence.
- 02
If this changes, what else moves?
SyntheticA revision does not end at engineering release. It propagates into configuration, material, released work, inspection and schedule. VeldBuild follows the dependency edges from the change to everything it touches, so the blast radius is a traceable calculation a person can review — not a memory test.
Rev C → Rev D on the seawater-cooling route reaches INS-124 hydrostatic test, HX-118 loop closure, B30 → B40 joint.
- 03
Which record actually governs?
WorkingA newer timestamp does not make a document the controlling one. Authority is a fact about a record — revision, baseline, effective date, applicability, supersession and the named approver — held explicitly, so a governed answer can say which revision governs this object right now, or refuse to answer when it cannot establish that.
- 04
Is the right material actually ready?
SyntheticA green line in a purchasing system is not production readiness. Material is ordered against a revision, certified against a specification, received against both, kitted, and available at the point of work — and it is held the moment any of those disagree. VeldBuild models the difference between “ordered” and “ready to weld.”
WP-019 is held on material: 2 of 9 spools short at receipt.
- 05
What physically exists?
TargetThe gap between the drawing and the object: planned, released, in work, built, inspected, accepted, as-built — completion that is measured rather than reported, and a record that has to survive delivery. This is the layer that requires a yard, and it is the one the whole mission is pointed at.
- 06
How do we know, and who signed?
BuildingEvery state worth acting on attaches to a record — an inspection, a test, an NDT report, a nonconformance, an acceptance with a name on it. The system should not say “complete”; it should be able to say “complete according to what, and accepted by whom.”
Machine recommends. System traces. Human decides.
AI drafts what a person will edit. Software holds state and evidence. A named person owns anything consequential — no amount of model confidence converts into approval. That boundary is not for sale.
- MACHINERECOMMENDSInterprets complexity and proposes.
- SYSTEMTRACESShows the evidence and the dependency.
- HUMANDECIDESA named person owns the consequence.
- SYSTEMRECORDSThe decision enters controlled configuration.
- MACHINEEXECUTESMachinery and crews carry it out.
- HUMANACCEPTSInspection closes against the governing revision.
Connect and govern build state — don’t replace the yard’s systems.
A yard already runs CAD, PLM, ERP, MES, QMS, scheduling and supplier systems. VeldBuild is designed to connect to them and govern build state across them — not replace them. No production connector exists today; this is target architecture.
- CAD / engineering
- PLM
- ERP
- MES
- QMS
- Scheduling
- Supplier systems
- Document systems
VeldBuild is a build-state layer, not an enterprise data-integration platform. It makes no interoperability claim with — and no claim to replace — any government or enterprise program.
The software page does not end in software.
VeldBuild earns the right to touch the yard one proof at a time. The progression is architectural, not a schedule — each stage carries its real status, and the later ones are honestly far off.
- 01Configuration & evidence foundationWorking
- 02Synthetic vessel & work model (VS-001)Synthetic
- 03Readiness resolutionSynthetic
- 04Change-impact propagationSynthetic
- 05Standalone VeldBuild applicationBuilding
- 06Source-system integrationsTarget
- 07Pilot with real production dataTarget
- 08Physical production stateTarget
- 09Machine & robotics interfaceConcept
- 10As-built, continuouslyLong-term
The aim is to preserve identity, authority, change, and evidence beyond delivery as a living configuration graph — not hand the vessel over as disconnected PDFs, binders, spreadsheets, and memory.
- Requirement
- Architecture
- Design
- Sourcing
- Material
- Fabrication
- Assembly
- Inspection
- Launch
- Trials
- Delivery
- Operation
- Maintenance
- Upgrade
- Retirement
Early, synthetic, and honest about it.
What runs today is a governed software layer and a synthetic build on VS-001. What does not exist: a deployed shipyard application, a customer, a production integration, a certification, or a government program. If you build ships and think the model is wrong, that is worth more to us than another diagram.