# Service Levels — Position

**Status: NO SLOs ARE PUBLISHED, AND THAT IS DELIBERATE.**

This document says what will be measured, how, and what has to happen before any
number is committed to. It contains no service-level figures, because none has
been measured.

---

## 1. Why there is no SLA yet

A service level is a promise about behaviour under conditions you have observed.
EcoKure has not observed production service levels or a customer pilot:

- No production customer deployment exists.
- No customer pilot has run.
- A target-environment AWS benchmark is now recorded, but it is single-AZ and
  target-representative rather than production validation.
- The benchmark measured 117,290 completed verifications, 0 performance errors,
  14.29 ms p50, 19.47 ms p95, 36.43 ms p99, 51.5 second recovery and 0 lost
  acknowledgements. These are evidence signals, not service-level commitments.
- The modeled cost signal is US$0.00001515 per assurance transaction, subject
  to the exclusions in the AWS evidence record; it is not a production price.

Publishing "99.9%" now would be choosing a number that looks reassuring and
calling it a commitment. Every other claim on this site is held to a measured
standard; a service level invented to fill a gap in a procurement questionnaire
would be the one place we abandoned it, and it would be the place a customer is
most entitled to rely on us.

**A regulated buyer asking for an SLA is entitled to a real one. Until we can
give a real one, the honest answer is that we cannot.**

## 2. What will be measured

Defined now so that the first pilot produces the right data rather than
whatever happened to be logged.

### Availability
- **Verification availability** — proportion of verification requests returning
  a verdict, attested or explicitly refused. A refusal in STRICT mode counts as
  *available*: the system answered correctly.
- **Evidence availability** — proportion of verdicts that were successfully
  attested. Measured separately, because a deployment that answers but cannot
  evidence is a different failure from one that cannot answer.
- **Readiness accuracy** — how often `/readyz` reported ready while the instance
  could not actually serve. A readiness probe that lies is worse than none.

### Latency
- p50, p95, p99 for gate-only, signing, and end-to-end.
- Signing measured separately per custody pathway: local key versus KMS. These
  differ by an order of magnitude and one is network-bound.

### Correctness
- False-pass and false-block rates against an agreed baseline.
- Abstention rate, and its movement over time.
- Reviewer overturn rate.

**These cannot be self-measured.** They need ground truth from a design
partner's real workflow, which is why the first pilot fixes the pass mark before
it starts.

### Durability
- Evidence loss: target zero, measured as acknowledged appends that do not
  survive. Backup, restore and tamper-detection-after-restore are already
  evidenced against a real PostgreSQL.
- Recovery time and recovery point, once a production topology exists.

### Review responsiveness
- Queue depth, age of the oldest open abstention, and proportion open beyond an
  agreed threshold. **This is a customer-side service level, not ours** — we
  provide the measurement; whether anyone works the queue is their operational
  commitment.

## 3. Sequence

1. Design partner agrees the workflow and the baseline.
2. Target-environment benchmark completes; latency and cost become facts.
3. Shadow pilot runs; correctness rates become facts.
4. **Then** propose service levels, with the measurement window and exclusions
   stated.
5. Only after a period of production operation should any of it become
   contractual.

## 4. What we will commit to before then

Not numbers, but behaviours that are already true and testable today:

- **Fail-closed.** In STRICT mode, an evidence-store outage produces a refusal,
  never a verdict that appears attested and is not.
- **Availability and auditability are reported separately.** A caller can always
  distinguish an attested verdict from an unattested one without inspecting a
  null field.
- **Evidence outlives us.** Packs verify with a single file containing no
  EcoKure code, offline. Our availability is not a dependency of your ability to
  prove what was decided.
- **Absence is never a zero.** A metric nothing is counting is reported as not
  measured, on every surface.

Those are commitments about how the system behaves when things go wrong, which
is what a service level is actually for.

## 5. Interim answer for a procurement questionnaire

> EcoKure does not publish service-level objectives. No production deployment or
> pilot has run, so no availability, latency or correctness figure has been
> measured, and we will not commit to numbers we have not observed. Service
> levels will be proposed from design-partner data, with the measurement method
> and exclusions stated. The fail-closed and evidence-independence behaviours in
> §4 are testable today and we will demonstrate them on request.

Anyone uncomfortable with that answer should be more uncomfortable with a vendor
that supplies a number instead.