Human oversight of AI-assisted systems engineering works when a reviewer can understand the proposed change, inspect its evidence and stop it before it changes a controlled baseline. That requires more than a confirmation button. A space programme needs explicit decision authority, a stable review package, visible uncertainty and an attributable record of what was approved, rejected or returned for further work.
Make the object of approval unambiguous
“Approve the agent's work” is too broad to be a useful engineering decision. The work may contain a requirements correction, a proposed trace link, a budget calculation and a draft test activity. A reviewer might agree with the calculation while rejecting the correction. Present the proposal as identifiable changes and findings that can receive different dispositions.
Start the package with the decision being requested. State whether the team is accepting a finding, authorising more analysis, approving a technical change or releasing a controlled baseline. Include the baseline and proposal versions. If an agent regenerates the narrative after review starts, retain the earlier version and show the differences that could affect the decision.
NASA's configuration-management guidance treats baseline control and product information as lifecycle concerns. Applying that principle to AI assistance means the review record needs to identify the engineering state being considered. A conversation's last message is a poor substitute for a stable, versioned proposal.
Allocate authority around consequences
Decide which roles prepare evidence, assess technical content and authorise action. On a small space team, one person may hold several roles, but the responsibilities still need to be visible. Record conflicts or missing expertise rather than assuming that the most senior available person can evaluate every subsystem consequence.
The requirement owner determines whether a proposed wording change preserves the obligation. Interface owners assess compatibility on both sides of a boundary. A verification lead evaluates the proposed demonstration and evidence. The programme's designated authority decides whether the combined change can proceed within the applicable approval process. An agent can recommend review participants from known ownership records, but it should flag missing assignments.
NIST's AI Risk Management Framework, including GOVERN 3.2, calls for defined human and AI responsibilities. For this article's template, that becomes a concrete rule: no required technical judgement disappears simply because the person preparing the package used an assistant.
Review depth should match consequence. An editorial clarification without a technical change may follow a lighter route than a new operating limit. Establish that distinction before the queue fills up. Otherwise, teams can either burden every edit with unnecessary ceremony or accidentally treat a technical relaxation as a copy-editing task.
An adaptable approval checklist
Template for programme tailoring. For each row, record pass, unresolved or not applicable, with the evidence location and responsible role. “Not applicable” needs a reason. This checklist supports a review discussion; it does not establish compliance with a particular mission's standards, contract or assurance requirements.
| Review question | Evidence to inspect | When to pause |
|---|---|---|
| What exact decision is requested? | Proposal identifier, difference and intended disposition | The package mixes analysis acceptance with change release |
| Does the context match the affected product? | Baseline, requirement revisions and configuration applicability | The evidence refers to a different revision or variant |
| Are the claimed facts supported? | Accessible source passages, calculation inputs and result locations | A citation is absent, inaccessible or says something different |
| Are assumptions and gaps explicit? | Assumption list, unavailable records and excluded scenarios | A missing input has been replaced by an invented value |
| Have relevant consequences been assessed? | Requirements, interfaces, budgets, risks and verification effects | An affected owner or engineering boundary is missing |
| Can the proposed verification demonstrate the obligation? | Method, conditions, acceptance criteria and configuration | A draft plan or earlier result is presented as new verification closure |
| Are reviewers authorised and able to challenge the proposal? | Role assignments, technical assessments and recorded disagreement | A required authority is missing or disagreement is concealed |
| What happens after this decision? | Release scope, remaining conditions, action owners and follow-up | Conditional approval could be interpreted as unrestricted release |
Use the checklist to reach a decision, not to count ticks. A serious unresolved item can prevent release even when every other row passes. Conversely, a genuinely irrelevant row should not trigger make-work. The review chair or equivalent role should explain the basis for the resulting disposition in terms an engineer joining the programme later can understand.
Worked example: reviewing the CubeSat power proposal
Fictional training example. A 6U Earth-observation CubeSat uses baseline BL-03. PAY-PWR-014 revision B sets a 20 W payload peak-power cap. A design proposal increases payload peak power from 18 W to 24 W. The related interface is ICD-EPS-PAY-02 and the verification activity is VER-PWR-07. These are invented programme records used to demonstrate a review process.
The assistant prepares a difference report and identifies two separate conflicts. The design proposal exceeds the unchanged cap by 4 W. The increase over the current design is 6 W, so a positive programme power margin of 5 W becomes negative 1 W, assuming all other values stay fixed in the same operating condition. The reviewer checks the arithmetic and the shared-condition assumption before accepting those findings.
The payload owner confirms that the 24 W figure describes the proposed design, not an already approved requirement. The power-system owner evaluates ICD-EPS-PAY-02 and the budget context. The verification lead checks which parts of VER-PWR-07 would need revision if a feasible change were eventually approved. Each of these is an illustrative responsibility; no named individual or real review is implied.
An unhelpful approval request would ask the authority to “accept the updated requirement and test plan.” It bundles a requirement relaxation with a verification change and obscures the negative margin. A useful request asks for disposition of a proposal that currently violates its cap, identifies what further analysis is needed and preserves the option to reject it.
Example decision record: return the design proposal for rework; retain BL-03 and PAY-PWR-014 revision B; request a feasible power and operating-concept option; require joint interface assessment and verification-plan review before resubmission. The accepted arithmetic remains in the record as analysis. Neither the interface nor the verification status becomes approved by association.
The record should also explain what the next submission must contain. If a team proposes duty-cycle changes, it must show how those affect the relevant peak-power condition and mission operation. A favourable orbit-average figure cannot simply replace a peak constraint. If hardware changes are proposed, their consequences need their own assessment rather than inheriting the old proposal's review.
Handle exceptional cases explicitly
The cited source is unavailable
Distinguish a missing record from a record the assistant was not permitted to read. Ask an authorised owner to provide an appropriate reviewable extract or confirm the relevant fact through the programme process. Keep dependent conclusions unresolved until that happens. Expanding the assistant's access is a separate decision, not an automatic remedy for an incomplete answer.
The baseline changes while people are reviewing
Compare the new baseline with the context used by the proposal. Identify changed dependencies and ask the responsible reviewers whether their assessments remain valid. If the power budget changes elsewhere, the earlier margin calculation needs updating even when the payload proposal itself is unchanged. Record that reassessment instead of copying approval statuses onto a different engineering state.
Reviewers disagree or the model sounds overconfident
Preserve the disputed claim and each technical rationale. Resolve disagreement through the programme's escalation route, using additional evidence when needed. A second model agreeing with the first does not resolve a disagreement about physical assumptions. NIST's Generative AI Profile discusses risks in human reliance on generated outputs. A review interface should make contradictory evidence easy to see.
The change is urgent
Use the programme's authorised expedited route, with a clear scope and record of the decision. NASA's decision-analysis guidance recognises that urgent decisions can require adapted steps while retaining attention to evidence and uncertainty. Urgency does not give an assistant technical authority or make an unresolved assumption disappear.
The authority permits action with conditions
Express the condition as an observable release criterion, assign its owner and identify who confirms completion. Separate permission to investigate from permission to implement. For example, authorising a bench investigation does not authorise an altered flight configuration. Make the permitted action visible wherever the proposal is handed to another team.
Protect the quality of the review itself
Show the change and source evidence before a polished recommendation. Give reviewers a compact issue list, then allow them to inspect the complete context. Avoid a presentation that gives every field the same visual weight when one item is a violated electrical limit and another is punctuation.
Keep the original model output and the reviewed correction distinguishable. That makes it possible to learn whether failures arose from retrieval, interpretation, arithmetic or a poor task definition. Review logs should record why a suggestion was rejected, particularly when the rejection reveals a missing programme rule that future tasks should observe.
Periodically inspect a sample of accepted and rejected suggestions. Check whether reviewers actually open evidence, whether unresolved items survive handovers and whether deadlines are creating automatic approval behaviour. Use those observations to change workload and presentation. An approval process can exist on paper while becoming ineffective through queue pressure or unclear responsibility.
Also preserve a usable fallback. If the assistant is unavailable, the team still needs access to its requirements, evidence and ordinary review route. A pilot should demonstrate that a reviewer can recover the decision context without replaying a conversation or depending on one model's memory.
How Arc supports the review record
Arc's review and approval capability coordinates named reviewers, comments, due dates and attributable decisions against reviewed context. Its controlled-change workflow supports branches, record differences, discussion, review and merge before changes enter a controlled baseline.
Within those boundaries, Arc's read-only and drafting agents can prepare context and proposals under configured permissions. Engineers review and approve controlled changes. The capability supports a meaningful approval process when the programme supplies its authority model, evidence criteria and review discipline; it does not itself establish certification or a regulated electronic signature.
Frequently asked questions
Is a human approval button enough to control AI engineering work?
No. The approver needs the applicable baseline, exact proposal, supporting evidence, unresolved issues and authority to stop the change. The recorded decision must identify the version actually reviewed.
Who should review an AI-generated engineering change?
Select reviewers according to the affected obligations and the programme authority model. A payload-power change may involve payload, electrical power, verification and configuration roles, with additional authorities where mission, safety or contractual effects require them.
Can a team approve a change with open actions?
Its process may permit a conditional disposition, but the record must specify what is authorised immediately, which conditions remain and who can release the next step. A condition must not become an untracked exception.
What happens if the baseline changes during review?
Recheck whether the proposal and evidence still apply. Where the changed context is material, update the review package and obtain a decision against that version instead of silently carrying forward the earlier approval.
Does attributable approval mean a regulated electronic signature?
No. An attributable approval identifies who made a decision against reviewed context. Claims about regulated signatures, certification or compliance require separate evidence and applicable controls.
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.