Proof / Viability

Measure ouroverhead yourself.

Viability is the third proof — the one most governance narratives quietly cheat by publishing marketing numbers. Keon does not. The unit of proof here is buyer reproducibility: we publish the metric definitions, the measurement methodology, and a verification harness so you can measure Keon's overhead in your own environment.

No fake numbers. No invented benchmarks. No hero dashboard. This page publishes zero measured values by design — definitions and method only.

Receipts prove authority. Evidence packs prove causation. Telemetry attests viability.

What telemetry proves

Governed operation is viable, and the overhead is yours to verify.

Telemetry answers the viability question: what did governance cost, and did the substrate stay up? It complements — never replaces — the receipt (authority) and the evidence pack (causation). Latency, availability, and rate families are product measurements. Chaos and degraded-mode behavior additionally anchor, in part, to the CAES L3 chaos-attestation criterion.

Metric families

Defined by name, meaning, and source — not by a number.

Each family below defines what is measured and where it comes from. No values appear here. Publication of any value requires a measured source, the methodology reference, and a buyer-runnable verification path.

Decision latency (p50/p95/p99)
Time to render an authorize / deny / escalate decision.
Runtime decision path
Gateway latency (p50/p95/p99)
Enforcement time added at the tool boundary, reported as overhead vs. an ungoverned baseline.
MCP Gateway
Receipt-persistence latency (p50/p95/p99)
Time to durably persist a signed receipt.
Runtime → receipt sink
Evidence-pack generation time
Time to assemble a reconstructable Evidence Pack.
Cortex
Fail-closed / deny / approve rates
Disposition distribution of governed decisions.
Runtime
Degraded-mode count
Entries into degraded mode, paired with the resolution disposition.
Runtime
Runtime availability
Uptime of the decision / execution engine.
Runtime
Gateway availability
Uptime of the enforcement boundary.
MCP Gateway
Receipt-sink health
Availability and integrity of the receipt store.
Receipt sink
Policy-eval error rate
Rate of policy-evaluation errors — errors fail closed, not open.
Runtime / Gateway
Tenant/actor binding-failure rate
Rate of failures to bind an action to an authorized tenant/actor — a binding failure is a deny.
Runtime

Tag: latency / availability / rate families are product-only [P]. Only the CAES L3 chaos / degraded-mode attestation portion is standards-backed [S], and only that portion.

Buyer verification flow

How you reproduce it.

01
Take the harness

Pull the published measurement harness and the metric definitions for the family you want to check.

02
Run it in your environment

Measure against your own Keon deployment — no hero numbers to trust, no Keon-hosted dashboard in the loop.

03
Compare to the baseline

Each overhead metric is defined against a stated ungoverned baseline, with its window and denominator.

04
Reproduce within tolerance

If the family reproduces within the stated tolerance, the viability claim holds. If it does not, the claim fails — that is the test.

Publication discipline

The rules every published number must obey.

This page carries definitions and method. When Keon publishes a measured value anywhere, it obeys these rules — so the number is never asked to be trusted, only reproduced.

  • 01
    Every published value carries its measurement methodology reference and a buyer-runnable verification path.
  • 02
    Overhead is reported against a stated ungoverned baseline, never in isolation.
  • 03
    Every value states its measurement window and its denominator / scope.
  • 04
    No value is published without a reproducible measured source. Absence of a measurement is reported as "not yet measured," never estimated.
  • 05
    Standards-backed vs product-only is tagged on every published claim.
How you'd catch us

Run the published harness against a Keon deployment and obtain overhead materially worse than the methodology implies — or find a public Keon number you cannot reproduce. Either one falsifies this posture.