SpaceGrade

Inspiration

Spacecraft fly with defects that were accepted before launch: a heater a few ohms out of tolerance, a battery lot slightly under capacity, a baffle with thin coating. A review board signs a deviation and the vehicle ships, and the deviation is usually correct. But that knowledge lives in the build record, and it rarely reaches the people, procedures and software that operate the vehicle.

We build hardware lifecycle software (SpaceGradeOS), so we see these records every day. The question behind this project was simple: what if the build record were in the loop when something goes wrong in orbit and nobody is on console?

What it does

When onboard fault detection fires, a ground autonomy agent wakes up. It reads the telemetry, then the vehicle's build record: every test, every nonconformance (NCR), and how each one was signed off for flight. Then it proposes an action. A deterministic policy, not the model, decides whether that action runs now, waits for an operator, or is refused.

The hero case is a debris conjunction two hours out. Avoiding it takes a thruster burn, and the thrusters must be preheated first. The latest time to start the preheat is

$$ t_{\text{start}} = t_{\text{burn}} - t_{\text{preheat}} $$

On the spec sheet, $t_{\text{preheat}} = 30$ min, so $t_{\text{start}} = T{+}45$. That falls after the next operator pass at $T{+}38$, so a human decides. This vehicle's heater was accepted at $52\,\Omega$ against a $46 \pm 2\,\Omega$ drawing (NCR-002), so the preheat takes $43.4$ min and $t_{\text{start}} = T{+}32$, six minutes before anyone is on console. The policy rule is

$$ \text{tier} = \begin{cases} \text{auto} & \text{if } t_{\text{contact}} > t_{\text{start}} \text{ and the action is inside the envelope } (\Delta v \le 0.5\ \text{m/s},\ \text{budget kept}) \ \text{gated} & \text{otherwise} \end{cases} $$

So the burn is authorised autonomously. The console then tracks each stage in mission time: preheat commanded, bed at 315 °C, burn, and miss distance checked (180 m to about 1.2 km).

Change one condition and the decision changes. Rework the heater before launch, or put an on-call operator on shift at $T{+}20$. With the same evidence, the burn waits for a human, and you play that operator.

Three more scenarios follow the same pattern:

• Slow leak: the pressure slope matches a qualification valve leak, leaving 29 m/s of delta-v at end of life against 120 m/s required.
• Weak battery cells: eclipse depth of discharge is 20.4 % as built against a 20 % limit, so a downlink session is shed.
• Blinded star tracker: a burn is held, and an onboard table change waits for the operator.

How we built it

• Models. NVIDIA Nemotron 3 Super plans the investigation and writes the assessment. Nemotron 3 Nano routes each plan step to a tool with native tool calling. Both run on Nebius Token Factory through the standard openai SDK. No other model provider is used.
• Tools read telemetry with fitted trends, the part's build record with as-flown dispositions, the operator schedule and the command path. One tool proposes an action to the policy, and another drafts a flight NCR back into the build record.
• A seeded, pure simulation. Model parameters come from record values: heater resistance sets the preheat curve, leak rate sets the blowdown, cell capacity sets the depth of discharge, and baffle stray light sets the tracker outages. Fault detection and the autonomy policy are deterministic code.
• The console. Next.js 16, React 19, Tailwind and a three.js digital twin. A timing chart compares the spec-sheet and as-built deadlines, the decision card is rendered from the policy's own record, and a lifecycle stepper follows the action.
• Trust checks on every answer. Every cited record id must come from a tool result, and every quantity with a unit must match a number a tool returned.
• Testing and evaluation. There are 63 unit tests and an end-to-end eval of 6 cases (4 scenarios plus both changed conditions) that checks cited records and autonomy tier. A typical flight run costs under one cent.

Challenges

• The model argued the wrong timing. Early runs had Nemotron's rationale say "an operator can approve at T+38" while the policy authorised the burn. We stopped letting the model state the decision at all. The card is computed, and the rationale is shown separately, flagged when the policy overrode it.
• The small router model needed guardrails. Nano only called tools reliably with reasoning on. It sometimes truncated arguments, and once abbreviated an enum ("COL" for COLLISION_AVOIDANCE_BURN). Rejected calls now don't count as done steps, they get retried, and Super takes over with a forced tool_choice.
• One number, one source. The same leak appeared as "29 m/s lost" in one place and "29 m/s remaining" in another. Fault detection, tools and policy now share one fit.
• The backstory had to hold together. If nobody is on console, how does a command reach the vehicle? We modelled an always-on relay link, so the constraint is a missing human, not a missing link. Each NCR also now records how it was accepted for flight, and that this never reached operations.
• Latency. Live runs take 27–130 s, so the console also replays recorded live runs on a compressed clock, clearly labelled.

What we learned

• The build record works as a virtual sensor. A few telemetry channels plus the vehicle's history can resolve faults the telemetry alone cannot.
• Keep the model's words and the system's decision apart. Let the model investigate and explain, but put the decision in deterministic code, show it as computed, and check the model's numbers against tool output.
• Small, fast open models make a capable agent loop once they get typed tools, a plan to follow and a fallback.

What's next

• Carry the as-flown dispositions into real operations tooling, and feed flight NCRs back to the next build.
• Move the policy's tables onboard, so the vehicle can apply the same rule when the ground is out of contact.

All data is synthetic; KESTREL-1 is a fictional smallsat. MIT licensed.

Built With

• ai-agents
• github
• nebius
• nebius-token-factory
• nemotron-3-nano
• nemotron-3-super
• next.js
• node.js
• nvidia-nemotron
• openai-sdk
• playwright
• react
• react-three-fiber
• svg
• tailwindcss
• three.js
• tool-calling
• typescript
• vercel
• vitest