I’m building Symbolia to help manufacturers improve their machines. AI will make it easier to write the software that controls production. Symbolia will check those changes, show the engineer what the evidence supports, and keep that knowledge useful as the equipment evolves.

I’m targeting manufacturing and heavy industry within a roughly $30 trillion industrial economy. MM13 My ambition is $1 trillion of additional realised annual customer benefit through verified optimisations. At our 10% share, that is a $100 billion annual opportunity. Each factory gains a better process; together, those gains can change the economics of production.

Consider a factory that wants a robot arm to finish its routine faster. New instructions must respect the arm’s movement limits, the machines around it and the conditions that require it to stop. We will turn those requirements into checks, expose mistakes and identify where a conclusion still needs a measurement from the installation. The customer then can make the decision to deploy with mathematical assurance.

The first customers make products with robotic equipment. Faster commissioning, fewer late surprises and better production save them time and money.

Why this becomes a business now

AI is creating both the demand and the means to meet it. More machine-generated changes need checking. At the same time, AI can help translate requirements, construct mathematical proofs and maintain them as software changes.

I’ll begin with industrial expertise and a narrow service. Each engagement will teach us which work customers value and which parts we can carry into the next installation.

Each job leaves useful knowledge

The enduring asset is our world graph: a maintained account of how machines behave, where that knowledge applies and the evidence behind it. A component understood once can help us check another machine. A fault found in one factory can reveal what to inspect elsewhere.

My wager is that this knowledge will make dependable improvement progressively cheaper. Customers retain control of private information; reuse across customers requires permission.

We will charge a fixed fee for checking changes and maintaining evidence, plus 10% of agreed, realised benefit from improvements assessed through Symbolia. The fee never changes the standard a change must meet.

Internal simulations have exercised the approach. Next comes a real robot arm, then a related installation. I’ll measure the total work saved at the same standard, the value of the evidence to the customer, and whether they pay again. Those results will guide expansion.

Making each process easier to accelerate than the last.

Founding thesis, evidence base and path to scale

Thesis

AI is making software cheaper to produce faster than it is making software trustworthy. The gap matters most where software moves a machine.

I’m building Symbolia in that gap. A customer brings an industrial change. We establish what it must do, check it against those requirements and preserve the evidence as the installation changes. The customer gains a sound basis for putting an improvement into use.

The scale I’m building for is industrial. Manufacturing and heavy industry sit within a broad industrial economy producing roughly $30 trillion of annual value. MM13 I want verified optimisations to create $1 trillion of additional realised annual customer benefit. Symbolia’s 10% share would make that a $100 billion annual opportunity. The ambition rests on making dependable improvement repeatable across machines and factories.

Industrial agents already generate automation code and configure projects. AI-assisted proof systems are advancing alongside them, and external verification has been used on a real safety-critical PLC project. These are the beginnings of a service that combines industrial expertise with increasingly capable machines. IN03 IN04 FV07 FV13

I expect assurance to become part of deployment itself. Generation can be abundant only if dependable use can scale with it.

I. The Next Bottleneck

Writing a program and establishing that its behaviour is acceptable are different kinds of work. The person who wrote it once carried much of the context needed to review it. AI separates those tasks.

Google’s 2026 DORA analysis describes engineers spending time saved in coding on auditing and verification. Faster authorship left more work before reviewers. IN02

Industry is entering the same transition. Siemens’ agents generate automation projects; its work with NVIDIA aims to connect simulation with operational changes. Anthropic’s Model Hardware Standard preview lets models discover and operate programmable equipment through common interfaces. IN03 IN04 IN05 IN06

More of the world is becoming readable by machines, and more of its instructions will come from machines. The scarce step moves towards the person who must authorise the change.

II. Symbolia

Symbolia will make industrial knowledge reusable. We will establish what a machine can be trusted to do, preserve the evidence and carry it into the next compatible installation.

For each controller patch, production sequence or configuration change, the customer receives an account of what has been established and what remains open. Continuous assurance means keeping that account current as the machine changes.

Suppose a controller must wait for a fresh fixture confirmation before starting a tool. A useful check establishes that rule for an exact controller build. Measurements must then establish that the installation’s signals mean what the model assumes. A firmware change may preserve the logic while invalidating a timing assumption.

The evidence must keep those distinctions. A proof, a finite model check, a test and a vendor specification each support different claims. Authors never approve their own work. Unknown effort and cost stay unknown.

III. Why Industry First

A robotic cell already has geometry, states, signals and repeated sequences. Much of its world has been represented for control. That makes industry fertile ground for verification.

IFR reported 4.664 million industrial robots operating in 2024 and roughly 542,000 new installations that year. This is an existing industrial base on which to begin. IN07

My first customers are manufacturers using robotic equipment to make products. They benefit when dependable changes increase useful production, shorten commissioning or prevent disruption. Machine builders and integrators can help us reach related installations.

I’ll begin beside the existing engineering approval process, leaving safety-rated protections in place. Human-written and legacy code supply useful first cases; earlier changes also provide the variation needed to measure reuse.

The initial service will be narrow. Repeated cells in one controller family offer sequences, handshakes, timeouts and restart behaviour we can learn to check well. The first engagement starts smaller: one arm in an investor’s spray-coating business, with the reach-envelope method first to qualify.

Repetition is the experiment.

IV. The Technology Is Arriving

Several parts of verification are becoming easier at once.

AlphaProof demonstrated mathematical search guided by formal feedback. VeruSyn and VeriStruct advanced software-proof construction. SymCrypt connects production-oriented Rust to Lean verification; AXLE provides infrastructure for proof work. FV09 FV07 FV08 FV04 FV11

CERN–GSI brings the precedent closer to our first customer: externally delivered verification found discrepancies in a real safety-critical PLC project. FV13

These advances reduce the work of stating a problem, translating software, finding proofs and maintaining results. I can build a useful service as each part improves. The research chapter records what the demonstrations establish.

V. The Assurance Compiler

I think of the system as a compiler for evidence. It takes code, requirements and knowledge of the installation, then produces an inspectable account of why a change meets its requirements.

The first task is to ask the right question. A program can perfectly satisfy the wrong theorem. Microsoft’s work on intent formalisation addresses precisely this problem. FV16

How fresh must a fixture confirmation be? Which sensor faults matter? What happens after a restart? Which timing bounds have been measured? The engineer approves the meaning before a proof can support release.

The checked model must then describe the actual implementation. Proving a rewritten controller establishes a result about the rewrite; the connection to the deployed program needs its own justification. FV04 FV05

Different questions need different tools: logical solvers, model checking, proof assistants or physical tests. The required architecture separates proposal, checking and approval. Customer agents propose software and deployment designs. Symbolia’s agents formalise requirements and prepare claims and evidence; deterministic checkers judge them against the protected requirements. Neither proposing role can approve its own work or change the acceptance rule. FV01

The resulting package binds the software, equipment versions, assumptions, evidence and approvals. A few human claims expand into their supporting questions. People and customer agents receive the same conclusions and gaps from one read of the validated records. A claim about the whole machine needs an argument connecting its parts.

Then the evidence stays alive. When firmware changes, the engineer can ask: what must we establish again?

VI. The Industrial Assurance Graph

The Industrial Assurance Graph is the world graph at the heart of Symbolia. It connects what we know about components to the conditions, measurements and checks that make the knowledge useful.

Imagine the next workcell arriving with a robot family already modelled, a controller instruction set understood and a scanner’s behaviour characterised. The new installation inherits that work wherever its conditions hold. Engineers concentrate on what is different.

This is where verification begins to behave like compilation.

Each customer’s evidence stays protected. Shared contracts and methods carry explicit permissions and versions. Measurements retain the conditions under which they were taken.

Our advantage will come from justified knowledge that takes contact with industry to acquire: device behaviour, integration faults, accepted engineering practices and the consequences of real changes. Better models will be available to competitors too. Useful reuse and maintenance must make our accumulated knowledge worth more than its cost. MM09 MM10

I’ll test that in two ways. First, measure the second arm against the first. Later, compare the graph with the strongest available model and public tools on unseen changes at matched expert and compute budgets. Separately, record the cost of each library release and what it contributes to deployments withheld from its construction. More mapping must buy useful coverage or less future work.

VII. Timing

The first stage is a closely supported service for a narrow equipment family. The next is a repeatable product whose related deployments require less specialist effort. The second-arm comparison tests that transition.

From there, I intend to check AI-generated changes within agreed operating limits and extend the service across equipment vendors. The destination is assurance infrastructure for automated production.

Expert work can fund reusable knowledge. Better proving models can lower delivery cost. Better coding models can increase the changes customers want to make.

