How to Use AI Without Losing Control of the Engineering Baseline
AI can help safety-critical teams find drift, assemble evidence, and draft changes, but the accepted engineering record must remain controlled by reviewable decisions.
The question is no longer whether engineering teams will use AI. They already are, and this is mostly a good thing.
AI can help teams find drift, assemble evidence, draft changes, and notice dependencies that would otherwise be easy to miss. But it does carry the risk that AI-enabled work starts creating shadow decisions around the engineering baseline.
So how can you get the benefit of AI without losing control of what the program has actually accepted?
In a safety-critical program, the baseline is not just a collection of files but the accepted record of engineering judgment. It says which requirements are current, which assumptions are active, which analyses support which claims, which evidence has been accepted, and which decisions the team is allowed to build on.
If AI can silently mutate that record, you have a problem.
But if AI can only make reviewable proposals against that record, the program has a powerful tool.
The baseline is a record of what the team has accepted
Engineering teams are used to working with drafts:
- A proposed requirement is not the same thing as an approved requirement.
- A candidate means of compliance is not the same thing as an accepted means of compliance.
- A test summary generated from source data is not the same thing as signed verification evidence.
AI makes these distinctions more important.
An AI system can suggest that a requirement should be rewritten. It can identify a conflict between a safety analysis and an interface definition. It can assemble a candidate compliance package from regulations, precedent, and project evidence. It can draft text that an engineer may later choose to accept.
But the moment that suggestion becomes part of the accepted baseline, engineering authority has been exercised.
And this requires humans.
AI can propose, not decide
A proposal should be concrete enough to review. It should show the affected artifacts, the source anchors, the diff, the rationale, the assumptions, and the decision being requested. It should make the reasoning visible enough that engineers can debate the substance, not guess what the AI might have been doing.
For example, if an AI system detects that a supplier interface changed, it should not quietly update every downstream requirement that appears related. It should prepare a review package:
- the changed supplier artifact
- the requirements, analyses, and tests that may depend on it
- the exact passages or elements that triggered the concern
- the proposed updates or review questions
- the level of confidence and the reason for uncertainty
- the human owner who can accept, reject, or refine the proposal
That is very different from an autonomous rewrite.
Chat is not a control mechanism
General chat interfaces are useful for exploration. But they are poor control mechanisms for engineering baselines.
A chat answer can be persuasive while hiding the distinction between source fact, recovered structure, and interpreted meaning. It can use domain-significant wording loosely. It can collapse uncertainty because the conversational format rewards a clean answer.
That is acceptable for brainstorming. It is not acceptable as the mechanism by which a certification-relevant artifact changes state.
Safety-critical engineering needs a different harness around AI:
- source-bound retrieval, not free-floating memory
- explicit diffs, not silent edits
- typed findings, not only prose
- review states, not conversational agreement
- auditable decisions, not ephemeral chat transcripts
- dependency tracking, not isolated answers
This is what makes AI-assisted work inspectable: engineers can see the evidence, challenge the reasoning, and decide what enters the baseline.
Git gives engineering work traceability and auditability
Git is widely available, open source, and very good at representing proposed changes before they become accepted changes. Branches and commits let a team separate an AI-generated proposal from the engineering baseline, inspect exactly what changed, preserve who accepted a change and when, and pin downstream analyses to a specific state of the record.
This is also why the move toward text-based engineering artifacts matters. SysML v2 is a good example: unlike the diagram- and tool-file-heavy SysML v1 world, SysML v2 includes a standardized textual notation. That makes model changes much more natural to diff, review, and audit alongside requirements, analyses, and code.
With Git, more of the engineering record becomes inspectable as change history, not just stored as final documents.
The most valuable output is often a better question
In many engineering workflows, AI should not try to produce the final answer. It should help the team ask the better review question:
- How do we make sure the
HALTcommand sent to our remote asset was actually executed? - Does this test still support the requirement after the operating mode changed?
- Does this compliance claim depend on an authority interpretation that has not been accepted yet?
- Did this supplier update invalidate an assumption in the hazard analysis?
- Are two teams using the same phrase to mean different things?
These are high-value outputs because they focus human judgment where it belongs. They make the decision surface clearer.
Engineers trust AI when it cannot move the baseline underneath them
Engineers do not resist AI because they enjoy the tedious and error-prone work of manual cross-checking their artifacts. They resist AI when it can change or obscure the record they are accountable for.
If AI produces unreviewable changes, it becomes another source of configuration risk. But if it produces traceable proposals, it can help teams find drift, assemble evidence, and maintain alignment across a moving program.
That is the practical standard for AI at M45: useful enough to accelerate the work, constrained enough that a qualified engineer can still explain exactly what the program accepted and why.
Or would you put a safety-critical vehicle into service if no qualified engineer could explain which AI-suggested changes had been accepted, and why?
Share