Skip to content
What KeyOne Can Do
Admin & Reference
On this page

What KeyOne does

KeyOne turns a principal’s own warehouse data into decisions — ranked, evidenced, and resolved by data rather than by a human ticking a box.

Everything below is a surface that exists today and is covered by tests. There is no “planned” column: a capability page that lists intentions alongside facts, in the same table, invites the reader to mistake one for the other.

The one rule that shapes everything

A decision closes when the query that detected it stops returning its row. Nobody can mark one done. There is no resolve button, no “complete” action, and no endpoint — internal/api/routes_test.go asserts that no resolve route can ever be added.

That is why the product has no task tracker. Work that a person closes by hand is work whose completion nobody verified.

Hubs

A hub is a page of KPIs, panels and a decision feed for one area of the business — availability, pricing, and whatever else the tenant’s definitions declare. A hub is data, not code: adding one is a YAML file in definitions/hubs/, never a frontend change.

Every KPI and panel carries its own honest state. A value that could not be measured says no_data with the reason the resolver gave; a query that failed says error. Neither renders as a zero.

Decisions

The unit of work. Each card names the entity it concerns, the definition that detected it, and its measured value impact — nil when there is none, never a formatted zero. A card can be dismissed with a reason or snoozed until a date; both are recorded, and neither claims the underlying problem was fixed.

Queries

Saved SQL against the canonical vocabulary, compiled through the tenant’s binding so one query definition runs on BigQuery, Snowflake, Postgres or Athena unchanged. Parameters are bound, never spliced. Every run is row-capped.

Reports

HTML documents with live data tags that resolve against saved queries at view time, exportable as a self-contained file. A tag whose query returns nothing says so where it sits.

Campaigns

A named push over a scope of decisions, with progress measured by resolved-by-data counts — not by self-reported completion — and a leaderboard ranked on the same basis.

KeyChat

An analyst that answers questions about the tenant’s own data by calling typed tools: list hubs, list saved queries, run one, list decisions, describe the binding vocabulary. It gets no privileged access — every tool runs through the same query path a user does, with the same row caps.

Three properties worth knowing: it says when a catalogue it showed you was truncated; it reports itself unconfigured rather than answering when no model key is set; and running its own SQL (run_adhoc_sql) is off unless a deployment explicitly turns it on.

The field app. Reps see their assigned outlets’ open work, record visits, and file forms with photos — offline-capable, with an outbox that survives a lost connection.

One rule is enforced structurally: seeing is not filing. An admin viewing as a rep may read everything and file nothing.

Settings

Users (invite, role, disable), the configured warehouse and its binding coverage, decision definitions, engines, notification preferences, and an operations section: run history, freshness, health checks and the audit log.

Binding coverage is the honest-gap report — which canonical fields this tenant’s source actually supplies, and which facts are therefore unusable. A hub with no visit data bound says “no visit data bound”, with the reason.

What KeyOne deliberately does not have

Stated because their absence is a design decision, not a backlog:

  • No resolve button. See the rule above.
  • No hand-created task tracker. Same reason.
  • No org switcher or multi-org signup. One binary serves exactly one tenant; identity is admin-provisioned.
  • No external BI dependency. Hubs, charts and reports are served by the binary itself.