Both curves can favour the same company.

VIII. Competition

Code Metal, TrustInSoft and Axiom already work on verified software. Siemens owns engineering workflows, equipment knowledge and customer relationships. These are capable competitors and potential partners. MM01 MM04 FV10 IN03

I’ll use the strongest proving engines available. Our work belongs in understanding industrial behaviour, connecting evidence across machines and keeping it current. Independence earns its place when customers get something useful across suppliers that a bundled tool does not provide as well.

Each new checking method enters the trusted core and requires a core release. Qualifying one before funding another keeps the cost of broader coverage visible.

The company must know what a change means, what it depends on and what the evidence establishes about it.

IX. Business Model

We will charge for onboarding and formalisation, a fixed fee for maintained assurance, and 10% of agreed, realised benefit from customer-proposed improvements. The fixed fee pays for useful checking, including findings that prevent a bad release. The gain share rewards value delivered in operation.

The economic unit is a consequential change. To scale, we must reduce total effort on comparable work, counting failed evaluations, customer review and maintenance. I’ll measure engineering time, commissioning delay, discrepancies found and the usefulness of the evidence to the release approver.

As checking becomes part of routine deployment, maintained assurance becomes infrastructure.

X. What Must Be True

Four results will earn expansion.

Technical fidelity: the claims describe the actual implementation and configuration.

Customer utility: the evidence improves an engineering decision beyond existing review, testing and simulation.

Compounding economics: related deployments need materially less specialist effort at comparable coverage and quality.

Commercial acceptance: customers pay again and use the evidence in their workflow.

The programme tests deployment reuse and return on graph investment. Internal simulations already show bounded arithmetic reuse and useful failure detection. Adapter experiments have explored further situations, some still awaiting integration. Customer value, physical validity and lower total delivery cost remain the next evidence to earn. The sources record the implementation boundaries. SY01 SY02

XI. The Larger Thesis

I began Age of Wonders with an observation: abundance often arrives before access.

The universe was there before the instrument. The sunlight was there before the grid. Capability can exist before the infrastructure that makes it useful.

Machine intelligence is entering the same transition. Symbolic Superintelligence describes a compilation boundary: human objective, AI cognition, program synthesis, verification and bounded execution. The model proposes; protected rules govern what reaches the world.

I’m building that boundary into Symbolia. My ambition is larger than robotics. As intelligence becomes cheaper, more of the world will be designed and controlled through software. We need a dependable way to decide which instructions can act on it.

That is the AI safety problem I intend Symbolia to solve. Make intelligence safe to put to work.

Shorten a cycle. Recover from a jam. Accommodate a different part. Each industrial change begins with an intention, then needs instructions and a way to check them.

I see those two tasks becoming accessible to machines together. AI expands what manufacturers can change. Advances in verification expand what we can establish about the result.

The bottleneck is acceptance

DORA’s 2025 survey announcement described nearly 5,000 technology professionals. Ninety per cent used AI at work; 30% reported little or no trust in generated code. Greater adoption was associated with higher delivery throughput and lower stability. Strong platforms, testing and feedback helped teams benefit. IN01

Its March 2026 analysis examined 1,110 open-ended responses from Google engineers, collected in Q3 2025. Engineers described time saved in creation returning as auditing work. The qualitative survey, subject to possible priming, shows how drafting speed and review capacity can diverge. IN02

Industry is moving in the same direction. Siemens’ April 2026 Eigen Engineering Agent launch named more than 100 pilot companies in 19 countries. It reported faster automation programming and configuration; June’s expansion connected electrical designs to automation projects. These are Siemens’ productivity claims. Its “standards-compliant” generation refers to its project framework, with functional-safety conformity a separate task. IN03 IN04

Siemens and NVIDIA’s January 2026 programme aims to connect virtual testing with operational changes, using the Erlangen electronics factory as an initial blueprint. IN05

Anthropic’s August Model Hardware Standard preview brings agents to instruments and robots through common drivers. Device limits, further safety evaluation and expert physical judgement remain part of that work. IN06

The direction is clear: machines will propose more changes to other machines. Someone must establish which changes deserve to run.

An industrial base ready for improvement

IFR counted about 4.66 million industrial robots operating in 2024, with 542,076 new installations. Those robots span many tasks and markets. My first customers are manufacturers whose supported equipment changes often enough to need a continuing service. Machine builders and integrators can help us reach them. IN07

The first engagement starts with one arm through an investor connection. It gives us a concrete place to learn before expanding across related installations.

Public specifications, stopping-distance data and manuals supply part of the starting knowledge. We have retained documents for major arm families and lab prototypes. Their figures enter as declared premises with sources and conditions; measurements must establish what holds at an installation. SY03

The value is close to the machine: a commissioning shift saved, a rejected batch avoided, a reliable restart. Siemens’ 2024 downtime report uses 181 interviews covering 2019–2023 to estimate wider industrial losses. It establishes context, without isolating losses caused by AI-generated software. I’ll price our work against the customer’s actual costs. IN08

European machinery law also makes the connection between change and evidence consequential. The Machinery Regulation generally applies from 20 January 2027. A digital change can qualify as a substantial modification when it creates a new hazard or increases risk and meets the regulation’s other conditions. Article 18 then gives the modifier manufacturer obligations for the affected scope. Ordinary edits do not automatically qualify; conformity routes include internal production control. The law does not universally require mathematical proof or an external verifier. IN09

Proving the work

Finding a proof and checking it are separate jobs. AI can search while a trusted checker enforces the statement and its allowed assumptions. FV01

Microsoft’s SymCrypt work connects specifications to extracted Rust models and maintains proofs as those models change. Some low-level connections rely on reviewed models. For this cryptographic scope, verification can follow the implementation. FV04

CERN–GSI’s PLC verification service found discrepancies in a real safety-critical project and developed reusable models for protected Siemens functions. Documentation and simulation supplied those models because the hidden implementations were unavailable. Solving one difficult component left work the next project could inherit. FV13

VeruSyn reports 6.9 million synthetic verified training programs and lower proof-generation costs under its sampling protocol. VeriStruct verified 128 of 129 functions across ten of eleven curated data-structure modules, including test functions and using supplied tests. These are advances in bounded proof construction, with industrial delivery effort still to measure. FV07 FV08

Connecting proofs remains hard. DafnyCOMP’s ICLR 2026 evaluation found average success of 0.55% at Pass@8 on its main chain tasks; a three-turn verifier-assisted protocol raised two models to 9.67%. It used older model configurations and excluded Claude from downstream tests because Claude helped construct the tasks. The result identifies a problem worth solving: making contracts across functions agree. FV12

Repetition must improve the economics

I’ll begin where useful verification already exists and build as the tools improve. The commercial test covers the whole job: requirements, modelling, proof work, review, measurements and maintenance.

The second installation must need less repeated work while preserving useful coverage. That is how faster code generation becomes faster industrial improvement.

Equipment vendors can bundle checking and integrators can build their own tools. Symbolia earns a place when a customer gets better evidence, less repeated work or continuity across suppliers, and returns for the next change.

What must be provisioned

I’m building the system around an approved account of the machine and what it must do. Code, equipment versions, operating modes, signals, component documents and physical evidence give each check its meaning.

AI can expose ambiguities and explore failures. The responsible engineer approves the requirements. Changes to layout, equipment or operating limits need the accountable person’s approval; automatic software release requires an explicit customer policy.

For a fixture handshake, we need to know which request a confirmation belongs to, how long to wait and what happens after interruption. We must also examine unwanted behaviour that the rules permit. Contradictory assumptions, unreachable conditions and dropped requirements can make an empty result look successful.

What a proof can establish

A proof establishes that a precise claim follows from stated assumptions. To cover the program that will run, it needs a justified connection between implementation and model. Proving a rewritten controller alone proves something about the rewrite.

For each supported controller, we must account for its language, scan cycles, timers, arithmetic, scheduling and signal updates. Unsupported behaviour stays outside the claim or remains an open question. Digests identify exact source and executable bytes; the build and translation evidence explain how they relate.

Tests can support that connection. Cedar proves properties of Lean models and uses differential testing to connect them to production Rust. The evidence must preserve which part is proved and which is tested. FV03

Match each obligation to its method

The question chooses the tool. State-machine analysis suits handshakes; range analysis constrains possible values; logical solvers and proof assistants establish mathematical properties. Tests and measurements tell us about hardware.

A solver’s answer needs a checkable certificate or an explicit place in the trusted system. Functional correctness and termination are separate claims. Lean and Mathlib supply foundations; industrial meanings and interfaces still need engineering. Lean’s proof checking and executable compilation also carry distinct trust requirements. FV02

