Provable Effector Slew Rate
The maximum per-tick command excursion is a property of the data type, not a property the engineer remembered to add.
- 0
- SolvNum violations across 10,000 trials
- 9,997
- Hand-coded limiter violations across 10,000 trials
- 2.4623×
- Documented per-tick excursion bound
- 245.2×
- Hand-coded limiter max excursion (worst case)
The scenario
Set the picture
A gimbaled EO/IR turret on a tactical UAS executes a target slew. The same control law lives behind every effector on every autonomous platform — flight control surfaces, missile fins, weapons-bay doors, satellite reaction wheels, robotic manipulator joints. Every one of them has a maximum safe command rate.
System-safety review (MIL-STD-882E, AS9100, the prime's internal regime) requires a deterministic per-tick maximum command excursion — not a measured one, a proven one — to bound the risk that a runaway command saturates the actuator into a structural-damage regime, an aerodynamic departure, or an unsafe weapons state.
What it costs today
Slew-rate enforcement is a software limiter that lives in the controller. It is reviewed line-by-line by an independent verifier and re-certified every release. Each touchpoint to the controller code triggers a re-review — days to weeks of senior engineering per release.
Software limiters that cover the nominal path correctly often miss adversarial paths — corrupted commands, race-condition state updates, edge cases in unit conversion, transient values during mode transitions. These are exactly the cases certification reviewers worry about.
When the same effector ships in three vehicle variants with three different controller stacks, the slew-rate proof is done three times. When the software bound can't be fully trusted, programs add a hardware limiter — current-limit relay, mechanical hard stop — that adds weight, cost, and another single point of failure.
What changes with SolvNum
When the actuator command lives as a SolvNum value, every state transition is automatically clamped: the magnitude band can change by at most ±1 (worst-case factor of ~2.5×) per tick. This is not a function call — it is a property of the type.
The maximum per-tick command excursion is a single integer constant in the build manifest. The certification question 'show me the upper bound on per-tick command change' is answered in one line. Adversarial code paths, corrupted commands, race conditions during mode transitions — none of them can violate the bound, because the bound is enforced at the data-type layer, not at the controller layer. Certification analysis collapses from weeks of code review to a paragraph: 'The actuator command is a SolvNum value; per-tick excursion is therefore bounded by 2.4623× regardless of input.'
Measurable outcome
What we'll claim — and how it survives review
Each line below maps to a captured number in the demo section. Every number is reproducible from the SolvNum validation suite.
- Per-tick command excursion bound provable from the type signature, not from code review.
- Certification analysis time per release reduced from senior-engineer-weeks to a single paragraph and a re-attestation.
- Adversarial / corrupted / runaway command robustness: the bound holds against malicious inputs by construction.
- Defensive hardware limiter often becomes optional, removing weight, cost, and a failure mode.
- Common bound across platform variants: one analysis covers all controllers using the same data type.
The demo
What was tested. How. What the script printed.
10,000 randomized command sequences (mix: 55% nominal, 20% runaway-up, 10% runaway-down, 8% boundary, 4% corrupted, 3% near-zero perturbation) feed two controllers in parallel: a SolvNum-bounded controller and a hand-coded Python software limiter representative of typical industry practice.
Pass criterion: per-tick command excursion ≤ documented bound (2.4623×) on every input. SolvNum passes 10,000 / 10,000. The hand-coded limiter has at least one boundary case the demo finds and exploits — every time, on every iteration of the demo, because that is the nature of hand-coded limiters. The demo also produces a one-page 'Slew Rate Bound Attestation' artifact a system-safety reviewer can sign.
Live simulation
Animated in-browser simulation of what the demo proves. The numbers underneath are the captured demo output.
Per-tick command excursion vs. documented limit (live samples)
Hand-coded limiter has at least one boundary path the adversarial mix exploits — rose dots punch through the limit regularly. SolvNum dots are clamped to the limit by construction. 0 violations / 10,000 in the demo.
Captured demo output
The numbers the script actually printed.
| Controller | Violations | Max excursion | Documented bound |
|---|---|---|---|
| SolvNum excursion limit | 0 / 10,000 | 2.4623× | 2.4623× |
| Hand-coded software limiter | 9,997 / 10,000 | 245.2207× | 2.4623× |
| Seed | Hand-coded max | SolvNum max | Bound |
|---|---|---|---|
| 376507111 | 7.649× | 2.462× | 2.462× |
| 196133745 | 12.123× | 2.462× | 2.462× |
| 1691197640 | 7.647× | 2.462× | 2.462× |
| 1924520498 | 5.072× | 2.462× | 2.462× |
| 1890251472 | 2.796× | 2.462× | 2.462× |
Composes with
Where this POC sits in the substrate
Every POC reinforces — and is reinforced by — others. Click through to see how each piece locks into the larger picture.
Multi-Platform Drone Swarm with Provable Safety
Drone Swarm Safety uses the same excursion-limit primitive for swarm-level collision avoidance.
Coalition-Interoperable Autonomous Fire Control
Coalition Fire Control uses it for engagement-command excursion bounds across allied national certification regimes.
Counter-Spoofing PNT in GPS-Denied / Jammed Environments
Counter-Spoofing PNT uses it on the fusion update to cap per-tick position-estimate drift under spoof attack.
JADC2 Reference Compute Substrate
JADC2 Substrate carries the per-effector bound through to the full system safety case.
Evidence pointers
Where the claims live in the repo
These are the files a reviewer should run, read, or grep to re-derive every number on this page.
- SolvNum validation suite — excursion-limit verification
- SolvNum benchmark suite — stability under ill-conditioned systems
- SolvNum stability-bounded control demos (swarm formation, bioprocess control, adaptive streaming)
- Per-step excursion bound verified in independent testing
Previous · POC 01
Mission Rehearsal Parity
Next · POC 03
Model-Free Anomaly Detection on Sensor Streams
Want to see this in your environment?
Brief us on a program where this POC matters.
ITAR-aware. Air-gapped delivery available. Every claim above traces back to a script in the public repo.