System complexity
Thousands of interdependent objects across a dozen disciplines, reconciling inside one hull on one schedule.
Software is the first layer.It is not the company.
The story is not “we built a governed-answer system to sell to shipyards.” It is that Veldarium is attempting to build a new American industrial company — software as the first earnable layer, shipbuilding as the first physical mission — each subsequent layer earned in order.
Not claimedNo active raise is implied by this pageBefore anything else
Veldarium has no disclosed revenue, funding round, valuation, backlog, customers, team size, facility, vessel, or contract. If this page ever reads as though it does, that is a defect — the full not-claimed list is below and on Trust.
Sheet 01 · Fact, hypothesis, ambitionThree registers, separated so diligence does not have to
Read in three registers
What is true. What we are betting. What we intend.
Most of diligence is separating these three, because most companies write all three in the same voice. They are separated here so you do not have to — and the middle column is the one worth arguing about.
Fact
Verifiable today by someone who does not trust us.
A governed-answer system runs today. It establishes which revision controls, cites the records it used, and refuses to answer when the evidence does not support one.
How to check itOpen the working layer and ask it something it cannot establish. It should stop rather than guess.
Veldarium operates no shipyard, has delivered no vessel, holds no contract, integrates no machinery, and makes no public team-size claim.
How to check itThe not-claimed list on this page and on /trust states each of these in the negative, and no page contradicts it.
Public vessel, program, work-package and material examples on this site are synthetic and labelled on the surfaces where they appear.
How to check itVS-001 carries a synthetic marker everywhere it is rendered, including inside the Build Room panel.
Four of eleven capability stages are implemented in this repository: one working deterministic governance stage and three synthetic models or demonstrations.
How to check itThe climb on /progress states the evidence and limitation for each stage. Future stages carry no implementation evidence.
Hypothesis
Believed and acted on, but not yet proven.
Governed domain primitives — authority, configuration, production state, human ownership — outlast model generations, and compound rather than depreciate as models change underneath them.
What would settle itSwap the model layer and see whether the system still answers correctly. If the primitives were doing the work, the answers hold.
Control of the engineering and production state is the binding constraint on shipbuilding tempo — more than labour, more than capital equipment.
What would settle itA real program where readiness is computed rather than reported, and the recovered hours are measured against the same work done the old way.
A software company can become a shipbuilder in this order — model, control, operate, then touch steel — and cannot credibly do it in any other.
What would settle itWhether the operating layer survives contact with a real yard before any physical capability is attempted.
Shipbuilders will adopt a system that refuses to answer when it cannot establish authority, and will trust it more for refusing.
What would settle itA pilot where the refusal behaviour is the reason it gets used rather than the reason it gets switched off.
Ambition
Intended. Not started, and not claimed as capability.
Run production operations on this system inside a working yard.
What has to be true firstThe operating layer has to exist and survive a real program first. It does not exist today.
Treat cutting, welding, handling and inspection machinery as first-class inputs to the same model that governs engineering.
What has to be true firstMachine integration has to be built. Veldarium has never driven a tool.
Own physical production capability — cells, not just software.
What has to be true firstCapital, a site, licensing, qualified people, and a demonstrated operating layer. None of it is in place.
Deliver a vessel a customer can depend on.
What has to be true firstEverything above, in order. This is the destination, and it is the only proof that finally counts.
The arena
Shipbuilding is unusually hard. That is the argument, not an objection to it.
The properties below make shipbuilding a poor fit for a quick software thesis. They may support a durable industrial position if it is earned, but none of them makes success likely.
Production complexity
Block construction, one-off geometry, confined access, and work that cannot be reordered freely.
Long timelines
Early design and sourcing decisions can surface much later in production and test.
Supplier dependence
Long-lead and engineered-to-order components can place important schedule state outside the yard.
Skilled-workforce dependence
Availability, experience, sequencing, and continuity across skilled roles materially shape delivery.
Capital intensity
Facilities, tooling and working capital at a scale that punishes being wrong.
Configuration complexity
What is actually built diverges from what was drawn, continuously, and has to be reconciled.
Difficult integration
Late integration and commissioning can expose unresolved upstream dependencies that added staffing alone may not remove.
Demanding quality
Acceptance standards that are non-negotiable and expensive to establish after the fact.
This does not make the outcome inevitable. Difficult arenas are difficult for the entrant too.
The expansion model
Five layers, in order, each gated on the one before it.
Vertically integrating too early is one of the most reliable ways to kill an industrial company. The sequence below is the plan, and the status labels are the discipline that keeps it honest.
- TodayWorking
Evidence-bound build state
- Authority — which record actually governs
- Evidence — the chain behind every answer
- Permission-aware retrieval
- Conflict and disagreement kept visible
- Revision and supersession
- Named human ownership of consequence
The bounded software foundation and deterministic readiness proof run on synthetic records, with each control listed and limited on /trust.
- BuildingBuilding
Shipbuilding system model
- Vessel hierarchy — program to operation
- Work packages and dependencies
- Material and supplier state
- Engineering and production state in one model
- Configuration across the whole vessel
The model is being built and demonstrated on VS-001, a synthetic concept vessel. No customer program runs on it.
- NextTarget
Shipbuilding operations
- Engineering system integrations
- Production coordination and sequencing
- Planning against real material readiness
- Supplier and procurement state
- Quality and inspection closure
Not started as delivered capability. This is the layer that requires working with a real yard, which requires earning it.
- LaterConcept
Machine integration
- Sensors and machine state
- CNC and fabrication systems
- Robotic welding and handling
- Scanning and automated inspection
- Autonomous material movement
A design position about where the architecture has to go. Veldarium operates no machinery and integrates none today.
- Long termLong-term
Physical capability
- Specialised production technology
- Production cells and tooling
- Manufacturing and yard partnerships
- Vessel construction
- Repeatable shipbuilding capacity
Company direction. Veldarium owns no facility, holds no vessel contract, and has built no ship.
The destination
Build ships.
That is the destination. Stating it is not the same as claiming it — every rung above has to be earned in order, and each one is labeled with where it actually stands.
Status key
- 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.
What capital should buy
Capability, then evidence, then the right to attempt the next layer.
Not a pie chart. A chain: money buys people and tools, which buy access to real work, which produces the first honest evidence this company will ever be able to publish.
- 01
Capital
Runway measured in capability earned, not months survived.
- 02
People
Engineering, naval architecture, production, robotics — not only software.
- 03
Tools
The engineering, simulation and production environment the work requires.
- 04
Design partners
Yards, fabricators and suppliers willing to expose a real bottleneck.
- 05
Prototypes
Working systems against real records, not slideware.
- 06
Integrations
Engineering, planning and material systems that already run the work.
- 07
Production experiments
Bounded trials on real work, with the result recorded either way.
- 08
Measured evidence
The first honest numbers this company will ever be able to publish.
- 09
Next capability
Evidence is what earns the right to attempt the next layer of the stack.
CFO pass · categories, not projections
Four capital regimes. No phase skips its evidence gate.
Software, a real-data pilot, physical R&D, and production have different cost structures and failure modes. No fabricated amount, timing, valuation, or return is attached. The point is to show what must become true before the next kind of capital is responsibly deployed.
- 01 · Now
Software foundation
BuildingMake authoritative build state inspectable before asking a yard or a machine to depend on it.
Cost categories: Engineering · Compute · Cloud or on-premises infrastructure · Security · Insurance · Legal · Integration development · Commercial discovery
Evidence gate: A bounded VeldBuild workflow passes defined authority, readiness, provenance, security, and human-review tests against representative records.
- 02 · After software evidence
Real-data pilot
TargetPressure-test one cross-system handoff without pretending to replace a yard’s operating stack.
Cost categories: Travel · Implementation · Data cleanup · Security review · Support · Customer-specific adapters · Evaluation · Training
Evidence gate: A willing industry partner defines the problem, sources, authority owner, baseline, success metric, data rights, and stop conditions before implementation begins.
- 03 · After pilot evidence
Physical R&D
Long-termTest how governed instructions and returned evidence survive contact with a bounded production cell.
Cost categories: Industrial space · Robots · Tooling · Safety systems · Production engineers · Materials · Metrology · Prototypes · Maintenance
Evidence gate: The operating layer has survived real work, the cell has a qualified owner, and safe-state, instruction validation, inspection, rollback, and evidence return are independently reviewed.
- 04 · After physical proof
Production capability
Long-termAttempt repeatable physical output only after the information and operating layers have earned it.
Cost categories: Facility · Steel and material · Skilled labor · Machines · Inventory · Supplier financing · Working capital · Quality systems · Insurance · Compliance
Evidence gate: Demand, design maturity, workforce, supplier capacity, quality authority, regulatory path, working capital, facility plan, and production evidence all support a bounded program decision.
Potential moat · hypotheses only
What might compound — and what would have to prove it.
An ontology, graph, integration, or feedback loop is not a moat because it appears in a deck. Each candidate below remains a hypothesis until repeated use, lawful data access, and measurable operating dependence establish otherwise.
CandidateMechanismWhat would prove it
Ship-specific build ontology
ConcepthypothesisA durable model of product, work, material, authority, quality, and as-built relationships.It must represent real yard state more faithfully and usefully than project-specific mappings.
ConcepthypothesisA durable model of product, work, material, authority, quality, and as-built relationships.It must represent real yard state more faithfully and usefully than project-specific mappings.
Accumulated industrial graph
ConcepthypothesisReviewed build relationships, dispositions, and evidence compound across programs without erasing program boundaries.Repeated programs must show lawful reuse, measurable retrieval value, and strong tenant and data-rights isolation.
ConcepthypothesisReviewed build relationships, dispositions, and evidence compound across programs without erasing program boundaries.Repeated programs must show lawful reuse, measurable retrieval value, and strong tenant and data-rights isolation.
Production feedback loops
ConcepthypothesisObserved fabrication, inspection, and as-built state can inform future design and planning.Reviewed production evidence must change a later decision without creating uncontrolled authority.
ConcepthypothesisObserved fabrication, inspection, and as-built state can inform future design and planning.Reviewed production evidence must change a later decision without creating uncontrolled authority.
Integration depth
ConcepthypothesisNative identifiers, revisions, applicability, permissions, and events survive cross-system reconciliation.At least one production integration must preserve meaning, failure behavior, revocation, and auditability.
ConcepthypothesisNative identifiers, revisions, applicability, permissions, and events survive cross-system reconciliation.At least one production integration must preserve meaning, failure behavior, revocation, and auditability.
Workflow embedding
ConcepthypothesisVeldBuild becomes part of a bounded authorization or acceptance handoff instead of another reporting surface.A real operating team must repeatedly rely on the workflow and retain a clear exit path.
ConcepthypothesisVeldBuild becomes part of a bounded authorization or acceptance handoff instead of another reporting surface.A real operating team must repeatedly rely on the workflow and retain a clear exit path.
Lifecycle configuration state
ConcepthypothesisThe accepted build graph survives delivery into maintenance, upgrade, and retirement decisions.A delivered configuration must stay current, authoritative, and usable through a real lifecycle event.
ConcepthypothesisThe accepted build graph survives delivery into maintenance, upgrade, and retirement decisions.A delivered configuration must stay current, authoritative, and usable through a real lifecycle event.
Risk
16 ways this does not work — and what would reduce each one.
A risk section that only lists risks is theatre. Each one below is paired with the specific evidence that would actually move it, which is also how the company decides what to build next.
RiskWhat evidence reduces it
Domain complexity — shipbuilding is genuinely hard and unforgiving of outsidersNaval architecture and production expertise inside the company, not consulted occasionally.
Credibility — an early company asserting it can change how ships get builtWorking software against real records, and public claim boundaries that hold up under inspection.
No customer or yard access — yards are slow to open, and for defensible reasonsA signed design-partner engagement on a bounded, real problem.
Integration — engineering and production systems in yards are decades deepA completed integration against a production system of record, with the failure modes documented.
Security and procurement — defense-adjacent work has real requirementsSecurity posture built before it is demanded, and stated plainly on /trust.
Long sales cycles — industrial buying may take quarters rather than weeksA repeatable bounded first engagement that produces value inside one cycle.
Capital intensity — physical capability is expensive and unforgivingSequencing: physical capability attempted only after the software and operations layers are earned.
Recruiting — this needs welders and naval architects, not only engineersHires across trades, production and engineering, not a software-only team.
Automation difficulty — variable geometry and access can limit where robotics are usefulHonest scoping of what machines can and cannot reach, tested rather than assumed.
Expansion discipline — premature vertical integration can exceed an early company’s evidence and capital baseEach layer gated on the one before it, publicly, with status labels that do not move quietly.
Founder concentration — strategy, product context and external relationships depend on one personDocumented decision rights, independent technical review, and leadership hires who own critical domains.
Regulatory and classification path — vessel and machinery approval cannot be improvised lateA scoped approval basis, named qualified owners, and early engagement with the applicable class and regulatory authorities.
Cybersecurity — connected vessel, yard and supplier state expands the attack surfaceThreat models, segmented deployment, least privilege, auditability, incident response and verified controls appropriate to the data and environment.
Incumbents — PLM, ERP, MES, CAD, data and defense platforms already own adjacent layersA complementary build-state wedge that preserves native authority and wins a bounded workflow without requiring stack replacement.
Supplier constraints — a graph cannot manufacture scarce components or create qualified capacitySupplier-state visibility tied to design alternatives, qualification lead time, working-capital needs and real capacity evidence.
Physical manufacturing execution — software evidence may fail to survive contact with steelA bounded production experiment with qualified people, approved instructions, safe states, inspection evidence and an honest recorded result.
The not-claimed list
What Veldarium does not have.
Published here rather than buried, because an early company’s credibility is built on what it refuses to imply. Every item below is something a reader might reasonably assume from the ambition on the rest of this site.
A shipyard, a drydock, or any manufacturing facility
A vessel under construction, delivered, or under contract
A Navy, Department of Defense, or other government contract or program
A defense customer, a commercial customer, or disclosed revenue
Production robotics, CNC machinery, or automated production lines in operation
Certifications, accreditations, or third-party audits
An employee count, team size, or disclosed funding round
Classified work, cleared facilities, or cleared personnel
Shipbuilding customers, design partners under contract, or a backlog
If this is the kind of company you back
Long-horizon, physical, and slow to fake.
Veldarium is not implying an active raise. If the expansion model above is the kind of company you want to understand — industrial, defense-adjacent, and measured in years rather than quarters — a direct conversation is the right first step.