---
title: "Progress: What Veldarium Has Built So Far | Veldarium"
canonical: https://www.veldarium.com/progress
html: https://www.veldarium.com/progress
description: "The construction log: what Veldarium has built, what is synthetic and what is unsolved, each entry with its evidence, its limit and the date it was verified."
last_updated: 2026-10-12
representation: registry-derived Markdown
---

# Progress

> The construction log: what Veldarium has built, what is synthetic and what is unsolved, each entry with its evidence, its limit and the date it was verified.

## The distance

4 of 11 stages are implemented, on synthetic records. Highest proof reached: level 3 of 8, synthetic system demonstration.

- **01 Model the vessel** (Synthetic, proof level 3). Exists: Concept-vessel geometry: hull profile, keel line, transverse stations, decks and superstructure; Seven schematic build segments, each with synthetic state; Eleven vessel layers: seven physical systems and four state layers. Missing: A systems model, not naval architecture: no hydrostatics, no scantlings, no class compliance. Would falsify it: Presenting the concept vessel as naval architecture, or filling unknown particulars as if measured.
- **02 Model the build** (Synthetic, proof level 3). Exists: A ten-level build hierarchy, from program down to a single operation; A twelve-stage build sequence, block by block; Per-block progress by trade and inspection. Missing: Hand-authored for one synthetic program. Not generated from, or connected to, any real engineering system. Would falsify it: Treating the seven schematic segments as an engineered production breakdown of a real vessel.
- **03 Control the information** (Synthetic, proof level 3). Exists: Governed answers over bounded record sets; Authority, revision, supersession, applicability and conflict modeled explicitly; Maker-checker human review for supported actions; A deterministic public demonstration, with no language model invoked. Missing: Bounded scope, listed control by control on Trust. It runs on synthetic and constrained record sets, not a production document system. Would falsify it: An answer that cannot name its authority, or that treats a repository test as production document control.
- **04 Propagate change** (Synthetic, proof level 3). Exists: One synthetic change evaluated across five records, its impact kept three-valued; Illustrative profile positions, not engineering locations; A thirteen-level walk from requirement to steel, each level holding its state under change; One known-not-affected record and one impact-not-established record kept distinct. Missing: The dependency graph is authored, not derived. Real propagation requires reading a live engineering model. Would falsify it: Silence treated as unaffected, or an unmodeled relation presented as a cleared impact.
- **05 Material state, established per kit** (Building, proof level 2). Exists: A nine-stage material flow: one item clears, one stalls at receipt; Material as a vessel layer beside the physical systems; Work-package readiness derived from kit completeness. Missing: No procurement integration, supplier data or inventory. It demonstrates the constraint and tracks nothing real. Would falsify it: A shortage the model cannot see, or a substitution that enters a kit unapproved.
- **06 Production state** (Building, proof level 2). Exists: One program view: engineering release, material, structure and inspection closure; Critical dependencies as named constraints with owners; Authored block state on the drawing model’s identifiers. Missing: Every value is synthetic. Nothing is read from a production system, and there is no history. Would falsify it: A live production number presented as measured when it is still authored.
- **07 Human and AI operation** (Target, no proof level). Exists: A published authority chain: machine recommends, system traces, human decides, configuration records, production executes, human accepts; The AI role and human gate stated for each of ten operating stages. Missing: Governed retrieval exists. Assembling live build state into a prepared decision comes after governed state survives a partner’s real records. Would falsify it: A recommendation that executes, or an unknown gate rounded to a proceed.
- **08 Human and machine production** (Long-term, no proof level). Exists: nothing yet. Missing: Nothing is built. Veldarium operates and integrates no machinery; this is a design position on where the architecture must go. Would falsify it: Any implication that Veldarium currently operates or instructs machinery.
- **09 Physical industrial cells** (Long-term, no proof level). Exists: nothing yet. Missing: Nothing is built. No facility, no equipment, no cell. Would falsify it: A laboratory photograph or vendor brochure presented as a Veldarium cell.
- **10 Integrated shipbuilding capability** (Long-term, no proof level). Exists: nothing yet. Missing: Nothing is built. This depends on every stage above it. Would falsify it: A software architecture described as shipbuilding capability.
- **11 Vessel delivery** (Long-term, no proof level). Exists: nothing yet. Missing: Veldarium has not yet built a ship. This is the destination. Would falsify it: A render, a repository, or a demonstration presented as delivery.

