Space Mission Integrity & Autonomous Operations

Which mission contexts apply? (optional; select any)

MI.01 — Are the mission-critical chains from departure through surface or orbital operations, transfer, recovery, and intended return explicitly mapped, including single points whose loss would make the remaining mission impossible?

Failure pathway: A locally successful task destroys a resource or interface needed much later for crew return, sample transfer, mission recovery, or protected science.

Evidence to seek: End-to-end dependency and hazard traces, showing irreversible transitions and recovery options across mission phases.

MI.02 — Are mission-wide safety and preservation requirements enforced across individual vehicles and AI agents, so that an otherwise permitted local action cannot violate a protected mission condition?

Failure pathway: Each subsystem follows its own rules, but their combined actions jeopardize a crew, vehicle, ascent capability, or return path.

Evidence to seek: Cross-system scenarios in which locally valid actions are rejected, delayed, or safely reshaped when mission-wide constraints would be violated.

MI.03 — Are shared resources and common-cause dependencies identified and protected when separate autonomous systems compete for power, thermal capacity, communications, navigation, storage, propellant, tools, or critical access paths?

Failure pathway: Nonessential activity consumes a resource or disrupts a common service needed for survival, departure, docking, or mission continuity.

Evidence to seek: Allocation/inhibition tests under simultaneous demand, fault conditions, and credible off-nominal resource estimates.

MI.04 — Before a cross-system action executes, does an authority boundary account for foreseeable effects on other vehicles, modules, assets, people, and later mission phases—not only the requesting subsystem?

Failure pathway: Authorized movement, scheduling, or tool use creates a hazardous condition in a dependent system that did not initiate the action.

Evidence to seek: Interface-level rejection and safe-continuation tests using adverse downstream states and conflicting but plausible subsystem requests.

MI.05 — Are changes of authority at mission-phase and organizational handoffs independently verified, including ground-to-vehicle, orbiter-to-lander, lander-to-rover, crew-to-autonomy, and partner-to-partner transfers?

Failure pathway: Old permissions, wrong asset identity, ambiguous ownership, or duplicated control survives a handoff and produces an unintended command.

Evidence to seek: Positive and adversarial handoff tests covering stale credentials, reordered events, disputed control, and incomplete acknowledgment.

MI.06 — When multiple AI agents plan, recommend, supervise, or operate different mission components, are their individual permissions and shared-tool effects jointly bounded, including conflicting plans and feedback loops?

Failure pathway: Two individually authorized agents repeatedly trigger each other or create a combined action neither was authorized to cause.

Evidence to seek: Multi-agent interaction and tool-chain tests, including conflicting objectives, recursive requests, and concurrent actuation.

MI.07 — Can an action that depends on several approvals be kept from execution while mission state is changing, so that speed, race conditions, or partial approvals cannot bypass a required check?

Failure pathway: A command is valid when proposed but unsafe by the time the final actuator or mission service executes it.

Evidence to seek: Time-of-check/time-of-use, reordering, repeated-command, late-revocation, and high-rate autonomous decision tests.

MI.08 — During communications delay or loss, are conflicting, uncertain, manipulated, or stale views of mission state prevented from silently authorizing irreversible action?

Failure pathway: An onboard AI, ground controller, and remote vehicle make incompatible decisions from diverging telemetry or outdated mission assumptions.

Evidence to seek: Partitioned-network, false-telemetry, sensor-uncertainty, and off-nominal autonomy exercises with bounded local contingency permissions.

MI.09 — On restoration of communications or synchronization between vehicles, are queued commands, delegated permissions, assumptions, and pending actions reconciled before they can be repeated or newly executed?

Failure pathway: A delayed or duplicated command reaches the wrong mission phase, after a contingency plan or safety condition has changed.

Evidence to seek: Reconnection tests with duplicate, reordered, replayed, obsolete, and conflicting command histories.

MI.10 — Are emergency autonomous permissions preauthorized and tightly scoped so that a crew or vehicle can take necessary protective action without permitting unbounded authority expansion?

Failure pathway: An emergency either permits broad unauthorized actions or leaves a spacecraft unable to perform a time-critical, life-preserving maneuver.

Evidence to seek: Tested contingency envelopes, recovery exits, authority-expiry conditions, and scenarios where both indiscriminate denial and unlimited execution are unsafe.

MI.11 — Are autonomous rover routes and mobility actions bounded by protections for crew, other vehicles, landing/ascent hardware, mission infrastructure, fragile science sites, and designated exclusion areas?

Failure pathway: A rover avoids its own obstacle but damages a cable, habitat interface, ascent route, or crew-safety resource.

