---
title: "Investor Room | Veldarium"
canonical: https://www.veldarium.com/investors
html: https://www.veldarium.com/investors
description: "The expansion model, what capital would accelerate if earned in order, the risks, and the evidence that would reduce them. No raise is implied."
last_updated: 2026-10-12
representation: registry-derived Markdown
---

# Investor Room

> The expansion model, what capital would accelerate if earned in order, the risks, and the evidence that would reduce them. No raise is implied.

## The company and its two systems

Veldarium is an American industrial technology company building toward AI-native shipbuilding: governed build state first, then bounded reasoning over it, production cells that execute only released work, a yard, and in time vessels, each opened by evidence from the step before.

- **VeldBuild:** VeldBuild is governed execution and production control: the deterministic, authoritative build-state system that preserves source authority, computes governed state, establishes whether work may start, and records approved transitions. It remains useful with no AI present.
- **VeldMind:** VeldMind is orchestration and bounded reasoning operating over VeldBuild state. It works out what deserves attention, traces the consequence paths a change opens, identifies missing evidence, preserves disagreement, abstains where the records cannot settle a question, and returns a traceable recommendation to the named person who decides.
- **Human authority:** Consequential industrial authority is assigned to a named person or role with an explicit scope. That person holds the decision. The software informs it and never makes it.
- **Physical execution:** People, suppliers, equipment, automation, workcells and facilities execute approved work. Evidence from that work returns to governed state before later work relies on it.

Today that means software: governance engines tested in Veldarium’s code, and public demonstrations on synthetic records.

**Destination:** Build an American shipbuilder able to design, supply, build, inspect, integrate, and deliver difficult vessels reliably.

## The brief

**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: https://www.gao.gov/products/gao-26-109068). 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: https://www.navy.mil/DesktopModules/ArticleCS/Print.aspx?Article=4355823&ModuleId=4021&PortalId=1). 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

Value migration, not a business model: no margin, market size, price or customer is stated, because none is established.

- **Software:** Governed build state: the model, the engines and the decision record. Harder to copy because: A ship-specific model of authority, readiness and evidence is slow to build and has to survive real records.
- **Integration:** Connectors and identifier mapping into the systems a yard already runs. Harder to copy because: Mapping that preserves each system’s meaning, revisions and permissions is earned one deployment at a time.
- **Production engineering:** Process plans, qualification logic and execution planning. Harder to copy because: Process knowledge proven on real work is not in any software product.
- **Automation:** Cells, tooling, controls and machine integration driven from governed state. Harder to copy because: A qualified cell is hardware, procedure and people together; buying the machine does not copy it.
- **Manufacturing:** Production capacity, facilities and the trades to run them. Harder to copy because: Qualified physical capacity takes years and capital to stand up.
- **Vessel programs:** Design, production, delivery and support of vessels. Harder to copy because: A delivered vessel, and the evidence that the next one is built better, is the hardest thing in the stack to copy.

## 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, and no phase reads as further along than the capability ledger says.

### 1. Software foundation (Now; Target)

Prove 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:** Engineering; Compute; Cloud or on-premises infrastructure; Security; Insurance; Legal; Source-system connectors; Customer research

### 2. First deployments (After software evidence; Target)

Extend 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:** Travel; Implementation; Data cleanup; Security review; Support; Connector hardening; Evaluation; Training

### 3. Physical R&D (After program evidence; Long-term)

Test 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 space; Robots; Tooling; Safety systems; Production engineers; Materials; Metrology; Prototypes; Maintenance

### 4. Production capability (After physical proof; Long-term)

Attempt 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:** Facility; Steel and material; Skilled labor; Machines; Inventory; Supplier financing; Working capital; Quality systems; Insurance; Compliance


## The deployment levels

One product, VeldBuild, over a widening boundary. Each level reuses what the level before it configured, and is entered only when that level survives review. No level carries a public price, and none exists yet.

### Work-area deployment (Target)

- **Boundary:** One work area: the work packages of one block, zone or module, and the release decisions made on them.
- **Who commits:** The production or program leader accountable for releasing that work.
- **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 for the 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 named 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.
- **How it is scoped:** Scoped by work area and the systems it reads. Terms are set with the customer in writing before any record moves.
- **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.

### Program deployment (Target)

- **Boundary:** Every work package in one program, from engineering release through inspection and acceptance.
- **Who commits:** The program leader, or the yard’s production and engineering leadership for that 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 for the customer:** Mapping for the rest of the program’s work, its acceptance plans and its change process.
- **Stays with named 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.
- **How it is scoped:** Scoped by program: the systems it adds, how deep the integration goes, and the validation and support the program requires, by proposal.
- **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.

### Yard deployment (Target)

- **Boundary:** Several programs sharing one yard’s capacity, crews, cells and suppliers.
- **Who commits:** Yard or enterprise production leadership.
- **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 for the customer:** The yard’s capability, qualification and capacity model, built once and shared by its programs.
- **Stays with named 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.
- **How it is scoped:** Scoped by yard and program count, and by the tenant and data-rights isolation the programs require, by proposal.
- **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.

## Product and configuration

Carried from one customer to the next: 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.

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.

## First deployments

VeldBuild has not yet run on a customer’s records and no connector exists, so the first work-area deployments are design-partner deployments: the first connectors are built for them, the customer accepts that, and its requirements shape the product. Veldarium keeps the product; the customer keeps its records and every decision.

## The hard questions

**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.

## Not claimed

No active raise is implied by this page. 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.

- A shipyard, a drydock, or any manufacturing facility
- A site, lease, permit or facility design for the reference production base. The base on /industrial-base is a proposed reference architecture, not a plan for a specific place
- A vessel under construction, delivered, or under contract
- A weapon system, or any working gun, launcher, canister or torpedo tube, for the synthetic VS-001 concept. Armament is shown as nonfunctional exterior equipment in a concept, for visual communication. No weapon system is selected, integrated or approved, and no capability, quantity, firing arc or ammunition arrangement is implied
- A certified flight deck, a working or weathertight aft bay cover, a verified fit of any aircraft, vehicle or equipment in the aft bay, or any stealth, signature, speed, sea-state, endurance or payload performance, for the synthetic VS-001 concept. Topside areas are reserved volumes in a concept. No sensor, communications, aircraft or vehicle-handling system is selected, designed, integrated or approved
- 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, or any team beyond the founder, or a disclosed funding round. The company is one person today
- A grant, SBIR/STTR award, or other non-dilutive public funding
- Classified work, cleared facilities, or cleared personnel
- Shipbuilding customers, design partners under contract, or a backlog
- A connected model of any provider. No frontier, private, or local model is wired to any Veldarium system
- A trained model, a training dataset, or a learning loop over real outcomes. Nothing in Veldarium is trained, and every outcome it checks is synthetic
- A probability, confidence score or forecast from any statistical model. None runs, so nothing is calibrated
- A design-partner deployment, pilot, or production installation at any yard or supplier
- Production, operational, or sensor telemetry from any real facility. Every figure on this site is synthetic
- Real-world validation of any result; repository tests are evidence about Veldarium’s code, not about a shipyard
- Autonomous or unattended operation. No machine or model authorizes consequential physical work
- A built Drawing Check, or any software that reads, edits or approves an engineering drawing, or a measured error rate for one. Drawing Check is a concept described on this site
- A qualified supplier, a supplier contract or purchase order, or a real bill of material, material certificate or lot record. No procurement, ERP or inventory system is connected, and every supply record in this repository is synthetic

## 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)