Mission team and operations: decide far from Earth

Many Earth-orbit operations can rely heavily on a real-time ground team. Mars breaks that assumption: light-time alone introduces minutes of delay and outages are possible. Mission teams need intent-based work, complete information packages, adaptable procedures and explicit local authority. This module treats operations as an engineered subsystem.

1. A role needs both authority and information

“The commander decides” is incomplete. Decides what, within what time, using which data and up to what risk? Responsibilities can be distributed across immediate safety, vehicle systems, medical work, navigation, science and maintenance. A small crew may combine roles, but ownership should remain explicit.

An operational role is more than a title. It combines decision authority, access to information and responsibility for handover. If two people both believe they own an urgent action, they may act in parallel; if each assumes the other owns it, nobody acts. Procedures therefore state who may stabilise the system, who authorises irreversible action and who maintains the timeline. Authority can change with mission phase and communications delay. During a Mars emergency, the local crew necessarily has more autonomy than a crew near Earth. That autonomy must be prepared through boundaries, thresholds and training rather than improvised after the anomaly begins.

2. Latency turns conversation into delayed messaging

With t = 12 min one-way light-time, the minimum round trip is about 2t = 24 min. Three sequential clarifications already consume more than an hour before analysis time. Efficient Mars communication therefore bundles context, evidence, actions taken, constraints and the requested decision.

With many minutes of one-way delay to Mars, conversation becomes asynchronous messaging. A poorly formed question can waste an entire light-time cycle before useful analysis even starts. A message to Earth should therefore contain current state, trend, configuration, actions already taken, hypotheses and the decision being requested. Earth should respond in the same style, stating assumptions that make the advice valid. Communications time becomes an operational resource. The local team continues stabilising and measuring while remote analysis proceeds. This prevents Earth from becoming a slow remote control for a system that evolves faster than the dialogue can complete.

3. Procedure, checklist and mission intent are different tools

A procedure describes sequence; a checklist protects critical points from omission; mission intent explains what outcome must survive when the case no longer matches the script. Autonomous teams need all three. A checklist cannot invent a response to a novel failure, while broad intent can be too vague under stress.

A procedure describes a controlled method; a checklist protects against omission of critical items; mission intent explains the outcome to preserve when reality leaves the written case. Confusing these tools creates either enormous lists or uncontrolled improvisation. An irreversible action may require an observable condition and confirmation. A frequent routine may need only a short checklist. When the crew encounters an unanticipated state, intent—preserve habitable pressure before science productivity, for example—supports judgement. Training therefore teaches not only how to execute steps but how to recognise when the procedure no longer matches the actual system state.

4. Handover carries assumptions and capability debt

Shift change should transfer open anomalies, temporary configurations, consumed margins, deferred work and the rationale behind decisions. “Pump B isolated” is less useful than “Pump B isolated after unstable current; Pump A running; no redundancy until the planned 18:00 test.” The log becomes shared operational memory.

A good handover transfers more than open tasks. It carries assumptions, weak anomalies, consumed margin and deferred decisions. A pump may still operate while current slowly drifts; if that fact disappears at shift change, the next alarm will look sudden. The log should separate measured fact, interpretation and action. A practical structure can include current state, changes since the last watch, active risks, prohibited activities, decisions pending and wake-up thresholds. The goal is not to write a novel at every handover but to preserve enough operational memory that the incoming team does not have to reconstruct context under pressure.

5. Schedule real human capacity, not perfect nominal utilisation

Crew time, sleep, expertise and EVA hours are resources. A six-hour two-person repair may be impossible when another anomaly requires continuous monitoring. Plans need reserve capacity for the unplanned rather than scheduling every person to 100 percent nominal utilisation.

Human capacity can be budgeted like electrical energy. A day with 40 theoretical person-hours should not be scheduled to all 40 if the mission needs anomaly response. Reserving 20 percent leaves 8 person-hours unassigned, although the right fraction depends on phase, fatigue and risk. Presence is not the same as competence: four available people do not replace two specialists if a repair requires particular qualification. Schedules also include sleep, meals, exercise, habitat maintenance, training and documentation. A resilient mission accepts that some capacity remains deliberately unproductive during nominal operations because that reserve is what makes off-nominal work possible.