Protect the question and the gate

The required design separates authorship from approval. Customer agents propose software and deployment designs; Symbolia’s agents formalise requirements and prepare claims and evidence. Deterministic checkers use protected requirements, pinned tools and permitted assumptions. A submitted theorem cannot replace the one the customer approved.

Proof construction itself can execute code. Lean’s validation procedure therefore isolates construction and checks exported terms against a trusted statement. Multiple checkers can reduce implementation risk while still sharing a mistaken specification. FV01

Authenticated source authorship and independent approval must be enforced inside the core before the product can rely on that separation. The implementation record carries the current boundary.

Keep the core small and the knowledge reusable

One application will manage requirements, permissions, evidence and workflow. A separate process runs admitted checks. Every addition to the trusted core increases what we must maintain and qualify.

Customer models and numerical adapters can live outside it as versioned packages. Checkers cannot: each admitted method becomes part of the core and requires a new release that updates every customer partition’s binding. That is why I’ll qualify one robot method before funding another.

The first customer unit uses SQLite and immutable evidence files. We can change storage as workload demands without creating a second authority. Shared knowledge needs explicit ownership, permissions, versions and withdrawal rules at every scale.

Admit an execution, then inspect its result

An independent admission binds the exact inputs, checker, adapter and runtime. The operator runs that bounded package. The host checks the outputs against the admission before recording a conclusion.

Interrupted attempts remain visible. Retries preserve earlier evidence and prevent an old worker from completing a newer attempt. Local recovery and bounded-worker checks have been qualified; production isolation remains a separate requirement. SY01

Solvers can search for improvements within approved variables and objectives. Their answers still need checking. A sampled best point is the best among those samples; optimality requires a bound or certificate. Profit never gives a proposal authority to relax physical limits. The library’s own suggestion path remains to be implemented; the present path begins with a customer proposal.

Make composition explicit

A component’s guarantee depends on its surroundings. Two proved modules may still disagree about clocks, signal meanings or recovery. A claim about their combined behaviour must establish that they meet each other’s assumptions.

The graph records those relationships. A robot routine depends on a fixture contract; both depend on communication. A cycle of assumptions needs a joint argument. Recording the cycle does not supply one.

Physical motion also needs appropriate bounds, fault models and measured model error. Proof, numerical accuracy and physical applicability remain distinct parts of the argument.

Issue a package that survives a handover

The engineer needs six things: the exact system checked; the approved requirements; the supporting evidence; the assumptions and trusted tools; the conditions that keep the result applicable; and the recorded approval authority. The first engagement shows how these become a delivery.

People and customer agents receive the complete claim tree from one read of the same validated records. The human report preserves the conclusions without a model rewriting them. If the tree exceeds the reader’s limit, the reader refuses a partial display.

Each gap names the evidence or work needed to close it. The planned API lets the deployment submit that evidence for independent review, retaining its original kind. Its implementation depends on the author-approval boundary. A technical gap need not become a Director decision.

A CRITICAL finding identifies a supported obstacle to an approved requirement. A SUGGESTED improvement is optional. Missing evidence leaves a question open; it does not establish physical impossibility.

Keep evidence current as the machine changes

A replacement gripper can change response time. A new payload can invalidate a motion envelope while the software stays identical. I want the engineer to see which earlier conclusions need renewal.

The current implementation tracks affected artifacts. Connecting changes to individual obligations remains core work; until qualified, a patch re-checks everything in scope. The second deployment must measure the benefit of preserving unaffected evidence.

A changed model can also reveal dependencies the old graph missed. Keeping knowledge applicable is continuing engineering work.

At deployment, the customer’s gate checks the evidence against the intended machine configuration. Monitors can detect departures from observable assumptions. Essential protections and fallback remain local, with an installation-specific policy for lost connectivity and blocked unassured releases.

Give advanced controllers a bounded place to act

A capable controller can operate inside limits enforced by a simpler monitor and fallback. NASA’s runtime-assurance research examines intervention timing, recovery and the conditions that make recovery possible. Shared sensors, computing resources and hardware need analysis for failures that affect both controller and protection. FV14 FV15

This concentrates assurance around an inspectable boundary on what the controller can do.

Every guarantee needs a path back to the machine it describes. Every change needs a path forward to the evidence it must renew.

One arm in a spray booth

I’ll begin with a single robot arm spraying coffins in an investor’s business, after rehearsing the workflow on lab prototype arms. Access and the exact engagement still need arranging. The aim is a useful first account of the machine, followed by a second arm that can show what carries over.

The requirements cover reach, joint speed and torque, guard zones, interlocks, cycle time and the arm’s current configuration. Existing safety-rated controls stay in place; we work beside the customer’s engineering process.

A spray booth brings conditions an arm datasheet cannot establish: ventilation, explosive-atmosphere rating, solvent exposure, overspray, the booth’s protective stop, and coating thickness and cure. These need evidence from the installation. The lab rehearsal exercises the assurance workflow; the booth supplies its own physical questions.

My customers manufacture products with robotic equipment. They gain from faster commissioning, fewer surprises and better production. Machine builders and integrators can help us carry the service across related installations.

The signal

A controller requests fixture engagement, receives confirmation and starts the robot. After an interruption, yesterday’s confirmation may still be visible. Accepting it can start today’s routine before the fixture has confirmed today’s request.

Our worked model makes that failure inspectable. It compares two rules across their complete reachable finite state spaces, including cycles and optional environmental actions.

The failure takes five steps: request 1, acknowledge 1, restart, request 2, start using acknowledgement 1. The corrected rule lets both operations start with their own acknowledgements.

The model uses two sequential, non-wrapping operation identities. It checks confirmation at start; timeout and progress are separate questions. It has no PLC translation or physical fixture model. Delayed messages, signal integrity, scan timing and lifetime identifier reuse need further work before deployment.

That is what a checked result should give the reader: an exact claim, its scope and evidence they can inspect.

The requirements and the methods available

The first arm needs the following questions answered. Reach is the first robotics method to qualify; the available arithmetic checks do not supply a robotics model.

Each new checking method needs a core release. Changing a physical requirement into a different mathematical question requires Director approval; a formaliser cannot relabel it to obtain a result.

What a first engagement delivers

The customer supplies the arm and firmware identities, motion model, mount, fixtures, layout, candidate change, requirements and available measurements. We agree responsibilities, confidentiality and reuse rights. Missing inputs become visible gaps.

I’ll return a claim tree and matching human report, the work needed to close each gap, and a record of what the change affects. The forecast is about fifteen obligations: at most two or three checked leaves and twelve or thirteen typed gaps. The planned API gives the deployment a route to submit further evidence for review. A request for work grants no approval authority.

We will record specialist effort and failed attempts where measured. Core files edited must remain zero; rebuilding the core to serve the engagement fails that test. New platform code is measured, with zero expected on the second engagement.

Motion-profile and firmware outputs begin as unassessed observations under an admitted, monitored driver. Independent checking determines what they support. Simulation and vendor specifications keep their own evidence kinds; physical validity needs installation evidence.

The second arm measures the inheritance. Common knowledge may transfer while local timing or configuration needs renewal. Count the saving after that work and continuing maintenance.

Give the buyer a fair comparison

Compare Symbolia, the existing workflow and readily available tests on the same changes. Fix the property set in advance. Include permitted historical faults and blinded defects chosen by an independent engineer.

Measure missed and confirmed defects, unresolved questions, false alarms, review effort, specialist hours, elapsed time and accepted evidence. Separate a wrongly stated or translated problem from unsuccessful proof search.

This tests usefulness on the agreed cases. The programme turns the result into a decision about the next engagement.

Expansion path

The second arm can inherit the method, question structure and evidence templates. A related cell may also inherit controller meanings and component contracts. Each needs its own configuration, measurements and approval.

A new controller family requires its language, runtime and interfaces to be understood. Factory-wide coordination adds interactions and production modes. Process industry and mobile robotics add different dynamics and hazards.

I’ll expand where the knowledge already earned does useful work.

A trillion dollars of useful change

I’m building Symbolia for manufacturing and heavy industry within a roughly $30 trillion industrial economy. MM13 My goal is $1 trillion of additional annual customer benefit, agreed and realised through verified optimisation. At our 10% share, reaching that goal would create a $100 billion annual success-fee opportunity, before fixed assurance fees.

That ambition begins with machines already at work. A factory can produce more with the equipment it owns, use less energy and waste less material. AI will make improvements easier to propose. Symbolia will help engineers establish which changes meet their requirements and put the useful ones into service.

Charge for maintained assurance

