--- title: "Shipbuilding Digital Thread Architecture | Veldarium" canonical: https://www.veldarium.com/systems html: https://www.veldarium.com/systems description: "The operating architecture of the production system: one requirement followed to accepted steel, where VeldBuild and VeldMind sit, which systems of record keep their authority, and where people decide." last_updated: 2026-10-12 representation: registry-derived Markdown --- # Systems > The operating architecture of the production system: one requirement followed to accepted steel, where VeldBuild and VeldMind sit, which systems of record keep their authority, and where people decide. A shipbuilder runs on one question: may this work start now? The answer sits in four systems (the drawing in PLM, the plate in ERP, the work in MES, the inspection in QMS) and is rebuilt by hand. Here one requirement is followed to accepted steel: who holds each fact, where software stops, and which person decides. ## The operating architecture > Who may do what, between a requirement and accepted steel? **Records settle every gate. A named person makes every consequential call.** Who holds what, then one requirement carried through nine stations to the accepted as-built, each marked where software stops and a named person takes over. - **VeldMind proposes. A person authorizes.** Its strongest output is a recommendation. Only a named person releases work. - **A failed test stops the loop where it fails.** A weld fails ultrasonic testing. The inspector rejects it, the as-built holds, and every package waiting on that joint says what it now waits for. No passing reading elsewhere averages the failure away. - **A hold costs capacity.** A hold ties up a bay, a crane booking and often a crew, and the delay travels down the schedule. ## Closed operating loop Source and execution systems → Integration, identity, source authority, and provenance → VeldBuild governed state → Governed context → VeldMind bounded reasoning → Named human authority → Authorized action → Physical execution → Evidence returned to VeldBuild ## The systems the yard already runs Every system of record keeps the authority it has. Each source stays authoritative for the fact classes assigned to it: - **PLM:** contributes Released product definition, revisions, configuration and effectivity. Authority remains: PLM remains authoritative for released engineering configuration. - **CAD / ship design:** contributes Engineering geometry, model and drawing context for a governed object. Authority remains: The engineering tool remains authoritative for geometry and model state. - **ERP:** contributes Procurement, purchase orders, inventory transactions and material receipts. Authority remains: ERP remains authoritative for commercial and material transactions. - **MES / MOM:** contributes Execution state, operation completion and shop-floor events. Authority remains: MES remains authoritative for what the floor reports as executed. - **QMS:** contributes Inspection results, nonconformances, dispositions and acceptance evidence. Authority remains: QMS remains authoritative for recorded acceptance and quality evidence. - **Scheduling / project controls:** contributes Baseline schedules, activities, resource windows and planned dependencies. Authority remains: Project controls remains authoritative for the schedule of record. - **CRM:** contributes Program, customer and commercial context: accounts, programs and milestones intended for CRM users. Authority remains: CRM remains authoritative for CRM data only. It does not establish engineering release, material acceptance, or inspection acceptance unless a customer explicitly configures it to. - **Documents / collaboration:** contributes Controlled documents, work instructions and their approval state. Authority remains: The document system remains authoritative for the controlled document itself. - **EAM / CMMS:** contributes Asset and equipment state, maintenance history and work orders. Authority remains: EAM remains authoritative for asset and maintenance state. - **Identity / SSO:** contributes User identity, roles and group membership for access decisions. Authority remains: The identity provider remains authoritative for who a user is. - **Supplier / logistics:** contributes Supplier milestones, advance ship notices, quality evidence and delivery events. Authority remains: The supplier system remains authoritative for what the supplier reports. No live production connector is claimed. ## Which way facts move - **Into VeldBuild:** Read into VeldBuild with the system that issued it, its revision and when it was captured. No connector exists today; every record on this site is synthetic. - **Back to a source:** Nothing is written back into a source system. A named person’s decision is recorded in VeldBuild with the evidence it rested on, and the source fact stays exactly as its owner holds it. - **Automated:** Automatic write-back into a persistent VeldBuild store is architecture direction, not built. Writing into a source system is not on that path. ## What computes what - **Records (synthetic):** What a source system asserts: which revision, observed when, by whose authority. Read with its lineage, never computed or learned. Never rewrites a fact its source owns. - **Rules (synthetic):** Readiness, change impact, evidence sufficiency, applicability and authority. The same records give the same answer, and every answer cites its records. Never turns an unknown into a yes. - **Reasoning (synthetic):** VeldMind composes the rules’ answers into one proposal and names what would overturn it. A language model could draft here, with the rules checking every draft. None is connected. Never approves, releases, or writes governed state. - **Statistics (concept):** Only where records are genuinely uncertain: matching one part across PLM and ERP, classifying documents, flagging an odd measurement. Nothing statistical is shown until it is calibrated against later outcomes, yard by yard. Never sets a state. It may only suggest. - **Outcomes (synthetic):** Later records are checked against what each recommendation said it rested on. What it missed goes to configuration control as a question, and never enters governed state on its own. Never widens what the system may do. A better track record earns no authority. None of the five decides. Release, disposition and acceptance stay with named people, and nothing a layer computes changes who they are. ## Seven layers, one authority each, and what of each is built. Read across the path above, layer by layer: what each takes in and hands on, the authority it holds, and the authority it never holds. - **Runs today, on synthetic records:** Source authority rules (Synthetic); Work readiness and evidence (Synthetic); Change impact across the build (Synthetic); As-built recording (Synthetic); Deterministic reasoning (Synthetic); The decision record (Synthetic); Workcell authorization (Synthetic); Measurement evidence rules (Synthetic). - **In development:** Program-wide material and production state (Building); The standalone application (Building). - **Designed, not built:** A persistent store, written automatically (Concept); A language-model adapter (none is connected) (Concept). - **Not started:** Source-system connectors (Target); Part identity across systems (Target); The as-built record as an operator surface (Long-term); Reasoning over a yard’s live state (Target); A machine interface (Long-term); A physical cell Veldarium operates (Long-term); Inspection and measurement connectors (Target). - **Never Veldarium’s:** The machine-safety function (Not claimed). ### The yard’s own systems - **Job:** Own the facts. PLM holds which revision is released, ERP what was bought and received, MES what the floor reports done, QMS what inspection accepted, planning the schedule. - **Takes in:** The yard’s work, as each system already captures it. - **Hands on:** Records, read under access the yard grants. Nothing flows back into them. - **Holds:** Authority over every fact it owns. That never moves. - **Never holds:** The composed answer. None of them alone says whether a package may start. - **Exists:** The yard’s, not Veldarium’s ### Integration and provenance - **Job:** Read each record, tie it to the thing it describes, keep where it came from, and turn away what may not decide. - **Takes in:** Records from each system, read-only. - **Hands on:** Admitted facts, each with its source, revision and owner; and the records turned away, with the reason. - **Holds:** The rule for which system may establish which class of fact, configured per yard. - **Never holds:** Any fact. It never edits a record, and never picks the newer of two. - **Exists:** Source-system connectors (Target); Part identity across systems (Target); Source authority rules (Synthetic) ### VeldBuild: governed build state - **Job:** Hold the governed state of the build, and compute whether work may start, what a change reaches, and which evidence still applies. - **Takes in:** Admitted facts, decisions recorded by named people, and evidence returned from the work. - **Hands on:** Readiness (ready, not ready or cannot establish) with the gate that holds and its owner, what a change reaches, and the decision record. - **Holds:** The governed answer composed from the sources, and the record of who decided what on which evidence. - **Never holds:** Release. It computes ready; a named person releases. - **Exists:** Work readiness and evidence (Synthetic); Change impact across the build (Synthetic); Program-wide material and production state (Building); The standalone application (Building); A persistent store, written automatically (Concept); As-built recording (Synthetic); The as-built record as an operator surface (Long-term) ### VeldMind: bounded reasoning - **Job:** When something changes, find what deserves attention, assemble the evidence, say what cannot be established, and propose one bounded action with what would overturn it. - **Takes in:** The governed context VeldBuild assembles: the question, the admissible evidence and what is still unknown. - **Hands on:** A proposal, routed to the person who holds the decision. Never a release. - **Holds:** No authority at all. It may not grant itself any. - **Never holds:** Nine consequential acts, each named on VeldMind with the person who holds it. - **Exists:** Deterministic reasoning (Synthetic); Reasoning over a yard’s live state (Target); A language-model adapter (none is connected) (Concept) ### Named human authority - **Job:** Decide. Release, configuration approval, disposition and acceptance each belong to one role, and the person in it decides on the evidence VeldBuild shows. - **Takes in:** The verdict, the records behind it, and a proposal if one was made. - **Hands on:** A decision (authorize, hold, or return for evidence), recorded against the evidence it was made on. - **Holds:** Every consequential decision. - **Never holds:** A decision outside its scope. Release is not offered while any gate is open or unknown. - **Exists:** The decision record (Synthetic) ### Workcells and machine safety - **Job:** Do the work inside an authorization bound to one cell, one package, one revision and one window. It is revoked the moment calibration expires, a qualification lapses or the governing revision moves. - **Takes in:** A released package, and a cell authorization derived from current governed state. - **Hands on:** Measurements and completion events. - **Holds:** Motion belongs to a separate, certified safety system at the cell. It can stop a fully authorized cell, and no Veldarium software may clear it. - **Never holds:** Acceptance of its own work. - **Exists:** Workcell authorization (Synthetic); A machine interface (Long-term); A physical cell Veldarium operates (Long-term); The machine-safety function (Not claimed) ### Evidence and acceptance - **Job:** Bring what the work returns back into governed state: admit a measurement only when it is applicable, current and independent, and let a named inspector accept or reject. - **Takes in:** Measurements with their uncertainty, and inspection results from QMS. - **Hands on:** Accepted as-built state, and recomputed readiness for the work that waits on it. - **Holds:** Inspection authority: accept, reject, or open a nonconformance. - **Never holds:** A sensor never accepts, and two conflicting readings are never averaged into a pass. - **Exists:** Measurement evidence rules (Synthetic); Inspection and measurement connectors (Target) ### Why the layers are built in this order Each layer is built only once the layer it acts on can be trusted, and each step is the cheapest place to find out the plan is wrong. - **Rung 0, Governed build state (Synthetic).** Governed state first, because it is useful alone and cheapest to disprove. A readiness answer is useful with no reasoning and no machine. Read-only, it can run beside current practice on one work area, checked by the people who rebuild the answer by hand today, without touching anything the yard depends on. - **Rung 1, Operational reasoning (Target).** Reasoning second, because it can only be checked over governed state. A proposal must cite records the system can resolve, and an unknown gate must still block it. Without governed state underneath, a model’s output can be fluent and unverifiable at once. - **Rung 2, Program-wide governed state (Target).** A whole program third, because one work area proves the method, not the volume. Real authority boundaries, real change traffic and real exceptions appear only across a program. That is where the configuration effort per deployment is measured. - **Rung 3, Bounded physical cell (Long-term).** Cells after that, because an authorization is only as good as the state it is derived from. A cell may run only while its governing revision, accepted material and valid calibration hold. Connecting a machine before that state can be trusted automates the error at the speed of the machine. ## Next: VeldBuild Established here: how authority moves from a requirement to accepted steel. Everything above rests on one claim: build state can be computed from records, and it says when the records do not settle it. VeldBuild tests that claim on one work package. [VeldBuild](https://www.veldarium.com/veldbuild) ## 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)