AI in systems engineering means applying machine assistance to the work of defining, developing, verifying and maintaining complex systems. For a space team, practical applications include reviewing requirements, finding design context and preparing change assessments. Benefits depend on the task, source quality and review effort; AI does not remove the need for engineering judgement, physical analysis or accountable technical decisions.
A productive discussion starts with a work product. Which decision is delayed because people cannot find the applicable evidence? Which recurring review spends time checking information that is already recorded? Which handover repeatedly loses context? These questions reveal concrete applications. Starting with a general ambition to add AI often produces a writing assistant whose output still needs the same investigation as the original task.
Are we assisting engineers or building AI?
A team may use AI to review a spacecraft requirement while the spacecraft itself contains no AI. Conversely, a spacecraft may contain a learned image classifier even if its development team uses conventional engineering tools. The first case concerns the reliability and control of an engineering aid. The second concerns the behaviour and assurance of a product function. Some programmes face both, but the evidence required for one does not automatically answer the other.
For example, an assistant that summarises an imaging-payload specification needs correct document retrieval, revision handling and reviewable statements. An onboard classifier needs defined operating conditions, performance criteria, suitable test data and integration with the spacecraft's response to uncertain outputs. A good specification summary does not establish that the classifier works in orbit. The companion article on systems engineering for AI-enabled space systems addresses that product question.
This guide focuses on engineering assistance. It also distinguishes generative text tools from other analytical methods. A rule that checks a numeric limit can be deterministic; a statistical model may identify unusual measurements; a language model can suggest an interpretation or next investigation. Choose the method for the evidence needed. There is little value in asking a model to guess whether 24 is greater than 20 when an ordinary calculation provides the answer directly.
Where can AI help across the lifecycle?
NASA's system-design guidance describes iterative work across stakeholder expectations, technical requirements, decomposition and design solutions. Its product-realization guidance addresses implementation, integration, verification, validation and transition. The map below places our proposed assistance tasks beside those engineering activities. It is an application worksheet, not a NASA AI recommendation.
| Engineering activity | Candidate AI assistance | Input needed | Human decision retained |
|---|---|---|---|
| Stakeholder expectations | Group stated needs and expose conflicting objectives | Attributable interviews, mission brief and operating scenarios | Agree whose need governs a trade |
| Requirements definition | Flag ambiguous wording and draft clarifying questions | Source intent, terminology and allocation context | Accept the obligation and its feasibility |
| Architecture and decomposition | Retrieve rationale and suggest missing interface questions | Applicable system model, alternatives and assumptions | Select and justify the design solution |
| Implementation and integration | Compare delivered records with the planned configuration | Build identity, interface records and delivery evidence | Accept hardware and resolve incompatibilities |
| Verification | Check whether evidence references the required configuration | Requirements, procedures, execution records and results | Accept evidence sufficiency and dispositions |
| Validation and transition | Organise scenario coverage and outstanding operating questions | Intended-use scenarios, demonstrated behaviour and open issues | Accept fitness for intended use and transfer readiness |
| Change and technical management | Prepare impact notes and identify stale linked context | Controlled differences, relationships, owners and baselines | Approve change and manage programme consequences |
At concept stage, summarisation is useful only if it preserves disagreements. If operations needs frequent imaging while the payload team assumes short collection windows, merging both statements into an apparently agreed objective conceals a design driver. Require the output to attribute each expectation, identify the conflict and ask what operational scenario should govern. An unresolved question can be a more valuable work product than a clean paragraph.
During requirements definition, use the assistant to distinguish missing information from poor wording. It can notice that a pointing requirement names an accuracy without a reference frame, or that a downlink requirement omits the operating conditions. It should request those values rather than inventing them. The review is successful when the requirement owner understands the missing decision and can connect the answer to its source.
During architecture work, retrieval can shorten the path back to a trade's assumptions. A useful result identifies the decision record, candidate configurations and reasons an option was rejected. A generated architecture sketch may help frame discussion, but its component relationships do not demonstrate physical compatibility. Keep design hypotheses distinct from adopted decisions, especially when the assistant can search both exploratory work and controlled programme records.
At integration, the central question may be configuration identity rather than technical vocabulary. Two interface documents can use the same connector name while describing different pin assignments. The assistant can prepare a comparison, but the relevant owners need to establish which records apply to the delivered hardware. A similarity score cannot determine whether two electrical interfaces are interchangeable.
For verification, start with evidence completeness and applicability. A result file may exist but refer to a different requirement revision or test article. AI can help expose that discrepancy and gather the relevant records. It should leave closure to the programme's verification process. Validation then asks whether the integrated system serves the intended use, so a collection of requirement-level results may still leave an operational scenario unresolved.
What does one power change involve?
Fictional programme example. A 6U Earth-observation CubeSat proposes increasing payload peak electrical power from 18 W to 24 W at unchanged duty cycle. The allocated payload cap is 20 W. PAY-PWR-014 revision B belongs to BL-03; revision C is proposed. ICD-EPS-PAY-02 records the electrical interface, and VER-PWR-07 identifies the related verification activity. The following is a teaching case, not a reported deployment or validated mission design.
The requirement review asks whether the new demand conflicts with the allocation. The immediate answer is yes: 24 W exceeds 20 W by 4 W. The architecture review asks what alternatives could resolve that conflict and what evidence supports each. The interface review asks whether the supply and connection remain suitable. The verification review asks whether the existing method and evidence would support the changed configuration. Each task needs different inputs and a different accountable decision.
A simple instantaneous power illustration starts with positive margin of 5 W. Increasing demand by 6 W gives -1 W, all else fixed. This does not establish an orbital energy deficit or a battery outcome. Those conclusions require additional models and operating assumptions. The assistant's job can be to connect the arithmetic finding to the people and analyses needed, while maintaining that distinction in every summary.
Imagine a proposed resolution that reduces imaging duty cycle. It may help an energy balance, but it changes the proposal's original unchanged-duty-cycle assumption and could affect mission collection objectives. An assistant should surface that new trade explicitly. It should not report that the power problem is solved merely because a different set of assumptions produces a more favourable result. The technical decision must return to the mission intent as well as the subsystem record.
Which benefits should we test?
Less time locating context. A connected retrieval task may bring the relevant requirement, interface, decision rationale and verification plan together. Test whether engineers reach the correct applicable records sooner, including the time needed to reject irrelevant matches. Counting documents retrieved rewards volume even when it increases review work.
More consistent first-pass review. A shared review rubric can make omissions easier to spot across a specification set. Test this with a mixture of complete and incomplete records. A tool that flags every statement as ambiguous produces a consistent output but does not help the engineer. Measure justified findings and material misses alongside false alarms.
Better preservation of decision context. Assistance can turn scattered review notes into a draft containing the proposal, rationale, assumptions and unresolved actions. The benefit comes when another engineer can reconstruct the decision without repeating the original conversation. Evaluate whether the draft preserved objections and conditions, rather than merely whether it reads smoothly.
Earlier visibility of stale evidence. A recurring check can identify changes whose linked test records have not been assessed. The output should distinguish a review needed from a requirement known to have failed. This helps the team direct attention without converting an administrative gap into an unsupported technical conclusion.
Which limitations affect the choice?
The NIST Generative AI Profile identifies confabulation and human-AI configuration among its risk areas. In engineering assistance, a practical concern is a plausible answer that a busy reviewer trusts too readily. A source link helps only if it leads to the correct revision and supports the particular claim. A convincing explanation is not independent evidence of correctness.
Missing programme information is another limit. AI cannot reconstruct an undocumented supplier agreement reliably or know why an engineer rejected a design if the rationale was never recorded. Retrieval may find related language, but relevance does not establish authority. The workflow should be able to return a focused information request and route it to an owner rather than fabricate the missing context.
Physical claims need suitable analytical support. A model may produce a plausible thermal explanation after reading a power change, yet still lack geometry, materials, boundary conditions and a valid analysis method. Treat that output as an investigation prompt. The same applies to structural adequacy, radiation effects and reliability conclusions. Assistance is most defensible when the engineering calculation and its assumptions remain separately inspectable.
Automation also moves work. Time saved drafting may reappear as checking citations, resolving false alarms or maintaining data connections. Access control can constrain coverage, and a model or connector update can alter behaviour. A pilot should therefore measure the completed task and the ongoing maintenance burden. No universal percentage saving follows from the presence of an AI feature.
How do we choose the first application?
The NIST AI Risk Management Framework is voluntary guidance for considering AI trustworthiness and risk. The worksheet below is our practical selection aid. Use it to compare candidate engineering tasks before configuring a pilot; it is not a numerical maturity model.
| Question | Promising answer | Reason to narrow the task |
|---|---|---|
| Can the input be identified? | Named records and revisions are available | Decisive information exists only in informal conversations |
| Can the output be checked? | Reviewer can inspect evidence for individual findings | Output is an unsupported overall judgement |
| Is there a reference outcome? | Completed engineer-reviewed cases exist | Success means only that users like the wording |
| Is action scope bounded? | Read or draft actions have a clear destination | Task needs broad authority over approved records |
| Can uncertainty be handled? | Named owner receives missing-information questions | Workflow demands an answer despite unavailable evidence |
| Does the whole task improve? | Review and correction effort are measured | Only generation speed is being counted |
For the CubeSat, a suitable first task is assembling a source-linked impact note for payload power changes. It has a defined record set, reproducible arithmetic and a reviewable outcome. Automatically selecting a new power architecture would require broader evidence and decision authority. Keep the first task small enough that the team can diagnose failures, then use its results to choose the next application. The AI adoption guide for systems engineering develops the pilot and rollout process.
How could the same change unfold?
Fictional programme scenario. A 6U Earth-observation CubeSat begins with BL-03, PAY-PWR-014 revision B and a 20 W payload peak-power cap. The design estimate is 18 W. A supplier proposes 24 W, requiring review of ICD-EPS-PAY-02 and VER-PWR-07. Draft requirement revision C remains unapproved. Consider two ways the team might develop its AI assistance over several subsequent reviews.
Scenario A: the assistant improves while the records remain fragmented — The team introduces a newer model and gives it a larger document collection. It produces clearer explanations and finds references in more files. However, supplier exports lack baseline identifiers, an old spreadsheet still contains a superseded budget and reviewers continue to send decisions as isolated messages. The assistant can retrieve more material, but an engineer must still reconstruct which material applies.
When the 24 W proposal returns, the tool may find the correct conflict and still cite the wrong verification revision. A polished package does not solve that underlying problem. The team’s evaluation should capture the time spent correcting source selection and checking assumptions, rather than only measuring how quickly the first answer appears.
Scenario B: the team improves the record and the bounded task together — The team first identifies the applicable baseline, records the draft status and links the interface and verification activity. It then gives the assistant a narrow task: prepare the revision-specific review context and identify missing evidence. Structured calculations expose the 6 W increase, the 4 W cap exceedance and, under fixed same-condition assumptions, the change from 5 W programme margin to negative 1 W.
The assistant returns the known conflict and requests the missing analysis. Engineers decide whether an alternative design or operating concept is feasible. When the tool or model later changes, the team can replay the same case against a stable expected record set. This scenario does not assume that the AI becomes more capable; it makes the work easier to assess with the capability already available.
These scenarios are illustrative alternatives, not measured programme outcomes. They show why information quality and execution quality should be evaluated separately. A better language model may help both teams, but only the second has made the source of an engineering conclusion easier to reconstruct.
When should we expand the agent’s role?
A roadmap can be organised around evidence rather than predicted dates. First demonstrate that the assistant retrieves applicable records for a bounded task. Then show that the output is useful after accounting for engineering review. Add a connected analysis only when its inputs can be validated and its results recorded reproducibly. Add drafting rights only when the team can inspect and disposition the resulting differences.
For each expansion, identify an owner, the decision it supports and the conditions for stepping back. If a connector starts losing revision context, pause the dependent task and restore the source path. If a model update increases unsupported findings, keep the narrower configuration until the relevant cases pass again. The ability to reduce scope is part of maintaining a useful service.
Measure the full workflow. Useful indicators include missed material issues, false alarms, unsupported claims, source-applicability errors and engineer effort to reach a reviewed package. Track the ongoing effort to maintain records and connections. A fast first draft with expensive correction is a different outcome from a genuinely easier engineering review.
Also examine what the proposed investment would displace. A team with unresolved interface ownership may gain more from fixing that process than from buying more sophisticated assistance. A team with a trusted record set and repetitive review preparation may have a clearer opportunity. The AI adoption guide turns these choices into a practical pilot sequence.
Where does Arc fit?
Arc's programme-model reference describes connected engineering records. Its verification capability connects requirements, configurations and evidence, while configured AI agents can read, draft and propose for human review. These are relevant capabilities for the assistance tasks discussed here.
Evaluate an intended workflow against the actual programme records and permissions. Ask for a demonstration that distinguishes a baseline from a proposal and an evidence gap from a failed requirement. The lifecycle map does not imply that Arc performs every analysis listed. Its role in a proposed setup should be explicit, with the engineering decision and supporting analysis owned by the appropriate people.
Frequently asked questions
Where can AI help systems engineers?
Candidate applications include organising stakeholder input, reviewing requirements, retrieving design rationale, preparing change-impact notes and checking verification records. Each application needs suitable source material, an inspectable output and an accountable engineering reviewer.
Is AI in systems engineering the same as systems engineering for AI?
No. AI in systems engineering concerns assistance with engineering work. Systems engineering for AI concerns designing and assuring a product that contains an AI function, such as onboard image classification. The product needs its own requirements, operating assumptions, integration and verification approach.
Can generative AI replace spacecraft analysis tools?
Generated text does not replace a validated analysis or its approved inputs. AI can help prepare inputs, locate results and explain documented assumptions. Numerical conclusions still require an appropriate calculation or model, the applicable configuration and engineering review.
How should a team measure an AI pilot?
Compare completed engineering tasks with the existing process. Include source retrieval, review and correction time, material issues found and missed, false alarms and the usefulness of abstentions. Choose acceptance criteria before evaluating the pilot.
Does using AI make a programme compliant with NASA guidance?
No. Software use alone does not establish compliance or approval. The applicable programme requirements, authority model, engineering activities and accepted evidence determine what must be demonstrated.
Use connected engineering context in Arc
Arc connects programme records, maintains controlled branch and review workflows, and links verification evidence to the relevant configuration. Engineers inspect proposed changes and retain decision authority.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.