Skip to content
All notes
Note · 1 September 2026

WHY PROVENANCE, not confidence.

A satellite operator does not need an AI that sounds sure. They need one whose every sentence can be checked. That is a different product, and it costs something.

The alarm is not the hard part

Detection has benchmarks. When a satellite's telemetry drifts, there is a whole literature on noticing — and ESA's own anomaly benchmark reached an uncomfortable conclusion about it: current algorithms miss what operators actually require, and false positives are the main reason operations teams stop trusting them.

Investigation has no benchmark at all. Once the alarm has fired, someone still has to cross-reference the telemetry database, the operations manual, the failure-mode sheets and the memory of whoever handled the last one like it. That pass is manual, it is slow, and it is where the expertise lives. Constellation operators are adding satellites faster than they can add the people who do it.

That gap — investigation, not detection — is what VELA was built for.

What a language model wants to give you

Ask a capable model to investigate an anomaly and it will do something impressive: it will write a confident, well-structured, plausible account of what probably happened. It will read like an experienced engineer wrote it. It may even be right.

The problem is the word confident. A paragraph that sounds sure is exactly the shape of output a flight operations team cannot use, because sounding sure is not a property of the spacecraft. It is a property of the prose. An operator reading it has no way to tell a grounded conclusion from a fluent guess, and in this domain a fluent guess that gets executed is the worst outcome available.

So the property we designed for is not confidence. It is provenance: every claim in an investigation carries the document it came from, or the claim does not ship.

What "does not ship" means

It means the check is in the build, not in a disclaimer.

VELA produces two things: a root-cause account, and a drafted recovery procedure. Each sentence of each is tied to a source — a line of telemetry, a section of the operations manual, an entry in the failure analysis. Before an investigation is releasable, an integrity check walks every claim and every step and looks for the source behind it. A claim with no source fails that check. So does a step in the recovery that is not grounded in the documentation. The check does not soften the sentence, hedge it, or attach a warning. It refuses the release.

That is the honest form of the word verified. It does not mean "the root cause is correct" — no system can promise that, and one that does should not be believed. It means every claim can be traced to something a human can open and read. Correctness is then a question a person can settle, with the evidence in front of them, rather than a feeling the prose gave them.

The other refusals

Provenance is the first refusal. There are three more, and together they are the product.

It never commands. VELA is advisory by design. It drafts the recovery; an operator executes every step. Nothing it produces can act on a spacecraft, and that is enforced by tooling rather than by policy, because a policy is a sentence and tooling is a gate.

It does not invent data. Agents rehearse on a synthetic reference set. No synthetic data is ever presented as a real mission, and no real telemetry is fabricated to fill a gap in an account.

It does not vary. Identical inputs produce an identical investigation. An account can be replayed from its inputs and compared against a known-good result, which is what makes it defensible under review rather than merely persuasive in the moment. It also runs in the cloud or fully air-gapped, by configuration — an operator whose data cannot leave the building does not get a different product.

What this costs

Refusals. Sometimes VELA will tell an operator that it cannot ground a conclusion in the sources it has. That is uncomfortable to watch in a demo, and it is the product working. A system that always has an answer is a system that is sometimes making one up, and in this domain the honest "I cannot trace this" is worth more than the fluent paragraph.

It also costs claims we would otherwise make. VELA targets the gap the ESA benchmark identified; it has not yet been run against that benchmark, and no score exists. We would rather say so than imply one. The same rule applies to every number on our site.

Where being wrong is expensive

There are domains where a confident wrong answer is cheap: you notice, you correct, you move on. Satellite operations is not one of them, and neither are the others we build for. When being wrong is expensive, guessing is not an option — and a system that cannot show its work is a system that is asking you to guess on its behalf.

Sources
  • The investigation gap, the ESA benchmark's conclusion, and the manual cross-referencing — VELA repository README, "Why".
  • Citations as load-bearing, the integrity check failing a release, advisory-only, synthetic reference data, determinism, air-gap by configuration — VELA repository README, "Non-negotiables"; /work/vela case study, "Five properties".
  • "Not yet run against ESA-ADB; no score exists" — VELA repository README, limitations; /work/vela case study.
  • "Verified means provenance, not correctness" — /method, Layer 06; the hero paragraph on the home page.