Our first customers will be manufacturers operating robotic equipment. I’ll begin with bespoke engagements, working with the engineers who change the machines and the operations leaders who benefit from better production.

We will charge a fixed fee to check changes and keep their evidence current, plus 10% of agreed, realised benefit. Onboarding and the work of turning requirements into precise checks will be priced explicitly, along with unusually expensive computation. The fixed fee supports a dependable service; the success fee shares in the improvements it helps make possible.

Suppose a factory improves its production process and saves $1 million a year in energy and materials, after the costs of making the change. Once the agreed measurements confirm that benefit, Symbolia earns $150,000 and the customer keeps $850,000 before fixed assurance fees. The same model applies to agreed gains from additional sales or reduced downtime.

Before work begins, we agree how to measure the benefit and deduct the costs of achieving it. The customer decides whether to deploy. The requirements a change must satisfy stay independent of our fee.

Build once, use again

The world graph is the business asset I intend to build. It holds maintained knowledge of machine behaviour, the conditions where that knowledge applies and the evidence behind it.

A robot family modelled for one engagement can help us understand the next installation. A controller’s timing behaviour need not be reconstructed for every customer. Engineers can spend more of their time on what has changed, using earlier work wherever its conditions hold.

That is how I expect margins to improve. The customer pays for dependable improvement while each comparable job requires less specialist work. Private information remains under the customer’s control; sharing requires permission.

Invest ahead of the next customer

As we learn which knowledge gets used repeatedly, I’ll invest in building more of it. That means understanding common components, gathering evidence and developing checks before a customer needs them. We can spread that investment across many installations while maintaining the knowledge they depend on.

The opportunity grows with the graph. Understanding another component lets us serve more machines; understanding how components interact lets us assess more valuable changes. Revenue from today’s work can fund knowledge that improves tomorrow’s service.

Prove the economics in use

The programme starts with a real robot arm, then a compatible installation. I’ll compare total delivery cost at the same assurance standard, including failed attempts, computation, review, customer effort and maintenance. The working model shows how specialist time affects the margin. Investment in the graph must repay the cost of building and maintaining it through useful coverage or savings on new installations held out from its development.

A customer who gains from the work and returns for the next change gives us a reason to expand. Reusable knowledge gives us the means.

I want each improvement to make the next one easier to achieve.

Systematic Industrial Assurance

A proof about a timer matters to a machine builder when the installed timer behaves as the proof assumes. Controller, firmware, settings and operating conditions give that theorem an address in the world.

I’m building Symbolia to keep that address intact as machines change. Its world graph will connect what we know about components to the installations that depend on them. Each job will leave knowledge the next can use.

Preserve what makes a claim applicable

A source records what someone says. A declared premise states what a calculation assumes. A proof establishes its specified claim within a model. A measurement supplies evidence from the world. Approval accepts evidence for a named use. The graph preserves those distinctions through every transfer.

Changed premises trigger reassessment. Earlier versions remain available to explain earlier decisions.

Where Symbolia compounds

One sound controller model can serve many routines. A component contract can spare the next engineer a fresh specification. A commissioning fault can reveal an assumption shared by several installations.

I expect this inheritance to become Symbolia’s central asset. Dierickx and Cool describe how accumulated assets can reinforce one another, resist imitation, erode or be displaced. Which of those forces governs this business is something I must measure. MM09 MM10

The measure is work saved after checking applicability and paying for maintenance. A million graph entries mean little if every new machine still needs a million explanations.

Invest in reusable capability

Two experiments will test the graph. The first asks whether a compatible new deployment receives equally justified assurance with less total work. The second asks whether further investment in mapping and evidence improves later work enough to repay construction, review and maintenance. A useful library can still be expensive to expand.

Each mapping batch will retain its sources, accepted assets, rejected work and actual costs. I’ll evaluate its library release on cases held out from construction, with the evaluator, model, requirements and resources fixed within each comparison. A case used to improve the next batch becomes development material; fresh cases must test that batch.

Some investments will disappoint. A contract may never apply; an exception may cost more to maintain than it saves. The programme will direct further spending towards assets that earn their place, leaving unknown costs visible.

Establish and organise the library

Customer evidence belongs within its authorised project. Access must hold through every dependency a query follows, including counts and ranking information that might reveal another customer.

A reusable contract needs an owner, exact dependencies, permitted uses, applicable versions and independent review. Sharing requires both parties to approve the exact material crossing the boundary. Imported evidence retains its meaning; the receiving engineer must still establish that it fits the new installation. Agents can propose assets. They cannot approve their own interpretation.

Retrieval finds candidates. The relevant checker decides whether a result applies. An unsuccessful search establishes only that the search missed.

The private prototype has exercised bounded transfer across project scopes. Publication into a shared world library still needs a governed way to clear eligible knowledge for reuse. Production sharing and reuse on new deployments remain to be qualified.

What a competitor must reproduce

Competitors can buy the same models, use public proofs and hire engineers. Equipment vendors may know their products better than I do. Customers can export their own evidence.

The advantage I expect lies in knowledge that is difficult to acquire and useful repeatedly. A firmware deviation may be absent from the manual. A stopping-time measurement belongs to particular conditions. A failure investigation may expose an interaction nobody had modelled.

A rival can obtain access, repeat the experiment or choose a design that avoids the missing fact. The question is what equivalent, justified coverage costs them. Private knowledge used only once can sustain a service relationship without building a reusable asset.

Computational irreducibility

Discovery, proof checking and establishing physical applicability have different costs. Lean separates proof construction from checking through a small kernel; supported artifacts can be checked by independent implementations. Reuse should spare the next customer the original search. MM11

Time spent building a graph establishes no lower bound on reproducing its value. A better abstraction may bypass much of that history. P versus NP does not settle Symbolia’s competitive position. MM12

Where evidence requires equipment access, operating history and repeated validation, acquisition can remain slow while code generation accelerates. I’ll measure the cost of equivalent accepted coverage, rather than the cost of copying every edge.

Test the graph against better AI

After the second-arm comparison, I’ll test unseen customer changes under three conditions: the maintained graph plus the strongest available model; the same model with public tools and documentation; and that baseline with the graph’s additional evidence supplied as ordinary documents. The third condition separates access to facts from the value of their organisation.

All three receive the same customer-permitted project information. Freeze the useful property set, match compute and total specialist budgets, and have an independent reviewer assess coverage and evidence quality. Repeat after model upgrades with the same model available to every condition.

Count missed and confirmed defects, unresolved obligations, false rejections, preparation, repair, review and maintenance. The test must transfer a contract to a different implementation, configuration or operating condition. Repeating an identical cached check is a control.

I expect the graph to make better AI more useful. If its contribution disappears, I’ll retire the assets whose upkeep no longer earns its cost.

Maintenance is the asset

Customers will control their confidential evidence. Reuse of generic adapters, templates and de-identified failure knowledge needs explicit agreement. Technical access grants no commercial reuse right.

Exportable evidence and openly checkable results will let customers examine our work and move between tools. Symbolia must earn their return through usefulness. Its accounts must include proof repair, obsolete contracts, missing dependencies and recovery work.

The graph I want to build will carry hard-won knowledge forward while staying answerable to the machines it describes.

What my simulation has established so far

The internal energy-network study registered fifteen obligations, checked three arithmetic results and kept twelve gaps open. Repeating the transfer reused all three results without another worker execution. The workflow also exposed errors in numerical meaning, source bindings and applicability. SY01

Study-side adapters exercised screening, premise-domain and pricing examples without changing the retained core. Some remained proposals outside the governed claim tree. These are simulation and integration results; robot qualification, physical validation and total labour savings remain ahead. SY02

Tools are arriving from several directions

I’m entering a field with strong suppliers. Industrial platforms, analysis firms and proof engines already serve parts of the customer’s need. They are competitors, potential partners and the standard Symbolia must beat.

These are primary-source descriptions. Financing and benchmark results remain company-reported; the source library preserves their scope.

Make the point of separation useful

My opening is the relationship between component evidence and a customer’s release decision. A complete cell has interactions and operating assumptions that must survive changes of equipment, software and supplier. Symbolia will maintain that account.

I’ll begin with one arm and one method: the kinematic reach envelope. Every requirement beyond the qualified method stays visible as a gap. A second ecosystem or mixed installation must later show where that knowledge transfers.

Customers will receive full machine-readable JSON and a hierarchical human report from the same validated records. Every obligation remains visible; a reader that cannot show the complete tree must refuse it. That makes the work inspectable. Customers will decide whether it makes the work worth buying.