6. Automation should make safe reactions fast and ambiguous decisions explainable

Automation excels at monitoring and bounded rapid response. When judgment is required, it should expose the evidence, affected functions and confidence behind a recommendation. An alarm that says only “critical fault” adds cognitive load; an alarm that explains trend and safe options supports autonomy.

Automation is valuable when it makes a safe reaction faster and repeatable. It becomes dangerous when it hides uncertainty or performs an irreversible action from a weak diagnosis. A good interface shows what triggered the action, which evidence supports the interpretation and what condition permits return. Humans need a practical way to take over when context exceeds the model, but ‘manual control’ cannot mean hundreds of low-level commands that no tired operator can manage. Degraded modes therefore combine minimum trustworthy automation, clear procedures and a readable state representation. The objective is to reduce cognitive load rather than move opacity from one layer to another.

7. Manage anomalies as stabilise, understand, recover

Stabilise prevents further deterioration. Understand gathers evidence and narrows causes. Recover restores functions in controlled sequence. Mixing the phases can produce premature repair commands before the actual state is understood.

Anomaly management can be organised as stabilise, understand, recover. Stabilise means stop escalation even when the exact cause is unknown. Understand means collect evidence, compare hypotheses and identify dependencies. Recover returns the service to a sustainable state and proves that return. Jumping directly to repair can destroy evidence or create a second fault. The crew also preserves a timeline of commands and observations so Earth or the next watch can reconstruct the event. This sequence is particularly useful under delay because it creates a coherent anomaly package while the spacecraft remains in a controlled state.

8. Failure scenario: technical anomaly after poor sleep

A fatigued team does not have the same decision performance as a rested one. If the anomaly can be stabilised safely, the rational response may be to automate monitoring, defer complex repair, prepare tools and restore crew readiness. Human safety includes fatigue management, not just technical compliance.

Fatigue changes perception, working memory, decision speed and risk tolerance. The system should not assume the crew can always execute a complex procedure at peak cognitive performance. Critical work can be delayed when a stable mode exists; urgent actions should be short, observable and supported by clear interfaces. Cross-training also reduces dependence on the most expert individual if that person is ill or exhausted. In a combined technical failure and poor-sleep scenario, the rational first choice may be to stabilise the system and let a rested team conduct the detailed diagnosis later. Human resilience depends on the ability to buy time.

9. Ask Earth questions that remain useful after delay

Earth is valuable for deep independent analysis. The crew can ask “compare repair A and B for our present configuration” instead of “tell us what to do now.” This lets Earth exploit expertise without pretending to close a real-time loop it physically cannot close.

A question sent to Earth should still be useful when the answer returns. ‘What do we do now?’ is weak if the reply arrives forty minutes later and the state has changed. A stronger request defines branches: if temperature exceeds X, the crew will isolate the loop; otherwise it will hold the current mode until a stated time. Earth can then analyse each future state, challenge thresholds and propose actions that remain applicable. This turns delay into parallel work. Messages need units, timestamps, configuration versions and uncertainty so a recommendation is not accidentally applied to a system state that no longer exists.

10. Lessons learned need controlled change

After an incident, procedures may change. The change should retain version, rationale, evidence, approval and rollback. A successful one-off workaround is not automatically a universal rule. Operational knowledge should evolve with the discipline of a well-managed software configuration.

Lessons learned matter only when they change work in a controlled way. After an anomaly, the team separates immediate correction, probable cause, evidence obtained, procedure change and required test. A new version should identify what changed and why. Silently replacing a checklist destroys the ability to understand earlier decisions; never changing it preserves a known weakness. The process therefore combines memory with evolution. On Mars, the same principle applies to physical configuration: a maintenance procedure must know which sensor version, firmware build or locally manufactured part is actually installed before prescribing an action.

11. Mini-project: run a degraded Mars day

1. Define four crew roles.
2. Create a schedule with 20 percent time reserve.
3. Add a 10:00 fault and two-hour Earth outage.
4. Write a stabilisation checklist.
5. Prepare the delayed Earth message.
6. Plan evening handover.
7. State how the procedure changes after review.

The purpose is to show that the organisation still functions when the nominal plan disappears.

Sources and references