Companion read to the Berkshire-AI-exclusion piece earlier this week. Builds on a recurring conversation around Zachary Dive’s argument that “general methods that scale beat anything custom” in AI-driven CAD work.
Executive summary
The “Bitter Lesson” of AI — general models beat custom abstractions — is right at the design-altitude (CAD exploration, throwaway iteration) and wrong at the deploy-altitude (plant-floor systems, regulated workflows, irreversible mistakes). Deploy-altitude AI needs the engineering tradition the AI conversation keeps skipping: verification and validation (V&V), the discipline that has governed aerospace, medical devices, spaceflight, financial-services modeling, defense, and nuclear power for sixty years. The architectural pattern that lets V&V work for AI is model-based systems engineering (MBSE). The four-pillar framing Pieter van Schalkwyk codified in the Digital Twin Consortium’s Industrial AI Agent Manifesto (bounded actuation, decision traces, operational memory, runtime separation) maps onto MBSE patterns that have existed for thirty years. The engineering homework of the next eighteen months is V&V completion plus MBSE architecture in deployed AI systems. Companies that complete the move will set the templates the rest of the market follows.
The operational implication: the design-altitude (where general models win) and the deploy-altitude (where V&V plus MBSE win) are two different engineering disciplines. Companies running AI in regulated industries need both, and the second one is harder.
Zachary Dive made an argument earlier this week that the AI engineering community needed to hear: in his work at Adam, the AI-CAD startup, the team initially built thousands of lines of custom abstractions plus a domain-specific language to help the model understand 3D geometry. Most of it got thrown out. What remained was a simple loop: the model writes CAD as code, the model looks at the part via screenshot feedback, the model decides what to do next. Zachary’s framing of this finding was Rich Sutton’s “Bitter Lesson” — general methods that scale beat anything custom, every time, and the next model release does the custom-abstraction work by accident.
The argument holds. It is exactly correct at the altitude Zachary is operating at — CAD exploration, low-stakes iteration, throwaway runs. General model + code generation + screenshot feedback wins there because verification is cheap and reversal is free. If a design exploration produces a bad part, you delete it. The model gets faster, the abstractions get thinner, the workflow accelerates.
It reverses at the deploy-altitude. Plant-floor systems, regulated workflows, anything where the mistake is irreversible — the bitter lesson does not apply, because verification is expensive, reversal is not free, and the customer pays for the failure. The same model that wins design-altitude work loses deploy-altitude work, not because the model got worse, but because the engineering discipline around it changed.
That deploy-altitude engineering discipline has a name. It is verification and validation — V&V — and the engineering community has been refining it for sixty years.
The V&V tradition the AI conversation keeps skipping
Most of the AI-governance conversation happens at the level of principles (the OECD AI Principles, the NIST AI RMF, the EU AI Act risk tiers, ISO/IEC 42001) or at the level of catastrophic-scenario worry (election manipulation, deepfake harms, frontier-model risk). The engineering rung in between is missing — the audit-grade discipline that turns principles into specific evidence requirements for specific systems in specific contexts.
The engineering disciplines that operate at the deploy-altitude already have this rung. They have had it for a long time, in named and citable form:
Aviation runs on DO-178C: five Design Assurance Levels (DAL-A through DAL-E), V&V activity scaled to consequence-of-failure, every line of code in a commercial-airliner flight computer traceable to a verified requirement. Medical devices run on FDA AI/ML SaMD: intended-use boundaries, performance validation against clinical reference standards, drift monitoring, predetermined change-control plans for retraining. Spaceflight runs on NASA-STD-7009B: eight credibility factors scored on a 0-4 scale, required minimums depending on decision consequence. A model that has not been credibility-assessed cannot drive a spaceflight decision above its assessed level (fn. 1). Financial-services modeling runs on SR 11-7 (revised as SR 2602, 2026): documented intended use, model development records, independent validation, ongoing monitoring, defined model-lifecycle policy. The bank examiner can request the records and the model owner cannot decline. Defense modeling and simulation runs on MIL-STD-3022: the DoD analog of NASA-STD-7009B with explicit accreditation gates between V&V completion and decision-use. Nuclear power runs on NRC 10 CFR Part 50 Appendix B: eighteen Quality Assurance criteria covering design control, document control, inspection, test control, corrective action. Every safety-significant decision in a nuclear plant traces back to this regime. Cross-industry baseline: IEEE 1012 — four integrity levels, V&V activity scaled to integrity level, life-cycle-phase tasks specified. Adopted into NRC, DoD, and FAA secondary regulation by reference.
The pattern across all of them: requirements explicit, verification against requirements, validation against intended use, audit trail traversable, integrity scaled to consequence, post-deployment monitoring, defined change-control (fn. 2). The vocabulary differs across audiences — the underwriter, the regulator, the patent examiner, the auditor, the IRB, the litigator, the board director, the investor, the customer — but the discipline is the same.
None of these regimes was designed for AI. All of them have been partially adapted — FDA AI/ML SaMD borrows directly from the medical-device SaMD framework; SR 11-7 has been applied to machine-learning credit-decisioning models since 2018. But there is no single unified AI V&V regime yet. Completing that move is the engineering homework of the next eighteen months.
Why MBSE is the architecture the V&V completion needs
Verification and validation regimes do not run on prose documents and slide decks. They run on architectural models that connect requirements to behaviors to evidence artifacts at sufficient resolution to support audit. The discipline that produces that architecture is model-based systems engineering — MBSE.
MBSE is the practice of building, maintaining, and using a single integrated model of a system across requirements, architecture, behavior, parameters, and verification artifacts — rather than coordinating across loose documents and code repositories. The INCOSE Systems Engineering Handbook is the practitioner reference. The OMG SysML v2 specification (released 2024) is the current modeling-language standard. The IEC 62832 Digital Factory framework specifies how MBSE-style models flow into operating production systems. ANSI/ISA-95 / IEC 62264 specifies the enterprise-control integration layer those models eventually have to integrate with.
In an MBSE-disciplined system, every requirement is traceable to a stakeholder need, an architectural element that implements it, and a verification artifact that demonstrates it. Every architectural element has a defined interface, a defined behavior, and a defined configuration envelope. Every operating decision is auditable back to the model element that authorized it (fn. 3).
This is the engineering equivalent of double-entry bookkeeping. It does not eliminate failures. It makes failures traceable, attributable, and learnable — which is what insurance carriers, regulators, litigators, and auditors actually want to see.
MBSE discipline is not isolated to the aerospace/defense/medical-device legacy where it grew up. When coupled with modern software methodologies — Test-Driven Development (TDD), Behavior-Driven Development (BDD), and Domain-Driven Design (DDD) — inside continuous integration and continuous deployment (CI/CD) pipelines, MBSE produces validated end-to-end requirements management through outputs and workflows that work for complex software systems including AI-augmented ones. The discipline lives inside the CI/CD pipeline, not as separate compliance overhead. The evidence is produced as a side effect of the work, not assembled after the fact. I will treat this coupling in detail in a follow-up piece, but it is worth flagging here that the audience reading MBSE as “legacy hardware discipline” should be reading it as the connective tissue between AI-augmented software-delivery practice and the V&V regimes that govern high-stakes deployment.
Pieter’s four pillars, named in MBSE language
The Digital Twin Consortium Industrial AI Agent Manifesto (Feb 2026, lead author Pieter van Schalkwyk of XMPro) argues that industrial AI agents have to move from “bounded” (technically constrained) to “bonded” (insurable, auditable, defensible). The four pillars Pieter names — bounded actuation, decision traces, operational memory, and runtime separation of business logic from configuration — are recognizable to anyone who has worked in MBSE-disciplined organizations. They are MBSE patterns in different language.
Bounded actuation is the MBSE concept of operating envelopes with explicit interface specifications. An industrial agent that can actuate equipment has an operating envelope defined in the model — what setpoints it can request, under what plant conditions, with what fallback behavior when the conditions shift. Decision traces are MBSE requirements-to-behavior-to-evidence traceability. When the agent makes a decision, the trace records which requirement the decision satisfied, which model element authorized the decision space, and which evidence supports the choice. SysML v2’s allocation-and-satisfaction relationships are the language; IEEE 1012 V&V artifacts are the verification side. Operational memory is configuration management applied to runtime state. The state that affects future decisions sits in a managed configuration store with version control, like the engineering artifacts that defined the system. Industrial historians have done this for decades for plant data. The MBSE move is to extend it to agent decisions. Runtime separation of business logic from configuration is parameterized models with parameter sets externalized from the logic. When the business rule changes — a new product line, a different operating regime, a regulatory threshold update — the model logic does not change; the parameter set does.
The four pillars are not new architectural inventions. They are MBSE patterns named in language the industrial-AI conversation can hear. The DTC Manifesto, in that sense, is a translation layer between the MBSE discipline and the AI-agent vocabulary — the same kind of move FDA AI/ML SaMD makes for medical devices.
What the V&V completion looks like in practice
The engineering homework of the next eighteen months is not principle-setting. It is V&V completion plus MBSE-style architectural discipline applied to AI deployments at high-stakes scale. Specifically:
A unified AI integrity-level taxonomy. IEEE 1012’s four integrity levels and DO-178C’s five DALs scale V&V rigor to consequence. The AI equivalent would let a deploying organization classify a use-case once, then derive the V&V evidence requirements from the classification. Today every team invents its own rubric.
Validated change-control patterns for model updates. FDA’s predetermined-change-control-plan is the closest existing model. AI systems retrain continuously; the V&V regime needs to specify how a change to training data, prompts, or model weights interacts with the previously-validated deployment without forcing full re-validation. This is doable; FDA has already done the equivalent for medical-device firmware.
Cross-regime credibility scoring for AI. NASA-STD-7009B’s eight-factor scoring is the template. An AI system’s credibility for a specific decision-use should score against verification rigor, validation depth, input data pedigree, output uncertainty quantification, results robustness, use history, governance maturity, and personnel qualifications. The scoring rubric does not yet exist for AI as a unified standard, but the engineering community has the credentials to write it.
MBSE architecture in the deployed system. The four-pillar pattern Pieter names — bounded actuation, decision traces, operational memory, runtime separation — is the architectural foundation that lets V&V evidence be produced as a side effect of operation, not as a separate compliance artifact. Without MBSE-style discipline in the deployed system, the V&V evidence is reconstructed after the fact, which is the failure mode the Berkshire-AI-exclusion wave (fn. 4) is responding to.
Post-deployment monitoring harmonized across regulators. SR 11-7 requires ongoing monitoring of financial models. FDA requires post-market surveillance for medical devices. NRC requires in-service inspection for nuclear plants. The monitoring obligations for AI systems need to harmonize across regulators so a deploying organization is not running parallel surveillance regimes for each audience.
A standards-body home that brings the pieces together. IEEE P7000 series and ISO/IEC JTC 1/SC 42 are the natural candidates. The unified rubric, the change-control pattern, the credibility scoring, the MBSE-architecture guidance, and the post-deployment monitoring obligations all need a single standards-track home where the engineering community can converge on the composition.
Why this matters for industrial-platform operators
For executives running AI deployment in regulated industries — energy, manufacturing, healthcare, financial services, transportation — the design-altitude versus deploy-altitude distinction is not abstract. The same model that runs your design-exploration tool produces wildly different consequences when it runs your plant-floor agent. The bitter-lesson framing works in the first context and breaks in the second.
I cannot count how many executives have asked me over the past two years why Microsoft CoPilot can’t simply solve their manufacturing-data problems via an “agent.” The question is reasonable. They have watched CoPilot draft their emails, summarize their meetings, generate first-pass spreadsheet analyses, and produce passable PowerPoint decks. The productivity lift is real. The leap they make is the natural one: if CoPilot can handle white-collar workflow, why not the manufacturing-data workflow that operates on the same underlying numbers?
The answer is that CoPilot is operating at design-altitude almost everywhere those executives have seen it work. Drafting an email is design-altitude: the human reviews and edits before sending. Summarizing a meeting is design-altitude: the summary is consulted, not acted on. Generating a spreadsheet exploration is design-altitude: the analyst reviews the formulas and either accepts or replaces them. The cost of CoPilot being wrong in these workflows is small — a re-edit, a re-prompt, a flagged anomaly that gets caught before it ships. Verification is cheap. Reversal is free.
A manufacturing-data agent operating on plant-floor systems is at deploy-altitude. When the agent decides to adjust a setpoint on a process line, the decision affects irreversible physical operation. When it decides to flag a batch as out-of-spec, the decision triggers a regulatory hold that ripples through inventory and customer commitments. When it decides to skip a quality check based on pattern-recognition confidence, the decision is one the carrier and the regulator and the litigator will all eventually evaluate. The cost of being wrong is not a re-edit; it is a recall, a write-down, a settlement, or a regulatory action. Verification is expensive. Reversal is constrained by physics, contracts, and regulation.
The model can be identical — the same GPT or Claude or Gemini-class is technically capable in both contexts. What changes is the architectural discipline around the model. At design-altitude, the discipline is “let the model try; the human reviews.” At deploy-altitude, the discipline is bounded actuation, decision traces, operational memory, and runtime separation of business logic from configuration — Pieter’s four pillars — plus the V&V evidence stack the carrier, regulator, and auditor expect. The executive question conflates the two altitudes because the model looks the same. The discipline required is not. CoPilot will absolutely solve manufacturing-data problems eventually — but not before the manufacturing organization builds the deploy-altitude architecture around it.
The companies that complete the V&V move and adopt MBSE-style architecture in their deployed AI systems will be the companies whose 2027 commercial-policy renewals look materially different from the companies still producing slide-deck governance. They will be the companies whose regulator submissions, IRB compliance checks, and patent-prosecution defensibility records come out of the same operational record — not assembled separately for each audience.
Zachary’s argument is right at the design-altitude. The full picture requires the engineering discipline that turns the model into an industrially-deployable system. That discipline is V&V plus MBSE. The engineering community already knows it. The AI conversation has not quite caught up.
Footnotes
(fn. 1) NASA-STD-7009B’s eight credibility factors are: (1) Verification, (2) Validation, (3) Input Pedigree, (4) Results Uncertainty, (5) Results Robustness, (6) Use History, (7) M&S Management, and (8) People Qualifications. Each is scored on a 0-4 scale, and the standard specifies required minimums based on decision consequence-of-failure tier. A model used to drive a spaceflight life-safety decision must clear higher minimums than one used for mission planning support. The scoring is independent of the development team. Full standard: https://standards.nasa.gov/standard/NASA/NASA-STD-7009.
(fn. 2) All seven V&V regimes named above share a common operational pattern, even though their detailed clause structures and integrity-level taxonomies differ. The reason the pattern is common is that the underlying problem is common: how does a non-developer audience (carrier, regulator, examiner, auditor) verify that what a developer claims about the system is actually true in the deployed environment, without having direct visibility into either the development process or the operational data. The answer is the same shape every time: requirements explicit, verification against requirements, validation against intended use, audit trail traversable, integrity scaled to consequence, post-deployment monitoring, defined change-control. AI deployments add one wrinkle — the system itself changes through retraining — but the wrinkle is already addressed by the FDA AI/ML SaMD predetermined-change-control-plan mechanism. The engineering work is composition, not invention.
(fn. 3) The MBSE-discipline test in a deployed system is simple: pick any operational decision the system made yesterday and ask, “Which requirement was that decision satisfying, which model element authorized the decision space, and which configuration parameter was in play?” If the answer requires reconstructing chat transcripts, slide decks, or developer memory, the discipline is not there. If the answer is one query against the operational record, it is. Most current AI deployments fail this test today — not because the engineers do not know how, but because the discipline has not been demanded by the audiences that will eventually demand it.
(fn. 4) Reference to the Berkshire-AI-exclusion piece published earlier this week. The core argument: AI-induced loss is not yet well-enough understood for carriers to price, and exclusion is the rational response to that pricing gap. The companion argument here is that closing the pricing gap requires the engineering V&V completion plus MBSE architecture — otherwise the operational record carriers need does not exist.