I’ll compare the whole accepted workflow, including the incumbent’s tools and engineers. Independence can ease a change of supplier, but it adds integration and responsibility. Where a bundled system already supplies equivalent evidence at lower cost, I’ll narrow the offer or partner.

Buy the engines; own the useful relationship

I’ll use established proof search, model checking, static analysis and testing tools, preserving the meaning of each result. Better engines should lower our delivery costs without erasing the customer’s assurance history.

The work worth owning is the connection between requirements, implementation, equipment and evidence—and keeping it true as each changes. An OEM can contribute a component contract; a specialist can validate a difficult model; a platform can distribute the workflow. Each partnership needs a clear owner for missing or erroneous evidence.

Symbolia is for every AI future

I expect increasingly capable generators to create more specialised machines and more frequent changes. Their interactions, physical conditions and owners will still need an accountable release decision.

Symbolia will earn its place by making that decision easier. If excellent generators and incumbent checks remove the need for an independent service in a segment, the programme’s decision table tells me when to narrow, partner or leave.

Where Symbolia must win

The graph must make the next job easier at equal assurance. After the second-arm measurement, the matched comparison against a capable model will test what maintained knowledge adds beyond better AI.

A second experiment will test the investment itself: whether successive mapping and validation batches improve held-out work after their full costs. Competitors will have better models too. I’m building a world graph whose value grows through knowledge they still need to establish, and service customers choose to keep.

The question formed

Symbolia came to me on a walk after nearly seven months of writing Age of Wonders.

The essays kept returning to one question: what is already possible, and what keeps it beyond reach? In Create an Age of Wonders, infrastructure carries abundance into use. Instruments bring distant phenomena into view. Energy systems carry power into daily life. Transport turns an exceptional journey into a route.

I had been approaching the same interval through different materials.

Ships inherit a route

The Free Starship imagines refuelling waypoints accumulating into routes. A successor inherits something earlier journeys established outside the ship.

Bridge to Infinity follows fixed works, maintenance and repeated journeys into the economics of transport. It’s All Energy describes useful supply becoming a stock of manufactured infrastructure we can improve and reproduce.

Build something whose next use carries less of the cost of its creation. That is the inheritance I want the assurance graph to give a machine builder.

Trust becomes part of the last mile

In Computational Abundance, I named the missing layer:

The last mile is trust made practical: a way to check the answer, see what happened, limit what the system may touch, and restore an earlier version when something goes wrong.

Software already has compilers, tests and version control. Other domains need checks shaped around their own failures. Intelligence becomes useful through the machinery that lets people depend on it.

The proposer reaches a gate

Symbolic Superintelligence gives that machinery an architecture. A human objective passes through AI cognition and program synthesis to verification and bounded execution. Tests sample behaviour. Proofs establish specified claims under assumptions. Interlocks constrain what reaches the world. The proposer controls none of these gates.

I expect a future of many specialised machines. As their design becomes cheaper, trust cannot remain bespoke for every new instance. Symbolia is where I’m building this part of the compilation boundary.

The idea comes into view

The essays moved through instruments, energy, computation, manufacturing and authority. By the time I reached formal verification, I could see the economic pattern beneath them: establish something once, keep it useful, and let the next person begin further ahead.

Symbolic Superintelligence makes a wider wager about the cost of open-ended mapmaking. Symbolia’s purpose survives a different outcome. Even excellent artificial mapmakers will create implementations and physical changes whose consequences need checking.

Love is the Foundation gives the work its destination: carrying what is abundant to people it has not reached. I want ordinary builders to make useful machines, and to change them with confidence.

Prove the product earns its cost

My next test is a complete customer journey: describe a cell, approve its requirements, build its claim tree, submit evidence and read the result. I’ll rehearse that journey on a synthetic six-axis cell and then on lab prototype arms before taking it into the coating booth.

The larger programme asks two questions. Does inherited knowledge reduce total work at equal useful coverage and evidence quality? Does further investment in the graph repay its construction, review and maintenance costs on later jobs?

The energy-network prototype established a starting point: fifteen obligations, three completed arithmetic checks and twelve visible gaps. Repeating the transfer reused the three certificates without another worker execution. New-deployment savings, physical validity and return on graph investment remain to be measured. SY01

The two world-graph experiments have not begun. These steps establish the evidence they need.

Establish the unit of trust and freeze the comparison

A reusable asset must name its claim, component and configuration versions, evidence, assumptions and remaining work. Sources, declared premises, mathematical checks, numerical observations and physical measurements keep their separate meanings.

In the private rehearsal, I’ll apply an asset to a compatible new input, refuse an incompatible convention or operating domain, and withdraw a dependency to stop further reliance on it. Earlier evidence remains inspectable. A separate reviewer must approve the asset and its use; the core must bind authenticated authorship to approval authority. Local credentials alone do not establish the full source-author boundary.

Before development reaches the test cases, freeze the tasks, coverage, evidence standard, evaluator, model and tool versions, resources and stopping rules. Both conditions receive the same approved requirements and necessary facts; one also receives the fixed library release. The measurement must be able to report improvement, regression and unknown cost.

Qualify one method

The kinematic reach envelope is the first and only funded robot method. Guard-zone and interlock method development waits for the measured second-arm comparison. Those requirements remain open obligations throughout; reach coverage cannot close them.

A new checker enters through a core release and renews the bindings for every customer partition. I’ll count acquisition, experiments, agent use, specialist interpretation, review, rejected work and maintenance. Unknown labour stays unknown; compute counts become cash costs only with actual rates and currency. The economic definitions apply to both library construction and delivery.

Keep construction examples separate from held-out tests, including related templates and traces. A case used to improve a release joins the development set; fresh cases test the successor. Without that separation, the result is a rehearsal.

The customer also needs an API to submit measurements and evidence against open claims, with authenticated authorship and independent approval. A mostly-gap tree becomes useful when the missing evidence has a governed route in.

Compare the second arm, then the model

Compare the second arm with the first only when their claim-shape keys match: the same obligation structure and checked-to-gap split, agreed in advance. Unequal assurance prevents a cost comparison. A negative saving belongs in the ledger.

Use fresh working state and vary task order to prevent answer leakage. Keep model changes separate from library changes. Retain failed tasks, refusals and unresolved obligations. Assess coverage and evidence quality before counting savings.

Count total implementation, formalisation, integration, review, compute, agent use and maintenance, including measured customer effort and time to a useful decision. Automated replay cannot fill a blank human timesheet.

Run the two experiments separately: effort with and without the library; then the contribution of each new library release against its incremental investment on held-out work, under fixed resources. Report task counts, variation and missing costs. The comparison against the strongest available model follows the second-arm measurement. Two deployments with matching claims are the minimum for a trend claim.

Findings that would change the plan

Each result will govern the next investment. The experiment must be able to change my plan.

Essential steps

The design partner is effectively identified. Before deployment, I need a dated Director authorisation naming the exact release and a rollback that restores a working Symbolia platform. Both remain open. Equipment access, procurement and availability will determine when work on the arm can begin.

The customer retains release authority. Ventilation, equipment rating, material exposure, overspray, interlocks, stopping behaviour and coating quality each need applicable evidence. A lab workflow rehearsal or vendor datasheet cannot supply physical validation of the booth.

I’ll offer a fixed fee plus 10% of agreed, realised incremental revenue or revenue-equivalent customer benefit, using the agreed economic definitions. A paid continuation must make actual cost, accepted coverage, limitations and maintenance clear. Repeat purchases will test commercial value; repeat savings and worthwhile graph investments will tell me how far to scale.

Research cut: 7 September 2026. These are the publications and revisions behind my argument. Each entry preserves the claim’s scope; company reports remain company reports. The strategy and illustrative models are my own, with customer validation ahead.

The research chapter develops the argument. This library lets readers examine its foundations; the local dossier retains source manifests and manuscript digests.

Primary source library

Living documentation was inspected on 7 September 2026. Duplicate citations to the same release are identified below.

Industrial demand and deployment

IN01 · Announcing the 2025 DORA Report: State of AI-Assisted Software Development

2025-09-23.

DORA reports widespread AI use and associations with software delivery throughput and stability. The research is observational and self-reported.

IN02 · Balancing AI tensions: Moving from AI adoption to effective SDLC use

2026-03-10.

A qualitative analysis of 1,110 Google-engineer responses collected in Q3 2025 describes creation gains alongside review and audit burdens. Possible survey priming limits interpretation; industrial defect and release rates were not measured.

IN03 · Siemens brings AI to the physical world with Eigen Engineering Agent

2026-04-20.

Siemens announced commercial automation-engineering agents and pilots across more than 100 companies in 19 countries. Productivity and quality figures are company-reported; the assigned-task benchmarks are unspecified.

