ECSS change impact analysis examines how a proposed change affects controlled requirements, engineering work, commitments and evidence. AI agents can help prepare questions and proposed edits around the connected records. The essential task is to preserve the accepted baseline, assess the consequences of the proposal and record the authorised decision before treating the changed engineering state as agreed.
Start by identifying exactly what is changing
A change review needs a stable comparison. Record the source and revision of the affected requirement, the baseline that currently applies, the proposed wording and the reason for the proposal. Then distinguish changes to technical intent from corrections to spelling, references or presentation. The same number of edited words can imply very different engineering work.
ECSS-M-ST-40C Rev.1, clauses 5.3.2.3 to 5.3.2.7 addresses change initiation, assessment, disposition and updates to controlled baselines and documents. Its assessment scope includes technical, programmatic and operational consequences. A text comparison is a useful starting point for that review, but it is only the starting point.
For a first-time supplier, one practical safeguard is to write the decision question plainly: “Should we accept this tighter requirement, and what changes to scope, engineering work and verification follow?” That brings the project manager, systems engineer and verification owner into the same discussion. Otherwise each may interpret a small specification edit as somebody else's task.
Worked example: a tighter pointing requirement
The fictional Lark attitude-control unit has REQ-LARK-010 with a maximum steady-state pointing error of 0.15 degrees. An existing analysis reports 0.12 degrees under its recorded assumptions. A proposed change reduces the permitted maximum to 0.10 degrees. These are teaching values, not mission limits prescribed by ECSS. The illustrative Lark programme records preserve the common comparison.
Under the simple numerical comparison, the old reported value is below the old threshold and above the new proposed threshold. That makes the old report insufficient, on its own, to justify meeting the proposed limit. It does not prove that every component needs replacing or that a new test campaign is automatically required.
First ask whether the intended conditions and error definition are unchanged. If they are, investigate the model, design and supporting assumptions against the tighter target. If they are not, the team needs to understand both changes. An apparent improvement in the numerical result could otherwise come from comparing different quantities.
Build an impact map that includes evidence and commitments
Use the following map to organise the assessment. It is an editorial working aid for this example. The named records illustrate questions to ask; they are not a list of mandatory Arc fields or a claim that an agent can discover every effect.
| Connected area | Question for the Lark review | Useful review output |
|---|---|---|
| Source requirement | Who requested the tighter target, and what problem does it solve? | Agreed intent and the source of authority |
| Allocated requirements | Which sensor, actuator or control allocations might need assessment? | Candidate affected allocations with owners |
| Interfaces and assumptions | Do timing, disturbance or operating-mode assumptions still apply? | Questions for the relevant interface owners |
| Analysis and design work | Which model inputs or design choices support the existing result? | Assessment scope and candidate follow-up work |
| Verification evidence | What can the old report still support under the new proposal? | Evidence-applicability and re-verification assessment |
| Delivery commitments | Does accepting the target alter effort, facilities or supplier inputs? | Scope, schedule and commercial questions for decision |
Include known gaps in the map. A missing relationship can mean the product model is incomplete rather than that no impact exists. Ask the responsible engineers to inspect likely interfaces and assumptions beyond the immediately connected records. Record “no effect identified” with its scope and rationale, not as a universal statement about the entire programme.
Give the agent a bounded assessment task
An effective review assignment specifies the old requirement, the proposal, the engineering context to inspect and the output you want. Ask for candidate impacts, source references, missing information and proposed follow-up edits. In the Lark example, the task might focus on whether existing verification records still describe the claim being made under the proposed requirement.
Require the output to distinguish observation from inference. “The reported result exceeds the proposed maximum” is an observation about the supplied values. “The control design may need work” is a hypothesis for an engineer. “Replace the sensor” is a design recommendation requiring substantially more justification. Combining those statements into a single confident conclusion makes review harder.
Use the ECSS compliance agent review method to inspect the suggested findings. Check the versions examined and the evidence behind each proposed edit. If the agent has not seen a key supplier report, preserve that limitation in the decision package.
Separate the proposal, the decision and implementation
A change can be technically reasonable and still be awaiting approval. It can be approved and still await implementation. It can be implemented while verification follow-up remains open. Preserve these distinctions so the team can answer what applies now, what has been accepted and what still needs work.
Clause 5.3.2.5 describes change dispositions of approval, rejection or deferral for further information. The same standard calls for baseline and controlled-document updates to reflect approved changes, and its configuration-status requirements distinguish approval from implementation. Your programme should make those states understandable across its actual tools and procedures.
For the fictional Lark proposal, a useful review conclusion might defer acceptance while the verification owner checks the analysis assumptions and the project manager assesses additional effort. That is a real decision with clear follow-up, even though the tighter requirement has not yet been adopted. Preserve the current requirement as the applicable baseline during that assessment.
Reassess the evidence without rewriting its history
ECSS-E-ST-10-02C Rev.1, clause 5.4.3 addresses re-verification following changes, including changes of requirements after initial verification. The supplier determines the extent and agrees it with the customer. Requirements subject to re-verification are recorded as open until the specified work and close-out have been completed.
That process needs an engineering assessment. Some evidence may remain applicable, some may require additional justification and some may no longer support the changed requirement. Keep the original report and its original context. A revised assessment can explain its relevance to the new baseline without making the historical result appear to have been produced for a different target.
Update the Verification Control Document information so that the current fulfilment position follows the agreed change. If the proposal is rejected, preserve the rejection and reasoning while continuing to assess the existing baseline. A pending agent suggestion should not silently change the meaning of an accepted verification record.
Carry the decision across supplier boundaries
A supplier may be able to change its internal design while still needing customer agreement for an altered requirement or interface. ECSS-S-ST-00C Rev.2, clause 6 describes the customer-supplier chain and the project requirements invoked through business agreements. Start from those actual obligations when deciding who needs to participate.
Prepare a clear package for the relevant parties: the proposed change, affected commitments, assessed impacts, unresolved questions and the decision requested. Avoid sending a long automated summary that leaves the receiving organisation to discover why its action is needed. After a decision, identify which requirement and evidence records each party must update.
For internal coordination, assign an owner to confirm the updates have been implemented. Closing the meeting action is not the same as checking that the accepted change appears in the engineering information used by the next person.
Using Arc to organise the change review
Arc's branch and revision approach supports proposing engineering changes, reviewing their effects and merging accepted work into the programme model, with baselines as references to agreed states. Connected requirements, systems, verification activities and evidence help the team organise the impact assessment.
Arc's ECSS compliance agents can propose edits for engineer review in the relevant clause context. Use those proposals as inputs to the change process the project has established. No particular automatic run frequency, exhaustive impact discovery or autonomous baseline approval is assumed here.
Evaluate the workflow with the Lark change before broadening it. Ask an engineer to inspect the source and proposed impact, a verification owner to assess the evidence consequences, and the responsible authority to record a decision. The useful result is an understandable path from proposal to accepted work and remaining obligations.
Frequently asked questions
What should ECSS change impact analysis cover?
ECSS-M-ST-40C Rev.1 clause 5.3.2.4 requires assessment of technical, programmatic and operational impacts on affected products. In practice, examine the changed requirement alongside allocations, interfaces, engineering work, verification evidence and delivery commitments.
Can an AI agent approve an ECSS requirement change?
Treat the agent output as a proposal for the responsible reviewers. The project must use its applicable change process and authority model. Arc ECSS agents propose edits for engineer review; an agent suggestion does not itself establish an approved baseline.
Does a tighter limit invalidate an old analysis report?
The historical report and its recorded result still exist. What needs reassessment is whether that result and its assumptions support the changed requirement. Preserve the original context and document the new applicability assessment.
When does ECSS require a re-verification assessment?
ECSS-E-ST-10-02C Rev.1 clause 5.4.3 includes changes of requirements after initial verification among the cases requiring the supplier to determine the extent of re-verification and agree it with the customer.
How does Arc support ECSS change control?
Arc supports branches, revisions, baselines and connected engineering records to help teams propose changes, review effects and merge accepted work. ECSS agents can propose edits, while the project retains its engineering and approval responsibilities.
Evaluate Arc
Put ECSS compliance agents to work on your programme.
Assess a proposed change against the records and evidence it affects. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.