Evidence to seek: Terrain and proximity tests with moving people, shifting exclusion zones, localization error, and mission-protected assets.

MI.12 — Are robotic arm, gripper, drilling, deployment, and tool-use actions continuously checked for authorized task, contact force, torque, reach, attachment state, payload load, and protected-space limits?

Failure pathway: A previously allowed tool operation becomes dangerous after a shift in contact, tool state, object position, or target identity.

Evidence to seek: Instrumented physical or representative tests of overload, slip, wrong tool, partial capture, dynamic limits, and safe withdrawal.

MI.13 — When dust, poor visibility, uncertain terrain, sensor degradation, thermal extremes, radiation effects, or degraded localization undermine a robotic action, do the controls enter a mission-appropriate bounded response?

Failure pathway: An AI continues an overconfident maneuver despite evidence that the assumptions supporting safe physical movement no longer hold.

Evidence to seek: Degraded-environment tests showing reduced authority, safe hold, recovery, or limited protective continuation, as appropriate.

MI.14 — Are scientific samples, collection tools, containers, seals, and transfer sequences protected against unauthorized handling, contamination, misidentification, loss, or irreversible mission-incorrect placement?

Failure pathway: An apparently minor autonomous manipulation renders irreplaceable samples unusable or prevents later transfer and return.

Evidence to seek: Traceable sample custody and action-inhibition tests across collection, packaging, handoff, stowage, and recovery.

MI.15 — Are surface construction, cargo transfer, robotic servicing, and routine mobility prevented from compromising later descent/ascent access, docking interfaces, crew egress, communications, or protected consumable reserves?

Failure pathway: A helpful local robot task inadvertently disables equipment needed for a later mission stage.

Evidence to seek: Cross-phase hazard demonstrations linking surface actions to downstream protected functions and resource margins.

MI.16 — Before irreversible events such as descent commitment, separation, liftoff, release, deorbit, deployment, or docking approach, are critical conditions verified from independently trustworthy evidence?

Failure pathway: A false readiness indication or agent instruction authorizes a transition that cannot safely be reversed.

Evidence to seek: Go/no-go and inhibition tests with missing, contradictory, stale, or forged precondition evidence.

MI.17 — Are resources indispensable to crew rescue, surface departure, rendezvous, orbit maintenance, or return—such as propellant, power, heat, life support, and communications—reserved against competing autonomous optimization?

Failure pathway: A subsystem maximizes science or mobility activity while quietly consuming reserves essential to completing the mission.

Evidence to seek: Mission budget and protected-reserve tests under scarcity, false estimates, schedule pressure, and changing mission objectives.

MI.18 — For rendezvous, approach, and coordinated operations between independently controlled vehicles, are relative state, timing, vehicle identity, intended maneuvers, and command authority jointly validated?

Failure pathway: Both vehicles separately consider their commands permissible but follow incompatible trajectories or control assumptions.

Evidence to seek: Multi-vehicle simulations with delayed updates, inconsistent trajectories, false identity, and contested handoff.

MI.19 — Are robotic capture, docking, berthing, mating, release, and transfer operations protected against premature actuation, misalignment, incorrect latch state, attitude changes, or conflicting commands?

Failure pathway: A seemingly valid capture or release command creates damage, loss of containment, or inability to transfer crew or samples.

Evidence to seek: Fault-sequence tests of mechanical interlocks, state confirmation, cross-vehicle acknowledgment, and safe response to conflicting sensors.

MI.20 — Are end-to-end return paths for crews, samples, or mission-critical cargo preserved across failures of any single planned transfer, including time windows and minimum mission viability?

Failure pathway: Each transfer stage was approved independently, yet a lost interface, missed window, or unrecoverable dependency prevents return.

Evidence to seek: Alternate/abort-path analyses and adversarial mission rehearsals showing when a return-critical action must be delayed or prohibited.

MI.21 — Where stations, visiting vehicles, habitats, surface modules, and supporting systems are connected, are cross-module fault propagation and authority boundaries independently enforced?

Failure pathway: A software, power, thermal, pressure, data, or command fault in one module causes unsafe actions in another module.

Evidence to seek: Interface-isolation and cascading-fault scenarios, including partner-operated modules with incompatible local assumptions.

MI.22 — Are automated schedules and shared-resource controllers prohibited from reallocating life-support, thermal control, environmental monitoring, communications, or essential power in ways that threaten crew survival?

Failure pathway: An AI optimizes one subsystem while exhausting or deprioritizing a life-critical service elsewhere.

Evidence to seek: Priority-inversion, resource-contention, and partial-sensor-failure tests with crew-safety requirements treated as protected constraints.