IN04 · Siemens takes AI for the physical world to the next level with two new Eigen Engineering Agent capabilities

2026-06-17.

Siemens added ECAD integration and project generation. “Standards-compliant” refers to its Automation Framework for project organisation, rather than functional-safety certification.

IN05 · Siemens and NVIDIA Expand Partnership to Build the Industrial AI Operating System

2026-01-06.

The partners outline an industrial AI roadmap linking simulation to proposed operational changes. Autonomous-factory operation remains an ambition.

IN06 · Previewing the Model Hardware Standard

2026-08-27.

A research preview proposes model-agnostic orchestration of programmable equipment, with early partner examples and device-level limits. It is an interface proposal; whole-cell safety requires a wider argument.

IN07 · World Robotics 2025 — Industrial Robots: Executive Summary

2025-09-25.

IFR reports 542,076 industrial robot installations and computed operational stock of 4,663,698 in 2024. These count robots, not workcells or prospective assurance customers. Publication day is corroborated by IFR's report-2025 page.

Relevant location: PDF pp. 3–4 (printed pp. 13–14).

IN08 · The True Cost of Downtime 2024

Published 2024.

Estimated Fortune Global 500 downtime costs extrapolate from 181 online interviews conducted April 2019–March 2023. They describe historical exposure; attributing it to AI-generated changes needs separate evidence.

Relevant location: PDF pp. 2–3 and 14; dated by the report's 2024 copyright.

IN09 · Regulation (EU) 2023/1230 on machinery — consolidated 27 July 2026

2026-07-27.

Articles 3(16), 18, 25 and 54 govern substantial modification, conformity routes and general application from 20 January 2027. Article 18 excludes non-professional modification for own use. The regulation has no universal external-verifier or formal-proof mandate. This consolidated text is documentary; the authentic Official Journal controls.

Relevant location: Articles 3(16), 10, 18, 25, 54; Annex I A(5)–(6); Annex III 1.1.9 and 1.2.1.

IN10 · Regulation (EU) 2026/1744 — Digital Omnibus on AI

2026-07-24.

The act amends the AI Act and machinery framework, including product-AI timing. Its high-risk categories have defined scopes, and future delegated acts remain distinct from completed rules.

Relevant location: Adopted 8 July 2026; Official Journal, 24 July 2026; Article 1(40)–(41), Article 3.

IN11 · We are Changing our Developer Productivity Experiment Design

2026-02-24.

METR explains how changing tools, selective participation and task choice complicate productivity measurement among open-source developers. Its early-2025 slowdown result cannot simply be carried forward to current tools.

IN12 · Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity

2026-05-11.

A convenience sample reports perceived technical-worker value gains. Very low email response, selection effects and response inconsistencies limit interpretation; the survey measures self-reported value rather than observed speed.

Formal methods and proof infrastructure

FV01 · Validating a Lean Proof — Lean Language Reference

Undated living documentation; inspected 2026-09-07.

Procedures for inspecting assumptions and checking a proof against a protected statement. Trust still depends on the statement’s meaning, checking infrastructure and logic.

FV02 · Elaboration and Compilation — Lean Language Reference

Undated living documentation; inspected 2026-09-07.

Lean's kernel checks core logical terms; a separate compiler transforms intermediate representations to C and native code. Executable unsafe code has a different trust boundary from kernel-checked logical terms. Theorems about logical functions need further justification to support claims about compiled execution.

FV03 · How We Built Cedar: A Verification-Guided Approach

Accepted 2024-04-18; FSE Companion event 2024-07-15 to 2024-07-19.

Cedar combines proofs of Lean models with differential random testing against production Rust. The authors report four validator bugs found through proofs and 21 additional bugs through differential/property testing. The implementation bridge is testing, with reported generator-coverage and untested-API gaps, rather than a proof of whole-program equivalence.

FV04 · Verifying Rust cryptography in SymCrypt, from standards to code

2026-07-13.

Microsoft released proofs for Rust ML-KEM and SHA3 used in Windows Insider builds. Agents assist specification and proof work; maintained extraction and replay connect evidence to code. Low-level boundaries include reviewed models. Broader rollout remains ongoing, and AI labour savings are unquantified.

FV05 · Aeneas — verification toolchain for Rust programs

Undated living repository README; inspected 2026-09-07.

Aeneas uses Charon and Rust MIR-derived representations to generate functional models for proof assistants, including Lean. Its documented translation and borrow-checking work covers a subset of safe Rust. Unsafe code and concurrency support remain in development; some loop/reference patterns are unsupported, and external definitions may need handwritten models.

FV06 · Verus overview — Verus Tutorial and Reference

Undated living documentation; inspected 2026-09-07.

Verus statically checks supported Rust against specifications through verification conditions and SMT solving, without introducing runtime checks. Its trusted base includes the verifier and Rust/LLVM compilers. Language and library coverage is partial; the checking chain differs from replayable Lean proof terms.

FV07 · Reducing the Costs of Proof Synthesis on Rust Systems by Scaling Up a Seed Training Set

First submitted 2026-02-04; inspected revision v3 2026-05-09.

VeruSyn reports 6.9 million synthetic Verus-verified Rust programs used to fine-tune Qwen2.5-Coder-32B. Accuracy@100 with five debugging rounds is 49% on system proof tasks versus Sonnet 4.5's 54%, at about 2% of its inference cost. These benchmark costs depend on sampling and pricing; they exclude the wider assurance process. Validation rejects changed specifications, extra assumptions and nontermination.

FV08 · VeriStruct: AI-assisted Automated Verification of Data-Structure Modules in Verus

First submitted 2025-10-28; inspected revision v4 2026-03-03.

VeriStruct reports success on 10 of 11 Rust data-structure modules and 128 of 129 functions through structured generation and repair of abstractions, specifications and proofs. The evaluation uses curated/modified modules, includes test functions in the count and requires a comprehensive user-supplied test suite. Success is measured against the resulting contracts.

FV09 · Olympiad-level formal mathematical reasoning with reinforcement learning

Online publication 2025-11-12; version of record 2026-03-13; issue 2026-03-19; IMO event studied July 2024.

AlphaProof solved three non-geometry IMO 2024 problems through reinforcement learning and test-time adaptation. Combined with AlphaGeometry 2, the system scored 28/42, within the silver-medal range. Experts formalised the problems; each AlphaProof solution took two to three days of test-time reinforcement learning. Two combinatorics problems remained unsolved. The demonstrated task is mathematical proof search.

FV10 · Releasing AXLE

2026-03-05.

Axiom released the Axiom Lean Engine: infrastructure for Lean proof verification and manipulation. Its technical scope is detailed in FV11.

FV11 · AXLE: A Cloud Infrastructure for Lean 4 Theorem Proving Utilities

Submitted 2026-06-24; accepted at AI for Math Workshop, ICML 2026.

AXLE describes 14 Lean tools, multi-version hosted execution and checks on signatures, axioms and incomplete proofs; authors report over 500 million requests. The paper prioritises cooperating clients and recommends stronger independent validation for hostile submissions. Fixed environments constrain multi-file projects. The count measures infrastructure requests at this revision.

FV12 · Local Success Does Not Compose: Benchmarking Large Language Models for Compositional Formal Verification

ICLR 2026 proceedings; precise publication day not displayed; supersedes inspected 2025-09-27 preprint results.

Final DafnyCOMP contains 400 programs: 300 chains and 100 DAGs. Main chain evaluation averages 0.55% verification at Pass@8, best 2%; a three-turn verifier-assisted protocol reaches 9.67% for two models. Tasks contain two to five acyclic functions. The eleven model configurations predate this dossier; Claude is excluded from evaluation because it helped synthesise the tasks.

FV13 · Formal Verification of PLCs as a Service: A CERN-GSI Safety-Critical Case Study (extended version)

Submitted 2025-02-26; extended version of NFM 2025 paper.

CERN verified GSI's FAIR Personnel Access System PLC project through separate requirements, development and verification teams. Iteration repaired discrepancies and added reusable models for protected Siemens functions, including timed functions. Those models were checked against documentation and simulated scenarios; hidden implementations remained outside the equivalence claim. The paper reports verifier bugs and leaves commercial cost and AI contribution unquantified.

FV14 · A Verification Framework for Runtime Assurance of Autonomous UAS

DASC 2024, September–October 2024 (author publication list); author-hosted draft.

NASA authors formalise Simplex runtime assurance in PVS/Plaidypvs for three UAS examples. The advanced controller is treated as a black box; proofs concern recovery and monitor sampling. Safety depends on timely detection and a suitable trusted recovery controller under the model's assumptions. More complex composition remains future work.

