Systems engineering for AI-enabled space systems controls mission behaviour, data, models, software, hardware, operating envelopes and human authority as one assurance problem. The team must trace each AI-dependent claim to configuration-specific evidence, define safe behaviour when confidence or context falls outside approved bounds, and reassess that evidence whenever a model, dataset, threshold or surrounding system changes.
This topic is distinct from using AI to help systems engineers. A drafting assistant can support requirements work without becoming part of the spacecraft. An onboard vision model, autonomous planner or ground anomaly agent influences the delivered system's behaviour and therefore belongs inside its technical, safety and verification baseline.
| Discipline | Object being controlled | Central assurance question |
|---|---|---|
| AI for systems engineering | A tool that assists engineers with analysis, drafting or coordination | Can authorised people inspect, correct and approve its provisional output? |
| Systems engineering for AI | A delivered system whose behaviour depends on AI, machine learning or an agent | Can the programme justify behaviour and risk for the applicable configuration and operating envelope? |
Why do AI-enabled space systems need a wider assurance boundary?
Conventional spacecraft software can already be complex, adaptive and state-dependent. Learned and generative components add another source of variation: behaviour is influenced by data, model architecture, parameters, thresholds and the distribution of conditions encountered in operation. A source-code review alone cannot describe every relevant behaviour.
The assurance boundary therefore includes more than a model file. It includes the sensors and preprocessing that form its inputs, the software and hardware that execute it, the decision logic that consumes its outputs, fallback paths, operator controls and the environment in which claims are intended to hold. An accurate model can still create an unsafe system if a threshold, interface unit or mode transition is wrong.
NASA's public AI and Software Assurance guidance discusses lifecycle assurance considerations for AI systems. ESA has also published work on verification and validation of autonomous systems. These sources do not provide a universal certification recipe. They reinforce the need to make the assurance strategy explicit and proportionate to the application.
What kinds of behaviour must the requirements distinguish?
| Behaviour class | Example | Requirements implication |
|---|---|---|
| Deterministic | A commanded safe-mode transition when a monitored limit is exceeded | Specify the trigger, timing, state and observable result directly |
| Learned or probabilistic | A vision model estimates relative pose with context-dependent uncertainty | Define the approved envelope, performance distribution, uncertainty handling and fallback |
| Generative | A ground assistant proposes an anomaly-recovery procedure | Constrain sources, output form, prohibited actions, review authority and acceptance tests |
| Agentic | An autonomy function selects and sequences permitted planning actions | Bound its objective, action space, resources, stopping conditions and escalation path |
A system can combine all four. Deterministic monitors may constrain a learned perception function, while a planner selects from pre-authorised actions and a human operator can inhibit execution. The requirement set should describe those interactions rather than label the whole system “AI autonomous”.
Performance requirements need more than a single average accuracy value. Depending on the mission, the team may need to define classes of operating condition, false-positive and false-negative consequences, uncertainty calibration, response time, resource use and behaviour under corrupted or missing inputs. Thresholds should connect to a system decision and hazard control, not appear as isolated model metrics.
Which AI artefacts should become controlled engineering items?
An engineering item needs control when changing it can alter an accepted behaviour or invalidate evidence. The exact list depends on the implementation, but an AI-enabled space programme should consider the following:
- Model artefact and version: the executable model, architecture and parameter set used by the target system.
- Training, validation and evaluation data: dataset versions, provenance, labels, exclusions, transformations and known limitations.
- Preprocessing and post-processing: calibration, normalisation, filtering, coordinate transforms and decision logic around the model.
- Thresholds and operational parameters: confidence gates, planning weights, resource limits and fallback triggers.
- Prompts and tool permissions: for a generative or agentic component, the controlled instructions, available tools and action constraints.
- Execution environment: software dependencies, target processor, numerical precision, accelerator and timing configuration.
- Monitoring and recovery configuration: health indicators, drift or out-of-distribution signals, operator alerts and safe-state behaviour.
Not every dataset row needs to become a requirement object. The programme does need a stable identifier and lineage for the dataset version supporting an accepted claim. A reviewer should be able to reconstruct which model, data, code, hardware and thresholds produced the result.
Which requirements must be fixed before hardware commitment?
AI development is exploratory, but hardware and mission decisions still need timely constraints. Before committing sensors, processors, memory, power, thermal design or communications, the team should define the required system outcome, critical input characteristics, latency, resource limits, authority boundaries, fallback behaviour and the minimum evidence strategy. Leaving those decisions to model training can produce a capable algorithm that does not fit the spacecraft.
Other statements may begin as hypotheses. The team might not yet know which image-quality boundary gives robust pose estimation or which uncertainty threshold balances unnecessary aborts against missed hazards. Record the assumption, responsible investigation, decision date and hardware consequence. When evidence supports a limit, promote it through the controlled requirement and change process.
This avoids false precision without allowing an indefinitely fluid baseline. “The model will determine the requirement” is not an adequate plan when supplier interfaces or safety controls depend on the answer. A useful requirement identifies what the system must achieve and how uncertainty will be handled, even while the implementation remains open.
A trace chain for AI-dependent mission behaviour
A connected assurance chain lets reviewers move from mission intent to the exact evidence supporting the current configuration. The chain also provides the path used for change impact.
| Trace stage | Example record | Question it answers |
|---|---|---|
| Mission need | Complete final approach without violating the keep-out zone | Why is autonomous perception needed? |
| System behaviour | Estimate relative pose and uncertainty inside the approved approach envelope | What outcome and boundary must the system provide? |
| Hazard and control | Prevent manoeuvre commitment when perception confidence is insufficient | What consequence is being controlled? |
| AI and interface requirement | Input quality, latency, uncertainty output and threshold behaviour | What must the model and surrounding system expose? |
| Controlled configuration | Dataset, model, preprocessing, threshold, software and flight hardware versions | Which exact implementation is under review? |
| Verification activity | Scenario simulation, robustness test and hardware-in-the-loop execution | How was behaviour challenged? |
| Evidence and result | Configuration-specific reports, anomalies and accepted limits | What was observed and accepted? |
| Operational monitoring | Confidence, input-quality and fallback-event telemetry | Does flight behaviour remain inside the justified envelope? |
The chain should distinguish evidence from interpretation. A simulation run is evidence of what happened under its scenario and configuration. The engineering claim explains which requirement it supports, why the scenario set is adequate and what limitations remain. Approval records who accepted that claim for the programme decision.
Worked example: updating an onboard vision model for autonomous rendezvous
Consider a servicing spacecraft that uses an onboard vision model to estimate relative pose during approach to a cooperative target. A new model version improves performance on imagery containing high-glare backgrounds. The change appears local because the command interface and output fields are unchanged. A systems view shows why the update still needs controlled impact analysis.
1. Define the proposed change and configuration
The proposal identifies the current and candidate model artefacts, training and evaluation dataset versions, preprocessing code, confidence calibration, target flight processor and rendezvous-software build. It explains why the update is needed and which operating scenarios are expected to change. The baseline model remains approved while the candidate is evaluated in a branch.
2. Follow affected requirements and hazards
The model traces to pose-error, update-rate and uncertainty-output requirements. Those statements connect to guidance constraints, the keep-out-zone hazard control, approach-mode entry criteria and the abort transition. The team asks whether the new error distribution or confidence calibration changes when manoeuvre commitment is allowed, even though the interface schema is constant.
3. Challenge the intended operating envelope
The evaluation includes nominal lighting, high glare, eclipse transition, partial occlusion, sensor noise, unexpected target attitude and corrupted frames. Scenarios cover regions near the acceptance boundary, not only average mission cases. The team records false-confidence events and fallback behaviour as well as aggregate pose performance.
4. Repeat integrated evidence
Model-level results are not enough because timing and numerical behaviour depend on the target platform. The candidate runs through software-in-the-loop and hardware-in-the-loop scenarios using the flight-representative processor and sensor pipeline. The programme checks latency, memory, thermal duty, interface timing, mode transitions, watchdog behaviour and the deterministic abort path.
5. Decide which evidence remains applicable
Sensor-interface tests may remain valid when their assumptions and code are unchanged. Pose-performance and confidence evidence tied to the former model cannot simply be inherited. Guidance tests that consumed recorded outputs may also become suspect if the new distribution crosses decision thresholds. Each evidence item receives a recorded remain-valid, supplement, repeat or retire decision with rationale.
6. Approve, limit or reject the update
The review compares the candidate's evidence with mission and hazard claims. It may approve the model for the complete envelope, restrict it to defined modes, retain the former model or request further evidence. The model does not approve itself, and a better mean metric does not override an unacceptable boundary case.
How should model or dataset changes reopen evidence?
Every accepted result applies to a defined configuration and set of assumptions. A model change can affect behaviour directly; a dataset change can alter learned parameters; a preprocessing change can alter the effective input; and a threshold change can alter the system decision even when the model is identical.
When one of these items changes, follow typed relationships to requirements, hazards, interfaces, tests and evidence. Mark potentially affected evidence as suspect rather than immediately invalid or silently valid. The responsible reviewers decide whether the evidence remains applicable, needs a focused supplement or must be repeated. Their rationale becomes part of the change record.
The impact path should include unconnected effects. If an energy budget, processor load or operator procedure is not currently traced to the model configuration, the assessment still needs a checklist or architecture review capable of finding it. Traceability is a strong starting point, not an automatic completeness proof.
What verification evidence is useful for AI-enabled behaviour?
No single method establishes every claim. A programme can combine data review, model evaluation, robustness analysis, simulation, software-in-the-loop testing, hardware-in-the-loop testing, integrated system tests and operational monitoring. The selected methods should correspond to the behaviour, consequence and uncertainty being controlled.
Dataset evidence addresses provenance, relevance, coverage, labelling and known gaps. Model evidence addresses performance, calibration, robustness and failure cases for a fixed configuration. System evidence addresses timing, interfaces, resources, mode transitions, fallback and mission effects. Operational evidence can reveal whether the encountered environment remains consistent with the justified envelope.
Passing evidence should not hide negative results. Record anomalies, excluded cases and known limitations alongside accepted performance. A credible assurance argument explains why the combined evidence is sufficient for the authorised use and what conditions trigger restriction, fallback or human intervention.
How does continuous assurance fit lifecycle reviews?
Continuous assurance means maintaining the trace chain, assumptions, evaluation results and change status as the design evolves. It does not mean continuously changing a flight baseline or replacing formal reviews with a dashboard. The V-model remains useful because requirements, architecture, implementation and verification still need corresponding evidence.
Before SRR, the programme should make the AI-dependent mission need, authority boundary, critical behaviours and assurance strategy visible. By PDR, it should establish the operating envelope, architecture constraints, controlled-item model, hazard controls and planned evidence. By CDR, the implementation configuration, integrated verification design, fallback paths and acceptance criteria should be mature enough for the programme decision.
Between gates, automated checks can flag missing links, changed assumptions, stale results and configuration mismatches. Review boards still judge sufficiency. The NASA assurance-strategies research and the NIST AI Risk Management Framework offer useful perspectives for structuring governance and evidence, but each mission must tailor its assurance case.
A practical implementation checklist
- Define the mission decision or behaviour that depends on AI and the consequence if it is wrong.
- Draw the complete assurance boundary across data, model, software, hardware, operators and environment.
- Separate deterministic, learned, generative and agentic behaviours and state their authority limits.
- Identify controlled artefacts, versions, relationships and the owner of each accepted claim.
- Define the operational envelope, uncertainty handling, monitoring and deterministic fallback.
- Build an evidence strategy across data, model, integrated system and flight operations.
- Use change impact to reopen affected evidence when models, data, thresholds or dependencies change.
- Keep lifecycle-gate decisions human, explicit and traceable to configuration-specific evidence.
How Arc can support the assurance record
Arc can organise requirements, architecture, controlled items, tests, evidence and changes in a connected programme record. For an AI-enabled system, that structure can link a mission claim to model and dataset identifiers, verification activities, results and operational constraints. Branches can keep a candidate model update separate from the approved baseline while reviewers inspect its technical impact.
Arc does not establish that an AI component is safe or compliant. The programme's qualified engineers and authorised reviewers define the assurance strategy, assess the evidence and accept the residual risk. The tool's role is to make configuration, relationships, outstanding questions and decisions easier to inspect.
Related reading
Read the agentic systems engineering guide for AI that assists engineering work. Use continuous verification for agile hardware and the spacecraft change-impact guide to govern evolving evidence.
Frequently asked questions
What is an AI-enabled space system?
It is a spacecraft, payload, launch, operations or ground system whose delivered behaviour depends on a learned model, generative model or agentic decision function. The assurance boundary includes the model, its data and configuration, the conventional software and hardware around it, and the operational controls that constrain its use.
How is AI for systems engineering different from systems engineering for AI?
AI for systems engineering assists engineers with work such as drafting or impact analysis. Systems engineering for AI defines, integrates and assures a product that itself contains learned or agentic behaviour. A programme may do both, but the hazards, evidence and configuration items are different.
Can an AI model be verified like deterministic spacecraft software?
Some surrounding properties can use conventional verification, but learned behaviour also needs evidence over representative operating conditions, uncertainty, robustness and failure handling. The programme should state what has been demonstrated, for which model, data, hardware, thresholds and operational envelope, rather than claim proof beyond the evidence.
What should be controlled when a spacecraft uses machine learning?
Control the model artefact and version, training and evaluation datasets, data lineage, preprocessing, parameters, thresholds, prompts where applicable, software dependencies, target hardware, operational mode, monitoring rules and the evidence accepted for that exact configuration.
What happens to verification evidence when an AI model changes?
Treat the model update as a controlled change. Follow its trace relationships to affected behaviour, interfaces, hazards, tests and evidence; record the impact decision; and reopen or mark evidence suspect wherever its assumptions, configuration or demonstrated envelope no longer apply.
Does continuous assurance replace SRR, PDR, CDR or formal qualification?
No. Continuous assurance keeps evidence and assumptions visible between gates. Formal reviews still assess whether the programme has sufficient approved evidence for its lifecycle decision, and qualification or acceptance remains governed by the applicable programme, customer and regulatory arrangements.