--- title: "Shipbuilding Build-State Glossary | Veldarium" canonical: https://www.veldarium.com/terminology html: https://www.veldarium.com/terminology description: "The canonical Veldarium vocabulary (build state, three-valued readiness, evidence, authority, and bounded reasoning), each term linked to the page where the concept operates." last_updated: 2026-10-12 representation: registry-derived Markdown --- # Terminology > The canonical Veldarium vocabulary (build state, three-valued readiness, evidence, authority, and bounded reasoning), each term linked to the page where the concept operates. ## Canonical vocabulary Each term, defined once. The HTML page links each to the route where it does the work. ### The company and the two systems Veldarium is the company. VeldBuild holds governed state. VeldMind reasons over it. A named person authorizes. They are not one product with a feature list. - **Veldarium:** 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. Today that means software: governance engines tested in Veldarium’s code, and public demonstrations on synthetic records. - **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. - **Named 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. ### How a fact is established Industrial logic is three-valued. Unknown is its own state. It is never counted as ready and never collapsed into false. - **Build state:** The governed answer to what is true about engineering, material, work, quality, physical configuration, and authority at a point in time. - **Three-valued readiness:** A policy evaluation over required gates and governed evidence, answering READY, NOT_READY, or CANNOT_ESTABLISH. Ready means every required gate is established. Known-open is not ready. Unknown is never treated as a yes or a no. - **Impact-not-established:** A node related to a change by topology, but with no assessment evidence. It is never silently treated as unaffected. Change impact is known-affected, known-not-affected, or impact-not-established. - **Hold point:** A required stop in the work where specified evidence and authorization must exist before continuation. ### What the build is made of The objects are typed, identified, and revisioned. A pile of documents is not a build graph. - **Build Graph:** The typed network of vessel, engineering, supply, work, quality, authority, and evidence objects plus the declared relationships between them. - **Configuration:** The approved definition and applicability of an object, including baseline, revision, effectivity, deviations, and supersession. - **Effectivity:** The boundary that determines where and when an approved definition governs. The newest revision is not automatically effective for every hull, zone, or work package. - **Work package:** A bounded unit of physical work with identity, scope, governing configuration, dependencies, resources, gates, evidence, and a responsible owner. - **As-built:** The accepted record of what was actually installed or produced, including approved departures from design intent and the evidence establishing them. - **NCR:** A nonconformance report: a controlled record of a condition that does not meet a requirement and requires disposition by the responsible authority. ### Evidence and authority A record is not evidence until authority, applicability, and time hold. Integration does not transfer source authority to VeldBuild. - **Evidence:** A record admissible for a stated fact, scope, and time. Presence alone is insufficient; authority and applicability must also hold. - **Provenance:** The resolvable lineage from a governed assertion back to its source record, revision, observation time, authority, and ingest path. - **Authoritative source:** The system, record, or named authority permitted to establish a specific class of fact. Integration does not transfer that authority to VeldBuild. - **Source authority:** The rule that states which originating system or role controls a fact class when multiple systems contribute candidate assertions. - **System of record:** Always scoped, never absolute. A source system is the system of record for the facts it owns: PLM for released engineering configuration, ERP for material transactions, QMS for recorded acceptance. VeldBuild is the system of record for governed build state: which of those facts governs a named subject now, whether the evidence still establishes it, what a released change reaches, and the approved decisions recorded against it. It never becomes the system of record for a fact a source system owns. - **Admissibility:** Whether a record may bear on a claim at all, asked before its contents are examined. A source permitted only to contribute never decides, however many contributing records agree; a source not permitted at all never enters the answer, so it can never be outvoted into relevance. The evidence engines execute this on synthetic records: an operation-completion signal from an execution system does not close a quality hold point, because the floor reporting completion is not an inspection accepting the work. ### Bounded reasoning VeldMind proposes. It does not convert an unknown gate into a proceed, and it does not write approved state. - **Governed context:** The smallest permitted set of current build state, evidence, source authority, policy, effectivity, and uncertainty needed to answer one bounded question. - **Reasoner:** A bounded deterministic tool, graph query, solver, model, service, or human specialist selected to answer one sub-question. No model of any provider is connected in the public demonstration. - **Verifier:** A check that tests source existence, authority, applicability, consistency, computation, policy, scope, or completeness. - **Recommendation:** What VeldMind returns to a named person: a proposed action with its evidence, its trace and the condition that would falsify it. It authorizes nothing. - **Decision:** A named person’s recorded act on a recommendation: approve, hold, or return for evidence. Approve is open only when every consulted domain is clear. - **Acceptance:** The recorded judgement of the responsible quality authority that work meets its criteria. Recording a result is not accepting it, and a sensor reading is an input to acceptance, never an acceptance. - **Bounded execution:** An authorized action constrained by explicit scope, consequence, reversibility, policy, logging, and revocation rules. Architectural direction, not a deployed capability. ### How maturity is labeled Planned is not implemented. Implemented is not deployed. Synthetic is not a customer result. Repository tests are not production assurance. - **Synthetic demonstration:** Executable behavior over invented data. It shows how the implementation behaves, not how it performs on a real program. Every demonstration on this site is synthetic and says so where it runs. - **Maturity labels:** Working, Building, Synthetic, Concept, Exploratory, Target, Long-term, Not claimed, Source-backed, Human-authorized. Each says how far a claim has been earned, or, for Source-backed and Human-authorized, what kind of claim it is. Each is defined once, in the status key on Trust. - **Concept vessel:** The concept for a modular uncrewed surface vessel, used for public demonstration. Length overall is a 50 m (about 165 ft) concept dimension. Beam, draft, depth, displacement, class, and regulatory basis are not established. It is not a customer vessel, not classed, and not under contract. - **Demonstrated vs direction:** Demonstrated runs in the deterministic synthetic demonstration today. Direction is architectural intent that is not built. Provider-neutral model routing, bounded execution, and automatic write-back are direction. - **Repository evidence:** Code, tests, fixtures, or configuration that demonstrate an implementation property in Veldarium’s code. - **Production evidence:** Evidence from a deployed, monitored operating environment. Veldarium currently claims none for shipyard operation or live enterprise connectors. ### Enterprise source systems VeldBuild is a governed build-state control plane, not a replacement for the systems a yard already runs. Every connector status is target. None is built. - **PLM:** Product lifecycle management. Typically remains authoritative for engineering definition and revision. Veldarium has no production PLM connector. - **ERP:** Enterprise resource planning. Typically remains authoritative for commercial, inventory, and order facts. Veldarium has no production ERP connector. - **MES:** Manufacturing execution. Typically remains authoritative for shop-floor execution records. Veldarium has no production MES connector. - **QMS:** Quality management. Typically remains authoritative for inspection plans, nonconformances, and acceptance records. Veldarium has no production QMS connector. - **BOM:** Bill of material: the structured list of items a work package or assembly consumes. Material readiness is a fact about that list, not a date field. ### Physical construction The company destination is vessels. These terms name the physical work the software is being built toward. Veldarium performs none of it today. - **Block construction:** Building the ship as modules that can be outfitted while still open, then joined. Access and sequence are designed, not discovered at the work face. - **Outfitting:** Installing systems, equipment, and furnishings into structure. Pre-outfitting does this while a block is still open and accessible. - **Erection:** Joining blocks and units on the ways, dock, or land level into the hull. Crane, line occupancy, and dimensional control constrain the sequence. - **Commissioning:** Testing installed systems against the governing requirements until they can be accepted. Late commissioning often exposes unresolved upstream dependencies. ## 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)