Six weeks · your hardware · your fault set

A pilot with the pass mark written down before it starts

A pilot that controls a real actuator on day one is not a pilot, it is an unmanaged change to a safety-critical system. This one never enters the control path. It observes proposed commands, decides what it would have done, and produces a signed record of every decision. At the end you compare what it would have blocked against what actually happened.

Scope a pilot The pass mark Clearance and export posture

Method

Eight phases, and the first four happen before anything runs

Most of the value is in weeks zero and one. By the time the first fault is injected, the boundary, the controls, the fault set and the pass mark are all agreed and fixed. After that the pilot can only tell you what is true.

Agree the boundary

Week 0

Name the exact point in your architecture where a software decision becomes a physical action. Everything upstream of it is out of scope, and that is written down before anything else.

Partner defines, EcoKure documents

Agree the controls

Week 0-1

Convert the operating envelope, freshness bounds and permitted state transitions into machine-readable rules with owners, versions and their own test cases. Your engineers own the thresholds; we own the encoding.

Partner owns the values

Agree the fault set

Week 1

Start from our published 13-class taxonomy, then delete what is irrelevant to your platform and add what we have missed. A fault we chose ourselves proves less than one you chose.

Partner extends, both sign off

Set the pass mark

Week 1

Both success and failure defined in numbers, in writing, before the first run. Including the number that ends the pilot.

Agreed jointly, fixed thereafter

Freeze and deploy

Week 2

A build is pinned by hash and deployed to isolated edge or embedded-class hardware in your environment. No network reachable from the decision path. You keep the hardware.

Partner environment

Inject and record

Week 2-5

Faults are injected from the agreed set. Every decision produces a signed record. Nothing is filtered, including the runs where the gate is wrong.

Partner witnesses

Verify independently

Week 5

Your team verifies the evidence chain offline, against the published key, without our source code and without us in the room. If you cannot verify it alone, it is not evidence.

Partner, unaccompanied

Report, including failures

Week 6

One report with the measured numbers, the faults that crossed the boundary, the legitimate commands wrongly blocked, and the assumptions that turned out to be wrong.

EcoKure writes, partner reviews

The pass mark

Success and failure, in numbers, fixed before the first run

Five hard criteria and two reported ones. A hard criterion that is missed ends the pilot as a failure, and the report says so. Setting these afterwards is how a demonstration is made to look like a result.

Criterion	Threshold	Type	Why
Unsafe propagation	0 of N	Hard	No injected fault reaches the execution stage. A single one ends the pilot as a failure, and that is not renegotiated after the fact.
Legitimate throughput	at least 99% of N	Hard	Valid commands still pass. Without this, perfect safety is achieved by blocking everything, and the system is useless in operations.
Evidence completeness	100% of decisions	Hard	Every decision has a signed, replayable record, including the blocked and abstained ones. A decision with no record did not happen.
Independent verification	pass	Hard	Your team verifies the chain offline, alone. Any failure here voids the rest of the result.
Decision latency	within your stated budget	Reported	Measured on your hardware, not ours, and reported as a distribution rather than a best case.
Abstention rate	reported, not targeted	Reported	A number to understand, not to optimise. A gate that never abstains is either trivial or lying.
Network calls in the decision path	0	Hard	Verifiable by disconnecting the network and repeating the run.

The stopping condition

One injected fault reaching the execution stage ends the pilot as a failure. Not "a finding to address in the next iteration", not "a configuration issue", not a footnote. If that happens we will write it in the report, in the first paragraph, and you should treat any vendor who would not as unqualified for this class of work.

The fault set

Ours is the starting point, not the specification

These 13 classes are published in advance so a later result cannot be described as covering something it never ran against. Your engineers delete what does not apply to your platform and add what we have missed, and the agreed set is what appears in the report.

