--- title: "VeldBuild: Shipyard Production Control | Veldarium" canonical: https://www.veldarium.com/veldbuild html: https://www.veldarium.com/veldbuild description: "VeldBuild is governed execution and production control: the deterministic build-state layer. It remains useful with no AI present. Its demonstration is synthetic." last_updated: 2026-10-12 representation: registry-derived Markdown --- # VeldBuild > VeldBuild is governed execution and production control: the deterministic build-state layer. It remains useful with no AI present. Its demonstration is synthetic. ## Governing question > What is true about this physical build right now, why is it true, what depends on it, what changed, what can happen next, who has authority, and what evidence establishes the answer? 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. VeldBuild is the first software and systems layer Veldarium is developing: one connected, inspectable model of engineering authority, configuration, material, work readiness, production, inspection, quality, and as-built evidence. ## The build state, demonstrated (synthetic) **Every object in the build carries what governs it, what waits on it, and what proves it.** One synthetic case: an engineering change lands on one block of a concept hull, mid-kit, with one package still 2 spools short. Release the revision and the graph sorts the work into what survives, what must be re-released, and what nobody has assessed. The same rules read every package. - **A named person releases the work.** Release, disposition and acceptance stay with the people who own them. VeldBuild records each decision against its evidence and executes nothing. - **Unknown stays unknown.** A gate known open returns not ready. A gate whose record is missing, or was captured on a basis that has since moved, returns cannot establish. Neither is rounded up to a pass. - **A wrong verdict is rework in steel.** Fit to a superseded revision and the work comes back out: joints cut, parts re-fitted, welds re-made, the test run again. The verdict exists to stop that before the first tack. ## Authoritative build state ### Engineering state The definition allowed to govern the work. - Requirement - Configuration - Revision - Release - Change - Effectivity - Interface definition ### Supply state What was required, sourced, received, inspected, accepted, substituted, certified and staged. - Requirement - Source - Purchase - Receipt - Inspection - Acceptance - Shortage - Substitution - Certification - Staging ### Production state The lifecycle of the bounded work, without averaging unknowns into progress. - Planned - Ready - Released - Underway - Waiting - Blocked - Completed - Inspected - Accepted ### Quality state The conditions and evidence between performed work and accepted work. - Required inspection - Hold point - Nonconformance - Disposition - Repair / rework - Acceptance - Evidence ### Physical state What actually exists, where it is, and how it differs from intent. - Location - Installed configuration - Interface completion - Access - Sequence - As-built condition ### Authority state The source and person allowed to make a consequential state transition. - Governing source - Named role - Decision scope - Approval - Exception - Waiver - Expiration / effectivity ## Build Graph - **Product definition:** Program, Vessel, Variant, System, Subsystem, Zone, Compartment, Block, Module, Assembly, Part, Asset. What is the vessel, and how is it decomposed? - **Engineering authority:** Requirement, Specification, Drawing, Model, Revision, Configuration baseline, Change order, Release. What defines the object, and which definition controls? - **Supply and material:** Material, Supplier, Purchase order, Material lot. What was sourced, received, certified, and made applicable? - **Work and resources:** Work package, Operation, Trade, Resource, Machine, Tool. What must happen, in what sequence, with which bounded resources? - **Quality and acceptance:** Inspection, Test, Nonconformance, Deviation, Waiver, Hold, Acceptance. What proves the work, what exception remains, and who accepted it? - **Physical and as-built state:** As-built record. What physically exists, where is it, and what record survives delivery? Typed relationships connect them: requires, satisfies, supersedes, installed in, located in, depends on, blocked by, released by, inspected by, accepted by, sourced from, affected by, governed by, derived from, configured as, connected to. Concept architecture with a synthetic VS-001 implementation subset. This repository does not contain a production graph database, yard integration, machine interface, or customer build record. ## Three-valued industrial logic - **Established:** Admissible evidence supports the condition within the governing scope and effectivity. This is not the same as AUTHORIZED. A fact being established is an input to an authorization decision a human still makes. - **Known open / not established:** Evidence supports that the required condition is currently unsatisfied. This is not "unknown". The system knows the fact is wrong and says which one, instead of hiding it behind a single red light. - **Cannot establish / unknown:** Required evidence is absent, ambiguous, contradictory, stale, or outside the permitted scope. This is not FAIL and never silently becomes PASS. An unknown is carried as an unknown; only its named owner can resolve it. ## Configuration and effectivity The newest revision is not automatically the governing revision. The system distinguishes: - Created - Reviewed - Approved - Released - Superseded - Effective for a program, hull, zone, object, or time window - Field exception or approved deviation - As-designed - As-planned - As-built ## Quality, acceptance, and as-built continuity Required inspection identified → Work performed → Evidence collected → Hold points resolved → Nonconformance disposition resolved → Acceptance criteria evaluated → Responsible authority accepts → Accepted configuration enters as-built state Requirement → Design → Revision → Material → Work → Inspection → Acceptance → Installed configuration → Test → Delivery → Sustainment ## What a change asks of each object One released change, CFG-029, traced on the synthetic build graph. Per object: what it now needs, which records need re-baselining, and who reconsiders it. Unassessed objects are queued for the change authority by what a late answer would cost (installed work, then open work, then material), never by guessed likelihood. - **MAT-441 (Seawater spool set kit):** Re-specify and clear again. Needs re-baselining: EV-KIT-441 (basis-changed). Who reconsiders it: Configuration authority. - **WP-019 (Seawater cooling spool set):** Re-plan against the new revision. Needs re-baselining: EV-CFG-029C (superseded), EV-INS-124 (basis-changed). Who reconsiders it: Production release authority · B30. - **WP-014 (Machinery foundation structure):** Nothing. Assessed and not affected. - **WP-030 (Adjacent zone electrical routing):** Assess the impact. Who reconsiders it: Configuration authority. - **WP-021 (Cooling equipment installation):** Recompute readiness. Who reconsiders it: No release authority on record. ## Evaluation doctrine - Readiness verdict correctness - Unknown preservation - Change-impact precision and recall - Authority-resolution correctness - Configuration and effectivity correctness - Provenance completeness - Source-conflict detection - Deterministic reproducibility **Boundary:** VeldBuild is in development. Every demonstration on this site runs on VS-001, a synthetic concept vessel, with hand-authored data. There is no shipyard deployment, no customer, no live production integration, and no relationship to any government program. ## One work package, changing state (synthetic) - **CFG-029 is open and 2 of 9 spools are held for Rev D:** Not ready, configuration binds. Reaches the floor: no. - **Rev D is released and WP-019 re-released at it; the 2 spools are still held:** Not ready, material binds. Reaches the floor: no. What changed: Configuration, from open to established, owned by engineering / configuration control. - **Rev D is released, WP-019 re-released at it, and every item is accepted:** Ready. Reaches the floor: no. What changed: Material, from open to established, owned by receiving / material control. VeldMind proposes: Hold: capability qualification blocks the start. Gate sources: Configuration (CFG-029 · change in flight); Material (KIT-B30-019 · material receipt); Predecessor (WP-022-ACC · predecessor acceptance); Access (AREA-MS-03 · area release); Quality (INS-124 · inspection plan); Resource (CREW-B30-019 · resource assignment). ## One revision, traced to the spool and the decision (synthetic) DWG-B30-019, Rev C to Rev D, line SW-COOL-019, equipment HX-118. Equipment data revision moves the HX-118 inlet nozzle 140 mm toward the run. The closure spool shortens by 140 mm and its neighbour re-angles, gaining 35 mm. - Changed: SP-019-08, 1180 mm to 1215 mm. - Changed: SP-019-09, 1060 mm to 920 mm. - Unchanged: SP-019-01, SP-019-02, SP-019-03, SP-019-04, SP-019-05, SP-019-06, SP-019-07. - Lots to review: LOT-019-08-C, LOT-019-09-C. Request: release OP-10. 1. Rev C governs. The package and its spools match it. Verdict: Ready. 9 of 9 spools usable. 2. Rev D is released in PLM. Nothing else has moved yet. Verdict: Not ready. 7 of 9 spools usable. Held by: WP-019 released at Rev C; Rev D governs. (Configuration control) Work instruction at Rev C; Rev D governs. (Production engineering) 7 of 9 spools usable; SP-019-08 (LOT-019-08-D, on order), SP-019-09 (LOT-019-09-D, in rework). (Materials and quality) 3. The package and its work instruction are re-released at Rev D. Verdict: Not ready. 7 of 9 spools usable. Held by: 7 of 9 spools usable; SP-019-08 (LOT-019-08-D, on order), SP-019-09 (LOT-019-09-D, in rework). (Materials and quality) 4. The remade SP-019-08 and the trimmed, re-tested SP-019-09 come to receiving. Verdict: Not ready. 7 of 9 spools usable. Held by: 7 of 9 spools usable; SP-019-08 (LOT-019-08-D, received, not inspected), SP-019-09 (LOT-019-09-D, received, not inspected). (Materials and quality) 5. Quality inspects and accepts both spools at Rev D. Verdict: Ready. 9 of 9 spools usable. VeldMind proposes: hold. Refused when it tried: approve the release; re-release the package at the governing revision. An approval given under Rev C is refused once Rev D governs: The evidence moved after this evaluation. Re-evaluate; an earlier approval does not carry over. ## How it would run on a yard’s records Everything above runs on synthetic records. Below is what changes on a yard’s records: computed where the engines already run, marked as design where they do not. ### What it reads, and what each record may decide - **PLM and released drawings.** Reads: Released drawing and model revisions, change orders with their status and effectivity, and the part and spool lists each revision carries. Becomes: Drawing, Revision, Change order, Configuration baseline, Part. May decide: Which revision governs an object. Bears on, never decides: Geometry and model state; The controlled document and its approval state. Feeds, in the demonstration: Configuration gate (CFG-029, change in flight). It never releases, edits or supersedes a revision. Configuration control closes a change in PLM, and VeldBuild reads that it was closed. - **ERP and material control.** Reads: Purchase order lines and the revision each was ordered against, goods receipts, heat and lot numbers with their certificates, stock location and kit allocation. Becomes: Purchase order, Material, Material lot, Supplier. May decide: What was ordered, shipped and received. Bears on, never decides: Whether received material was accepted; Program and customer context. Feeds, in the demonstration: Material gate (KIT-B30-019, material receipt). It never reads a receipt as acceptance. ERP knows the material arrived; whether it may be used is a quality judgment made elsewhere. - **MES and the floor.** Reads: Operation status as the floor reports it (started, complete, suspended) and the work package each operation belongs to. Becomes: Operation, Work package. May decide: What the floor reports as executed. Bears on, never decides: Whether an inspection accepted the work. Feeds, in the demonstration: Predecessor gate (WP-022-ACC, predecessor acceptance). It never reads “complete” as “accepted”. A finished operation is execution state; the predecessor gate also needs the inspection that accepts it. - **QMS and inspection.** Reads: Inspection and test plans with their hold points, inspection results, nonconformances and their dispositions, and receipt inspection of material. Becomes: Inspection, Test, Nonconformance, Hold, Acceptance. May decide: Whether received material was accepted; Whether an inspection accepted the work. Feeds, in the demonstration: Material gate (KIT-B30-019, material receipt); Predecessor gate (WP-022-ACC, predecessor acceptance); Quality gate (INS-124, inspection plan). It never accepts, rejects or dispositions anything. An inspector or the review board decides in QMS, and VeldBuild records the decision with the record it rested on. - **Planning and scheduling.** Reads: Area and zone release for the window, crew and trade assignments, and bookings of cells, cranes and stations. Becomes: Zone, Trade, Resource, Machine. May decide: The schedule of record. Feeds, in the demonstration: Access gate (AREA-MS-03, area release); Resource gate (CREW-B30-019, resource assignment). It never reschedules. Where two packages compete for one cell, the resource gate reads open and names who owns the window. Connector status: Target. None is built, and every record on this site is synthetic. ### How a record earns the right to decide 1. **Read, under access agreed in writing (Target).** One connector per system reads the records that govern the work area, with the credentials and on the schedule the yard grants. It holds read access only. Nothing is written back. 2. **Resolve each identifier to one object (Target).** The yard’s drawing, part, heat and package numbers map to governed objects through a table the yard’s own people review. An identifier that maps to no object, or to two, is never guessed: every answer that needs it reads cannot establish until the mapping is settled. 3. **Keep where it came from (Concept).** Every record keeps nine fields of provenance, so any answer traces back to the native record behind it. The demonstration’s records carry a subset: the record, its issuer, the object and revision it was captured against, and when. 4. **Admit it, or turn it away with a reason (Synthetic).** A record about another object, captured against a revision that no longer governs, not yet effective, or from a system not permitted to bear on the question never enters the answer. It is kept, with the reason it was turned away. 5. **Let only the owning system decide (Synthetic).** A system permitted only to contribute never decides, however many contributing records agree. Two permitted records that disagree resolve by configured precedence or not at all: the answer is cannot establish, and a person reconciles them. Recency never decides. The rule, run on five synthetic situations (record ids invented; answers computed): - ERP shows the kit received in full. Quality has recorded nothing yet. **Cannot establish.** 1 record bears on Kit B30-019, but none comes from a source permitted to establish this class. Contributing evidence never becomes a governing answer. - Quality records the receipt inspection of the same kit as accepted. **Established.** QMS establishes whether received material was accepted for Kit B30-019 (RI-0419, owned by Quality). - PLM has released the new revision. The document system still holds the old drawing. **Established.** PLM establishes which revision governs an object for DR-118 (PLM-REL-2207, owned by Configuration control). - Two receipt inspections of the kit, both in QMS, disagree. **Cannot establish.** Sources of equal authority disagree for Kit B30-019: accepted (RI-0419) vs rejected (RI-0420). A person resolves this; the system will not pick, average, or take the newest. - The only acceptance on file was recorded against the revision the change superseded. **Cannot establish.** No admissible record establishes this claim for Kit B30-019. Not admitted: RI-0419 was captured against Rev C, not Rev D. ### The six readiness gates, and why an unknown is never a pass Readiness is a three-valued conjunction, not a checklist score. One gate known open makes the package not ready, whatever the others say. With none open, one gate that cannot be established makes the answer cannot establish. Only when all six are established from current records is it ready. The gates, as the demonstration configures them: - **Configuration.** Which released revision governs WP-019, and is it the one the work is written against? Satisfied by: change in flight. Counts for: Valid until superseded. Owner when not established: Engineering / configuration control. In the demonstration now: Open. Change CFG-029 is open against Rev C; the route is held until Rev D is released. - **Material.** Is the correct material present, and accepted at receipt? Satisfied by: material receipt. Counts for: Valid until the object or configuration changes. Owner when not established: Receiving / material control. In the demonstration now: Open. Kit: 2 of 9 spools held, because Rev D re-specifies them; they clear when the reworked and remade ones are accepted at receipt. The material to do the work at the governing revision is not on hand. - **Predecessor.** Is the upstream work (WP-022) complete and accepted? Satisfied by: predecessor acceptance. Counts for: Valid until the object or configuration changes. Owner when not established: Production planning. In the demonstration now: Established. WP-022 complete and accepted; the upstream work WP-019 starts from is closed. - **Access.** Is the physical area (zone MS-03) released and reachable for this work? Satisfied by: area release. Counts for: Describes one moment. Owner when not established: Production planning. In the demonstration now: Established. Zone MS-03 in B30 is released for outfitting; no conflicting hot-work or staging hold is open on the area. - **Quality.** Are the quality requirements satisfiable, with no open nonconformance blocking the start? Satisfied by: inspection plan. Counts for: Valid until the object or configuration changes. Owner when not established: Quality. In the demonstration now: Established. INS-124 (pressure test) is planned as a hold point at completion; no open nonconformance stands against the start of work. - **Resource.** Is the required trade and qualified capacity actually free in the window? Satisfied by: resource assignment. Counts for: Describes one moment. Owner when not established: Production planning. In the demonstration now: Established. 2 pipefitters and 2 pipe welders assigned across 2 shifts, the trades the 9-joint scope requires. Outfit crew capacity (3) is free in the window. An unknown gate means a record that should exist cannot be found, or was taken on a basis that has since moved. Reading it as a pass sends a crew to cut, fit and weld against something nobody has checked, and the cost lands in steel: rework, re-inspection, a block that waits for its neighbor. Reading it as a fail sends the wrong person. A known-open gate needs its owner to close it; an unknown one needs someone to find or re-baseline a record, and nothing about the work may be wrong. So the three answers stay apart, and each offers the release authority different actions. - **Ready:** the release authority may Authorize release or Hold. Authorize release: Work is released against the evidence set as it stands at this moment. Hold: No gate is open; a hold records that the named person chose to wait, and the verdict is unchanged. - **Not ready:** the release authority may Hold. Hold: A gate is known open. Someone closes it; the verdict recomputes from the record, not from this decision. - **Cannot establish:** the release authority may Hold or Return for evidence. Hold: A gate cannot be established. Release is withheld until the record is located; the verdict recomputes from the record, not from this decision. Return for evidence: A gate cannot be established. Someone locates or re-baselines the missing record. Nothing about the work is asserted to be wrong. Across all 256 combinations of the eight program events on the readiness console, the engine answers ready in 1, not ready in 248 and cannot establish in 7. Ready is the narrow answer, as it should be: every gate has to hold at once. ### How a change travels through the build graph 1. **The build graph finds the candidates.** From the revised drawing, VeldBuild follows the build graph to the work, material and neighboring work the change could reach. That set is what might be affected, and nothing more. 2. **An assessment record decides each one.** A candidate is known affected or known not affected only when an impact assessment says so. One nobody has assessed, or one whose assessments disagree, is impact not established: never read as unaffected, never settled by picking one assessment, and queued for the change authority. 3. **Evidence on the old basis stops counting, and is kept.** Records captured against the superseded revision no longer establish their gates, so those gates read cannot establish, not open: the record may still be right, but it was taken on the old basis. Nothing is deleted, and a release given on the old basis is refused under the new one. 4. **Work downstream recomputes.** Packages that wait on affected work have their readiness recomputed, and each names the role that releases it. The change reaches the floor as named holds, not as a rumour. In the demonstration, CFG-029 reaches 5 objects: 2 known affected, 1 known not affected, 1 not yet assessed, and 1 downstream package that must recompute. 3 records stop establishing what they did. ### Who releases the work, and what VeldBuild records VeldBuild computes whether a package is ready. It never releases one. Release belongs to one named person for the work area, who decides against the evidence as it stands, and VeldBuild records the decision with that evidence attached. Authorize release is offered only on a ready verdict; a decision recorded on one basis does not survive a change to it. In the demonstration, release for the area is held by M. Okafor, Production release authority · B30. The record VeldBuild writes for a hold: - Decision: AUTH-WP-019-HELD - Action: Hold - Verdict when decided: Not ready - Decided by: M. Okafor, Production release authority · B30 - Rationale: Held: configuration and material known open. Release withheld until they close. - Evidence it rested on: CFG-029, KIT-B30-019, WP-022-ACC, AREA-MS-03, INS-124, CREW-B30-019 - Recommendation it answered: REC-WP-019-NOT-READY ### A first deployment, on one work area (Target) In a yard, the gates are configured, not coded: which gates apply to the area’s packages, which record satisfies each, how long that record counts, and who owns the gate when it is not established. The six gates above are the demonstration’s configuration; a deployment writes the yard’s own, with the people who hold those gates today. - **The boundary:** One work area: the work packages of one block, zone or module, and the release decisions made on them. - **Who uses it:** The release authority for the area, the planners who prepare its packages, and a reviewer who checks answers against their sources. - **What it 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. - **What is configured:** 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. - **What stays with people:** Release, engineering disposition and quality acceptance. VeldBuild computes and records; the named authority decides. - **What it produces:** A recorded readiness answer for every package in the area, measured against a baseline agreed before anything is connected. 1. **Name the work area.** The block, zone or module, the release decisions made on it, who holds them and what a wrong release costs. Stops if no release there is rebuilt by hand. 2. **Agree access.** Read access, data rights, handling, the baseline and the success and stop conditions, in writing. Stops if access cannot be made safe and testable. 3. **Run alongside.** VeldBuild reads the area’s records and answers beside current practice, so every answer is checked. Stops if answers do not survive review. 4. **Extend or stop.** Your release authority and reviewer decide whether it extends to the program. If it extends, the connectors and mapping carry forward. Built once, carried between yards: 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 yard: 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. ### What would prove it is worth keeping (Target) Nothing here has been measured, because VeldBuild has not run on a yard’s records. These are the outcomes a production director would watch on the first work area, each against a baseline agreed before any record is read. None carries a figure, and none is claimed. - **Less time rebuilding the current state by hand from several systems.** Measured by: Time from a question to an answer the reviewer accepts, against a baseline agreed before anything is connected. [Shown on the worked case](https://www.veldarium.com/case#seats). - **Earlier sight of what a change reaches, and of what nobody has assessed.** Measured by: Affected objects found before work started against those found after, on reviewed changes. [Shown on the worked case](https://www.veldarium.com/case#propagation). - **Fewer packages released while a condition is still open.** Measured by: How often released work was later found blocked, before and after. [Shown on the worked case](https://www.veldarium.com/case#floor). - **The binding constraint and its owner named, instead of a status color.** Measured by: Whether the named owner was the person who actually cleared the gate. [Shown on the worked case](https://www.veldarium.com/case#floor). - **Evidence that stays attached to the decision it supported.** Measured by: Whether every source cited in a decision survives an independent review. [Shown on the worked case](https://www.veldarium.com/case#decision). - **Clear ownership of each consequential decision, recorded where the next person can check it.** Measured by: Whether the release authority acts on the answers without authority moving off the people who hold it. [Shown on the worked case](https://www.veldarium.com/case#decision). The work area 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. ### How it fails, and why every failure ends in a hold Every failure below ends in a held package or a refused decision, never in a release. Software that is wrong in the open direction puts a crew on unchecked work; software that is wrong in the closed direction costs a planner an hour. VeldBuild is built to be wrong only in the second way. - **A record a gate needs cannot be found, or its link is broken.** The gate reads cannot establish, and so does the package. Authorize release is not offered; the release authority may hold or return it for evidence. Who acts: The gate’s owner, to find or relink the record. (Synthetic) - **Evidence was cleared against a revision that no longer governs.** The gate it supported drops to cannot establish, never to open, and the record stays on file as what was true then. Who acts: Whoever captured it, to re-baseline it against the governing revision. (Synthetic) - **Two records from systems permitted to decide disagree.** Cannot establish, with both records and their values shown. No vote, no average, and never the newer one. Who acts: The authority that owns the fact, to reconcile them in its own system. (Synthetic) - **A system that may only contribute says yes: ERP shows the material received.** The record is kept as context and decides nothing. Material acceptance still waits on quality. Who acts: Quality, through receipt inspection. (Synthetic) - **Someone tries to release a package that is not ready.** VeldBuild refuses the record outright. Approval is never offered on a package with an open or unknown gate. Who acts: No one can; the gate has to close first. (Synthetic) - **A release was given, and then the revision it rested on was superseded.** The earlier approval is refused under the new revision. It is not carried forward. Who acts: The release authority, deciding again on the new basis. (Synthetic) - **Two measurements of the same work disagree.** Conflicting evidence: the as-built record is held. Readings are never averaged into a pass, and a sensor never accepts its own work. Who acts: The named inspector. (Synthetic) - **A connector stops updating, or a source system is unreachable.** Answers that depend on its records stop being current, and read cannot establish rather than repeating the last good value. Who acts: The yard’s system owner and the integration owner. (Concept) - **A yard identifier maps to no governed object, or to two.** Nothing is guessed. Every answer that needs it reads cannot establish until the mapping owner settles it. Who acts: The mapping owner named for the deployment. (Target) - **VeldBuild itself is unavailable.** No answer is not a yes. The area releases work the way it does today, and every source system is untouched, because nothing was ever written into one. Who acts: The release authority, by current practice. (Concept) ### Revisions, evidence and events Evidence counts for as long as its kind allows: Valid until superseded; Valid until the object or configuration changes; Valid until a declared date; Describes one moment. A record that stops being current reads superseded, basis changed, validity window elapsed, and is kept as what was true then. State moves only on a recorded event: Created, Revised, Released, Superseded, Held, Installed, Inspected, Accepted, Nonconformance opened, Nonconformance closed, As-built reconciled. ## 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)