The future of systems engineering with AI is best planned around better access to engineering context, more reusable checks and clearer evidence for decisions. Space teams can prepare by connecting controlled records, making analyses reproducible and evaluating bounded assistance. How quickly broader autonomy becomes useful remains uncertain; investment decisions should follow demonstrated engineering value rather than predictions about fully automated spacecraft development.
A spacecraft programme may outlast several generations of AI models and software interfaces. Its requirements, configuration history and verification evidence still need to remain intelligible. The most useful question is therefore what a team can improve now that will remain valuable when a model changes, a supplier changes tools or the programme enters a different lifecycle phase.
Separate observable foundations from forecasts
There are concrete developments to inspect. The NASA Systems Modeling Handbook demonstrates model-supported engineering work products. OMG’s SysML 2.0 publication and Systems Modeling API specification provide standards that implementations can use for modelling and access to model data. These sources establish available guidance and specifications, not universal adoption.
AI architecture guidance also describes ways to combine model calls and tools. Anthropic distinguishes predefined workflows and dynamically directed agents. That supports discussing alternative execution patterns. It does not establish that an agent can make a spacecraft trade safely or that increased autonomy will always improve an engineering process.
NIST’s AI Risk Management Framework provides a voluntary basis for managing AI risk, with its Generative AI Profile addressing risks specific to generative systems. The practical implication is that better capability and disciplined evaluation need to develop together. The scenarios below are our conditional interpretation of these foundations, not predictions made by those organisations.
Four plausible shifts and the evidence each needs
| Possible shift | Practical opportunity | What remains uncertain | Evidence before investment |
|---|---|---|---|
| From document search to configuration-aware questions | Retrieve applicable obligations and evidence together | Whether the accessible records encode enough context | Correct answers on conflicting-revision cases |
| From isolated checks to prepared change packages | Combine findings, dependencies and draft review material | Whether adaptive investigation misses important paths | Engineer-reviewed coverage and correction effort |
| From manual analysis handoffs to bounded tool use | Prepare validated inputs and preserve returned results | Connection quality and model suitability for each task | Reproducible calculations with visible failures |
| From one-off prompts to maintained engineering services | Reuse evaluated tasks across a programme | Operating cost and change sensitivity | Owned evaluations, update process and recovery route |
The first shift may be valuable before the others. A reliable answer to which evidence applies to the current payload design can remove a recurring coordination problem without requiring autonomous design. A team should be free to stop at that capability if it meets the need. More elaborate execution is an option to justify, not an inevitable maturity stage.
The durable investment is interpretable engineering information
Engineering information is useful when another person can understand its identity, meaning, authority and history. AI increases the value of making those properties explicit because an assistant can otherwise assemble a convincing answer from records that do not belong together. Stable identifiers and controlled revisions are therefore useful both for ordinary collaboration and for future automated retrieval.
Prioritise relationships that support recurring decisions. Connect a requirement to its source, allocated element and verification path. Attach an analysis result to the input configuration and assumptions used to produce it. Record why an interface agreement changed. These links should answer a real review question; creating a large graph without maintained meanings adds another source of administration.
Keep an export and reconstruction route. A future team should be able to determine the approved requirement and evidence basis without depending on the conversational history of one assistant. Preserve records in a form that can be inspected and transferred with their key identities and relationships. Evaluate that ability as part of tool selection and migration planning.
Model and API standards can help, but actual exchange remains an implementation question. A small round trip with representative records is more informative than a broad interoperability claim. Include a rejected proposal, a superseded analysis and an externally owned requirement in the example, since these states reveal whether the connection preserves the distinctions the programme relies on.
Two futures for the same spacecraft change
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.
How the work of systems engineers may change
Some effort may move from finding and formatting material towards defining good questions, assessing retrieved evidence and resolving cross-discipline conflicts. That is a conditional task-level expectation, not a forecast that a role disappears. A systems engineer still needs to understand what the system is intended to accomplish and which assumptions connect a proposed change to mission consequences.
Task design becomes a useful skill. An engineer should be able to define the permitted sources, applicable configuration, expected output and completion condition. They should also recognise when a question cannot be answered from records alone. A missing measurement, uncertain model boundary or unresolved stakeholder need may require new engineering work rather than a more elaborate prompt.
Evidence review also becomes more deliberate. Reviewers need to distinguish a quoted obligation, a computed result, an inferred relationship and a proposed action. Training can use deliberately flawed packages: a correct number from the wrong baseline, a test linked to the wrong hardware or a confident statement based on an unavailable supplier source. The purpose is to practise inspecting support, not to teach blanket distrust of assistance.
Maintain domain competence while introducing new tools. Junior engineers benefit from reconstructing at least some calculations and trace paths themselves; senior engineers need time to explain why a plausible suggestion is technically inadequate. A programme that saves document preparation effort but removes opportunities to learn its architecture may create a different long-term problem.
Use decision triggers instead of an autonomy timetable
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.
Keep future possibilities separate from current engineering authority
It is possible to imagine agents coordinating several specialist analyses and assembling candidate spacecraft trades. Whether that is useful depends on tool reliability, model validity, problem definition and review effort. None of the cited sources establishes a universal point at which a team should delegate design acceptance or verification closure to an AI system.
For present planning, keep those decisions attached to named programme authorities. Build interfaces that make supporting evidence easy to inspect and proposed changes easy to compare. This remains a sensible investment even if future agents become substantially more capable, because stronger assistance still needs to communicate what it has done and which configuration its output concerns.
What this means when evaluating Arc today
Arc currently describes a connected programme model, human-controlled AI assistance and reviewed baseline changes. Evaluate those documented capabilities using an actual record flow and a bounded engineering task.
The broader scenarios in this article are not an Arc roadmap or a promise of future functionality. Ask the proposed setup to demonstrate the evidence path, permissions and review outcome that matter now. For the information architecture behind that evaluation, read digital thread versus digital twin and how MBSE, requirements management and AI fit together.
Frequently asked questions
Will AI replace systems engineers?
The cited sources do not establish a reliable forecast of role replacement. AI can assist particular tasks, while system intent, trade-offs, evidence sufficiency and accountable decisions still require an explicit engineering process. Plan around demonstrated task performance and the review work it creates rather than a prediction about entire job titles.
Which investment is useful even if AI progress slows?
Clear record ownership, stable identities, revision-aware links, reusable calculations and evidence tied to configurations improve engineering work independently of AI. They also make future assistance easier to evaluate and replace.
Does SysML 2.0 mean future engineering tools will connect automatically?
No. Published language and API specifications provide a technical basis for implementations, but actual interoperability depends on supported versions, semantics, conformance and tested exchanges. A programme must verify its selected tools and mappings.
What evidence should justify expanding an AI pilot?
Use representative engineering cases and compare usable output quality, missed issues, false alarms and total review effort with the current workflow. Expansion should also depend on maintainable connections, clear ownership and successful handling of unavailable or conflicting information.
Is this article an Arc product roadmap?
No. It separates current capabilities supported by Arc’s public reference from conditional future scenarios. Availability of specific tools, integrations and workflows must be established for the proposed deployment.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.