Nomos research · Satellite incident observability
We ran four connected ground experiments. One used public satellite telemetry. Two ran on a physical Jetson. One challenged small language models. Together, they test the path from noticing a problem to giving an operator a defensible answer.
Ground evaluationsNo flight claimEvidence downloadable
The 60-second answer
Detecting unusual behavior worked. Explaining it required preserving a small amount of decisive evidence. The language models we tested were not reliable enough to replace that evidence or the operator.
Public telemetry let a small detector flag unusual segments, but it did not contain enough context to name the cause.
On the Jetson, small incident records preserved the exact failure and stayed attached to one operation across runtime restarts.
None of four small language models consistently changed its answer when we removed the decisive evidence.
What this supports: start with tracing for satellite operations. Capture and validate evidence deterministically, then let a model help a human read it.
One question at a time
Each test answers a narrower question than the one before it. Read the conclusion first, then open the workbench if you want the underlying replay.
Public OPS-SAT telemetry
We trained a transparent detector, then tested it on 529 labelled telemetry segments it had never seen.
See a catch, false alarm, and missThe detector also raised four false alerts.
Plain conclusionIt can raise a useful alarm. This dataset cannot tell an operator why the anomaly happened.
Physical Jetson fault injection
We made an image job fail from memory exhaustion, a frozen worker, and a full disk. From outside the workload, every failure looked identical: the result never arrived.
Replay the three failuresThe largest record was 494 B. At a 4 KiB limit, logs and routine system readings each explained 5/15.
Plain conclusionThe symptom was not enough. A small record saved beside the workload kept the clue that separated the three causes.
Physical Jetson runtime restart
We followed one imaging operation through two watchdog restarts. The same operation ID and hash-linked journal continued across three runtime boots.
Follow the operation across three bootsApplication logs and routine telemetry each localized 20/25. Their five misses were all watchdog-restart cases.
Plain conclusionThe usual downloads showed that the runtime came back. The operation trace kept what it was doing before it disappeared.
Four small open language models
Each model saw an incident record twice. In the second copy, we removed only the decisive clue. Passing required the model to name the cause with proof, then say “unknown” when that proof disappeared.
Inspect the proof-removal pairsThe best result was 6/15 pairs when we supplied the exact proof rules.
Plain conclusionNot yet. A model may help explain verified evidence, but none we tested was reliable enough to diagnose on its own.
The product implication
These results do not point to an autonomous agent flying the spacecraft. They point to a durable operation record that fits beside existing flight software and gives the ground team a coherent story after contact returns.
The agent is not the source of truth. The trace is.
Command, mode, payload, storage, and downlink boundaries.
A small durable record survives log rotation and runtime restarts.
No diagnosis passes unless the record directly supports it.
The human remains responsible for the operational response.
The honest boundary
The next useful test is not another benchmark. It is learning where this record fits inside a real operator’s stack.
Tell us how your team handles incidentsChoose your depth
The workbench is the fastest way to understand the four tests. The paper and raw files are available for technical review.
Move from real telemetry to fault evidence, persistent traces, and model grounding in one interface.
Review the protocol, comparisons, system boundary, and citations in one document.
Download measured summaries, model responses, Jetson runs, source snapshots, and hashes.
The worker exceeded its 1 GB limit. Linux killed the process.
The main thread deadlocked. A workload watchdog recorded where it stopped.
The output write hit a full 128 KB test disk and returned “no space left.”
| Evidence sent | Memory | Frozen worker | Disk full | Total |
|---|---|---|---|---|
| Application log tail | Unknown · 0/5 | Unknown · 0/5 | Found · 5/5 | 5/15 |
| Routine system readings | Found · 5/5 | Unknown · 0/5 | Unknown · 0/5 | 5/15 |
| Focused incident record | Found · 5/5 | Found · 5/5 | Found · 5/5 | 15/15 |