FV15 · Runtime Assurance of Aeronautical Products: Preliminary Recommendations

January 2023 (report cover; NTRS metadata says 2023-01-01).

NASA's preliminary civil-aviation guidance recommends domain-validated monitor requirements, traceability, evidence linking executable monitors to specifications, verified safe fallback, input assurance and common-cause failure management. Runtime assurance can introduce hazards and needs its own assurance argument.

FV16 · Intent Formalization: A Grand Challenge for Reliable Coding in the Age of AI Agents

Shuvendu K. Lahiri · Microsoft Research · 17 March 2026, arXiv v1.

A research agenda for translating informal intent into validated, checkable specifications. The paper surveys early approaches; specification validation and production scaling remain open challenges.

Competition and accumulated advantage

MM01 · Code Metal Closes $125M Series B

2026-02-19.

Code Metal announces a $125 million Series B for verified code translation and hardware optimisation in mission-critical industries. Financing and product direction are company-reported.

MM02 · Siemens launches the Eigen Engineering Agent, bringing purpose-built AI to industrial automation engineering

2026-04-20.

Siemens announces general availability, TIA Portal integration, project-context engineering and output validation. Customer counts and productivity are company-reported. The validation description specifies no formal-proof guarantee or whole-system safety certification.

MM03 · TIA Portal Test Suite V20: Application test — Introduction

2024-11.

Version-pinned documentation for S7-1500 block tests using PLCSIM Advanced, assignments, cycle/time execution and assertions. It describes simulation-based testing.

MM04 · TrustInSoft Announces April 2026 Release of TrustInSoft Analyzer with AI Powered Verification Enhancements

2026-04-28.

The release adds AI-generated drivers/stubs, formal-methods-based MC/DC analysis and integrated Rust workflows. Its body dates the release to April 2026; the official listing supplies day 28. The separate 10 March announcement previews availability. Performance claims remain vendor-reported.

MM05 · Certora Technology White Paper

2025-02-24.

Describes smart-contract bytecode verification against CVL/CVLR specifications, including mutation checks for specification weaknesses. Results concern the supplied contracts under the tool's modelling assumptions.

MM06 · Runtime Verification: Our Work

Undated living documentation; inspected 7 September 2026.

Describes formal verification, modelling, fuzzing, design review, reusable customer artifacts and embedded-systems assurance. Service scope and customer outcomes are supplier-reported.

MM07 · Aristotle Learns to Code, Achieving New State-of-the-Art of 96.8% on Code Verification Benchmark

2025-12-03.

Harmonic reports 160 proofs and 23 disproofs among 189 supplied VERINA algorithm/specification tasks. The 96.8% figure concerns this benchmark with given specifications.

MM08 · Releasing AXLE

2026-03-05.

Duplicate of the primary release catalogued as FV10.

MM09 · Dierickx and Cool: Asset Stock Accumulation and Sustainability of Competitive Advantage

1989-12-01.

The publication's abstract identifies asset accumulation, imitation, substitution and mechanisms including time compression, complements and erosion. Inspection covered publisher metadata and abstract; the detailed argument was read in the authors' working paper MM10.

MM10 · Dierickx and Cool: Asset Stock Accumulation and Sustainability of Competitive Advantage — INSEAD working paper 87/46

1987-12.

The authors explain time-compression diseconomies, complementary stocks, erosion and substitution, stressing that these properties vary between accumulation processes. This March 1987 draft was revised in December, before the 1989 final publication. Its application to Symbolia is my analysis.

MM11 · The Lean Language Reference: Introduction

Undated; inspected 7 September 2026.

Lean uses a small independently implementable proof-checking kernel, with independent implementations available. The manual described version 4.34.0-rc2 on access. Construction and checking are separate; checking cost still depends on the proof.

MM12 · Clay Mathematics Institute: P vs NP

Undated; inspected 7 September 2026.

P versus NP remains unsolved. This is complexity background, not a lower bound for Symbolia’s tasks or graph. A large brute-force search space leaves better algorithms possible.

MM13 · World Bank: Industry, including construction, value added (current US$)

World, 2024; World Development Indicators update 13 July 2026, retrieved 13 September 2026.

The World Bank API returned $28,403,795,045,949.50: roughly $30 trillion in annual industrial value added. The industry definition covers manufacturing, mining, construction, electricity, water and gas. Value added deducts intermediate consumption; it is not gross sales or an assurance budget. The retained response fixes the edition used here.

This is the economic scale behind my target in manufacturing and heavy industry. The $1 trillion annual improvement ambition is my thesis. At a 10% share of that agreed, realised benefit flowing through Symbolia, the annual success-fee opportunity is $100 billion, before fixed fees. The calculation describes the scale I intend to pursue.

The manuscript lineage

The origins chapter follows the current Age of Wonders manuscripts and my account of the walk. SHA-256 digests identify the versions read; the named PDF editions were not compared page by page. Irreducible remains a published historical predecessor to Symbolic Superintelligence.

• Create An Age Of Wonders — canonical essay.
• Perceptual Abundance — canonical essay.
• Its All Energy — canonical essay.
• Computational Abundance — canonical essay.
• Bridge To Infinity — canonical essay.
• The Free Starship — canonical essay.
• Symbolic Superintelligence — canonical essay.
• Irreducible — historical predecessor.
• Love Is The Foundation — canonical essay.

Internal prototype evidence

SY01 · Symbolia’s simulated energy-network engagement and architecture reconciliation

Private development record, independently re-read within the project on 12 September 2026. This is my prototype evidence; customer validation and public replication remain separate.

The transfer registered fifteen obligations, checked three existing arithmetic certificates and kept twelve gaps open. A repeat reused the three certificates without new worker execution. Fifteen exact scalar fields and fifteen preview identities reproduced. Later reviews retained failures and corrections in preparation, output bindings and applicability. The private evidence manifest identifies the receipts.

These records show bounded method/cache reuse and useful failure detection. Total labour savings, production isolation, physical validity and return on graph investment remain unestablished. The programme will test reuse at equal coverage and recorded cost. External sources retain their original inspection dates.

Historical checkpoint, 13 September 2026. The accepted core then carried 1,046 passing tests; SY01’s claims were unchanged. At that checkpoint, four qualifications awaited independent acceptance: the public path, world-graph reuse, world-graph investment, and reuse on a second deployment. The public path had local test results; the two world-graph qualifications were unstarted. Physical validity, labour savings and production isolation remain unestablished. Pending acceptance, unrun tests and failed tests retain distinct meanings.

SY02 · Study-side adaptation examples

Private development record, 12 September 2026. My prototype evidence, awaiting external validation.

In the same energy-network study, I asked whether a new situation fits the architecture, needs a study-side adapter or requires a core change. Each class needed one of those three verdicts.

Study-side adapters exercised screening, premise-domain and pricing examples without editing the retained core. The records name existing arithmetic, return-profile and execution primitives, but some results remained proposals outside the governed claim tree. The thermal-blooming screen did not exercise core integration; the sizing-economics proposal had no registered governed leaf, qualified return-refresh bridge or independently admitted correction. A missing primitive remained an explicit finding. These records support bounded adapter work, not four independently integrated situation classes.

No labour saving, physical validation, hardware feasibility or physical applicability is established. The optical calculations report sampled optical quantities; their fine-minus-coarse quadrature differences do not enclose continuous numerical error or establish electrical output. The economic outputs are symbolic inequalities in unknowns with no actual intercepts: conditional boundaries rather than accounting returns, quotes or physical conclusions. The unfinished return-cycle bridge remains a separate gap. Nothing here concerns robots.

These examples locate useful adapters and unfinished integration. Governed transfer and its cost need separate measurement.

SY03 · Retained public robot-arm datasheets

Retained during September 2026 under the platform plan's arm-data directory. Public vendor documents, republished nowhere.

Manufacturer specifications, stopping-distance data, functional-safety notes and instruction manuals for common industrial arm variants across ABB, FANUC, KUKA, Universal Robots, Yaskawa and Kawasaki, together with lab prototype arms including the Franka FR3, Kinova Gen3, Dobot CR series and uFactory xArm. Several of the retained Kawasaki and Yaskawa documents cover explosion-proof painting robots, which is the hazard class of the first engagement.

These figures enter the claim tree as declared premises with their source, digest and vendor conditions. They remain unmeasured on the installation. A datasheet premise supplies no physical validation.

An independently reviewed recovery organised the figures against fifteen proposed deployment obligations, all open. Exact source-field qualification remains pending; recovered positive votes alone do not confirm the premises.

