Ambiguity → the wrong system
Informal requirements read differently to different engineers. "Fast", "shortly after", "stable" — each reader fills the gap their own way, and a correct implementation of a misread requirement is still the wrong system.
BTC TestStack
Formal Specification and Formal Verification
What if your computer could understand your requirements?
Natural-language requirement
After the enable signal, the brake command shall settle within a short time.
Formalized (Universal Pattern)
TRIGGERenable == true
ACTION|brake − target| ≤ 0.5
WITHINt ≤ 20 ms
Proven for all inputs and calibrations
model checking · no reachable violation
The challenge
Natural language leaves room for doubt.
Two gaps sit between a written requirement and a safe system. Both stay open no matter how many tests you run.
Testing → the unanswered question
Testing checks the behaviors you thought to try. It can't cover every input, state and calibration, so the real question — "can my safety requirement ever be violated?" — stays open after the suite goes green.
Testing is sampling. Formal verification is proof.
Formal methods close both gaps: make the requirement precise, then prove the code against it.
Formal specification
An intuitive language.
BTC Universal Pattern is a graphical, intuitive method for requirements engineering — the editor and the documentation are the same artifact. You describe what must hold; the tool makes it machine-readable, and traceability to the source requirement is preserved throughout.
Three steps to a machine-readable requirement
1Identify
Mark the expressions
Highlight the meaningful phrases in the requirement and turn them into reusable macros.
after [enable],
the [brake settles]
2Structure
Arrange & time it
Place the macros graphically as trigger, action and timing — the pattern removes the ambiguity.
trigger enable
action brake settles
within 20 ms
3Map
Link to the interfaces
Bind each macro to real system signals. The requirement is now machine-readable and executable.
enable → ctrl.en
brake → act.trq
✓ machine-readable
Bi-directional traceability to the source requirement is preserved at every step.
Trusted AI
AI-assisted formalization — the missing piece.
Writing formal specifications by hand was a challenge. Formalizing a requirement is fundamentally a language task — which is exactly what modern AI is good at.
The BTC AI Assistant drafts a Universal Pattern from a written requirement — trigger, action and timing — ready for you to refine, approve, or generate test cases from.
Formal verification
The power of proof.
Machine-readable requirements = automated verification.
01
Formal Test
Cross-checks every existing test case against every formalized requirement at once — catching side effects a test was never written to look for, with no extra effort.
02
Automatic Test Generation
Model checking generates the exact test cases missing from your suite, driving requirements coverage to 100% — deterministically, not by trial and error.
03
Formal Verification
Model checking produces a mathematical proof that a requirement can never be violated — no input or calibration combination reaches the unsafe state — or returns a concrete counter-example.
Key benefits
What you get from formal methods.
Better requirements
Formalizing forces precision — vague requirements are caught before code and tests exist.
Meaningful coverage
Requirements coverage measured and closed automatically, not estimated.
Side-effect detection
Every test checked against every requirement — regressions surface with zero extra effort.
100% coverage
Auto-generated vectors close the gaps to full requirements coverage.
100% Proof
A guarantee over all inputs and calibrations.
Prove it on your own code.
An evaluation license includes a launch workshop with our engineers — set up on one of your real requirements, end to end.