Proof levels, and the stages that reached each:

1. **Code exists:** The mechanism is written and can be read. Reached by stages 01, 02, 03, 04, 05 and 06 of 11.
2. **Tested:** Tests that can fail hold its rules, including the ways it must refuse. Reached by stages 01, 02, 03, 04, 05 and 06 of 11.
3. **Synthetic system demonstration:** The mechanisms run together on authored records a reader can inspect. Reached by stages 01, 02, 03 and 04 of 11.
4. **Real records, live decision:** A real operating decision made on a partner’s records, with a named owner and failure criteria. No stage has reached it.
5. **Physical process:** One physical process run under governed state, measured and inspected. No stage has reached it.
6. **Repeatable physical output:** The same output produced again and again, with time, cost, quality and rework measured. No stage has reached it.
7. **Integrated production:** Several processes, suppliers and trades working as one production system. No stage has reached it.
8. **Vessel delivery:** A vessel designed, built, tested and delivered, then a second. No stage has reached it.

## Proof ledger

### Concept vessel and system model (Synthetic)

One synthetic concept vessel, VS-001, carried through every scene on this site: hull, structure, seven build segments and eleven layers of systems and state.

- **Why it matters to shipbuilding:** Downstream capabilities need shared object identity. When planning, material and inspection refer to different objects or segments, their state cannot be reconciled without resolving that disagreement.
- **What actually works:** One geometry drives geometry, system, dependency, production, inspection and delivery views; Layer isolation with dependency, owning roles, work packages, machine opportunities and inspection points; Keyboard-operable, reduced-motion-complete, screen-reader summarized
- **What is synthetic:** The hull, its dimensions and all identifiers are invented; System routes are illustrative, not engineered
- **What it does not do:** Not naval architecture: no hydrostatics, scantlings, stability or class compliance; The 3D view is a concept visualization lofted from the two-dimensional schematic profile: no engineered hull surface, no volumes, no interference checking and no class; Cannot be imported from or exported to any CAD or PLM system
- **Repository evidence:** apps/web/src/lib/shipbuilding/vessel-geometry.ts; apps/web/src/components/industrial/Vessel.tsx; apps/web/src/lib/shipbuilding/vessel-spatial.ts
- **Owner:** Founder (Product and design)
- **Last verified:** 2026-09-07
- **Opens next:** A vessel model that can be populated from a real engineering source rather than authored.

### Build hierarchy: program to weld (Synthetic)

Ten levels of build hierarchy on the concept vessel, each answering the same questions: what it is, its state, who owns it, what governs it and what it waits on.

- **Why it matters to shipbuilding:** Production is executed against work packages, not drawings. A system that cannot represent the package, its operations, its material and its inspection cannot tell anyone whether work can start.
- **What actually works:** Drill from program to a single weld operation and back to accepted configuration; Gates rendered explicitly: what each object is waiting on; Blocked state traced to a cause: a revision that re-specifies two of the spools
- **What is synthetic:** The entire program and every record in it
- **What it does not do:** One authored program; no multi-vessel, no scheduling engine, no critical path; No write path: nothing can be updated, closed or approved; No integration with any planning or ERP system
- **Repository evidence:** apps/web/src/lib/shipbuilding/build-room.ts; apps/web/src/components/industrial/BuildGraph.tsx
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** A hierarchy populated from a real planning or engineering source instead of authored.

### Governed answers (Working)

The layer Veldarium has taken furthest: which record governs a question at a given scope and date, with rejected evidence kept visible and a refusal when authority cannot be established.

