AlphaOrbit

AlphaOrbit is all you need!

Comment

This following project was submitted to Build with Gemma Hackathon (Sponsored by Google Deepmind) - Aug 1, 2026

Teammates: Kevin, Sofiia, Bohdan (Teammates do not have a devpost account).

Autonomy Under Delay

Gemma-powered anomaly reasoning for deep-space telemetry

Alpha Orbit Team · GDG Waterloo, August 1, 2026

1. What we're actually trying to fix

The starting point for this project is a boring fact that turns out to matter a lot: light is slow. A round trip to Mars takes anywhere from about 6 to 40 minutes depending on where Earth and Mars are in their orbits. During that window, if something on the spacecraft starts drifting — a thermal sensor reading creeping outside its normal band, a power draw that doesn't match the flight plan — ground control is not in the loop yet. The spacecraft either has to sit and wait, or it has to make a call on its own.

Most anomaly detection work in this space stops at the flag: a model says "this looks weird" and hands it to a human. That's fine when the human is five seconds away. It's not fine when the human is twenty minutes away and the anomaly is accelerating. So the piece we actually spent our time on isn't detection — detection is the easy, well-studied half. It's what happens after the flag: can a language model reason about what the anomaly probably is, given the physics of the system, and propose something a mission operator could sanity-check and approve without having to reconstruct the whole picture themselves.

2. Dataset

Our primary benchmark is OPSSAT-AD, the anomaly detection dataset built from the European Space Agency's OPS-SAT CubeSat. It's a genuinely nice dataset to work with for a one-day build: 2,123 labeled telemetry segments, about 20% of them flagged as anomalous, with 18 handcrafted features already extracted and, usefully, baseline results published for 30 different ML algorithms — so we have a real number to compare against rather than inventing our own yardstick.

We're using the NASA SMAP & MSL telemetry dataset as a secondary source, mostly for validating that our anomaly-detection stage generalizes past a single spacecraft. Worth being upfront that this dataset has known limitations — the community has pointed out issues with how some of its anomaly windows are labeled — so we're treating it as a sanity check, not as ground truth we tune against.

3. System architecture

The pipeline is deliberately split into two halves that do different jobs. The first half is fast and numeric. The second half is slow and interpretive. We didn't want one model trying to do both.

  • Sensor telemetry — raw multi-channel readings coming off the spacecraft, at whatever cadence the platform streams them.
  • Anomaly detection — an LSTM scores each timestep and flags anything that crosses a z-score threshold. This is the part that has to run constantly and cheaply, so it stays lightweight.
  • Gemma reasoning agent — only the flagged windows get here. Gemma receives the anomaly, the channel's physical meaning, and enough surrounding context to reason about what's actually happening, not just that something crossed a line.
  • Decision output — a structured, JSON-shaped recommendation: severity, likely cause, suggested action — something a human or an automated system downstream can act on directly.

The reason for the split is mostly practical. Running an LLM over every telemetry sample would be slow and, frankly, unnecessary — most of the stream is boring and doesn't need a paragraph of explanation. Gemma only gets invoked on the handful of moments that are actually worth its attention, which keeps the system usable in something close to real time.

4. Why Gemma, and how it's actually used

We're running Gemma 3 (instruction-tuned, via the Gemma API) rather than self-hosting a larger checkpoint. That was a pragmatic call given we had one day — it's well-documented, function calling and structured JSON output are supported out of the box, and we didn't want to burn hours debugging a local deployment when the actual interesting work was in the prompt design and the pipeline logic around it.

The part we put the most effort into is grounding. An LLM reasoning about telemetry with no context will happily produce a fluent, confident-sounding explanation that's completely made up — which is the last thing you want in a system framed around life-or-death decisions. So every call to Gemma is built from three pieces:

  • Channel metadata: what the sensor physically measures (voltage, temperature, pressure), not just an internal channel ID.
  • The anomaly signal itself: the z-score, the magnitude, and whether the detector flagged it as a point anomaly or a contextual one.
  • Domain context: a short primer on the relevant orbital mechanics or spacecraft subsystem, so the model's reasoning stays inside what's physically plausible.