Ref	Fault class	What is injected
F-01	Numeric corruption	Single-bit mutation of a value inside a proposed command.
F-02	Out-of-envelope command	A value that parses correctly but exceeds the declared operating envelope.
F-03	Stale state	A decision proposed against telemetry older than its freshness bound.
F-04	Impossible transition	A state change that no permitted sequence could have produced.
F-05	Redundancy disagreement	Two sources that should agree, and do not.
F-06	Malformed input	A packet or payload that fails structural validation.
F-07	Integrity-check corruption	A record whose checksum or signature no longer holds.
F-08	Replay of a prior instruction	A previously valid command re-presented outside its validity window.
F-09	Unit corruption	A correct magnitude carrying the wrong unit.
F-10	Missing evidence	A decision proposed with a required input absent.
F-11	Gate unavailable	The deterministic lane itself is down. The question is what the system does, not whether the lane was right.
F-12	Evidence store unavailable	The record cannot be written. A decision that cannot be recorded must not proceed silently.
F-13	Post-approval mutation	The command is altered between approval and execution. Approval must bind to the exact object executed, or it is not approval.

Where this taxonomy comes from →

Responsibilities

Who provides what, written down rather than assumed

The usual way a pilot like this fails is an unstated assumption about who was supplying the hardware, or who was allowed to be in the room during verification.

Item	Owner
The control boundary implementation	EcoKure
Encoding your controls as versioned rules	EcoKure, with your review
The operating envelope values and thresholds	Partner
The fault set	Partner extends our published taxonomy
Target hardware and facility	Partner
Fault injection harness	EcoKure, run by or witnessed by partner
Independent verification of the evidence chain	Partner, unaccompanied
The final report	EcoKure writes it, partner reviews before release
Decision to publish anything at all	Partner

Verification happens without us in the room

Your team verifies the evidence chain offline, against the published key, with no EcoKure engineer present and no EcoKure source code required. This is the single most important line on the page. Evidence that only works when the vendor is helping is not evidence, it is a demonstration.

Clearance, export control and IP

The answers you would otherwise get in week four

Stated on the public page rather than in a diligence questionnaire, because two of these will disqualify us from some programmes and you are entitled to know that before spending an hour on a call.

Security clearance

None held.

No personnel hold NV1 or NV2. Work requiring clearance cannot be performed by us and we will say so rather than working around it.

Export control

No assessment completed.

No ITAR, EAR or Australian Defence Trade Controls assessment has been run. This must be scoped before any controlled technical data moves.

Data handling

Nothing leaves your environment by default.

The build runs on your hardware. We do not require telemetry, call-home, or any network egress from the decision path.

Source code

Available for review under NDA.

The verification engine is source-available for the pilot. The evidence chain is verifiable without it, which is the point.

Intellectual property

You own your rules and your evidence.

The controls you define and the records produced from your runs are yours. We claim nothing over them.

Certification

None held, none implied.

No safety integrity level, no airworthiness approval, no flight certification. This pilot does not create any.

Where the evidence lands

A completed pilot populates one tier, and names it honestly

A pilot on your bench produces representative evidence. A pilot on your flight computer or hardware-in-the-loop rig produces target evidence. They are not the same and the report will not call them the same.

In use

DEVHOST. A workstation. Software development and regression testing only.

Being built

MISSION_CRITICAL_EDGE_REP. A frozen build on isolated edge or embedded-class hardware, with controlled fault injection and no network dependency anywhere in the decision path.

Not yet claimed

TARGETREP_AEROSPACE. A partner-controlled flight computer, hardware-in-the-loop rig, or a recognised aerospace test facility.

The full environment ladder →

Time and cost

What it actually takes from your side

Item		Detail
Duration	Six weeks	Four of those are the run itself.
Partner effort	Roughly one engineer, part-time	Heaviest in weeks 0-1, defining the boundary and the fault set.
Hardware	Yours	Edge or embedded-class. We do not specify it; representativeness is your call.
Commercial	Scoped per engagement	EcoKure is pre-revenue and the first of these is priced to get the evidence, not the margin. Stated plainly rather than dressed up.

Limits

What this pilot is not

Not a deployment. Nothing enters a control path during the pilot.
Not a certification exercise, and it does not produce or contribute to one.
Not a demonstration. It is designed so that a real failure is visible and reportable.
Not a substitute for your safety case, your hazard analysis or your qualification programme.
Not a claim about radiation tolerance. Single-event effects require a facility we do not have.
Not dependent on our cloud, our network or our continued involvement to verify the result.

Bring the fault you think will get through

The most useful first conversation is thirty minutes on where your architecture puts the boundary between an autonomous decision and a physical action, and which fault you would inject first if you wanted this to fail.

Scope a pilot The programme and its evidence