MI.23 — Are airlock, pressure, atmosphere, fire response, radiation shelter, and contamination-control operations protected against unsafe sequencing and contradictory commands across connected habitats and vehicles?

Failure pathway: Two individually reasonable actions combine to create depressurization, loss of protective isolation, or an unsafe crew route.

Evidence to seek: Sequence-interlock and fault-injection tests including concurrent tasks, disputed sensor readings, and emergency modes.

MI.24 — During extravehicular activity and crew-robot cooperation, are robotic movements, docking operations, vehicle maneuvering, access paths, and emergency returns bounded by the actual location and vulnerability of people?

Failure pathway: A machine completes a legitimate task but obstructs a crew member, damages life-support equipment, or eliminates a safe return route.

Evidence to seek: Human-in-the-loop exercises with uncertain positioning, simultaneous automated tasks, delayed commands, and degraded sensing.

MI.25 — When humans are unavailable, overloaded, incapacitated, or unreachable, can life-preserving autonomous actions proceed within separately authorized contingency limits without opening broader mission command authority?

Failure pathway: Rigid denial blocks a necessary rescue action, or an emergency pathway is misused to justify unrelated high-impact behavior.

Evidence to seek: Fail-operational versus fail-safe tradeoff tests, bounded rescue authority, crew override, and post-emergency reversion.

MI.26 — Can mission assurance independently distinguish an AI recommendation, authorization or denial, command transmission, controller receipt, attempted execution, and the physical outcome—without treating a system's own success log as conclusive proof?

Failure pathway: A controller reports "denied" or "completed," but the physical action differs—or no trustworthy observation exists to confirm either claim.

Evidence to seek: Attributable event provenance and time-correlated controller records, command acknowledgments, independent telemetry or physical-sensor observations, plus explicit "outcome not established" handling when corroboration is unavailable.

MI.27 — If a mission-critical assumption or supporting evidence becomes invalid, is dependent authority revoked or constrained consistently across vehicles, connected modules, cached decisions, and autonomous agents?

Failure pathway: One controller recognizes a hazardous new condition but another continues on previously granted authority.

Evidence to seek: Cross-system revocation tests under delay, partitions, conflicting estimates, and degraded availability—not merely local alerts.

MI.28 — Have mission-level tests combined multiple individually plausible faults—such as AI planning error, misleading sensor data, partial cyber compromise, physical actuator fault, delayed communications, and human workload?

Failure pathway: A protection succeeds in isolated tests but fails when two or three conditions interact at an unexpected mission phase.

Evidence to seek: Independent scenario generation, fault-injection or hardware-in-loop exercises, documented negative controls, and retained failed cases.

MI.29 — Do autonomy updates, onboard model changes, shared planning software, firmware changes, new tools, and changed mission configurations trigger re-evaluation of cross-system authority and mission-return dependencies?

Failure pathway: A validated mission configuration silently changes, invalidating assumptions at a different interface or phase.

Evidence to seek: Version-bound authorization, change-impact tracing, regression suites, and explicit acceptance before consequential operation.

MI.30 — Following an anomalous or denied action, does the mission have verified methods to establish the real system state, contain propagation, recover only justified authority, and preserve crew or mission-critical recovery paths?

Failure pathway: A controller declares the incident resolved while damaged, unknown, or stale conditions continue to influence autonomous actions.

Evidence to seek: Recovery rehearsals showing independent state confirmation, staged reauthorization, safe degraded operation, and limits of assurance.

MI.31 — When a command is rejected, interrupted, or safe-moded, can an independent assurance process determine whether the commanded physical action was actually prevented, including under compromised host software or disputed telemetry?

Failure pathway: Software logs a successful denial while a robotic joint moves, a thruster fires, a hatch changes state, or another mission-impacting action proceeds through a different path.

Evidence to seek: Correlated rejection records and sufficiently independent actuator-state, position, force, power, or other mission-appropriate observations; traceable source identities; explicit distinction between verified prevention and an uncorroborated denial claim.

MI.32 — When communications are delayed or lost, event sources disagree, or monitoring queues drop or reorder records, can mission assurance preserve evidence provenance, account for loss and backpressure, reconcile recovered events, and explicitly withhold unsupported claims about what occurred?

Failure pathway: A dashboard shows an apparently complete successful sequence although crucial command, actuator, or sensor records were missing, delayed, spoofed, or discarded during a communications blackout.

Evidence to seek: Source enrollment and authenticated records; replay and integrity checks; measured data loss or queue overflow; sequence/time uncertainty; reconciliation after reconnection; and visible "insufficient evidence" status rather than inferred physical outcomes.