- **Why it matters to shipbuilding:** If a crew cannot determine which revision controls the work, the resulting decision can create rework, inspection, or material risk. This proof does not measure how often that occurs.
- **What actually works:** Authority, revision, supersession and applicability modeled explicitly rather than inferred from recency; Conflicting records surfaced instead of averaged into fluent prose; Evidence lineage attached to every answer, including what was rejected and why; Refusal path when no governing record can be established; Maker-checker human review for supported action types; Deterministic synthesis: no external language model in the public path
- **What is synthetic:** The public proof runs on the synthetic concept vessel and one synthetic work package
- **What it does not do:** Bounded to the document types listed in the capability registry; No production connector fleet: it does not read a live PLM, ERP or QMS; Scope and limits are listed control by control on Trust
- **Repository evidence:** packages/core/src_pkg/services/answer.ts; packages/core/src_pkg/test/answer-governance.unit.test.ts
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** Applying the same authority model to a bounded real engineering record set with an industry partner.

### Change impact propagation (Synthetic)

One synthetic engineering change followed through the build: what it is known to affect, what an assessment shows it does not, what no one has assessed, and the work that must be recomputed.

- **Why it matters to shipbuilding:** A useful impact record needs an evidenced boundary while preserving relations the available data cannot establish.
- **What actually works:** Three distinct states: known affected, known not affected, impact not established; The same synthetic records feed the evaluation and the public impact view; Illustrative profile positions are labeled as presentation coordinates, not engineering locations; Unknown impact is not silently promoted to not affected
- **What is synthetic:** The dependency graph is authored for VS-001, not derived from an engineering model
- **What it does not do:** Cannot discover dependencies: they are declared; No cost or schedule model behind the schedule-impact step; One scenario, not a general impact engine
- **Repository evidence:** apps/web/src/lib/shipbuilding/change-propagation.ts; apps/web/src/lib/shipbuilding/change-impact-eval.ts; apps/web/src/lib/shipbuilding/build-graph-model.ts
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** Deriving the dependency graph from a real model so propagation is computed rather than authored.

### Requirement to vessel (Synthetic)

One synthetic requirement traced down thirteen levels to a pipe-work operation, each level holding what a change would ask of it. The Systems map draws the same path in nine stages.

- **Why it matters to shipbuilding:** Veldarium’s thesis is that making the path from requirement to physical work visible can make change review more disciplined; this surface does not measure an outcome.
- **What actually works:** Thirteen levels from requirement to vessel in code, each with an owner, an illustrative magnitude and its state if the requirement changes; The Systems map draws the path in nine stages, naming the requirement and the drawing it reaches
- **What is synthetic:** The requirement, its revision and every object it touches
- **What it does not do:** One requirement, one path. Not a requirements management system; No verification or traceability matrix; Magnitudes are illustrative, not calculated
- **Repository evidence:** apps/web/src/lib/shipbuilding/requirement-walk.ts; apps/web/src/components/industrial/ExecutionSpine.tsx
- **Owner:** Founder (Product and design)
- **Last verified:** 2026-09-07
- **Opens next:** Many requirements over one vessel, with coverage and orphan detection.

### Material readiness model (Synthetic)

Two items on the same route into one work package. One clears. The other was made to a revision a change has just superseded, so it is held and the package is not ready.

- **Why it matters to shipbuilding:** If the material is not there, the work is not ready, and no planning system is entitled to say otherwise. Physical constraints have to govern the digital system rather than the reverse.
- **What actually works:** Readiness derived from kit completeness rather than asserted; A named cause for the hold, not a red badge; Material modeled as a first-class vessel layer
- **What is synthetic:** The items, the supplier, the superseded revision and the lead times
- **What it does not do:** No procurement, inventory or receiving integration; No supplier records, lead-time data or substitution workflow; Nine stages are illustrative of a real flow, not a configurable process
- **Repository evidence:** apps/web/src/lib/shipbuilding/work-packages.ts; apps/web/src/lib/shipbuilding/readiness.ts
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** A material graph that reconciles a real BOM against real purchase and receipt state.

