What Mission Control Taught Us About School Software

When a big report dies at minute four in most student information systems, you get a blank screen and a support ticket. In ApolloSRM, a backup attempt has already started, the first one to finish wins, and a small chip in the corner tells you what happened. That difference has a name inside our platform: Flight Director. We borrowed it, along with most of the design, from the people who ran the Apollo missions.

What did Mission Control actually get right?

Three things, and they hold up fifty years later. First, telemetry over intuition: every console in Houston watched live data, and no controller argued from a hunch. Second, one decision maker: dozens of people saw anomalies, but a single Flight Director decided what to do about them. Third, one voice to the crew: only CAPCOM spoke to the astronauts, no matter how many engineers had opinions, because a crew hearing five voices under stress makes mistakes. School software fails on all three counts. It has no telemetry on its own background work, nobody deciding what to do when a job dies, and when things go wrong the user hears from everyone and no one: an error toast here, a stack trace there, a support queue at the end of it.

Why did my report fail, and why did nobody tell me?

In a typical SIS, a long-running report is fire and forget. The server starts it, and if the process dies, restarts, or hangs, nothing records that fact anywhere a human will look. The report is simply never ready. You refresh, refresh again, and eventually file a ticket that says the system is slow. ApolloSRM treats every long-running job as a guarded run: it registers when it starts, sends a heartbeat while it works, and the platform learns how long that kind of job normally takes at your school. A run that goes silent past its expected window is not a mystery. It is a detected anomaly with a policy attached.

What does a self-healing SIS actually do?

It depends on the job, and the honest answer is that the policy is chosen per kind of work, not applied blindly. A big report run that stalls gets the strongest treatment: a parallel backup attempt launches before the original is even declared dead, whichever finishes first wins, and if both finish with different answers, that disagreement is flagged for our engineers as a correctness signal. A workflow that was interrupted resumes from the last completed step instead of starting over. An integration sync that hangs is simply made visible, because it will run again on its own schedule anyway. In every case the recovery is narrated. A chip on your screen moves from Running to Recovering to Recovered, and the event lands on your Today feed. We learned the hard way that invisible help decays into invisible failure, so nothing here is silent.

What never gets fixed automatically?

Money and federal files. A stalled disbursement posting or a federal submission run is never retried by a machine, by construction, because a duplicated disbursement is a compliance incident. Those runs escalate to a human with a diagnosis attached: what stalled, when the last heartbeat landed, what the error said. The goal is a person making a good decision quickly, and that is a place where automation should hand over the controls, not grab them.

What is CAPCOM, and why only one voice?

CAPCOM is the single in-app presence that talks to you about any of this. It shows your run chips, and at most one suggestion at a time. If a run failed, it offers two buttons: Explain and Retry. Explain reads the actual telemetry of your run and answers in plain language, and it is built to say there is not enough information to diagnose rather than invent a cause. If a screen keeps failing on you, CAPCOM may offer help once, and if you dismiss the same kind of suggestion twice it stays quiet about it for a month. The anti-Clippy rules are structural, not a matter of taste: a suggestion must come with a concrete action, silence is the default, and dismissal is treated as training data.

How does the software get better when people struggle?

This is the part we are proudest of. When three or more people at different desks hit the same wall in the same week, the same error on the same screen, that pattern files itself into our engineering queue automatically, with the reproduction context attached and no personal details in it. Our nightly tooling drafts the fix and a human engineer reviews it. Struggle becomes telemetry, telemetry becomes a queue card, and the queue card becomes a repair. The rough edges of the product shrink as a function of how much it is used, which is roughly the opposite of how legacy systems age.

What about privacy?

The struggle signals that power all of this are consent gated twice: your school chooses a tracking mode, and every individual can opt out, and an individual opt out cannot be overridden by an administrator. The signals themselves are shapes, not content: which screen, which kind of friction, how many times. Never what was typed. Staff leaders see only screen-level aggregates, and any screen with fewer than five affected people is suppressed entirely, because this exists to fix screens, not to watch staff. Nothing in this system touches a grade, a rubric score, or an admissions decision.

Frequently asked questions

Why did my SIS report fail with no error message?

Most systems run reports as fire-and-forget background jobs, so a crashed or hung run leaves no trace a user can see. A system built for reliability registers every long-running job, tracks a heartbeat, and turns silence past the expected duration into a visible, recoverable event instead of a mystery.

Does ApolloSRM retry everything automatically?

No. Recovery policy is chosen per kind of work. Report runs can be safely retried and even raced with a parallel backup attempt because running them twice cannot change your data. Money movement and federal file generation are never auto-retried; those escalate to a human with a diagnosis attached.

Can my administrator see that I was struggling on a screen?

Not individually. Leaders see screen-level aggregates only, and screens with fewer than five affected people are suppressed. Capture itself requires the school's tracking mode to be on and respects each person's own opt-out, which no administrator can override.

What happens when the AI cannot explain a failure?

It says so. The Explain feature reads the real telemetry of the run and is instructed to answer that there is not enough information to diagnose rather than fabricate a cause. An honest non-answer beats a confident wrong one, in software and in Houston.