Pilots
Shadow mode first. Nothing touches production.
A pilot that controls a production decision on day one is not a pilot, it is an unmanaged change. EcoKure runs alongside your workflow, produces evidence packs, and controls nothing until you have seen what it would have done.
Method
Six steps, and the fifth one is the point
01
Scope one workflow. Named, with its start and end points, and the systems that are explicitly out of scope written down.
02
Map the dependencies. Source evidence, governing controls, decisions, approvals and reviewers, agreed with you rather than assumed by us.
03
Measure the baseline. What the current process costs in time and review effort, taken before we touch anything.
04
Run in shadow. EcoKure observes and produces evidence packs. It controls no production decision.
05
Compare against pre-agreed criteria. Set before the pilot begins, including what would count as failure. This is what separates a pilot from a demonstration.
06
Decide. Proceed, extend, revise or stop, with the criteria for each fixed in advance so the decision is not argued afterwards.
A pilot report without failures in it is not a pilot report
Every report we produce includes what did not work, the cases the system declined to decide, and the assumptions that turned out to be wrong. It is written to be read by a board or a risk committee, which means it has to survive someone looking for the weak part.
Measurement
What gets measured, and why each one matters
| Metric | What it tells you |
|---|---|
| False-pass rate | Whether the system can be trusted at all. Everything else is secondary to this. |
| False-block rate | Whether production will tolerate it. A safe system nobody can work with is not deployed. |
| Abstention rate | Whether determinism is being bought at the cost of usefulness. |
| Affected versus preserved accuracy | Over-flagging destroys the economics as surely as under-flagging destroys the safety case. |
| Replay reduction | The commercial argument, in your numbers rather than ours. |
| Review workload | Whether the human cost of the exceptions is affordable in practice. |
| Deterministic replay consistency | Whether a third party can reproduce a result. If not, nothing else is verifiable. |
| Tamper-detection rate | Whether the evidence is worth signing. |
| Time to evidence release | Whether the workflow gets faster or slower overall. |
| Integration time | Whether delivery can be repeated, or whether every deployment is bespoke. |
The template
Twenty-five fields, agreed before anything starts
A field left blank is a field that gets argued about later. We complete this with you, and you keep it whether or not the pilot proceeds.
| # | Field | What good looks like |
|---|---|---|
| 1 | Customer problem | One sentence, in your language, describing what currently goes wrong and what it costs. |
| 2 | Workflow boundary | The specific workflow, named, with its start and end points. |
| 3 | In-scope systems | Named systems, with owners. |
| 4 | Out-of-scope systems | Named explicitly. This field prevents more disputes than any other. |
| 5 | Source evidence | What the workflow relies on, where it comes from, how it is versioned. |
| 6 | Governing controls | The obligations, policies and internal controls that apply, with references. |
| 7 | Dependency model | How evidence, decisions and approvals depend on each other, agreed with you. |
| 8 | Required lanes | Which lanes run, in what order, and what each can and cannot decide. |
| 9 | Reviewer roles | Who is authorised to review what, and their expected time commitment. |
| 10 | Deployment model | Cloud, on your infrastructure or hybrid, with the data-residency position. |
| 11 | Security requirements | Tenancy, key management, access control, logging and retention. |
| 12 | Benchmark methodology | How the result will be measured, written down before the pilot starts. |
| 13 | Baseline | The current-state measurement, taken before EcoKure touches the workflow. |
| 14 | Success criteria | Specific, measurable, pre-agreed and signed by you. |
| 15 | Failure criteria | What would constitute a failed pilot, stated as plainly as success. |
| 16 | Abstention handling | What happens operationally when the system declines to decide. |
| 17 | Evidence-pack contents | Exactly what a pack contains, and how a third party checks it. |
| 18 | Implementation timeline | Weeks, with dependencies and who is blocking whom. |
| 19 | Your responsibilities | Data access, subject-matter expert time, review capacity, environments. |
| 20 | Our responsibilities | Integration, configuration, reporting and support during the pilot. |
| 21 | Legal and IP | NDA, pilot agreement, ownership of configurations, publicity rights. |
| 22 | Data handling | Processing terms, residency, retention, deletion, sub-processors. |
| 23 | Reporting | Cadence during the pilot, and the final board-ready report format. |
| 24 | Decision at completion | Proceed, extend, revise or stop, with the criteria for each set in advance. |
| 25 | Pathway to production | What changes between pilot and production, including who owns the risk. |
Honesty
What we tell you before you commit anything
- EcoKure is early stage and pre-revenue. No customer has yet taken a pilot through to a production licence.
- Implementation effort per customer is not yet a known quantity. We measure it during the pilot rather than quoting a number we cannot support.
- Pricing is a hypothesis. No customer has paid it, and we will say so rather than imply a market rate exists.
- We hold no certifications. Controls are built to be auditable, which is a different claim.
- If the pilot fails its own criteria, the report says so and we do not ask you to reinterpret it.
Scope one workflow
The first conversation is thirty minutes and produces the first four fields of the template. If it does not, that is a useful answer too.