### Program state view (Synthetic)

One operational picture of the concept program: engineering release, material readiness, structure, inspection closure, block state and named critical dependencies.

- **Why it matters to shipbuilding:** This teaching view asks what a responsible owner might need to inspect in one place; it makes no claim about how real programs currently review state.
- **What actually works:** Critical dependencies expressed as a constraint, a consequence and an owner; Authored synthetic block state uses the same identifiers as the drawing model; no roll-up is claimed
- **What is synthetic:** Every number on the view is invented for the synthetic program
- **What it does not do:** No ingestion, no history, no time series, no forecasting; Values do not move because nothing produces them; The value is the information architecture, not the figures
- **Repository evidence:** apps/web/src/lib/shipbuilding/build-room.ts; apps/web/src/lib/marketing/yard-capability.ts
- **Owner:** Founder (Product and design)
- **Last verified:** 2026-09-07
- **Opens next:** State computed from the build model instead of authored alongside it.

### Human authority boundary (Working)

One published chain, applied across the site: machine recommends, system traces, human decides, configuration records, production executes, human accepts.

- **Why it matters to shipbuilding:** Acceptance, safety and disposition carry legal and physical consequence. A system that blurs who decided something is not usable in a yard, however good its answers are.
- **What actually works:** Every operating stage states its AI role and its human gate separately; Each of the four actors carries an explicit boundary, including what AI does not do; Enforced by test: the deciding and accepting actor must be human
- **What is synthetic:** Nothing synthetic in this entry
- **What it does not do:** This is an architectural commitment and a published position, not an enforcement mechanism; Nothing here prevents a future integration from violating it: that requires runtime controls
- **Repository evidence:** packages/core/src_pkg/services/actions.ts; packages/core/src_pkg/test/actions-integrity.unit.test.ts
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** Runtime enforcement: an approval path that cannot be satisfied without a named person.

### Industrial base dependency model (Source-backed)

The industrial base drawn as a four-tier load path, vessel to systems to fabrication to foundations, with the exposure at each node stated.

- **Why it matters to shipbuilding:** A relevant constraint may sit in a yard, supplier, foundry, machining source, workforce pipeline, or another part of the industrial base; each claim needs facility-level evidence.
- **What actually works:** Structural argument published with per-node exposure; A facility-record standard published before any record exists
- **What is synthetic:** Nothing synthetic in this entry
- **What it does not do:** The verified facility registry is empty. No record has been through the sourcing standard yet; No claim is made about any specific company; Source bodies are cited as publishers of data, not as partners
- **Repository evidence:** apps/web/src/app/industrial-base/page.tsx; docs/PUBLIC_CLAIMS_REGISTER.md
- **Owner:** Founder (Research)
- **Last verified:** 2026-09-07
- **Opens next:** A first set of facility records that satisfy every required field, including a published coordinate.

### Operational decision assembly (Target)

Assemble live build state into one prepared decision a supervisor can accept or reject.

- **Why it matters to shipbuilding:** Veldarium’s hypothesis is that assembling the governing state may reduce decision-preparation burden. No current baseline, phone-call count, or time saving is claimed.
- **What actually works:** Nothing claimed yet
- **What is synthetic:** Nothing synthetic in this entry
- **What it does not do:** Not started. The governed retrieval half exists; the operational assembly half does not; Requires readiness computed from live records; today the readiness engine runs only on synthetic ones
- **Repository evidence:** docs/PRODUCT_TRUTH.md
- **Owner:** Founder (Product engineering)
- **Last verified:** 2026-09-07
- **Opens next:** The first capability where Veldarium software changes what happens on a shift.

## What comes next

