What Lumis is for
When a data or ML system breaks, the alert says what hurts, not why. Someone then spends the first hour checking pipelines, databases, deploys and vendors one by one. Lumis does that first hour. It forms possible causes, checks each against the system’s own evidence, and says which cause the evidence supports, showing every step. When the evidence can’t decide, it says so, and says what would.
Lumis reads; people decide. It never changes your systems.
- kinds of source it reads, read-only
- 7
- parts, each with one job
- 5
- kinds of honest answer
- 4
- changes to your systems
- 0
The parts
Connect: reading the evidence, safely
Lumis reads the tools a data team already runs:
- Metrics: Prometheus.
- Logs: Loki.
- Traces: Tempo.
- Pipelines: Prefect.
- Clusters: Kubernetes.
- The database: PostgreSQL, through a read-only role.
- The code: Git, read-only, approved files only.
Three things hold for every read:
- It runs only the queries the team has approved. The AI model never writes its own.
- Secrets are redacted before anything reaches a model.
- Credentials stay with the worker that runs the investigation, never in the browser or with the model. A relay that keeps them inside your own network is planned.
Atlas: the system as it was
An investigation needs to know what the system looked like when the alert fired, not what it looks like now.
- What Atlas holds: a map of services, pipelines, datasets, models and their links, with everything that changed and when.
- Where the map comes from: discovery from dbt, MLflow, Prefect, Backstage, OpenLineage and Kubernetes, kept up to date on a schedule.
- Time travel: Lumis can show the estate at the moment of the alert, and what changed just before.
- People win: a person’s correction always outranks what was discovered.
Checks: known failures first
Engineers can write checks for failures they already know, in a readable format. A sure match settles an incident in seconds, with no AI. A new check runs in shadow first: it is recorded, never decides, and builds a track record before anyone promotes it.
Reason: the investigation
When no check settles it, an AI model investigates, within limits the team agreed:
- The model proposes. Possible causes, each with what should be true if it’s right and what would rule it out. It asks for evidence, and reads the code and the history of changes.
- The evidence decides. Lumis checks every claim against observations it gathered itself. The model never marks its own work.
- A second look before concluding: at ties, near misses, and changes the answer doesn’t explain.
Every investigation ends in an honest answer, one of four:
Ledger: the record
- Every investigation is kept step by step: each idea, each piece of evidence, each change of belief and why.
- It is append-only and tamper-evident, and it can be replayed later.
- People record their verdicts on each answer. That record is how we measure Lumis; later it becomes memory Lumis can use as leads (planned).
Underneath
- Investigations survive crashes and restarts, and resume where they stopped.
- An API with live investigation streams. Alerts from Alertmanager open incidents and, if the team chooses, start investigations.
- Each team has its own database and its own agreed limits, and can use its own AI model account.
The console (in progress)
Where people follow an investigation live, replay it step by step, review the system map, and connect their tools. It is in progress, on recorded and example data. An assistant in the console, Axion, is planned.
What v0.0.1 deliberately doesn’t do
- It doesn’t act. No restarts, rollbacks or config changes. Approved actions with guardrails come later, and only with a person’s approval.
- It doesn’t let the model run free. No arbitrary queries, and no conclusion without evidence.
- It doesn’t hide doubt. An answer it isn’t sure of is labelled.
How we know it works, and where it doesn’t yet
We test Lumis on GridCast, a realistic forecasting system we built and break fifteen ways. The full results, including the wrong answers and the limits, are in the companion case study. In short:
- eleven of the fifteen faults have never been missed;
- the three hardest went from splitting to 18 of 18 on a quiet machine;
- on busy machines, one of them (a timeout change beside an already-slow vendor) still splits.
All of it on our own test system, not customer data. Public benchmarks are next.
What’s next
- Replaying a team’s own past incidents, from exported data.
- Public benchmarks: OpenRCA and ORCA-bench.
- More alert sources: Grafana, Datadog, PagerDuty, Opsgenie and Prefect.
- A relay that keeps credentials inside the customer’s network.
- Memory of past incidents as leads.
- Approved actions with guardrails, later.
Working with us
We’re looking for Lumis’s first design partners. If you run data or ML pipelines and want to see it on your own incidents, join the waitlist.
