--- title: "VeldMind: Bounded Reasoning Over Build State | Veldarium" canonical: https://www.veldarium.com/veldmind html: https://www.veldarium.com/veldmind description: "VeldMind is orchestration and bounded reasoning over VeldBuild state. It returns a traceable proposal; a named human decides. Its public demonstration is deterministic and synthetic, with no model connected." last_updated: 2026-10-12 representation: registry-derived Markdown --- # VeldMind > VeldMind is orchestration and bounded reasoning over VeldBuild state. It returns a traceable proposal; a named human decides. Its public demonstration is deterministic and synthetic, with no model connected. ## Governing question > Given authorized build context, what should a responsible person consider next, what evidence supports that recommendation, what remains uncertain, and where must the system stop? 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. ## The decision loop, demonstrated (synthetic) > May the work go to release review, and who says so? **It names what holds the work, and hands the decision to a person.** Change a record and five deterministic engines recompute the proposal, its reasons, and the actions the release authority may lawfully take. - **It proposes; a person decides.** Its strongest output is “advance to release review”. It has no write path to approved state. - **Unknown stays unknown.** Where a record is missing and no gate is known open, the answer is cannot establish and the proposal is “hold pending evidence”, naming the question no record answers and who owns it. - **A false proceed is steel in the wrong place.** Get it wrong and a crew fits to a superseded route, lays the weld, and closes an inspection against the wrong criteria. The fix is cutting it back out. ## How it works, step by step (synthetic) Every step reads a record. Planted wrong rules show the cases can fail. How a question becomes a proposal, what the reasoning returns when evidence runs out, and how planted wrong rules test the cases, with what that does not yet cover. Every figure is computed on this commit. 1. **One bounded question.** The question names one governed object and one action no stronger than advance to release review, and it is asked of state VeldBuild has already computed, never of a document. On the worked package: May WP-030 (VS-001, block B30) proceed to release review? Never: Accept an open question, or one whose answer would be a release. 2. **Each part to the engine that owns it.** Each part of the question goes to the one deterministic engine that owns the answer, and each answer keeps that engine’s own vocabulary. Nothing is translated onto a shared scale, so nothing is softened on the way. On the worked package: 6 sub-questions go to the readiness gates, one per gate, and 1 more goes to the build graph, because a released change reaches the package. Never: Route a sub-question to a model. Today every route resolves to a deterministic evaluator. 3. **Findings, each citing its record.** Each engine returns one of three stances (clear, blocked, cannot establish) and cites the record it read. A finding with no record says so and cites nothing. On the worked package: 6 gate findings: 5 clear and 1 cannot establish. The clear findings cite KIT-B30-030, WP-014-ACC, AREA-MS-03, INS-207 and CREW-B30-030; the one that cannot establish cites nothing, because no record exists. The build graph adds a reason, never a verdict. Never: Return a fourth, softer stance, or a score. 4. **Precedence, not a vote.** Where findings disagree, both stay on the record and a stated rule settles it: a known-open gate holds the work, an unknown is never upgraded, and the build graph may add a reason to a hold but never decides one. On the worked package: 5 of 6 gate findings are clear, so a vote would return proceed. The rule “Unknown is never upgraded” returns cannot establish. The build graph adds a reason to hold, and no verdict. Never: Average, tally or weight the findings. 5. **The falsifier.** The recommendation names the observation that would overturn it, derived from the gate that holds the work: who could produce it, and whether it would overturn the answer on its own. On the worked package: A current record is produced for "Which released revision governs WP-030, and is it the one the work is written against?". If it establishes the gate this hold is withdrawn; if it shows the gate open this becomes a known-open hold. Producing the record is not itself a proceed. Owner: Engineering / configuration control. Overturns this on its own. Never: Offer a falsifier that would release work. If the missing record establishes the gate and nothing else is outstanding, the proposal becomes advance to release review, still not a release. 6. **The seam.** The reasoning ends at a proposal. Its strongest possible action is advance to release review, and VeldMind has no code path to approved state. On the worked package: Proposal: hold pending evidence, confidence cannot establish. VeldMind recommends and explains; it does not release work. A named human authority decides. Never: Emit a release, or any action above the ceiling. 7. **The decision, by a named person.** The person who holds the decision chooses from the actions the answer lawfully permits. Authorize release exists only when every consulted domain is clear, and the record binds the decision to the evidence as it stood. On the worked package: M. Okafor (Production release authority · B30) may hold or return for evidence. Authorize release is not offered, because a gate cannot be established. Never: Choose for the person, or offer approve beside an unknown. ## What it reads Only state VeldBuild has already computed from records. What a recommendation can rest on: governing configuration; gate evidence; finite qualified capacity; dependency topology. The domains the live instrument consults: governed readiness; finite qualified capacity; capability qualification; physical evidence; nonconformance. Never read directly: a drawing or model file; a spreadsheet, an email or a meeting note; a raw sensor or machine stream; a source system’s own database. Those reach VeldBuild first, where each fact keeps the source that owns it and becomes a record with a revision and a recording authority. VeldMind reads only what VeldBuild has made a governed record, so every finding can be traced to one. ## Why it cannot cite a record that does not exist - **A claim is a record, or it is not made.** Every finding cites the record its gate carries, and a gate with no record cites nothing, so the trace cannot point at a record the governed state does not hold. Among the wrong rules planted to test the cases (25 / 25 caught) is a fabricated citation, and the run fails unless a case catches it. With a model attached: Each identifier a model cites would be looked up in VeldBuild, and a draft carrying one that does not resolve would be discarded before a person sees it. That check on a model’s output is not built. - **Confidence is a state, not a number.** A recommendation is either established or cannot establish. There is no score to inflate, and cannot establish only ever accompanies a hold. With a model attached: A model’s own confidence would not be carried into the proposal. The epistemic state comes from the gates, which are computed from records. - **Unknown blocks, however fluent the explanation.** A missing record leaves its gate unknown, and no proceed is emitted while any verifier check cannot establish. With a model attached: A persuasive draft could not close a gate, because the gate is computed by the engine and the draft has no field for it. - **Every answer can be replayed.** The same governed state yields the same recommendation, its id included, so a later and different answer can be traced to changed records, changed rules, or both. With a model attached: A model does not replay this way, which is why it may only propose: the deterministic checks decide what reaches a person, and they do replay. ## Governed pipeline 01. **Event / question (demonstrated):** A change or a question enters against a specific unit of governed work. The demonstration intake is one work package (WP-019) with a configuration change (CFG-029) in review. 02. **Context assembly (demonstrated):** Read the established build state around the subject, and nothing else. Gates, governing evidence and the dependency graph are read from the readiness and Build Graph engines. Retrieval over larger corpora is direction. 03. **Authority resolution (demonstrated):** Establish who holds the decision before reasoning toward it. The release authority for the subject is resolved from the record and carried on every output. 04. **Decomposition & routing (demonstrated):** Break the question into sub-questions and route each to a bounded reasoner. Today every route resolves to a deterministic reasoner. Provider-neutral routing across probabilistic models and tools, under cost, latency and confidence budgets, is direction. 05. **Bounded reasoners (demonstrated):** Each reasoner answers its sub-question and cites its own source. Deterministic gate and graph-topology evaluators run today. Bounded probabilistic reasoners, tools and agents, each with explicit authority, are direction. 06. **Disagreement (demonstrated):** Surface where reasoners point in different directions, and keep it. Tension between a clear perspective and a blocked or unestablished one is resolved by precedence, never by majority. 07. **Verification (demonstrated):** Check that nothing asserts knowledge the evidence does not support. A verifier returns "cannot establish" for an unknown gate rather than resolving it into a pass. Adversarial cross-checking is direction. 08. **Uncertainty (demonstrated):** Classify what is known, what is open, and what cannot be established. Three-valued throughout: unknown is its own state, never collapsed into false. Calibrated probabilistic confidence is direction. 09. **Synthesis & recommendation (demonstrated):** Produce one recommendation: what, why, and on what evidence. The synthesis is the deterministic recommender; its ceiling is "advance to release review", never "release". 10. **Policy / authority gate (demonstrated):** The recommendation stops at policy and a named human. Release is only lawful when the verdict is READY, and it is a human action. VeldMind cannot authorize. 11. **Authorized execution (direction):** Once authorized, bounded action is carried out under explicit authority. Bounded tool/agent execution under an explicit authority lease is architectural direction. No autonomous execution exists. 12. **Evidence & state update (demonstrated):** The decision and its evidence are recorded as governed state. The human decision and event trail are recorded in the demonstration. Automatic write-back into a persistent VeldBuild store is direction. 13. **Outcome check (demonstrated):** What happened afterwards is checked against what the recommendation said it rested on. Runs over synthetic decisions today. A hold is never scored right or wrong, and an outcome the recommendation did not name becomes a proposed dependency for configuration control to review. Nothing is trained, and an outcome changes no authority. ## Reasoner classes - **Gate evaluator (synthetic):** Three-valued readiness over established / open / unknown gates. - **Graph-topology evaluator (synthetic):** Change reachability over the typed dependency graph. - **Rules engine (concept):** Policy and applicability rules over governed records. - **Retrieval / search (concept):** Evidence and document retrieval over a larger governed corpus. - **Provider-neutral model adapter (concept):** Bounded probabilistic reasoning behind one governed gateway, designed to route across a frontier, private or specialist model (e.g. OpenAI, Anthropic, Google, or a local model). No model of any provider is connected today. - **Optimization solver (concept):** Constrained optimization for planning and trade-space questions. - **Simulation service (concept):** Scenario simulation for downstream-consequence questions. Provider-neutral by design: deterministic reasoners run in the synthetic demonstration today, and probabilistic models attach through one governed gateway rather than being wired into the product. No model of any provider is connected. Provider neutrality is the architecture, not a live integration. ## Verification - **Source verification (demonstrated):** Does every citation resolve to a record the governed state actually carries? - **Authority verification (direction):** May that source establish this class of fact? The reasoner carries each record’s recording authority forward and resolves who may decide, but does not qualify a source against the claim it is cited for. - **Applicability verification (demonstrated):** Does a released change reach this subject, so records taken before it stop governing? - **Consistency verification (demonstrated):** Do the bounded reasoners conflict, and is the conflict settled by a named rule rather than a tally? - **Computation verification (demonstrated):** Is the result reproducible: the same governed state yielding the same trace, every time? - **Policy verification (demonstrated):** Is the proposed action inside what the verdict permits? The ceiling is advance to release review, never release. - **Scope verification (demonstrated):** Has the reasoning exceeded its permitted boundary, such as a proceed resting on a gate no record closes? - **Completeness verification (demonstrated):** Is a record that would establish a gate missing, and is that stated rather than passed over? - **Independent verification (direction):** Where useful, can another bounded reasoner test the conclusion? Every sub-question today is routed to exactly one reasoner, so no conclusion is re-tested. ## Uncertainty - **Missing evidence (demonstrated):** A required record is absent, so the gate it would close cannot be established either way. Returns: Hold pending evidence. The gate stays unknown, and the proposal names the question no record answers and who owns it. Settled by: A current record from the gate’s owner. If it establishes the gate the hold is withdrawn; if it shows the gate open, the hold becomes a known-open one. - **Conflicting evidence (direction):** Two admitted records assert incompatible states. The reasoner reads one record per gate and never compares two, so it cannot reach this. Returns: Not reached today, because one record is read per gate. Settled by: Comparability first (same quantity, basis and measurement class), then the configured source precedence. Where precedence cannot decide, cannot establish, with both records kept. - **Ambiguous applicability (demonstrated):** A released change reaches this subject, so a record captured before it no longer governs it. Returns: Cannot establish for the subject a released change reaches. Records captured before the change stop governing it. Settled by: An impact assessment for that subject from configuration control, or records captured again against the new revision. - **Model uncertainty (direction):** A probabilistic reasoner cannot establish the conclusion. No such reasoner runs here, so this state is unreachable. Returns: Unreachable, because no probabilistic reasoner runs. Settled by: A deterministic check on what a model drafted. Never a confidence threshold. - **Stale evidence (demonstrated):** The record was captured against a basis that has since moved, so it no longer establishes what it once did. Returns: Cannot establish, never known open: the record existed and the basis it was captured against has moved. Settled by: The record re-baselined or captured again against the current basis. - **Source reliability (direction):** The source or acquisition path is not sufficient for the fact. The reasoner does not assess how a record was obtained. Returns: Not assessed today. Settled by: A declared acquisition path for each evidence class, checked before a record is admitted. - **Unresolved dependency (demonstrated):** A related downstream object has no completed impact assessment, so its state is not established either way. Returns: Impact cannot be established for the neighbor nobody assessed. It is never read as unaffected. Settled by: A completed impact assessment for that object. - **Insufficient authority (direction):** The actor or source lacks the necessary scope. The reasoner resolves who holds a decision but does not test an actor’s scope against a request. Returns: Not assessed today. The reasoning names who holds a decision but does not test an actor’s scope. Settled by: A check of the actor’s scope against the requested action before a decision is accepted. - **Computational uncertainty (direction):** The computation cannot be reproduced within its declared tolerance. The engines here declare no tolerance, being exactly reproducible rather than approximately so. Returns: Not applicable: the engines reproduce their output exactly. Settled by: A declared tolerance, if an approximate computation is ever admitted. ## Authority ladder - **L0 · Observe (synthetic):** Read bounded state without changing it. Earned so far: The reasoning reads computed state and writes none; the composition is tested to invoke no model and write no state. Would need: The same reads over a yard’s own records, through VeldBuild, with each source’s authority configured by the yard. Sent back down by: Any write to state from the reasoning path. - **L1 · Retrieve (synthetic):** Assemble permitted evidence with provenance. Earned so far: Every finding cites the record its gate carries, and a missing record is cited as missing. Would need: Retrieval over real records, each citation checked by the engineer who owns the fact. Sent back down by: A citation that resolves to a record VeldBuild does not hold, or to the wrong revision. - **L2 · Analyze (synthetic):** Compute, compare, classify and preserve disagreement. Earned so far: On synthetic records, 37 / 37 governed cases hold and 25 / 25 planted wrong rules are caught. Would need: The corpus written again against a yard’s records, with its engineers stating the expected answers before the engines run. Sent back down by: A planted wrong rule that no case catches. - **L3 · Recommend (synthetic):** Return a traceable proposal to the responsible person. Earned so far: Each proposal names its falsifier and stops at advance to release review. Would need: Proposals followed on real work: each falsifier checked against what happened, holds never scored, every override by a person recorded with its reason. Sent back down by: A proceed proposed while a gate is unknown. - **L4 · Prepare change (concept):** Draft a reversible state transition for review. Earned so far: Nothing. No change is drafted today. Would need: A recommend rung that has held up on real records, a reversible transition type defined by configuration control, and a review log showing every drafted change read and decided by a named person. Sent back down by: A drafted change that reaches the record without a person’s decision. - **L5 · Execute authorized reversible action (concept):** Act only inside an explicit, logged and revocable authority lease. Earned so far: Nothing. No action is executed. Would need: The durable execution contract built and tested, an authority lease a person can revoke, and a history of prepared changes accepted without being reversed. Sent back down by: An action taken outside its lease, or one that cannot be undone. - **L6 · Controlled industrial execution (long-term):** Coordinate approved physical action through governed systems. Earned so far: Nothing. Veldarium operates no machine and generates no machine instruction. Would need: Everything above, on a physical cell whose machine safety stays with the cell’s own authority. Sent back down by: Any software path that clears a machine inhibit. - **L7 · Reserved / prohibited authority (human-authorized):** Keep regulated, safety-critical or otherwise reserved decisions outside autonomous execution. Earned so far: Not a rung to earn. Would need: No evidence moves a reserved decision. Regulated, safety-critical and release decisions stay with people by design, not by maturity. Sent back down by: Any delegation of a reserved decision. ## Where a language model would sit A model, if one is ever connected, would sit where the deterministic reasoners sit now: it may read, draft and propose, and the engines check every draft before a person sees it. A better model gets no more authority. Selection would be provider-neutral, so no vendor becomes an authority in this loop. Today no model of any provider is connected, and every route resolves to a deterministic reasoner. Allowed (concept), each with its bound: - **Read governed records by identifier, through VeldBuild:** Read only, and scoped to the object and the question it was handed. Never a source system, a file share or the open web. - **Ask the deterministic engines:** The engines compute every gate and every verdict. The model may choose which question to put to them first. - **Decompose a question and draft an explanation:** Every sentence that asserts a state must cite a record identifier, or it is removed before review. - **Propose a hypothesis or a next check:** Labeled as a proposal. It changes no gate, no queue and no schedule. Refused (concept), each with what enforces it: - **Write governed state, directly or through a tool:** The gateway issues no write tool. VeldBuild records a transition only from a named person’s decision. - **Cite a record VeldBuild does not hold:** Every cited identifier is resolved against VeldBuild, and a draft with one that does not resolve is discarded. - **Set a gate or the confidence of an answer:** Both are computed by the engines from records. The draft has no field for either. - **Read outside the governed set:** Retrieval is scoped to the object, the question and the configured source authority. - **Widen its own scope, or call another service:** Scope is issued by the gateway for one question and expires with it. - **Gain authority by being more capable:** Routing may weigh calibrated confidence only inside the authority the question carries. A better model gets no more. Every decision VeldMind never takes stays with the person named at the top of this page, and a model would inherit that boundary unchanged. None of this is built: no model of any provider is connected, and the gateway and its checks are architecture. ## After the decision Each recommendation names its falsifiers, so it can be checked against what happened. Silence is not success: a release counts as having held up only once its window closes. A hold is never scored right or wrong, because nobody sees what held work would have done. An outcome the recommendation did not name becomes a proposed dependency for configuration control to review; nothing enters the build graph on its own, and accepting a proposal is a person’s act that is not built. Each decision records its ruleset and a digest of its input, so a replay explains a later, different answer as changed records, changed rules, or both. Nothing is trained. Synthetic decisions: - **AUTH-WP-019-HELD (Lifted, as it said it would):** Lifted once DR-118 and Kit B30-019 moved, which is what the hold said it was waiting on. - **AUTH-WP-019-APPROVED (Turned on something it did not name):** Flange gaskets were supplied to the Rev C pressure class, and Rev D raised it. The recommendation did not name GSK-118. Proposed for review: Does GSK-118 govern or feed WP-019? - **AUTH-WP-030-RETURNED (Not yet observed):** Still held. Whether the work would have failed if released cannot be observed. 1 of 2 outcomes that turned on something went the way the recommendation said they could. 1 pending. ## Evaluation on this commit - **Governed cases that hold:** 37 / 37. Each case is an industrial state, a bounded question and the answer a written rule requires, with the rule and its source named in the case. - **Invariant families covered:** 20. Distinct failure shapes: a stale evidence basis, a rejected measurement, the wrong measurement class, two reads off one instrument head, a record filed but not accepted. - **Wrong rules injected, and caught:** 25 / 25. Each is a plausible wrong rule written into the engine source (majority vote, unknown read as ready, a fabricated citation), and one that fails to apply fails the run. - **Cases that must preserve an unresolved condition:** 26. The required answer carries a condition the evidence cannot settle, and the case fails if the engine resolves it in either direction. - **Cases that must surface a disagreement:** 9. The reasoning must report that its sources conflict rather than return the answer it prefers; one case exists only to prove no tally is taken. - **Known limitations recorded on purpose:** 4. What the engines actually do where that is worse than the intent. Pinned so it cannot drift, and published so nobody has to discover it. - **What the case figure shows.** 37 / 37 means every case returns the answer its written rule requires, across 20 distinct failure shapes. A case states the industrial condition, the question and the rule before the engine runs. - **What the mutation figure covers.** 25 / 25 means each of the 25 wrong rules planted in six engine files is caught by at least one case, and the run fails on one that escapes rather than reporting a lower score. It covers only the rules planted: none is planted yet in the five-domain composition the live instrument runs, the decision engine, the workcell engine, the capacity model or the scheduler. - **Where over-confidence would show first.** 26 cases require the engines to leave a condition unresolved, and fail if the engine settles it in either direction; 9 require a conflict to be reported rather than smoothed over. - **What it does not show.** That these are the right rules for a particular yard. That needs the yard’s own engineers to write the expected answers against their own records, and it has not happened. - **What it does not evaluate.** A model. None is connected. The scored contract defines what one would be graded on, and no result exists. ## Evaluation doctrine - Task-decomposition quality - Routing accuracy - Evidence-citation correctness - Unsupported-claim rate - Disagreement preservation - Verifier catch rate - Refusal correctness - Recommendation usefulness - Latency and cost - Human override rate - Falsifier completeness (counted) **Boundary:** VeldMind reasons over governed state and may propose; a named human authorizes; VeldBuild records the approved state. Probabilistic output never becomes approved industrial state on its own. ## What VeldMind does, and never does - Does: Identifies which record under a job changed, and how - Does: Traces the change to every object it can reach - Does: Selects which of those objects need a question now - Does: Pulls the records bearing on each question from VeldBuild - Does: Checks which evidence still governs, and which rests on a moved basis - Does: Names the record that should exist and does not - Does: Separates what can be established from what cannot - Does: Drafts one bounded proposal, with the observation that would overturn it - Does: Abstains where the records cannot settle the question - Does: Routes the decision to the named authority who holds it - Never: Approve an engineering change. Held by: Engineering / configuration control. - Never: Override configuration authority. Held by: Engineering / configuration control. - Never: Waive a requirement. Held by: The requirement’s owner. - Never: Release production work. Held by: The production release authority. - Never: Accept an inspection. Held by: The quality inspector. - Never: Authorize procurement. Held by: Supply chain and its approver. - Never: Command a machine. Held by: The cell, under its own machine safety. - Never: Override a system of record. Held by: The system that owns the fact. - Never: Grant itself authority. Held by: No one may grant it. ## 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)