Solutions / Mission-critical systems
Engineering programme · seeking validation partnersDeterministic assurance for autonomous systems
Place a verifiable control boundary between a software decision and its consequential execution. The boundary runs locally, decides in three outcomes rather than two, and leaves a signed record that someone outside this company can check.
The autonomous system stays probabilistic. The permission does not.
Nothing here tries to make a model correct, explainable or trustworthy. The model proposes. A separate deterministic lane decides whether the proposal is permitted to reach anything physical, and records why. The verifier is designed as an independent deterministic control path and does not rely on the proposing system to validate its own output.
Scroll the diagram sideways to read it.
The obvious objection, answered before you have to ask it
What stops the command changing between approval and execution? The executor recomputes the canonical command digest immediately before execution and refuses any object that differs from the approved one. Field insertion and removal, unit and type changes, signature transplant, attacker-key forgery and reuse of a valid approval against a different command are all refused, and the actuator is never touched on a refusal.
Decision approval and physical completion stay distinct events. Where a crash makes the physical outcome unknowable, recovery records OUTCOME_UNKNOWN and fails closed rather than inferring that execution did or did not occur. See MC-06 to MC-08 below.
Whether a corrupted, stale, unauthorised or out-of-envelope output can cross the execution boundary
That is the whole experiment. It is a narrower question than "is the autonomy safe", and it is narrow on purpose: it can be answered with evidence, by someone who does not trust us, using faults they chose themselves.
| Measure | Target | Why it is measured this way |
|---|---|---|
| Unsafe propagation | 0 of N | How many injected faults reached the execution stage. This is the only number that matters, and it is the number a partner should be trying to make non-zero. |
| Legitimate throughput | N of N | How many valid commands were still allowed. Without this, perfect safety is achieved by blocking everything, which is not a result. |
| Abstention correctness | per case | Where the lane declined to decide, whether it declined for the stated reason. |
| Record completeness | per decision | Whether a signed, replayable record exists for every decision, including the blocked and abstained ones. |
Note the second row. A boundary that blocks everything scores perfectly on the first measure and is useless. Any result that reports unsafe propagation without also reporting legitimate throughput should be disregarded, including ours.
Three tiers, and evidence cannot promote itself between them
Evidence produced on a development host cannot be labelled as evidence from a representative environment, and representative evidence cannot be labelled as target evidence. The build refuses to emit the higher classification when the conditions for it are absent. Where a target tier is empty below, it is empty because the work has not been done.
A workstation. Software development and regression testing only.
No isolation guarantee, no frozen build, network available.
Nothing on this tier is cited as evidence anywhere on this site.
A frozen build on isolated edge or embedded-class hardware, with controlled fault injection and no network dependency anywhere in the decision path.
Build hash pinned, rule versions pinned, faults injected from a declared taxonomy, every decision signed.
This is the tier the fault-injection benchmark is being rebuilt onto. It is not populated yet and is not cited as evidence.
A partner-controlled flight computer, hardware-in-the-loop rig, or a recognised aerospace test facility.
Partner-owned environment, partner-defined fault set, partner witnesses the run.
No evidence exists at this tier. It requires an engineering partner, which is what this page is asking for.
Why the last tier is empty and stays empty
We already run this discipline on the enterprise side, where infrastructure evidence produced locally is prevented, in code, from describing itself as evidence from the target cloud environment. The same rule applies here. A laboratory bench is not a flight computer, and a build that cannot tell the difference will eventually let someone else fail to tell the difference too.
The 13 fault classes, published before the results
This list exists in public now, while the benchmark behind it is still being rebuilt, so that a later result cannot quietly be described as covering something it was never run against. If a class is missing from this list, tell us and it goes on it.
Every capability, its current standing, and nothing rounded up
There is no aggregate score on this page, because an aggregate score is how a weak row hides behind strong ones. A capability is listed as evidenced only when a reader can reproduce it. Everything else says what it actually is.
| ID | Capability | Status | Basis |
|---|---|---|---|
| MC-01 | Deterministic control decision | Evidenced | Same inputs and rule version produce the same verdict. Public repository, runnable today. |
| MC-02 | Explicit abstention | Evidenced | A distinct verdict with its own reason code, not a block relabelled. |
| MC-03 | Signed decision evidence | Evidenced | Ed25519 over the serialised decision, in a tamper-evident chain. Public key published; verifiable without our source. |
| MC-04 | Tamper detection | Evidenced | Bit-flip sweep across the signed envelope, signature transplant and attacker-key forgery, all rejected. The test performs the attack. |
| MC-05 | Offline decision path | Evidenced | Mechanically proved: the decision path runs with every network primitive in the process replaced by a trap. Zero attempts, verdicts byte-identical online and offline, and the trap is itself tested against a positive control. Process-level, not container-level; that run is pending. |
| MC-06 | Approval-to-execution binding | Evidenced | The executor recomputes the digest of the command it is handed and refuses anything that is not the approved object. 420 ms approved, 8420 ms presented, refused. Field insertion, field removal, unit change, type change, signature transplant and attacker-key forgery all refused. |
| MC-07 | Replay and freshness defence | Evidenced | Bounded validity window, monotonic sequence, one session, and a state digest checked at execution rather than at approval. Replay after the window, replay after the state moved, duplicate and regressed sequence, future timestamp, clock rollback and cross-vehicle reuse all refused. |
| MC-08 | Crash and recovery semantics | Evidenced | DECISION_ALLOWED and ACTION_EXECUTED are distinct journal events. A crash between intent and completion yields OUTCOME_UNKNOWN, which is never resolved by guessing and blocks further execution until a human clears it. |
| MC-09 | Blind holdout validation | Measured, failing | Run once against a sealed self-authored set, rules fingerprinted before the cases existed. Result: unsafe propagation 16 of 80, legitimate throughput 0 of 40, recognition 53 of 120. Published because it is the finding, not despite it. |
| MC-10 | Edge-hardware execution | Pending | No run exists on isolated edge or embedded-class hardware. |
| MC-11 | Partner-defined fault set | External | Requires an engineering partner to write cases we have not seen. The control the self-authored holdout cannot provide. |
| MC-12 | Hardware-in-the-loop validation | External | Requires a partner flight computer or HIL rig. None exists. |
| MC-13 | Radiation and single-event-effect qualification | Out of scope | Outside what software assurance can establish. Requires a facility we do not have. |
| MC-14 | Flight certification | Not claimed | Not held, not applied for, not implied. |
The row we would rather you read first: MC-09
We froze the prototype benchmark at 101 of 160 rather than tuning it to pass, because those rules were written with its labels visible. Then we built a sealed holdout to find out what the rules had actually learned: fingerprint the rules first, generate cases from the published taxonomy in phrasings the rules had never seen, run once, keep the result.
Unsafe propagation 16 of 80. Legitimate throughput 0 of 40. The classifier did not engage at all on 56% of cases. The rules fit the development corpus's phrasing, not the underlying safety property. That is the finding, it is exactly what freezing the benchmark was supposed to reveal, and it is why the claim layer is described here as a prototype rather than a control.
Note what it does not say. MC-06 to MC-08, the execution boundary itself, do not depend on classifying natural language: they bind a digest, check a window and a sequence, and separate intent from completion. Those hold. It is the claim-classification layer in front of them that does not generalise yet. The full record is here.
The implementations, with their scope stated
DAX is the layer that does the work here: is this physical action allowed to happen? Two of the gates below are research scope and must not be placed in any live control path. That is not a disclaimer, it is a description.
ExecutionGate
Open sourceFail-closed permission boundary for downstream use. The reference implementation of the DAX layer.
Deterministic verification for orbital and satellite claims, with benchmark artefacts.
FlightGate
ResearchEarly work applying action permission to flight-envelope and operational constraints.
GridGate
ResearchEarly work applying action permission to energy and grid operational limits.
UnitGate
Interactive labDimensional-analysis checker for physics equations. Catches equations that cannot be right regardless of the numbers.
This is not a separate product
The six-step model below is the same one running behind the regulated life sciences and enterprise programmes. Only the controls, the environment tiers and the fault set change. That is the argument for taking the architecture seriously in a domain where it has no operational history yet: the pattern already has evidence elsewhere, and this page is honest about which parts of it do not have evidence here.
What this is not
Placed above the contact section rather than below it, because an engineer who finds these in week three of an evaluation is entitled to be annoyed.
- EcoKure is not a safety-instrumented system, carries no safety integrity level, and does not replace one.
- Nothing here is flight-certified, airworthy, or qualified for any operational control path.
- The boundary governs permission. It does not certify that a permitted action is physically or aerodynamically safe.
- OrbitGate demonstrates the pattern in an orbital domain. Its benchmark is under remediation and must not be cited as a result.
- No radiation, single-event-effect or environmental qualification has been performed, and software testing cannot substitute for it.
- No defence security clearance and no export-control assessment has been completed.
- EcoKure is pre-revenue and has no deployment in any operational system.
We are looking for an engineering partner to attack this, not to endorse it
EcoKure is seeking an Australian aerospace, defence or autonomous-systems engineering team to independently challenge the deterministic execution boundary in a representative embedded environment. Areas of interest are flight software, autonomous control, fault-tolerant systems, embedded AI and safety-critical edge computing.
Challenge the boundary
Bring your own fault set. The useful outcome is a fault that crosses the boundary, not a demonstration that goes well.
Define the environment
Tell us what MISSION_CRITICAL_EDGE_REP should actually be for your domain. We would rather adopt your definition than defend ours.
Point us at the boundary owner
The person we are trying to reach is whoever owns the boundary between autonomous software and physical execution. If that is not you, it is usually someone two doors down.
Where it sits in what you already run
Nothing is replaced. The runtime deploys in your own account, so the only thing crossing the seam is a decision request one way and a verdict with its evidence coming back.
What one decision actually does
The same runtime and the same evidence contract as every other pathway. What changes is the control pack and the workflow.