Software is the first layer.
It is not the company.
What would capital accelerate, in what order, and what would break it?
Veldarium enters shipbuilding through software that settles what work may start and who releases it, and moves toward production only as evidence earns each step. The entry is narrow. The destination, an integrated American shipbuilder, is not. The order is the Roadmap.
No raise is implied, and no amount, date, valuation or revenue figure appears, because none exists to state. Nothing here is an offer to sell, or a solicitation of an offer to buy, any security. Statements about the future are intentions, not predictions or promises.
Rung 0 · Governed build state to Vessels
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
Next: Real records, live decision
The brief
Four questions, then where the value moves.
- What problem is large enough to matter?
- Navy and Coast Guard shipbuilding has run billions of dollars over cost and years behind schedule for two decades. GAO, April 2026. Veldarium’s hypothesis, not a finding of any source: no single cause explains it. The prize is qualified, repeatable production capacity, and no software product creates that alone.
- Why now?
- In December 2025 the Navy announced a 448 million dollar investment in ShipOS, a program that applies Palantir’s software to shipbuilding data, run by its Maritime Industrial Base program with Naval Sea Systems Command. U.S. Navy, December 2025. Veldarium’s hypothesis, not a finding of any source: capital now reaching the industrial base will need a layer that settles, with evidence, the question at the work face: whether a package may start, on which records, and who releases it.
- What is Veldarium?
- An American company building toward an integrated shipbuilder, starting with software. VeldBuild, the first layer, would establish from a yard’s records what work can start and who decides. VeldMind would reason over it and never hold authority.
- Who pays, and for what?
- A shipyard or fabricator, for VeldBuild over a widening boundary: a work area, then a program, then a yard. The product carries between deployments; each customer’s mapping, gates and roles are configured for it. Terms for a first deployment, including whether it is paid, are not yet set.
Where value could sit, layer by layer
- SoftwareGoverned build state: the model, the engines and the decision record.A ship-specific model of authority, readiness and evidence is slow to build and has to survive real records.
- IntegrationConnectors and identifier mapping into the systems a yard already runs.Mapping that preserves each system’s meaning, revisions and permissions is earned one deployment at a time.
- Production engineeringProcess plans, qualification logic and execution planning.Process knowledge proven on real work is not in any software product.
- AutomationCells, tooling, controls and machine integration driven from governed state.A qualified cell is hardware, procedure and people together; buying the machine does not copy it.
- ManufacturingProduction capacity, facilities and the trades to run them.Qualified physical capacity takes years and capital to stand up.
- Vessel programsDesign, production, delivery and support of vessels.A delivered vessel, and the evidence that the next one is built better, is the hardest thing in the stack to copy.
What has to be proven before each next phase can start?
Capital goes to the next evidenced bottleneck, never ahead of it.
No phase reads further along than the capability ledger says.
What each phase must prove, and what capital would accelerate
Categories of cost, never amounts. Nothing in a phase is bought before its gate opens.
- 01
Software foundation
NowTargetProve governed build state on one partner’s real records before asking a yard or a machine to depend on it.
- What must be proven
- 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.
- What capital enables
- EngineeringComputeCloud or on-premises infrastructureSecurityInsuranceLegalSource-system connectorsCustomer research
- 02
First deployments
After software evidenceTargetExtend VeldBuild from the first work area to a whole program, beside the yard’s own stack.
- What must be proven
- The layer holds under engineering, material, production and quality authority on a live program, used repeatedly by the people who own those decisions, with a working exit path.
- What capital enables
- TravelImplementationData cleanupSecurity reviewSupportConnector hardeningEvaluationTraining
- 03
Physical R&D
After program evidenceLong-termTest how governed instructions and returned evidence survive contact with a bounded production cell.
- What must be proven
- VeldBuild has survived real programs, the cell has a qualified owner, and safe-state, instruction validation, inspection, rollback, and evidence return are independently reviewed.
- What capital enables
- Industrial spaceRobotsToolingSafety systemsProduction engineersMaterialsMetrologyPrototypesMaintenance
- 04
Production capability
After physical proofLong-termAttempt repeatable physical output only after the information and operating layers have earned it.
- What must be proven
- Demand, design maturity, workforce, supplier capacity, quality authority, regulatory path, working capital, facility plan, and production evidence all support a bounded program decision.
- What capital enables
- FacilitySteel and materialSkilled laborMachinesInventorySupplier financingWorking capitalQuality systemsInsuranceCompliance
What a customer buys, level by level
One product over a widening boundary: what runs, what is configured per customer and what each level must earn. No public price.
deployment levels
What a customer buys, level by level
One product over a widening boundary: what runs, what is configured per customer and what each level must earn. No public price.
- 01
Work-area deployment
TargetScoped by work area and the systems it reads. Terms are set with the customer in writing before any record moves.Boundary. One work area: the work packages of one block, zone or module, and the release decisions made on them.
Buyer and users. The production or program leader accountable for releasing that work. The release authority for the area, the planners who prepare its packages, and a reviewer who checks answers against their sources.
VeldBuild runs. VeldBuild readiness and change impact over every package in the area: READY, NOT READY or CANNOT ESTABLISH with the binding constraint named, every revision traced to the work it reaches, every decision recorded against its evidence.
Reads. Read access to the records that govern the area: revisions in PLM, material in ERP, work in MES or planning, inspection in QMS. Nothing is written back.
Configured per customer. Connectors to those systems, the mapping of the customer’s identifiers into governed objects, the release gates its acceptance plans require, and its authority roles.
Stays with people. Release, engineering disposition and quality acceptance. VeldBuild computes and records; the named authority decides.
Carries forward. The connectors, identifier mapping, gate configuration and authority roles carry into the program deployment.
Earns the next level when: The answers survive the customer’s technical and operational review, and the release authority acts on them without authority moving off the people who hold it.
Measured by: Time from an engineering change to a defensible readiness answer against the baseline agreed before work begins, how often released work was later found blocked, and whether every source in an answer survived the reviewer.
- 02
Program deployment
TargetScoped by program: the systems it adds, how deep the integration goes, and the validation and support the program requires, by proposal.Boundary. Every work package in one program, from engineering release through inspection and acceptance.
Buyer and users. The program leader, or the yard’s production and engineering leadership for that program. Planners, release authorities, material control, quality and engineering change owners across the program.
VeldBuild runs. The program’s whole build graph: configuration authority over every revision, material applicability, inspection and acceptance evidence and production state, with VeldMind proposing over it where the program wants.
Reads. The same systems across the whole program, plus scheduling, supplier and document systems as the program needs them.
Configured per customer. Mapping for the rest of the program’s work, its acceptance plans and its change process.
Stays with people. Everything at the work-area level, plus configuration approval. VeldMind proposes and never holds authority.
Carries forward. The program’s governed model and gate configuration carry into the yard deployment, and are what the next program in the same yard starts from.
Earns the next level when: The workflow is used repeatedly, keeps a clear exit path, and reconciles cleanly with the systems of record that own each fact.
Measured by: Whether the team keeps using the workflow without Veldarium in the room, how cleanly it reconciles with the systems that own each fact, and whether the exit path still works.
- 03
Yard deployment
TargetScoped by yard and program count, and by the tenant and data-rights isolation the programs require, by proposal.Boundary. Several programs sharing one yard’s capacity, crews, cells and suppliers.
Buyer and users. Yard or enterprise production leadership. Capacity planning, production control and quality across programs.
VeldBuild runs. Cross-program build state: finite capacity across programs, whether each workcell may lawfully start for the supervisor who releases it, and physical evidence returned from inspection and measurement systems.
Reads. Every program’s systems, plus inspection and measurement systems. Interfaces to machines are a design position, not part of any offer.
Configured per customer. The yard’s capability, qualification and capacity model, built once and shared by its programs.
Stays with people. Everything above, plus capacity allocation and cell release. No software clears a machine’s safety inhibit.
Carries forward. The yard’s qualification and capacity model is what each further program in the yard starts from.
Earns the next level when: Repeated programs show lawful reuse, measurable coordination value, and strong tenant and data-rights isolation.
Measured by: Whether coordination value holds from one program to the next with tenant and data-rights isolation intact.
- The product, carried between customers
- The governed build-state model and its object classes · The readiness, change-impact, evidence and authority engines · The decision record · VeldMind’s bounded reasoning · A connector for each kind of source system
- Configured for each customer
- Read access and data rights for the customer’s systems · Mapping of its identifiers, work packages and revisions · Its release gates, acceptance plans and authority roles
- What exists today
- The engines run today on synthetic records and are tested in Veldarium’s code. The standalone application is in development, and no connector exists yet.
- Not a level
- Physical capability is not something a customer buys from VeldBuild. It is the company’s direction, behind the capital gates above.
What is true. What we are betting. What we intend.
Evidence, bets and intent, kept in separate columns.
fact · bet · intent
What is true. What we are betting. What we intend.
Evidence, bets and intent, kept in separate columns.
Fact
Verifiable today by someone who does not trust us.
A governed-answer system runs today on synthetic records. It establishes which revision controls, cites the records it used, and refuses to answer when the evidence does not support one.
How to check itOn VeldMind, a work package returns CANNOT ESTABLISH where a majority vote would proceed, because one question has no record.
Veldarium operates no shipyard, has delivered no vessel, holds no contract, integrates no machinery, and is one person today.
How to check itThe not-claimed register 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 labeled on the surfaces where they appear.
How to check itThe concept vessel carries a synthetic marker everywhere it is rendered, including inside the VeldBuild build-graph workspace.
4 of 11 capability stages are implemented in Veldarium’s code and demonstrated on this site, on synthetic records.
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. They compound as models change underneath them instead of depreciating.
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.
A meaningful share of avoidable delay and rework sits at the handoffs between engineering, material, production and inspection, and software can reach it before a facility can.
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 first deployment where the refusal behavior 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 as well as 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 assumptions this rests on, none of them established
Where durable advantage might come from, and the proof each still needs.
hypothesis · nothing achieved
The assumptions this rests on, none of them established
Where durable advantage might come from, and the proof each still needs.
What would break it
Each risk and why it is one, then the evidence that would reduce it.
- Domain complexityShipbuilding is hard and unforgiving of outsiders.
- CredibilityAn early company asserting it can change how ships get built.
- No customer or yard accessYards are slow to open, and for defensible reasons.
- IntegrationEngineering and production systems in yards are decades deep.
- Security and procurementA Navy program’s engineering, material and quality records are usually Controlled Unclassified Information, often export-controlled. Reading them needs the partner’s own controlled environment or a CMMC assessment Veldarium does not hold.
- Long sales cyclesIndustrial buying runs in quarters and years, through security, procurement and integration review.
- Services driftPer-customer configuration could become the business.
- Capital intensityPhysical capability is expensive and unforgiving.
- RecruitingThis needs welders, fitters and naval architects, not only software engineers.
- Automation difficultyVariable geometry and access can limit where robotics are useful.
- Expansion disciplinePremature vertical integration can exceed an early company’s evidence and capital base.
- Founder concentrationStrategy, product context and external relationships depend on one person.
- Regulatory and classification pathVessel and machinery approval cannot be improvised late.
- CybersecurityConnected vessel, yard and supplier state expands the attack surface.
- IncumbentsPLM, ERP, MES, CAD, data and defense platforms already own adjacent layers.
- Supplier constraintsA graph cannot manufacture scarce components or create qualified capacity.
- Physical manufacturing executionSoftware evidence may fail to survive contact with steel.
What evidence would reduce each risk
The hard questions
14 questions this company has to answer.
Where the answer is not known yet, it says so.
Why can’t Palantir build this? · Why can’t Siemens build this? · Why would a yard open its records to a company that means to build ships? · Why can’t an incumbent shipyard build it internally? · Why does this founder have any right to attempt this? · Why start with software? · Why not buy an existing MES? · What has actually been built? · What has never touched real steel? · Where does capital go first? · How does it avoid becoming a firm that sells hours? · What is proprietary, and what would be hard to copy? · What becomes more defensible when physical capability arrives? · What would make the entire thesis wrong?
The answers, plainly
- Why can’t Palantir build this?
- It already sells software into the yards: in December 2025 the Navy committed 448 million dollars to ShipOS, putting Palantir’s platform over shipbuilding data. Veldarium is aimed lower and further: from whether one work package may start, and who releases it, down to the yard itself, its cells and the automation that executes released work. Whether that survives beside a platform a yard already runs is untested.
- Why can’t Siemens build this?
- Siemens and other industrial software vendors sell systems that each govern part of the build: product definition, execution, resources. A yard runs several at once, and none of them owns the answer composed across them. They sell to shipbuilders; Veldarium intends to become one.
- Why would a yard open its records to a company that means to build ships?
- Because the records stay the yard’s: read-only, nothing written back, and confined by written terms to that yard’s own deployment, never used to build Veldarium’s own capacity. The physical rungs name yards and fabricators as partners, not targets. No yard has yet been asked to accept those terms.
- Why can’t an incumbent shipyard build it internally?
- It can, and that is a real risk. The bet is that a company designed around governed state, evidence and qualification from the start builds capacity differently from one retrofitting while it delivers a backlog. Unproven.
- Why does this founder have any right to attempt this?
- It should not rest on one person, and the plan does not: almost every seat a shipbuilder needs is open and named, the first gate is judged on a partner’s records by the partner’s own release authority, and each rung lists the people and partners it needs. What can be checked today is the work on this site; what would falsify the bet is published beside it.
- Why start with software?
- It is the cheapest layer to prove or disprove, every later layer depends on it, and it can be tested on one work area without a facility. The yard, its cells and their automation come only after it survives real records.
- Why not buy an existing MES?
- An MES runs execution. It does not decide whether a work package is admissible across engineering, material, qualification and inspection held in other systems, and a company that only ran execution would be too narrow to build ships.
- What has actually been built?
- Readiness, change-impact, evidence and authority engines, tested in Veldarium’s code on synthetic records, and this site. No connector, no customer records, no connected model.
- What has never touched real steel?
- All of it. No cell, no machine, no weld, no measurement, no vessel.
- Where does capital go first?
- Into rung 0’s gate: the 4 seats it needs in-house (industrial software, data and integration, configuration management and production control and planning), the first connectors, and one partner’s work area. Not into equipment.
- How does it avoid becoming a firm that sells hours?
- It sells one product over a widening boundary, and each deployment has to reuse the connectors and mapping of the last. If configuration effort per deployment rises instead of falling, the model is failing, and that is measured.
- What is proprietary, and what would be hard to copy?
- Today, a ship-specific model of authority, readiness and evidence, and the engines that compute it; a capable team could copy it. What would be hard to copy is earned later: integrations that keep each system’s meaning, process knowledge proven on real work, qualified cells and delivered vessels.
- What becomes more defensible when physical capability arrives?
- The loop. A company that holds governed state, runs the process and measures the result can tie each measurement to the decision that released the work, and improve the next one. Neither half exists yet.
- What would make the entire thesis wrong?
- If governed state does not change real release decisions on a real program, the entry fails. If it does, but the same discipline does not make a physical cell faster or more repeatable, the expansion fails.
The next proof
From synthetic demonstration to operating evidence on real records.
VeldBuild would run on one design partner’s work area, with source authority, named owners, failure criteria and review measures agreed in writing first. That evidence opens the next phase. No customer, design partner, pilot, contract or timing is implied.