Liveness
Checking…Process-level check for the deployment platform. It does not depend on the database.
Open health check →12 claims, sorted strongest first. Each one carries the point where its evidence stops, so the weak rows are findable rather than buried.
Review the assurance boundary
Move between the record, the declared scope and the remaining qualification work.
Select an illustrated object to inspect its role.
01 / 03
Check the source, version, environment and limitation before using a figure in an assessment.
Source-linked published recordsInternal or local synthetic checks do not establish independent reproduction or customer validation.
“Measured” is not “production-ready”. “Design only” is not an integration claim. The right-hand column is the one worth your time.
The same input yields the same verdict, and the tests that show it are published.
Bounded synthetic inputs. It says nothing about inputs nobody has tried.
A signed demonstration pack and a standalone verifier you can run yourself.
Customer KMS custody is still a deployment gate.
Capacity measured in a target-representative environment.
Not a customer production validation, and not an AWS endorsement.
When a source changes, what depended on it is replayed and the rest is shown untouched.
A reference store, not a customer graph. It works from declared dependencies.
What a termination request deletes, what it cryptographically erases, and what was never held.
A published procedure. No customer has yet exercised it.
The deployment pattern is defined and documented.
Customer validation is still required. Nobody has run it in your boundary.
A published engineering outline of processing, retention and erasure.
Not legally reviewed. Two clauses are named as unresolved.
An adapter map covering the supported cloud targets.
No equivalent applied run exists on a second cloud.
No SLOs are published.
No production deployment or pilot has run yet to measure them from.
No support or on-call commitment exists by default.
It must be agreed per pilot, in writing.
This page does not assert that EcoKure is production-ready for you.
It requires your infrastructure, your security review and a pilot.
No certification is held.
Controls are designed to be reviewable. That is not accreditation.
A sequence, not a menu. Each gate is a decision somebody in your organisation signs, and none of them is ours to sign.
Named owner, data boundary, intended use and excluded use, accepted in writing before anything runs.
Run beside the existing process without actuating decisions. Measure review workload and exceptions.
Introduce a controlled rule or source change and inspect what it affected and what it left alone.
Generate a signed pack, replay it independently, and record the limitations you found.
Your steering group decides whether the measured result supports the next stage.
EcoKure does not replace accountable people. It makes the decision boundary, control state and evidence trail visible enough for them to govern.
Machine-readable on purpose. A 200 means the check passed; the strict readiness check returns 503 while any required production gate is still open, which is an honest pending gate rather than a broken link.
Process-level check for the deployment platform. It does not depend on the database.
Open health check →Checks the application and protected corpus databases, production secrets, transactional email, canonical HTTPS and reviewer SSO. The reviewer gate requires the ecosystem SSO client secret and a configured reviewer email allowlist. Until both are set, /readyz correctly returns 503 even while public pages are serving.
Promotion, recovery, rollback, incident response and offboarding, in readable Markdown.
Open production runbook →