Proof you can check.
Every public claim has a class, a record and a boundary. Start with the result, then inspect the evidence behind it.
Evidence / Two distinct questions
Is it intact? Is it still applicable?
Follow a signed record through a source change and see why integrity and current validity need separate checks.
Select an illustrated object to inspect its role.
01 / 03
The record still matches its fingerprint.
Integrity checks detect tested changes to a record. An intact signature links the record to the signed content.
Published local integrity checksAuthenticity does not establish scientific correctness, complete dependencies or current authority.
Label the strength.
The strongest class is reserved for claims someone outside EcoKure can check.
View all six evidence classes
You can check this yourself, today, without our help and without our source code.
Measured by us, reproducible by us, not yet checked by anyone else. Never described as validation.
Tested by a third party who has integrated the system. Stronger than our own result, weaker than independent, because the tester has an interest in the integration working.
Something that has actually happened between us and a third party, stated with its exact limits.
Load-bearing for a decision but not yet proved. Listed so nobody mistakes it for a result.
We published it, found it did not hold, and retracted it. Left visible on purpose.
Three checks.
Follow the claim to its record, verify it independently and read the limit.
Find the claim
Start with the exact capability or result.
Check the record
Open the supporting evidence and verify it.
Read the limit
Decide what it does—and does not—support.
View the full six-step evidence path
What is being said?
Start with the exact capability or measured result.
How strong is it?
EVIDENCED, MEASURED, PILOT, DESIGN ONLY or NOT CLAIMED.
What record supports it?
Open the programme row, signed pack or run result.
Can you check it?
Use the machine-readable result, verifier or public gate.
Where does it stop?
Read the boundary before treating a result as production evidence.
What happens next?
A bounded pilot turns the open question into customer-owned evidence.
Where each programme's evidence actually stops
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.
Enterprise assuranceTARGETREP_AWS
The target-representative AWS run is now recorded alongside the local capability register. It is target-environment evidence, not production customer validation or certification.
Life sciencesPARTNER_INTEGRATION
The strongest external evidence we hold, and still an integration audit by the integrating party rather than an independent one.
Mission-critical systemsMISSION_CRITICAL_EDGE_REP
The newest programme and the one with the least evidence. The fault-injection benchmark is the honest weak point and is described as such on the programme page.
Open buyer readiness and measured benchmark detail
Enterprise readiness, in one place
A compact snapshot of what has been measured, what has passed its own test, and what still needs an authorised customer environment or independent review. It is designed to make the next conversation concrete.
- PASSSynthetic enterprise validation20 of 20 scenarios; zero critical failures
- PASSSynthetic adversarial validationNegative controls, tamper rejection, rollback and bypass attempts exercised
- PASSFull tenant control loop16 of 16 checks passed
- MEASUREDLive AWS KMS capacity curve2,000 sign/verify operations; synthetic payloads
- MEASUREDRepeated live AWS KMS stability1,500 repeated sign/verify operations; worst p95 62.94 ms
- MEASUREDLive runtime concurrency boundary600 of 600 read-only requests; 40.225 requests/sec at 32 workers
- PASSAWS runtime IAM policy shapeRead-only policy inspection; runtime task evidence is recorded separately.
- PASSCustomer-owned image and AWS deployment authorityScoped ECS/ECR/CloudWatch authority and a scanned, immutable customer ECR digest are recorded; the supervised ECS task and smoke are recorded separately.
- PARTIALCustomer-owned AWS six-check smokeThe supervised synthetic smoke passed the runtime, signing, storage, backup/restore, headers and controlled decision paths. Tenant isolation across independent principals and external HTTPS ingress remain review gates.
- PASSDependency lock and SBOM43 locked runtime components inventoried
- PASS NO KNOWN VULNERABILITIESLock-bound vulnerability scanNo known findings returned for the exact package lock at scan time
- PASS RELEASE INPUTS HASHEDRelease input integrity manifestSource and build inputs hashed; the customer image digest is recorded separately.
- PENDINGProduction isolation and recovery 3/3 measured checks passingValidate tenant isolation, backup/restore, RTO/RPO, monitoring and incident procedures in the target environment.
- Application store on PostgreSQL, not a local file
- Protected corpus on PostgreSQL, not a local file
- Corpus and application stores separately configured
Green here does not close the gate. These are the parts a machine can decide; the gate still closes on the evidence named below.
- PENDINGExternal security reviewComplete threat-model review and penetration testing against the deployed configuration.
Closes only on an independent tester. Self-testing cannot close this one by definition, which is the whole point of it.
- PENDINGReal shadow pilotRun one bounded workflow with customer data boundaries, reviewers, SLOs and a signed go/no-go record.
Closes on a real customer workflow, their reviewers and their data boundary.
- PENDINGOperational services 3/4 measured checks passingConfirm production email delivery, canonical DNS, SSO registration and support/retention arrangements.
- Canonical HTTPS base URL and SSO redirect
- Transactional email (Resend API or SMTP) configured
- Reviewer SSO registered
- Production secrets present, no placeholders
Green here does not close the gate. These are the parts a machine can decide; the gate still closes on the evidence named below.
Complete synthetic pilot path
One bounded BioChangeGate workflow was built and independently chain-verified 500 times: 1.2196 ms p95 in-process, 1076.63/s, with 0 errors.
This is a local synthetic capability measurement. It excludes network, database, KMS and customer integration latency.
Open the machine-readable result →Re-running only what changed scale benchmark
A deterministic synthetic benchmark measured full replay against dependency-scoped replay at 100,000, 1,000,000 and 10,000,000 decisions. The measured runs avoided 9,830,508 records at the 10m tier and completed with matching forced-failure resume digests.
Measured local capability only. PostgreSQL, 30–60 minute stability, randomized crash schedules and Temporal/Camunda comparisons remain unrun. This is not a production SLO, certification or customer result.
Open the machine-readable benchmark →Customer-facing HTTP path
The same synthetic EvidencePack route was exercised over local HTTP 200 times: 26.908 ms p95, 70.0/s and 0 errors.
Loopback runtime evidence only. It excludes customer network, database, KMS and deployment topology.
Open the machine-readable HTTP result →APRA workflow scenario coverage
AML/CTF, KYC, safer-gambling, remediation and credit-control report paths each completed 30 hosted HTTP runs with 0 errors overall. Each report returned a matched scenario and integrity digest.
These are synthetic workflow fixtures. EcoKure does not make AML, KYC, credit or regulatory decisions, and this is not APRA certification or a production SLO.
Open the scenario coverage result →Resumable selective-replay worker
A local SQLite reference worker processed 2,000 synthetic decisions/job across 5 runs: 41.9282 ms p95 and 49,572 records/sec. A forced crash resumed on a second attempt without replaying completed results.
This proves the worker contract against synthetic data. It is not evidence of a customer PostgreSQL queue, production SLO or regulatory compliance.
Open the machine-readable worker result →Adversarial enterprise validation
9 synthetic red-team scenarios passed with zero critical failures, including stale-release races, conflicting controls, non-replayable evidence, tamper rejection, rollback lineage, offline reconstruction, unauthorised promotion attempts, the full tenant control loop and replay-worker crash recovery.
This is measured local synthetic evidence against isolated test adapters. It is not a penetration test, production approval, regulatory certification or customer-runtime SLO.
Open the machine-readable validation result →Enterprise validation suite
20 of 20 synthetic red-team scenarios passed with zero critical failures. The suite covers AML/CTF and KYC change races, safer-gambling deficiencies, source corrections, manipulated assumptions, conflicting controls, unauthorised overrides, missing evidence, tamper rejection, rollback, simultaneous changes, 10,000-record impact analysis, offline recovery, tenant boundaries and resumable replay.
This is measured local synthetic evidence designed to expose failure modes. It is not a penetration test, production approval, regulatory certification or customer-runtime SLO.
Open the full scenario matrix →Deployed runtime capacity probe
400 of 400 concurrent synthetic GET requests completed with 0 errors across liveness, signed EvidencePack, enterprise validation and OpenAPI routes. Aggregate throughput was 24.532 requests/sec.
Live Railway synthetic read-only measurement. This is diagnostic capacity evidence, not a customer SLO, penetration test, production approval or proof of customer database/KMS/queue performance.
Open the machine-readable capacity result →Deterministic replay matrix
5 repeated runs of the 20-scenario enterprise matrix and signed synthetic EvidencePack produced identical decision and chain digests.
2000 synthetic dependency records per run. This is local repeatability evidence, not production approval, regulatory certification or a substitute for customer-environment testing.
Open the machine-readable repeatability result →Live EvidencePack publication consistency
24 of 24 read-only requests across 8 public EvidencePack endpoints completed with zero errors across 3 rounds. Canonical content digests remained stable.
Measured against the live Railway publication surface. This does not test customer data, the customer runtime, underlying database/KMS behaviour or production approval.
Open the machine-readable consistency result →Live runtime concurrency boundary
600 of 600 concurrent synthetic read-only requests completed with 0 errors at 32 workers. Aggregate throughput was 40.225 requests/sec.
Live Railway measurement across health, EvidencePack, validation and OpenAPI routes. This is diagnostic capacity evidence, not a customer SLO, autoscaling guarantee, penetration test or production approval.
Open the machine-readable boundary result →Deployed runtime concurrency profile
800 of 800 synthetic requests completed with 0 errors across four controlled concurrency levels.
Same synthetic route mix at each level. This shows the measured Railway envelope only; it is not a customer SLO, autoscaling guarantee or AWS production capacity claim.
Open the machine-readable load profile →Dependency impact at ten million nodes
An independent synthetic oracle agreed with the traversal on 6,999,998 affected nodes out of 10,000,000; 2 deliberately unknown mappings were isolated and not treated as safe.
Synthetic in-memory graph only. This demonstrates bounded impact traversal against an independent generator; it is not proof of customer graph completeness, database performance or a production SLO.
Open the machine-readable scale result →Repeated live AWS KMS stability
1500 of 1500 synthetic sign/verify transactions completed across 3 rounds with 0 errors. Aggregate throughput was 161.506 transactions/sec; worst observed p95 was 62.94 ms.
This measures the customer-controlled KMS boundary from the benchmark host. It is not a full application SLO, production approval, quota guarantee or customer quote; the modeled reference is US$0.00001515 per assurance transaction.
Open the machine-readable stability result →High-concurrency stress boundary
A repeated 32-worker run completed 1500 of 1500 synthetic transactions with 0 errors. Throughput was 29.034 transactions/sec, with worst p95 1920.361 ms and worst p99 2109.271 ms.
This intentionally exposes a saturation boundary. It supports a production design decision around worker caps, queueing and back-pressure; it is not a customer SLO or a claim that 32 concurrent workers is an appropriate configuration.
Open the machine-readable stress result →All 23 public claims, in one table
If a claim we make anywhere else is not in this table, it should not have been made. Tell us and we will either evidence it or remove it.
Browse the full claims register 23 claims
| Claim | Class | How you check it |
|---|---|---|
| Verification is deterministic. The same input produces the same signed verdict. | Verifiable now | Run the same input through a public gate twice and compare the certificates byte for byte. |
| Every verdict is Ed25519 signed and anchored in a tamper-evident chain. | Verifiable now | Call the live endpoint below and verify the signature in your own code. The public key is published. |
| ProofBench-X: Of 1,116 ProofBench-X cases: 1,089 pass, 17 safely refuse, 10 are blocked, 0 fail. Zero certificate drift, zero model overrides accepted, zero unsafe proof claims. | Verifiable now | Clone dtl-mathgate and run the suite, or read the run file at data/benchmarks/proofbench_x_results.json. It is the benchmark we do stand behind. |
| The gates are independently auditable without our source code. | Verifiable now | The audit protocol is public. Any lab can test a gate and sign a verdict in the registry. |
| Security lanes cover ten CWE and OWASP weakness families with zero false positives against an unguarded baseline. | Verifiable now | Clone dtl-security-benchmark and run it. The corpus and the scoring are both in the repository. |
| Our own fuzzer bypassed a naive canonicalisation defence with three obfuscations, and the hardened lane then held. | Internal result | Reproducible from the benchmark repository. This is our strongest security result and it is a story about finding our own weakness. |
| DELA detected 100 of 100 selected official evidence transitions in held-out testing, with repeatable execution. | Internal result | Internal research result on a set we selected. Not independent validation, and it does not become independent by being repeated. |
| 126 integration tests pass at 100%, covering the verification layer inside a third party's platform. | Partner-verified | From the partner's audit report, which we can share under NDA. Their test suite, their environment, our engine. |
| Zero wrong answers across 1,866 correctness checks, and zero gate bypasses across 395 adversarial inputs spanning ten OWASP weakness families. | Partner-verified | Same report. Correctness-adversarial, not load-adversarial, and the distinction matters. |
| Transport failures are recorded as degraded rather than scored as valid safety abstentions. | Partner-verified | The partner's audit examined this specifically and hardened it. An outage cannot disguise itself as the system declining to answer. |
| The evidence chain survives concurrent writes from multiple processes with no duplicate or missing sequence numbers. | Verifiable now | Run the concurrency harness in our repository. It re-verifies the whole chain afterwards. |
| Metering lost charges under concurrent workers before we fixed it. | Withdrawn | Found by our own harness: 40 lost charges across 480 concurrent calls. Fixed with row-level and cross-process locking, and the harness now passes. Listed here because the defect was real. |
| A European compliance platform completed a technical review of the verification layer and integrated a first version for testing. | Relationship | A mutual NDA is executed. There is no commercial contract, no revenue, and no signed memorandum. |
| A proposal for an evidence-lineage shadow pilot was forwarded internally at a major AI research organisation for consideration. | Relationship | That is the entire status. No validation, adoption, testing or partnership has occurred, and we are awaiting any further response. |
| Five Australian provisional applications are filed: the original DTL, DEGA, DCLA and DELA filings, plus AU 2026908121 for verified semantic compilation, authority-bound execution and model-independent persistence of computational capabilities. | Relationship | Filed, not granted. No freedom-to-operate search has been run. Our own prior art note concludes the individual mechanisms are not novel and the open question is the combination. |
| Regulated organisations will pay for deterministic evidence. | Untested assumption | Untested. EcoKure is pre-revenue. This is the single assumption the whole business rests on and we will not dress it up as anything else. |
| Implementation effort per customer is low enough to support a product margin. | Untested assumption | Unmeasured. We measure it during the first paid pilot rather than quoting a number we cannot support. |
| The orbital fault-injection benchmark reproduces 101 of its own 160 expected outcomes, and 27 of the 78 cases that should block still do not block. | Withdrawn | Clone orbitgate and run the corpus yourself. We publish the shortfall rather than the corpus size, because the corpus size is not a result. No orbital benchmark figure should be cited by us or anyone else until this reproduces in full. |
| Four lanes of that benchmark now reproduce fully: command 10 of 10 and propagation 20 of 20, both from 0 and 1 respectively, with 88 new regression tests. | Verifiable now | Clone orbitgate and run the test suite: 171 tests pass, up from 83. The new tests fail against the previous commit and pass against the current one, which is the only useful way to state a fix. |
| Tamper detection on signed decision records: a bitflip sweep across the entire signed envelope, signature transplant, and attacker-key forgery are all rejected. | Verifiable now | Clone orbitgate and run the attestation suite. The test performs the attack rather than describing it, and 83 tests pass on the current code. |
| Earlier internal coding-benchmark scores. | Withdrawn | Withdrawn in full. See the retraction record below. We publish no score for that benchmark. |
| An earlier 500 of 500 result on a public software benchmark. | Withdrawn | Withdrawn after an audit found answer-key lanes active in the run. Never cited by us, and it should not be cited by anyone else. |
| A 162 of 166 security-benchmark figure carried in earlier decks. | Withdrawn | Withdrawn. It did not reproduce from the current harness and traced only to a self-audit document. The substance was fine. The number was not. |
Three ways, none of which involve us
Call the live endpoint
No account, no key. What comes back is a cryptographically signed verdict with its position in the tamper-evident chain.
Clone a gate and break it
19 gates are public repositories. Run one against your own cases and find where it is wrong. We would rather you found it than a customer did.
Sign your own verdict
The audit protocol is published. Any lab can test a gate and publish a signed result, without our source and without telling us first.
Three results we published and then withdrew
This section exists because deleting mistakes is how trust dies. Each entry states what the claim was, what we found when we checked it, and what we did. The original posts stay online beneath their retraction notices.
ProofBench-X quoted as 1,116 of 1,116, all passing
September 2026Orbital verification benchmark, 160 cases
August 2026Public software-benchmark result, 500 of 500
July 2026Security-benchmark figure, 162 of 166
July 2026Internal coding-benchmark scores
July 2026Why this is on the site rather than buried
A benchmark figure you cannot reproduce is worth less than no figure at all, because it fails the moment somebody tries. Publishing the retractions costs us three impressive numbers and buys the only thing that matters in a regulated sale: that the numbers we do publish can be trusted. If you are evaluating us, this section should carry more weight than any result above it.
What we have not answered yet
These are the questions a serious evaluator would ask. We would rather you read them here than assemble them yourself in week three of diligence.
- The orbital fault-injection benchmark does not currently meet its own expected outcomes, and no mission-critical evidence exists on representative embedded hardware.
- The claim-classification layer does not generalise beyond the phrasings it was developed against: a sealed holdout returned 16 of 80 unsafe cases propagated, 0 of 40 legitimate commands passed, and no engagement at all on 56% of cases.
- No freedom-to-operate search has been run on any of the four provisional applications.
- No independent party has yet agreed the definition of a material evidence change, which is the load-bearing definition in the whole evidence-lineage claim.
- No customer has taken a pilot through to a production licence, so willingness to pay is unproven.
- Implementation effort per customer has not been measured, so gross margin is an assumption.
- No third-party security or technical assurance report exists yet. The partner audit is an integration audit by the integrating party, which is a different thing.
- The concurrency fix is proven on the file store. The Postgres path uses row-level locking and has not yet been tested under load.
- EcoKure holds no certifications, and every control claim should be read as audit-ready rather than certified.
Why it matters
The question arrives years after the decision.
By the time a regulator, an auditor or a court asks why one decision went the way it did, the people who made it have moved on and the systems have changed underneath it. The record has to survive all of that on its own, or it was never really a record.
Found something wrong on this page?
That is the most useful message you could send us. A claim that does not hold should be corrected or withdrawn, and we would rather hear it from you now than from a customer's counsel later.