Current implementation boundaries

The latest local successor has passed its full test suite and independent reviews for internal admitted arithmetic, guarded paired JSON/human reading and independent approval of authenticated proposal registrants. That bounded successor is adopted and open for private pull-request review. These controls run on a trusted local host; they do not recover the original authors of imported source material. Full source-author coverage, public mutation routes, production runtime and physical or customer validation remain open.

Change tracking identifies affected artifacts. Linking each change to the obligations it invalidates remains core work; until qualified, a patch re-checks everything in scope. Reuse experiments must count that work and its maintenance.

Executable finite-state example

A stale acknowledgement across restart

Original illustrative finite protocol model; no production PLC or physical machine is verified.

Every robot_start transition carries a nonempty acknowledgement whose identity equals the active request identity.

Evaluated on robot_start transitions. The results below are generated from the local model.

Assumptions of the model

• Exactly one active request at a time; at most two operations with fresh identities 1 then 2, without wraparound or reuse.
• Events are atomic and interleaved; all enabled event choices are explored without a fairness assumption.
• Restart cancels the active request but preserves both the acknowledgement latch and the issued-operation counter.
• A new acknowledgement can name only the current active request; an old one can persist until cleared or replaced.
• The environment may acknowledge, clear an acknowledgement, or wait indefinitely; no timeout or progress property is asserted.
• Start reads the request and acknowledgement identities atomically; later input changes do not change the provenance recorded for that start.
• The second operation is the final one; after it, environment actions and restarts remain possible but no third request is issued.

Where this result stops

• Reachable closure is exhaustive only for these finite models. Two operation identities do not prove arbitrary lifetime behaviour.
• Matching provenance is not evidence of physical fixture engagement, sensor integrity, collision avoidance or functional-safety compliance.
• No delayed-message queue, identifier reuse, scan/task scheduling, wall-clock timing, firmware, compiler or PLC source-to-binary relationship is modelled.
• A matching acknowledgement can still be incorrect about the physical world; the model does not represent that fault.
• No liveness, timeout, recovery-progress or performance guarantee follows from this safety property.
• The SHA-256 digest binds the results to this script; it does not prove the script correct or authorise any industrial release.

{
  "schemaVersion": "symbolia.handshake.v1",
  "title": "A stale acknowledgement across restart",
  "scope": "Original illustrative finite protocol model; no production PLC or physical machine is verified.",
  "schema": {
    "variants": "One complete reachable transition graph per start policy; labelled edges include self-loops and distinct actions with the same endpoints.",
    "stateCount": "Number of distinct reachable states including the initial state.",
    "edgeCount": "Number of enabled labelled transitions over all reachable states, including cycles.",
    "startTransitionCount": "Number of reachable robot_start edges, not physical starts observed.",
    "shortestCounterexample": "Null when no violating start edge exists; otherwise an initial state and shortest enabled event sequence ending at a violation.",
    "maxShortestDistance": "Greatest shortest-path distance from the initial state; this is a measured graph statistic, not an exploration bound.",
    "checks": "Executable regression checks for this illustrative checker and witness; not an independent proof of the checker implementation."
  },
  "property": {
    "id": "start_ack_has_current_request_identity",
    "statement": "Every robot_start transition carries a nonempty acknowledgement whose identity equals the active request identity.",
    "evaluatedOn": "robot_start transitions"
  },
  "assumptions": [
    "Exactly one active request at a time; at most two operations with fresh identities 1 then 2, without wraparound or reuse.",
    "Events are atomic and interleaved; all enabled event choices are explored without a fairness assumption.",
    "Restart cancels the active request but preserves both the acknowledgement latch and the issued-operation counter.",
    "A new acknowledgement can name only the current active request; an old one can persist until cleared or replaced.",
    "The environment may acknowledge, clear an acknowledgement, or wait indefinitely; no timeout or progress property is asserted.",
    "Start reads the request and acknowledgement identities atomically; later input changes do not change the provenance recorded for that start.",
    "The second operation is the final one; after it, environment actions and restarts remain possible but no third request is issued."
  ],
  "model": {
    "file": "handshake.mjs",
    "sha256": "045d1bc8ac4787058f3e52eb909073a487309a9fdc1ee49a28525b9a6d590d5c",
    "algorithm": "Breadth-first enumeration to reachable-state closure; no depth cutoff; all enabled labelled transitions checked.",
    "stateFields": {
      "issuedOperations": "Persistent count of issued operations: 0, 1 or 2.",
      "phase": "idle, waiting or started.",
      "requestId": "Active operation identity, or null when idle.",
      "ackId": "Latched acknowledgement identity, or null when empty."
    },
    "operationIds": [
      1,
      2
    ]
  },
  "variants": [
    {
      "id": "naive",
      "title": "Accept any acknowledgement",
      "result": "counterexample",
      "stateCount": 16,
      "edgeCount": 56,
      "startTransitionCount": 3,
      "violatingStartTransitionCount": 1,
      "maxShortestDistance": 6,
      "reachableClosureComplete": true,
      "shortestCounterexample": {
        "length": 5,
        "initialState": {
          "issuedOperations": 0,
          "phase": "idle",
          "requestId": null,
          "ackId": null
        },
        "steps": [
          {
            "index": 1,
            "action": "issue_request_1",
            "from": {
              "issuedOperations": 0,
              "phase": "idle",
              "requestId": null,
              "ackId": null
            },
            "to": {
              "issuedOperations": 1,
              "phase": "waiting",
              "requestId": 1,
              "ackId": null
            },
            "start": null
          },
          {
            "index": 2,
            "action": "environment_ack_current",
            "from": {
              "issuedOperations": 1,
              "phase": "waiting",
              "requestId": 1,
              "ackId": null
            },
            "to": {
              "issuedOperations": 1,
              "phase": "waiting",
              "requestId": 1,
              "ackId": 1
            },
            "start": null
          },
          {
            "index": 3,
            "action": "interrupt_and_restart",
            "from": {
              "issuedOperations": 1,
              "phase": "waiting",
              "requestId": 1,
              "ackId": 1
            },
            "to": {
              "issuedOperations": 1,
              "phase": "idle",
              "requestId": null,
              "ackId": 1
            },
            "start": null
          },
          {
            "index": 4,
            "action": "issue_request_2",
            "from": {
              "issuedOperations": 1,
              "phase": "idle",
              "requestId": null,
              "ackId": 1
            },
            "to": {
              "issuedOperations": 2,
              "phase": "waiting",
              "requestId": 2,
              "ackId": 1
            },
            "start": null
          },
          {
            "index": 5,
            "action": "robot_start",
            "from": {
              "issuedOperations": 2,
              "phase": "waiting",
              "requestId": 2,
              "ackId": 1
            },
            "to": {
              "issuedOperations": 2,
              "phase": "started",
              "requestId": 2,
              "ackId": 1
            },
            "start": {
              "requestId": 2,
              "ackId": 1
            }
          }
        ],
        "violatingStep": 5
      }
    },
    {
      "id": "fixed",
      "title": "Require the current request identity",
      "result": "no_counterexample_in_reachable_closure",
      "stateCount": 15,
      "edgeCount": 50,
      "startTransitionCount": 2,
      "violatingStartTransitionCount": 0,
      "maxShortestDistance": 6,
      "reachableClosureComplete": true,
      "shortestCounterexample": null
    }
  ],
  "limitations": [
    "Reachable closure is exhaustive only for these finite models. Two operation identities do not prove arbitrary lifetime behaviour.",
    "Matching provenance is not evidence of physical fixture engagement, sensor integrity, collision avoidance or functional-safety compliance.",
    "No delayed-message queue, identifier reuse, scan/task scheduling, wall-clock timing, firmware, compiler or PLC source-to-binary relationship is modelled.",
    "A matching acknowledgement can still be incorrect about the physical world; the model does not represent that fault.",
    "No liveness, timeout, recovery-progress or performance guarantee follows from this safety property.",
    "The SHA-256 digest binds the results to this script; it does not prove the script correct or authorise any industrial release."
  ],
  "checks": {
    "passed": true,
    "names": [
      "Both policies permit a matching acknowledgement and reject an empty one",
      "Only the naive policy permits a stale acknowledgement",
      "Both complete reachable graphs are closed under every enabled transition",
      "Environment cycles, clearing and restart persistence are present",
      "Both operation identities can start: fixed success is not vacuous",
      "Naive witness replays and has minimum length in the reachable graph",
      "Fixed provenance property holds on every reachable start transition",
      "Mutation removing the fixed identity comparison is rejected"
    ]
  }
}

Read the commercial argument and the first engagement alongside these examples.