Engineering change request automation: prepare the impact review before approval

The first requirement is a reliable reference to the configuration being changed. I would capture the affected item identifiers, released revisions, request origin, stated reason, and the source system that owns those records. A filename containing “latest” is not a baseline.

NASA's systems engineering guidance describes assessing proposed requirement changes before approval and implementation, using official submission channels, and managing controlled changes through a formal process. I would use that principle to structure the review packet, while following the engineering organization's own authority, standards, and contractual obligations. NASA technical management guidance

The system should preserve the difference between an engineering change request, an approved change, and a released configuration. These are separate states with separate evidence. A request can be well documented and still be rejected. A change can be approved and still await implementation and verification.

I would ask the engineering lead to approve the minimum review packet. It may include the problem statement, affected items, proposed modification, alternatives considered, interface impacts, verification approach, procurement implications, and the required discipline reviewers.

Each field needs an owner and a completion rule. A structural assessment should be completed by the appropriate engineer, not inferred from a supplier brochure. A manufacturing impact review should identify the actual process or tooling affected. Where a field does not apply, record who made that determination and why.

The model can draft a summary of supplied evidence and flag missing sections. It should cite the exact source revision used. If the evidence is contradictory, preserve both statements and route the conflict. A smooth synthesis can hide the very disagreement the review board needs to resolve.

The integration should fetch records from the existing document, product lifecycle, or requirements systems using scoped access. I would constrain retrieval by project, configuration, and item identifiers before asking a model to summarize the material.

A broad search for a component name can return obsolete designs, similarly named parts, and records from another program. The output should show candidate relationships and their provenance. It should not claim a complete impact analysis merely because the search returned several plausible documents.

The permissions need testing independently of the model. A reviewer authorized for one program should not receive another program's files through a generated summary. If a source system denies access, the workflow should report the missing permission and stop that retrieval rather than use a wider service account behind the scenes.

I would label each possible impact as confirmed, candidate, or unresolved. A reference from an approved interface document is different from a model's inference that two components might interact. The distinction should remain visible in the packet and in exported review material.

For each candidate, identify the evidence and the reviewer who can confirm it. The workflow can prepare questions such as whether a revised connector affects the harness drawing or test procedure. It should not convert those questions into findings until the responsible engineer records the assessment.

This also creates a practical acceptance boundary for the automation. It can be evaluated on whether it retrieved known references, preserved their revisions, and exposed missing reviews. It should not be evaluated as though it independently completed the engineering analysis.

Review assignments should come from the organization's approved routing rules. The person requesting the change should not be able to bypass required disciplines by editing a description field. If the rules require a configuration board or additional signoff, the software should enforce that transition.

Approval should attach to an exact packet revision, affected baseline, and proposed change. If the proposal or source baseline changes materially while review is pending, the system should mark the earlier approval stale and obtain the necessary re-review.

I would keep approval and release separate in the integration. An approved request authorizes the next controlled step; it does not necessarily authorize every downstream write. The released configuration should have its own evidence of implementation, verification, and approval under the organization's process.

A connector failure must not leave the team guessing whether a change record was created. Use stable operation references and retain provider identifiers. If the API times out after a write, reconcile against the source system before retrying.

Keep partial progress visible. The packet may be assembled while one required assessment is missing. The workflow should report that specific condition rather than declaring the whole request failed or complete. An assigned exception lets the responsible person resolve the issue without rerunning unrelated steps.

Manual edits need respect as well. Before issuing a reminder or changing a status, read the current record. A reviewer may have rejected the request or reassigned the work while the automation was paused. Replaying old instructions against a newer controlled record is an avoidable source of confusion.

I would prepare a test set containing a superseded component revision, an incomplete interface map, contradictory source documents, a missing discipline review, a duplicate submission, and an approved packet edited before release. Include an attachment containing instructions to override review rules.

The expected behavior should be concrete. A superseded revision must be identified. Incomplete impact evidence must remain unresolved. Missing required review must block the relevant transition. Duplicate submission must not create another official change. Editing the approved packet must invalidate the approval where the policy requires it. Document instructions must never alter authority.

The engineering lead should also inspect ordinary examples with correct inputs. Excessive blocking creates a different failure: engineers work around the integration because every request becomes an exception. The objective is accurate preparation and clear escalation, with the real engineering decision preserved.

I would track packet completeness, missing-reference corrections, stale-revision detections, routing corrections, and time spent preparing materials. Record the sample size and distinguish automated findings from reviewer-confirmed impacts.

Do not claim that shorter queue time proves a better engineering decision. A faster process could simply have skipped a necessary review. The evidence should show both operational improvement and preservation of required controls. Any claim about reduced defects or improved safety would require a much stronger measurement basis than this workflow alone provides.

The handover should include the state model, routing rules, connector permissions, test cases, recovery instructions, and a named owner for unresolved exceptions. Start with one change category and a bounded source set. Expand after the engineering team can explain exactly what the automation prepares and what it leaves for them to decide.