Notice the change
Watch a small set of mission signals.
Satellite observability, made legible
Something changed.
Nomos kept the evidence.
A satellite produces thousands of sensor readings. When one looks unusual, Nomos preserves the small window that matters and shows an operator what it knows—and what it doesn’t.
See how it works
Ground prototype · no flight claim
Keep the useful moment
Save evidence before logs roll away.
Explain without guessing
Show proof—or say what is missing.
One incident workbench
Four tests. One evidence path.
Follow the same question from detection to diagnosis: start with public OPS-SAT telemetry, inspect a physical Jetson fault, test whether its story survives a restart, then see whether four open models stay tied to proof.
Question one
Can we spot unusual behavior?
We trained a small, transparent detector, then tested it on 529 telemetry segments it had never seen. Choose a result below.
Loading real telemetry
Acquisition window —
A sensor over time
Loading telemetry…
Each point is one reading from the satellite.What Nomos keeps
A small record of the moment.
Instead of sending the whole telemetry window, the prototype keeps the time, score, strongest observations, and decision.
Raw window—
Incident record—
See the saved record
Loading benchmark artifact…
What Nomos cannot know yet
Why it happened.
This dataset has sensor readings, but not the spacecraft context needed for a root cause. A trustworthy system should ask for that context—not invent an answer.
CommandsOperating modePower & thermalSoftware logs
Root cause: unknown
Across all 529 unseen segments
Useful, but not perfect.
The prototype found most labelled anomalies and rarely cried wolf. It still missed 23. Those misses are exactly why an operator stays in the loop.
90anomalies caughtout of 113
23anomalies missedneeds improvement
4false alarmsout of 416 normal
Technical benchmark details
Held-out F1—
Precision—
Recall—
Measured step—Published-feature transform + classifier; amortized batch timing.
Question two
Can the evidence explain a failure?
On a physical Jetson, we made an image job fail three ways. From the outside, every failure looked the same: no result arrived.
Recorded ground test
Watch the incident unfold.
Ready
- 1Image processed
The onboard model finished its work.
- 2Result missing
Nothing arrived before the deadline.
- 3Evidence saved
Linux recorded why the worker stopped.
- 4Worker restarted
A fresh worker produced a verified result.
What the operator first saw
No result arrived.
The symptom was identical in all three tests.
What the incident record proved
Memory ran out.
Linux marked the worker OOM-killed and returned exit code 137.
382-byte recordSame 512-byte download budget
Saving more data is not the same as saving the right data.
Choose what reaches the ground. The answer changes even though the byte limit does not.
Enough direct evidence
Cause explained.
The saved record contains the system event that directly identifies this failure.
15/15failures explained
See the raw evidence
15/15failures explained by the incident record
≤494 Blargest record sent to ground
0/10false alerts in clean runs
Question four
Does the answer follow the proof?
We gave four small open models each incident record twice. The second copy was identical except the one decisive proof had been removed.
Models cleared for Jetson
0 of 4No model went onboard. Passing required all 15 pairs: cite the proof while it exists, then say “unknown” when it disappears.
Safety gate held
What the model received
A strict prompt asked for one cause and the record ID that proved it.
Loading measured model results…
One controlled change
Remove the proof. Ask again.
BeforeProof present
Loading evidence…
Model answered
Loading…
Waiting for measured result
AfterProof removed
Loading evidence…
Model answered
Loading…
Waiting for measured result
Loading the recorded pair…
What we would build now
Proof first. Model second. Human in control.
- 1Software validates proof
A deterministic gate checks the cited record against the mission rule.
- 2The model explains
It retrieves history and turns validated evidence into readable context.
- 3The operator decides
No command or diagnosis becomes authoritative without the human workflow.
Measured results
All 420 responses
Ground-host inference · physical-Jetson evidence · no flight claim
Question three
Can one operation survive a restart?
We ran one imaging operation until a watchdog restarted its runtime twice. A persistent trace kept the operation’s story while ordinary downloads filled with what happened after recovery.
Recorded restart trial
One operation. Three runtime boots.
Loading measured trace
Operation—— runtime restartsChecking journal
- Loading the recorded operation…
Ordinary 2 KiB download
Runtime came back.
The failed stage is unknown.
Persistent operation trace
Stopped during payload execution.
Loading the decisive record…
Same 2 KiB maximum
Did the download preserve the failed stage?
Twenty-five failures covered five stages. The five misses below were all watchdog restarts during payload execution.
Application log tailRestart cause unknown
—failures localized
—this restart
?Lost pre-restart context
Routine telemetryRestart cause unknown
—failures localized
—this restart
?No decisive event
Operation tracePayload execution
—failures localized
—this restart
✓Stage retained
In plain English
Logs told us the runtime came back. The trace kept what it was doing before it disappeared.
—restart trials recovered
—journals passed integrity checks
0false diagnoses in 5 clean controls
Readable result
Raw summary
All 511 evidence files
Runtime-process restarts · no OS reboot or flight claim
The product idea
The first useful step isn’t an agent that flies the satellite.
It is a trustworthy incident record that helps a human understand what changed. An agent can summarize that evidence later. It should never replace it.
1Your flight softwareKeeps running the mission
→
2Nomos recorderPreserves the useful moment
→
3Your ground toolsShow evidence to the operator
For technical reviewersMethods, limits, and source material+
What is real
The OPS-SAT replay uses public telemetry and held-out labels. The fault and restart tests ran on a physical Jetson Orin development board.
What is not proven
Nothing ran in flight. No commercial operator has validated the workflow. OPS-SAT-AD cannot support root-cause diagnosis.
What happened with open models
Four small packages faced 15 proof-removal pairs. The best reached 5/15 without a runbook and 6/15 with one. None cleared the gate.
Why one interface
The KARI operator study emphasized integrated context, traceable state changes, and real-time plus playback views.