Technology & research
We measure our own failure modes before claiming we've solved them.
Every claim on this page is backed by a controlled fault-injection benchmark, run against real model checkpoints where possible, engineered specifically to demonstrate the blind spots of simpler approaches rather than just assert them.
This isn't an internal design doc dressed up after the fact, it's the reference implementation of a published, peer-reviewed method. Full citation in References.
What reliable, trustworthy edge AI requires
Seven principles we use to evaluate ourselves, and would ask any vendor to answer to.
This isn't a list of our own features dressed up as an industry standard. It's the checklist we think anyone deploying AI in a system that can't afford to fail should be able to run against whatever they choose, us included. Where we fall short of one of these today, we say so.
Independent
The monitor cannot share a failure mode with what it monitors. Different weights, different training data, ideally a different architecture family entirely, if the same corrupted memory page, the same adversarial input, or the same blind spot can take out both, it isn't independent oversight, it's the same single point of failure wearing two names.
Verifiable
A system that certifies its own health against its own memory of its own past state has no real anchor. Integrity has to be checked against something external, a fresh fingerprint from a fleet service, a federated resync, a signed release, never generated on-device from nothing.
Fast enough to act, not just observe
A dashboard that shows a problem five minutes after it happened is observability, not safety. If the system can take a physical or consequential action, the monitor has to run inline, in the same loop, fast enough to gate that action before it happens.
Explainable at the point of failure
An anomaly score tells you something is wrong. A diagnosis tells you what to do about it. "Trust dropped to 0.11" is not actionable on its own; "tier0_hash_mismatch, quarantine and resync" is.
Bounded and reversible
Every automated fix must be validated against held-out evidence before it is trusted, and every accepted state must join a bounded, revertible history. An unbounded self-modifying system is not self-healing, it is an unaudited one.
Escalates, doesn't mask
A fault that keeps recurring after repeated automated remediation has to stop retrying and reach a human. A system that quietly re-heals the same fault forever is hiding a problem, not solving it.
Improves the fleet without centralizing raw data
Cross-unit learning should happen through weighted, validated aggregation of model updates, not by shipping raw sensor data to a central store. Privacy and fleet-wide improvement are not a trade-off if the architecture is federated from the start.
This vocabulary is deliberately close to the NIST AI Risk Management Framework's trustworthiness characteristics and ISO/IEC 42001's AI-management-system principles, not because we hold either certification today, but because a shared language is what lets a safety or procurement review actually compare vendors instead of comparing marketing pages.
Proven beyond vision, not just argued
"Any AI-based system" is a demonstrated claim, not an aspirational one.
The self-healing core, hardware check, behavioral self-test, fault localization, healing, and federated learning, is built behind a single domain-adapter interface that separates it from the handful of genuinely domain-specific decisions: how a feature vector is built, what an independent structural-plausibility check looks like, how a repeatability canary runs, how local healing retrains. Everything else underneath that interface never changes.
Vision
The perception stack described throughout this page. Its structural-plausibility check is spatial consistency, segmentation geometry a forward-facing camera could never actually produce.
A real transformer-based LLM
Built specifically to prove the interface is genuinely pluggable, not vision-shaped in disguise. Its structural-plausibility check is degenerate-repetition detection, a real language-model failure mode with no vision equivalent. Its repeatability canary compares greedy-decoded token sequences instead of a geometry check. Its local healing path is real next-token cross-entropy fine-tuning. Run end-to-end: a real small transformer, real backpropagation, a real injected weight corruption correctly caught, through every seam of the same pipeline, feature construction, hardware check, self-test, localization, local healing, and rollback.
This doesn't mean every domain works identically well out of the box, a structurally different system's novelty boundary is only approximately located until its own trust-decision core is fine-tuned on that system's labeled data, stated plainly rather than implied to be more proven than that. It means the architecture's domain-agnostic claim has been tested against a second, genuinely different kind of model, not just asserted about a second kind of model nobody has tried.
Benchmark design
Five fault types, three arms, measured the same way every time.
Every trial compares three arms: no self-healing at all, a reconstructed baseline representative of a simpler local-checksum approach, and the full tiered architecture, so the value of each layer is visible, not assumed.
| Fault type | What it simulates | What it proves |
|---|---|---|
| Hardware fault, obvious | weights pushed far out of range | Hash check and legacy checksum both catch this, the easy case. |
| Hardware fault, subtle | weights permuted, magnitude sum unchanged | Only a real cryptographic hash catches this. A sum-of-magnitudes checksum is structurally blind to it. |
| Behavioral fault | compute path broken, weights fully intact and hash-verified | Only the behavioral self-test suite catches this. A weight hash is structurally blind to it, by definition there is nothing wrong with what is stored, only with what is computed. |
| Genuine domain shift | sustained, real distribution change | Confirmed only after sustained-drift detection, never on a single frame. |
| Transient noise | one noisy frame, not sustained | Measured as a false-trigger rate, the system should not react to this at all. |
What we measure
Detection rate, false positives, localization accuracy, and how long recovery takes.
Detection rate
Per fault type, across repeated trials at a fixed, known injection point.
False-positive rate
Measured on clean runs and on transient noise specifically, lower is strictly better.
Localization accuracy
Does the diagnosis match the actual injected fault, only meaningful for an architecture that localizes at all.
Recovery latency
Frames from fault onset to a verified, trusted state, and output quality before/after a heal cycle.
Design principles
No fabricated numbers
If a metric can't be honestly measured for a given scenario, for instance, accuracy metrics on a live flight with no ground-truth anomaly label, it's reported as unavailable, not estimated or faked to fill a chart.
Real checkpoints, real substitutes clearly labeled
Benchmarks prefer real, trained models automatically when available, and fall back to small, explicitly-labeled substitutes only when they aren't, so results are never silently generated from a toy model.
What "154x fewer parameters" actually compares
76,842 trust-layer parameters against 11,689,512, the standard, well-known parameter count of a ResNet-18 classification backbone specifically, not a combined multi-model stack and not the smaller Fast-SCNN segmentation head. Reference deployments in this project audit both; the ratio quoted site-wide is against the larger of the two, so it's never inflated by picking the smaller comparison.
References
Rahbari, D., Daneshtalab, M., & Jenihhin, M. (2026). Aux-AI: A Federated Independent Oversight Framework for Trust-Aware Industrial Autonomy.
The paper this system implements, not a whitepaper written to describe it after the fact. Every tier, routing decision, and the federated aggregation scheme on this page trace back to it.
- Bansal, A., Kim, H., Yu, S., Li, B., Hovakimyan, N., Caccamo, M., & Sha, L. (2022/2023). Perception Simplex: Verifiable Collision Avoidance in Autonomous Vehicles Amidst Obstacle Detection Faults. arXiv:2209.01710.
- Mehmood, U., Sheikhi, S., Bak, S., Smolka, S. A., & Stoller, S. D. (2021/2022). The Black-Box Simplex Architecture for Runtime Assurance of Autonomous CPS. arXiv:2102.12981.
- Poudel, R. P. K., & Liwicki, S. (2019). Fast-SCNN: Fast Semantic Segmentation Network.
- Cordts, M., et al. (2016). The Cityscapes Dataset for Semantic Urban Scene Understanding.
- Page, E. S. (1954). Continuous Inspection Schemes. Page-Hinkley sequential change detection.
- Blanchard, P., et al. (2017). Machine Learning with Adversaries: Byzantine Tolerant Gradient Descent.
- NIST AI RMF 1.0 (2023) and ISO/IEC 42001:2023, the trustworthiness and AI-management-system vocabulary this page aligns its claims to.
Where the monitor actually lives
Not one placement. Three, each doing a job the others structurally can't.
This isn't a compromise, it's the pattern that both the MLOps-monitoring literature and the safety-critical robotics literature converge on independently. A single placement is never enough: something has to be fast enough to gate an action, something has to see across the whole fleet, and something has to produce the evidence a safety or procurement review will actually ask for.
Every inference, next to the model
Tier 0, Meta, and Tier 1 run in-process, fast enough to gate the actuator before a bad output is ever acted on. This is the same principle formalized in runtime-assurance research for autonomous cyber-physical systems, pairing a fast, unverifiable model with a monitor that can intervene in real time, an idea academic work calls the Simplex and Perception Simplex architectures (see references). The honest difference: those architectures typically wrap a provably-bounded classical detector; ours is a learned, statistical trust layer, traded for the ability to watch any model rather than one with a hand-derived safety proof. Closing that gap for the single highest-stakes failure mode is on our roadmap, not a solved problem.
A dedicated, federated service
The federated coordinator and fleet-stats endpoint run asynchronously, aggregating trust across every connected unit, too slow and too expensive to run per inference, but this is where a quarantined node's fresh, verified reference actually comes from. Standard MLOps monitoring architecture converges on the same split: a lightweight in-process check paired with a dedicated service for anything that needs a wider view.
A gate before release, not after
The fault-injection benchmark on this page runs as a release gate, not a one-off report, producing the detection-rate, false-positive, and recovery-latency numbers a safety review or an AI governance framework will ask for before anything ships. Too slow for every inference, exactly right for every release.
Proven today
What's actually running, benchmarked, and demonstrated, not just designed.
- Offline evaluation and benchmarking against a labeled dataset, with real, measured detection and localization accuracy, scored alongside several published anomaly-detection and fault-tolerance baselines, not just an internal comparison.
- A working reference implementation of black-box auditing with a genuine, tiered self-healing layer.
- A live, real-time demonstration of the complete pipeline against a simulated flight, including an on-demand live fault injection for demonstration, detection and recovery, observable as it happens.
- A documented, versioned contract for attaching an arbitrary model for evaluation or demonstration.
- A domain-agnostic core, proven end-to-end against a second, genuinely different domain, not a renamed copy of the first.