Where the defects are, and what they are
A located list: which part of the design carries which problem.
Design verification for equipment software
Find the design defects
before you build the machine.
Design problems that surface after the equipment is assembled are the most expensive kind to fix. DatumProof finds them while the machine is still a drawing.
Every year, quietly
Every equipment maker carries a cost no ledger names.
It is the design problem found only after the machine reaches the customer's floor. Days lost tracing the cause, a schedule that slips, parts rebuilt — and at the worst end, a recall or a safety incident.
No account line reads "design defect". So the pain is felt at board level while the number is known to nobody. What is certain is that it is not small.
And the number changes by an order of magnitude based on one thing: when you find it.
- ×1 Found at design
- ×10 Found at integration test
- ×100–1000 Found on site or in production
A long-standing rule of thumb in software engineering. In equipment development, on-site rework, schedule slip and safety re-certification stack on top of it.
Why now
What has been catching these defects is, in the end, people.
Until now the safety net has been the judgement of senior engineers — the ones who look at a design and know, without being able to say quite how, that it will bite.
Those engineers are retiring, and younger ones are harder to hire every year. The problem has not changed; the net catching it is thinning. The gap widens with time.
What we do
We take that work on, without you adding headcount.
Before the machine is built, we search the design for the defects hidden inside it — including the situations nobody thought to consider, because we exhaustively cover every circumstance the machine can end up in.
Think of it as the role a newly hired senior engineer would fill, filled another way.
What you receive
The order of events that triggers each one
Not "something is wrong somewhere" — the exact sequence that produces the fault.
Proof that the dangerous states cannot occur
Not "it did not happen when we tried". Within the scope we check, it cannot happen in this design. That scope is agreed with you before work starts.
All of it in a form your engineers can take straight into the next design review — results to work from, not a report to decode.
About your intellectual property
Your drawings never leave your company.
Our software runs entirely inside your network. It sends nothing out. It is not the increasingly common arrangement where drawings are uploaded to an AI service.
A company that guards its own technology guards its customers'.
A proven approach
We did not invent this method.
"Does that actually work?" is the reasonable first reaction, and it deserves a straight answer.
This is not our invention. The companies held to the highest standards in the world have used this approach for decades, and in aerospace and rail the safety certifications require it. Our work is to bring a method that is already proven into the shape your floor can use.
The proposal
There is no need to start big. Start with one design.
One electrical design — the most concrete kind — is enough. We work under NDA, and you decide the next step after you have seen the result.
We would rather not argue the case in words. We will show it on one real design of yours.
- Scope
- One of your designs (electrical design recommended). The scope is fixed before work starts
- Duration
- 4–8 weeks as a guide, for the agreed scope
- Terms
- Under NDA. Design documents are treated as confidential
- Hardware
- Not required. The precondition is that the operating conditions and states are traceable from the design documents
- Cost
- First engagements are priced as reference work
Technical detail from here on
The same argument, restated for the engineers who will do the work.
On the name
If the datum is in doubt, everything measured from it is in doubt.
On a drawing, the datum is the reference every dimension is measured from. If the datum is wrong, every measurement stacked on top of it is wrong with it — which is why a drawing begins by declaring its references.
For equipment software, that reference is the design. Yet in this industry the reference itself is never proven. Implementation and testing are stacked on top of it and the stack is trusted because the machine moves.
DatumProof makes that reference provable.
The problem
The right-hand side of the V-model cannot be executed
The descending left side of the V — requirements, hazard analysis, safety requirements, system design, detailed design, implementation — can be carried out with legacy material and the experience of senior engineers. The problem is the ascending right side: verification.
Automation equipment has no physical structure that can be tested as separated units. Unit testing and module verification therefore do not hold, and verification depends entirely on integration testing, system validation and commissioning. For decades the industry has run on a single empirical check: the machine moves, so it is fine.
The cost of that gap is that errors surface at the moment they are most expensive to fix. And without unit or module verification, you cannot localise them. When something breaks on site, you begin from a question: is this a design fault or an implementation fault?
Where we sit
We are not creating demand. We add one rung to a ladder the market is already climbing.
Formal methods may sound abrupt to the equipment industry. In practice, the world is already moving toward designing with models — model-based systems engineering is a market growing at double digits.
Building a model and proving that model is correct are two different jobs. DatumProof does not compete with the tools that build models. It is the verification layer that sits on top of them.
- 01 Equipment outgrew what one engineer could hold in their head.
- 02 So the world moved to designing with models (MBSE / MBD).
- 03 But nobody proves the model itself is right.
- 04 Formal verification closes that gap. DatumProof
Against testing
"We tried it and it did not happen" versus "we proved it cannot"
Concurrency and timing faults, found at design time
Race conditions, deadlocks and timing-dependent faults arise when several axes, sensors and controllers act at once. Their occurrence probability is low, which is precisely why testing does not reproduce them — they stay quiet in the lab and appear on the customer floor.
Every reachable state, not only the ones you thought of
A test confirms the cases the designer imagined. Design verification checks that the safety property holds across every state the design can reach — including the sequences nobody wrote a test for.
A defect arrives as a reproduction procedure
Not "something is wrong somewhere". You get the exact event sequence that reproduces the violation — a counterexample you can walk through in a design review.
Formal verification does not replace testing. It verifies the design, not the built machine — wiring, assembly and physical response remain testing's job. The two answer different questions.
Services
What we do
A
Design verification diagnosis
One system under development, or one component under evaluation, verified at design time.
BDesign specification formalisation
We move your natural-language design documents into a form that can be verified.
CCertification and regulatory documents
Safety property proofs and their supporting evidence, prepared in a form you can submit.
DTraining and workshops
Formal methods explained in the vocabulary of people who build machines.
Try it on your own design.
Not a concept pitch — the specific defects and counterexamples that come out of your actual design. Start by choosing one target.