The heartbeat is steady now. Frames arrive every few hundred milliseconds. Voltages and temperatures and angles flow down the link in an orderly cadence, and a room full of people who, a quarter of an hour ago, were staring at nothing, are now reading the spacecraft's vital signs in something approaching real time. The relief lasts about ninety seconds. Then somebody at a console says the sentence that begins every operational mission in history: > *We need to send a command.* The solar arrays did deploy, but one of them is reporting a slightly elevated motor current. The attitude control mode that was hard-coded into ROM for the first orbit is fine for the first orbit and wrong for the second. The transmitter is on a default power setting that drains the battery faster than the panels can refill it. None of these are emergencies. All of them are *decisions that have to be made and acted on by a machine that does not yet know they need making.* So the operator types a command into a terminal. A few bytes of intent. The bytes go down a cable to a ground modem, get modulated onto a carrier, climb back up through the atmosphere and out through the same pass window the telemetry is coming down through, and — if everything works — arrive in a register on the spacecraft a few milliseconds later. This is the moment the link stops being a sensor and starts being an *interface.* And it is the moment every assumption we have been making quietly inverts. Everything in this chapter is a variation on a single problem. The downlink only had to be *received*. The uplink has to be *obeyed*. A telemetry stream is a confession the spacecraft cannot help making; a telecommand is an instruction the spacecraft must decide whether to accept. The whole apparatus of uplink protocols — the coding, the framing, the sequence numbers, the acknowledgements, the verification packets, the two-key procedures — exists to answer a single question with as much paranoia as the field can muster: *should this command be executed, exactly once, exactly as sent?* ## Telemetry is forgiving. Commands are not. Telemetry has a property that makes it tolerant of damage: it is *redundant in time.* If one frame is corrupted, another one arrives a fraction of a second later. The voltage reading you missed is essentially the voltage reading you are about to get. A lost telemetry frame is a small hole in a long, repeating tape. The picture is still legible. A command has no such property. A command is a *single, discrete act of intent.* If it is delivered twice, the spacecraft has done something twice. If it is delivered in pieces and reassembled wrong, the spacecraft does something different from what was meant. If it is corrupted in transit and the corruption is not caught, the spacecraft executes a command that *no one on Earth ever sent.* The asymmetry runs the other direction in another way too. The link is asymmetric in *power.* The spacecraft has a transmitter the size of a paperback. The ground has a transmitter the size of a refrigerator, driven by a klystron pushing kilowatts into a dish ten metres across. Telemetry is fragile because the spacecraft cannot shout; telecommand is, paradoxically, less fragile in the channel itself — but vastly more dangerous if it goes wrong. You can lose a telemetry frame and recover by waiting. You cannot lose half a command and recover by waiting. You cannot un-deploy an antenna. You cannot un-fire a pyrotechnic bolt. You cannot un-execute a memory write. Every protocol on the uplink is structured around this asymmetry. The frame format is different. The coding is different. The verification rules are different. The state machine is different. The whole shape of the conversation changes the moment Earth opens its mouth. ## The shape of a command A telecommand is built out of the same layers as telemetry. On paper the stack looks symmetric — coding, framing, packets, APIDs, the whole familiar pile. In behaviour it is not symmetric at all. **Every layer on the uplink is doing a job its mirror on the downlink does not: deciding whether to obey.** At the bottom is a **TC synchronization and channel coding** sublayer of its own. The bits are wrapped in a code — historically BCH, more recently LDPC — tuned not for the long, lossy reality of a deep-space downlink but for a short, bursty uplink. The receiver onboard does not need to decode a continuous stream; it needs to decide, with very high confidence, whether the small block it just heard is a valid command block or noise to be thrown away. The code is chosen so that the probability of accepting a corrupted block as valid is essentially zero. Better to reject a real command and let the ground retry than to execute a hallucinated one. Above that sits the **TC transfer frame**, the uplink cousin of the telemetry frame from the previous chapter. It carries the same kind of header — spacecraft ID, virtual channel, sequence number — plus one extra piece of machinery: a **frame acceptance check**. The spacecraft refuses to even *consider* a frame's contents unless its number, its spacecraft ID, and its virtual channel match what the spacecraft was expecting next. A duplicate is silently discarded. A frame from the future is held. A frame from the past is rejected. This is the first place in the stack where the spacecraft has *opinions*. The downlink frame layer simply emits; the uplink frame layer judges. Inside the frame is a payload — one or more telecommand packets, structured almost identically to the space packets from the previous chapter, but flagged as type "command" rather than "telemetry," with an APID naming the onboard process meant to receive them. The body is the actual instruction: a memory address and a value, a mode change, a sequence to begin, a table to load. ## The two modes of conversation There is a deep choice baked into how a spacecraft accepts commands, and almost every mission picks one of two answers. The first answer is to treat the uplink as **stateless**. Every command frame is independent. The spacecraft accepts it if it is well-formed, ignores it if it is not, and never refers to it again. This is fast, simple, and forgiving of dropouts. It is also dangerous: if the ground does not know whether a command arrived, the only way to find out is to read the telemetry that comes back afterward and look for the effect of the command. If there is no effect — because the command was lost, or because it was executed but the resulting telemetry was *also* lost — the ground has to decide whether to send it again. Send it twice and the spacecraft will execute it twice. Do not send it twice and the spacecraft may not execute it at all. The ambiguity lives entirely in the operator's head. The second answer is to make the uplink **stateful**. The spacecraft and the ground agree to keep a tiny piece of shared state — a sequence number — that advances by one for every accepted command. The ground numbers each frame. The spacecraft accepts frame N+1 only after it has accepted frame N. If a frame is missed, the spacecraft refuses everything that follows until the missing one is retransmitted. The conversation becomes a single, ordered, gap-free sequence. Replay is impossible — the same number cannot be accepted twice. Reordering is impossible — frames must arrive in order. The cost is fragility: a single missing frame stalls the whole uplink until the gap is closed. The stateful answer is the one CCSDS standardised, in a protocol with the unromantic name **COP-1**: a sliding-window protocol with retransmission, acknowledgement, and explicit gap recovery — the closest thing space data systems have to a TCP-style "reliable delivery" guarantee. But it lives at the *frame* layer, not above it. The thing it acknowledges is the envelope, not the message inside. We will return to its machinery later, in its own right; for now, take the uplink as reliable when it matters. ## Verification: the round trip that is not a round trip Suppose the command arrives. The spacecraft accepts it. COP-1 acknowledges it on the next downlink frame. The ground knows the spacecraft *received* the command. That is not the same as knowing the spacecraft *executed* it. The frame layer's acknowledgement only tells you the envelope made it through. The instruction inside the envelope is handed off to an application — the power subsystem, the attitude controller, the thermal manager — that may not run for milliseconds, or seconds, or until the next scheduled tick of the control loop. The application may decide the command is illegal in the current mode and refuse it. It may begin executing and abort halfway through. It may execute successfully and produce a result the operator did not intend. So missions layer *another* round of verification on top of COP-1, this one at the application layer. The idea is to turn a single ambiguous question — *did the command work?* — into a sequence of small, separately answerable ones. The onboard command processor first decides whether the command is syntactically valid and emits an **acceptance** packet — *accepted* or *rejected*. The relevant subsystem then begins execution and emits a **start** packet. For long-running commands — a slew, a calibration, a file transfer — it emits periodic **progress** packets along the way. When the command finishes, a final **completion** packet says whether it finished nominally or with errors. Each of these is a separate downlink packet, tagged with the original command's identifier so the ground can correlate them all back to the one keystroke that began the chain. The operator does not see "the command worked." The operator sees four small events arriving in sequence — *accepted*, *started*, *progressing*, *complete* — each one a separate piece of evidence that the spacecraft has, step by step, done the thing it was asked to do. The screen does not light up with a single green tick; it ticks four times. Until all four arrive, the command's status is, formally, *unknown* — and an operations team that respects the protocol will not send the next command until the previous one has fully closed out. This is the second protocol asymmetry. Telemetry flows because it is *generated*. Verification flows because it was *requested*. The downlink is now carrying two intermingled kinds of data: the spacecraft's autonomous report on its own state, and its directed answers to the ground's questions. The same APID multiplexing we built in the last chapter is what keeps them sorted. ## The commands you cannot take back Most commands are reversible. A mode change can be changed back, a pointing offset re-offset, a scheduled activity cancelled before it starts. A small number of commands are not — and the whole shape of operations on a real mission is organised around that minority. When you fire a pyrotechnic bolt, the bolt is fired. When you vent a propellant tank, the propellant is gone. When you overwrite a region of program memory, the previous contents are not preserved unless you put them somewhere first. When you switch off the primary transmitter to test the redundant one, the primary may not switch back on. When you upload new flight software and reboot into it, the old software is no longer in control and the new software has not yet proven it can take a command. These are the commands that keep mission directors awake. They are the reason every operations team has a **two-key procedure**: one operator types the command, another operator reviews it on a separate screen, and *both* must explicitly authorize before the command leaves the ground. They are the reason the command database tags every command with a hazard level. They are the reason some commands cannot be sent at all without an uplink password the operations lead carries in a sealed envelope. The whole point of the verification stack — acceptance, start, progress, completion — is to make sure that, *if* something went wrong, you find out *before* you send the next irreversible command. Verification is not paperwork. It is the brake. This is also where the latency of the previous chapter returns with teeth. On a LEO mission, an irreversible command's full verification cycle takes a few seconds. On a Mars mission, it takes the better part of an hour. The operator who sent the command will not know whether it worked until long after the moment of action has passed. So missions do not send irreversible commands at Mars distances unless they are confident *the next forty minutes of consequences are acceptable in every branch* — the one where it worked, the one where it failed, and the one where the spacecraft cannot tell them which. ## Trust, designed in advance Everything in this chapter is, in the end, a single argument: *trust across space must be designed before it is needed.* You cannot bolt on authentication after a hostile actor has discovered your uplink frequency. You cannot retrofit sequence numbers after the spacecraft has accepted a duplicate command and tumbled. You cannot add verification packets after the first irreversible command has fired into silence. Every safeguard has to be sitting in the protocol — in the frame format, in the acceptance check, in the verification schema, in the procedures the operators follow — *before* the moment that needs it arrives. The reason these protocols look so paranoid on paper is that they were written by people who had already been bitten by every failure mode they prevent. The two-key procedure is in the operations manual because some mission, somewhere, lost itself to a single keystroke. The application-layer verification packets exist because some mission, somewhere, thought the frame-layer acknowledgement was enough and watched a half-executed command drift the spacecraft out of contact. The frame acceptance check exists because some uplink, somewhere, locked onto a noise burst that happened to decode into a valid-looking command. The protocols are scar tissue. Each one was paid for once, in the currency of an actual spacecraft. The discipline of the field is to inherit those scars *without* needing to acquire them again. ## What we have built Step back. Look at what the first three chapters have, together, assembled. A spacecraft that is in contact. A receiver that has locked, in three nested loops, onto a moving, drifting carrier. A channel decoder that pulls trustworthy bits out of soft noise. A frame layer that delivers numbered, structured envelopes in both directions. A packet layer that lets dozens of onboard processes share a single pipe without collision. An uplink that refuses to be tricked, that orders its commands strictly, that retransmits when it must. A verification stack that turns the unanswerable question *did it work?* into a sequence of small, answerable ones. This is **the link**. Everything beyond this point in the primer assumes the link exists. The chapters that follow will not return to the question of *whether the spacecraft can be heard.* They will ask, instead, what the spacecraft does when no one is listening — when the pass ends, when the geometry pulls the dish below the horizon, when the link goes silent not because anything has failed but because that is what links do. The spacecraft is about to spend twenty-three of every twenty-four hours on its own. Because the frame-layer acknowledgement only confirms that the envelope was delivered intact — it says nothing about whether the instruction inside was valid, whether the relevant subsystem accepted it, whether execution actually began, or whether it completed nominally. Each of those is a separate failure mode at a separate layer. The verification stack (acceptance → start → progress → completion) turns each layer's silent success into an explicit downlink event, so that the next irreversible command is sent only after the previous one's consequences are fully visible. The pass is ending. The dish at Svalbard is already tracking the spacecraft toward the opposite horizon. In a few minutes the link will fall away and the spacecraft will be alone — not metaphorically, not partly, but completely. What it does next is something it must decide for itself.

In this chapter