Skip to main content

Platform

The runtime underneath the report

Where the investigation runs, what it reads, and where it is required to stop.
The same engine installs into your own cluster (available in closed beta) or runs on ours, and neither version can pass the approval boundary on its own.

Request accessJoin the closed beta
Runtime surfacedeploymentpipeline stagestrust boundary

How it runs

Choose a deployment model without changing the evidence contract.

Self-hosting via HelmBeta

Every consequential action is cleared by a person

Every consequential action needs a named person's approval: anything above read-only in production, and high-risk or irreversible actions everywhere.
A time-boxed, revocable grant is a named person pre-approving one kind of low-risk action; read-only and non-production low-risk actions run automatically.

Beta

Runs where your evidence lives

Self-host the runtime via Helm inside your own infrastructure (available in closed beta), or use the managed service.
The investigation engine is identical.

Standard infrastructure

Self-hosted, the runtime installs into your own Kubernetes cluster (available in closed beta) and needs Postgres and Kafka.
The evidence store sits behind an interface, so it is not tied to one cloud's API.

Your own model keys, when self-hosted

On a self-hosted install you point the runtime at your own LLM provider credentials.
The provider is set per deployment, not per organisation, so on the managed service we supply the model.

Beta

From alert to answer

7 stages. The investigation can stop at any of them, and it always stops before production changes. Select a stage to see what it produced in this sample.

Investigation pipeline · checkout-apiPM-SAMPLE-001 · 14:23–14:31 UTC
↑ human approval boundary
Stage 0114:23 UTC

Detect

An alert, a deploy or a direct request opens an investigation and starts gathering evidence from the sources you've connected.

In this sample
checkout-api p99 · 410 ms → 2.9 s
Opens PM-SAMPLE-001, timestamped 14:23–14:31 UTC in this sample.
Stage 0214:24 UTC

Gather

Read-only connectors pull the deploy diffs, metric series, logs and cluster events (planned) inside that window.

In this sample
1 commit · 3 series · 2,140 lines · 18 events
Volume and origin are recorded per source, before anything is interpreted.
Stage 0314:24 UTC

Exhibit

Each source becomes a numbered exhibit, with its origin, timestamp and volume recorded alongside it.

In this sample
E-01 · E-02 · E-03 · E-04
From here on, a claim that cannot name an exhibit cannot enter the report.
Stage 0414:26 UTC

Hypothesise

Candidate explanations are written as falsifiable statements that an exhibit could disprove, not as prose.

In this sample
H-01 … H-04
Four candidates, each stated so that a specific exhibit could disprove it.
Stage 0514:28 UTC

Challenge

Each alternative is compared with the leading explanation. One is set aside, with the reason recorded, when it cites no evidence or states lower confidence.

In this sample
3 rejected · 1 held · cache degradation ✗ E-04
A rejection is a result. It ships with the report rather than being deleted.
Stage 0614:30 UTC

Report

The leading explanation, its citations and its confidence are assembled, with the alternatives considered and why each was set aside.

In this sample
Illustrative sample, no confidence score
Below certainty: the sample neither reproduces the issue nor observes recovery.
Stage 0714:31 UTC

Gate

A remediation is proposed and the investigation stops there. A human decides whether it is applied.

In this sample
A-01 · awaiting approval
Nothing here runs on the system's own authority: by default a person clears A-01. A time-boxed, revocable grant can pre-approve low-risk actions only.

Stage 01, Detect. An alert, a deploy or a direct request opens an investigation and starts gathering evidence from the sources you've connected.

detect → gather → exhibit → hypothesise → challenge → report → gate · the run always stops before the gate

Alternatives kept with the reason each was set asideBeta

Connectors, and what each one does

Connectors by name, and the role each plays today.
Prometheus and Kubernetes are read through native, read-only connectors.
Logs are read through the Grafana connector; a direct Loki connector is planned.

  • GitHubSearches code. Comments on pull requests and opens draft pull requests.Shipped
  • GrafanaReads logs, metric ranges and SQL queries. Annotates dashboards.Shipped
  • JiraReads tickets. Adds comments and labels, and moves tickets between states.Shipped
  • SlackSearches channels and threads. Sends notifications.Shipped
  • PagerDutyStarts an investigation from an incident. Pages and escalates. Not read as evidence.Shipped
  • DatadogStarts an investigation from an alert. Trigger only: Datadog data is not read as evidence.Shipped
  • PrometheusNative connector, read-only. Reads metrics.Shipped
  • KubernetesNative connector, read-only. Reads cluster events, pods and nodes within the scope you approve.Shipped
  • LokiRead through Grafana today, where your Grafana is backed by it. No run reads Loki directly yet.Planned
  • Argo CDNo connector yet.Planned
  • OpsgenieNo connector yet.Planned

An agreed path, or no path

Five gates, named before evaluation starts: source, credential scope, evidence, audience, action owner.
Each carries its status below.

01
An evidence source you approve
Named per connector, in writing, before anything is connected.
Planned
02
A minimum, agreed credential
Credentials are kept per organisation and per connector. Minimum scope is agreed before anything is connected; verifying it is only partial so far — detail on /security.
Partial
03
An evidence check
A conclusion is tested against the evidence gathered; one the evidence cannot carry is not reported as supported.
Shipped
04
A named audience
Reports and report-bearing actions go only to destinations your organisation approved. Checked at every call site today; a guard inside the executor itself is planned.
Partial
05
A human approval boundary
Every consequential action waits for a named person: anything above read-only in production, and high-risk or irreversible actions anywhere. Read-only and non-production low-risk actions run automatically, to approved destinations only. Grants (Beta) cover low risk and below.
Shipped
In the closed beta
Human approvalBeta
Self-host via Helm, available in closed betaBeta
Air-gapped install from a signed bundleBeta
Not yet published
Encryption, retention and the subprocessor register — status published on /security.
Roadmap
Air-gapped web console, offline backups and upgradesPlanned
this page is a statement of practice, not a certification · no compliance badges
Every control behind these gates, with its published status and review date

Run it where your evidence already is

The same runtime installs into your own Kubernetes cluster (available in closed beta) or runs on ours, and the investigation it performs is the same one either way.

Join the closed beta

Self-host via Helm — available in closed beta.