The output is constrained to a structured schema — severity, probable cause, recommended action, confidence — rather than free text. That was a deliberate choice: free text is easier to demo but harder to act on, and it's also easier for a model to hand-wave through. Forcing structure made the weak spots in our prompting obvious much faster than reading paragraphs would have.

5. Decision governance

One thing we wanted to avoid is building something that reads as a one-off script wired to one dataset. The pipeline is structured as three reusable layers: triage logic (LSTM + Gemma jointly classify severity and likely cause), escalation rules (confidence and stakes decide whether the system can act on its own or has to flag a human), and a human-review queue (anything low-confidence or high-stakes waits for sign-off — nothing silently auto-executes).

We think this pattern holds up outside spacecraft telemetry. The shape of the problem — a stream of sensor data, a need to catch rare bad events fast, and a cost to both false alarms and missed ones — shows up in grid operations, industrial control systems, and clinical triage just as much as it does in deep space. We didn't build for those domains, but the architecture doesn't assume anything specific to spacecraft beyond the prompt's domain context, which is the one piece you'd swap out.

6. What was actually hard

A few honest notes on where the time went, since a lot of it wasn't where we expected.

Threshold tuning was noisier than it looked

The z-score threshold for the LSTM detector turned out to be a real trade-off, not a constant we could set once. Too sensitive and Gemma gets flooded with borderline cases that aren't worth reasoning about; too conservative and we miss the contextual anomalies, which by definition don't show up as a single spike. We ended up tuning against the OPSSAT-AD labels rather than picking a threshold that felt intuitively right, which took longer than we budgeted for.

Getting Gemma's JSON output to actually be reliable

Structured output sounds simple until the model occasionally wraps its JSON in a sentence, or drops a field when it's less confident. We spent real time on prompt phrasing and a thin validation layer that catches malformed output and re-prompts rather than crashing the pipeline. It's not a solved problem, more like something we got to "reliable enough for a live demo," which is a different bar than production-ready.

Keeping the explanations grounded, not just fluent

Early prompt versions produced explanations that sounded plausible but weren't actually tied to the specific channel or anomaly type — the kind of thing that's easy to miss if you're not checking against the physics. Feeding in the channel metadata explicitly, rather than trusting Gemma to infer it, fixed most of this. It's a small change but it was the single biggest jump in output quality we saw all day.

7. Walking through the demo

The demo is built around one concrete scenario rather than a grid of metrics, because we think that's the more honest way to show what this actually does. A thermal sensor on OPS-SAT drifts outside its normal band — ground control won't see it for another twenty minutes. The LSTM flags it in real time. Gemma explains what's physically happening and why it matters right now, then proposes a structured action: throttle back, reroute power, or hold and monitor. The system can act within its own guardrails, or escalate, depending on the confidence and stakes of that particular call. No hour-long round trip to Earth required for the routine cases.

8. Evaluation

The OPSSAT-AD paper gives us a genuine baseline: results from 30 published anomaly-detection algorithms on the same segments we're using. Our detection stage is being scored against those directly. The harder part to evaluate is the reasoning layer — there's no established benchmark for "is this explanation physically sound and actionable," so for now that's a qualitative check: we hand-reviewed a sample of Gemma's outputs against the known anomaly causes in the dataset and flagged anything that looked hand-wavy or ungrounded. That's a real limitation of this evaluation, and it's the piece we'd want to formalize if we kept building past today.

9. Limitations and what we'd do next

  • We haven't done edge deployment — everything runs against the Gemma API, not on flight-representative hardware. Getting a smaller Gemma variant running on something like a Jetson Orin is the natural next step.
  • Trajectory and orbital-mechanics context is currently a static primer in the prompt, not pulled from real ephemeris data. Wiring in SPICE kernel data would let the physics grounding be exact rather than approximate.
  • The human-review queue is designed but not load-tested — we don't yet know how it behaves under a burst of simultaneous anomalies, which is exactly the situation it exists for.

Built With

  • gemma
  • rnn
  • transformer
Share this project:

Updates