- **Next proof level:** Level 4 of 8, real records, live decision.
- **The evidence that would count:** One real release decision on a design partner’s work area, rebuilt from its own records: every fact traced to its owning system, a named owner, and failure criteria written before any record is read. It is the gate of [rung 0, governed build state](https://www.veldarium.com/roadmap#rung-governed-state).

### Every stage: its evidence, its next gate and what counts as complete

- **01 Model the vessel.** Earned through: apps/web/src/lib/shipbuilding/vessel-geometry.ts; apps/web/src/components/industrial/Vessel.tsx; apps/web/src/lib/shipbuilding/vessel-spatial.ts. Next gate: Model the build as production strategy, not visual segmentation. Counts as complete when: A vessel representation whose unknowns stay unknowns: schematic geometry with engineering limits explicit, and no invented class, beam, or displacement.
- **02 Model the build.** Earned through: apps/web/src/lib/shipbuilding/build-room.ts; apps/web/src/components/industrial/BuildGraph.tsx. Next gate: Control which record governs. Counts as complete when: Work packages bound to zones, trades, predecessors and inspection gates, distinguishable from a pretty explode view.
- **03 Control the information.** Earned through: packages/core/src_pkg/services/answer.ts; packages/core/src_pkg/test/answer-governance.unit.test.ts. Next gate: Propagate change without collapsing unknown impact into clear. Counts as complete when: A named human can see which record governs, why a conflict was refused, and what evidence would change the answer, against a bounded record set.
- **04 Propagate change.** Earned through: apps/web/src/lib/shipbuilding/change-propagation.ts; apps/web/src/lib/shipbuilding/change-impact-eval.ts; apps/web/src/lib/shipbuilding/build-graph-model.ts; apps/web/src/lib/shipbuilding/requirement-walk.ts; apps/web/src/components/industrial/ExecutionSpine.tsx. Next gate: Material and supply as facts about kits, not dates. Counts as complete when: A change reports known-affected, known-not-affected, and impact-not-established as distinct, computed from topology plus recorded assessments.
- **05 Material state, established per kit.** Earned through: apps/web/src/lib/shipbuilding/work-packages.ts; apps/web/src/lib/shipbuilding/readiness.ts. Next gate: One operational picture of what is actually happening on the build. Counts as complete when: Readiness of a work package derived from kit completeness, receipt, and applicability, not from a planner assertion.
- **06 Production state.** Earned through: apps/web/src/lib/shipbuilding/build-room.ts; apps/web/src/lib/marketing/yard-capability.ts. Next gate: Assemble live build state into a prepared decision a named person still owns. Counts as complete when: Blocked work traces to a named constraint with an owner, and inspection closure is a running number against the governing revision.
- **07 Human and AI operation.** Earned through: packages/core/src_pkg/services/actions.ts; packages/core/src_pkg/test/actions-integrity.unit.test.ts. Next gate: Waits on rung 0’s gate: one real decision on a partner’s records. Physical production is not next either. Counts as complete when: A prepared option names its evidence, its uncertainty, and the person who must accept or reject it. The system does not release work.
- **08 Human and machine production.** Earned through: no receipt: nothing has been built for this stage. Next gate: Not the next front. Earned only after human-and-AI operation is real. Counts as complete when: Machine programs generated from a released model, and sensor state read back into the build record.
- **09 Physical industrial cells.** Earned through: no receipt: nothing has been built for this stage. Next gate: Not the next front. Requires a cell that does not exist. Counts as complete when: A physical cell Veldarium actually operates, with measurement captured into the same record that governed the instruction.
- **10 Integrated shipbuilding capability.** Earned through: no receipt: nothing has been built for this stage. Next gate: Not the next front. Depends on every stage above it. Counts as complete when: Engineering through delivery on one governed state, with partnerships where others are better and internal capability where owning it matters.
- **11 Vessel delivery.** Earned through: no receipt: nothing has been built for this stage. Next gate: The destination. Not a current gate. Counts as complete when: A vessel that leaves a yard and works. Then a second, and a third.

## Contact

To discuss a first VeldBuild deployment, or the company: [chris@veldarium.com](mailto:chris@veldarium.com). Name the release decision your team rebuilds by hand. Do not send confidential information in the first message.

## Sitemap

- [Full site map](https://www.veldarium.com/sitemap.md)
- [Machine context](https://www.veldarium.com/llms.txt)