ECSS compliance agents help engineers examine project records against relevant ECSS clauses and prepare proposed changes for review. A useful agent workflow identifies the project scope, applicable sources and records it examined, then makes its reasoning inspectable. Engineers still decide whether a finding is correct, whether an edit is technically sound and whether the resulting compliance position is justified.
What should an ECSS compliance agent actually check?
Start with a named engineering task. “Check this project for ECSS compliance” leaves too much unspecified: which obligation set, which product, which revision and which kind of result? A better assignment is to review the verification planning records for one supplier deliverable against the requirements that the project has made applicable.
Keep three questions separate. Is the obligation applicable? Does the project contain a credible plan or implementation response? Does available evidence support the stated fulfilment position? A record can be present and still fail the second or third question. For example, a verification activity called “pointing analysis” supplies a label, but it does not explain the operating conditions or identify a usable report.
This separation reflects an important source distinction: ECSS-S-ST-00C Rev.2, clauses 9.2 and 9.3 treats customer-defined applicability and supplier demonstration of compliance separately. An agent should work within that agreed relationship. Finding a plausible clause does not authorise it to add the clause to the contract.
Define the review inputs before the agent starts
Write a short review brief that someone outside the immediate team can reproduce. Include the purpose of the check, the evidence boundary and the decision the output will support. This is particularly useful for a first contract, where the same engineer may otherwise switch silently between bid assumptions and approved project requirements.
| Input | What to record | Why the reviewer needs it |
|---|---|---|
| Obligation set | Applicable standards, revisions and agreed tailoring decisions | Separates relevant requirements from merely related text |
| Project scope | Supplier deliverable, product level and current engineering question | Prevents conclusions about records outside the assignment |
| Controlled context | Requirement revision and the baseline or proposal under examination | Exposes comparisons against the wrong engineering state |
| Evidence set | Included reports, record versions and known missing inputs | Makes an incomplete review visible |
| Allowed output | Findings, questions and proposed edits | Separates assistance from an accepted change |
| Review owner | Engineer responsible for disposition and the next approval route | Gives each consequential finding somewhere to go |
Preserve exclusions as well as inclusions. If the agent did not receive a supplier report, ask it to describe the information gap. Do not let the absence of a retrieved document become a claim that the supplier has never performed the work. Those statements lead to different engineering actions.
Worked example: an old result and a proposed tighter requirement
The fictional Lark attitude-control unit has requirement REQ-LARK-010: maximum steady-state pointing error of 0.15 degrees. An existing analysis reports 0.12 degrees under its recorded assumptions. A proposed edit tightens the maximum to 0.10 degrees. These values illustrate a record comparison; they are not ECSS limits or a complete pointing specification. The illustrative Lark programme records keep the example inspectable.
A useful finding identifies the proposal, the previous requirement and the existing report. Numerically, 0.12 is below 0.15 but above 0.10. That supports a narrow observation: the reported value does not meet the proposed threshold under the stated comparison. It does not establish that the flight product will fail, that the original analysis is wrong or that changing a sensor is the correct remedy.
The engineer should check whether the report measures the same quantity, uses the applicable configuration and covers the conditions intended by the proposed requirement. If those conditions are unclear, the first proposed edit may be a clarification to the requirement rather than a design change. A well-presented agent finding exposes that uncertainty instead of hiding it behind a red status.
What should a reviewable finding contain?
Use a finding structure that makes the next decision easy. The following is an editorial review format, not an official ECSS document or a claim about a particular Arc screen.
| Finding element | Useful content |
|---|---|
| Observation | Describe the mismatch or missing information precisely |
| Source context | Identify the relevant clause and its applicability record |
| Project context | Identify the requirement, proposal and evidence revisions examined |
| Reasoning | Explain how the observed facts support the finding |
| Proposed action | Suggest a clarification, edit or reassessment with a named owner |
| Uncertainty | State assumptions, missing inputs and alternative interpretations |
| Disposition | Record the engineer's decision and its rationale |
For the Lark example, “reassess this evidence if the requirement change is approved” is more useful than “non-compliant”. The former identifies an action and its trigger. The latter can confuse the accepted baseline, a pending proposal and the engineering state of the unit.
How should engineers review proposed edits?
Review the source interpretation before the proposed wording. Confirm that the cited clause is relevant to this product and that any agreed modification has been applied. Next inspect the engineering records. A correct source reference cannot rescue a comparison against an obsolete requirement or a report for another configuration.
Then assess the proposed change on its own merits. Does it preserve the intended obligation? Does it introduce a new assumption, weaken acceptance criteria or shift work to another supplier? If an agent proposes changing an existing compliance statement, ask which evidence supports the new statement. Better wording and demonstrated fulfilment are separate questions.
Finally route any accepted proposal through the project's established decision process. For verification, ECSS-E-ST-10-02C Rev.1, clause 5.4.2 describes the Verification Control Board and customer approval of its conclusions. An agent's finding or an engineer's initial agreement is not a replacement for that agreed route.
Evaluate the agent with deliberately difficult records
Before expanding a check, prepare an engineer-reviewed example set. Include a valid case, an actual omission and a record that only appears problematic. Examples might use a correctly excluded clause, a report valid for another configuration and a requirement with an intentional blank field explained elsewhere. Clearly label these as evaluation records.
Record missed issues, unsupported findings, reviewer corrections and the effort required to reach a decision. Review the quality of sources as well as the wording of the answer. A finding that sounds convincing but cannot be traced back to the examined records may consume more engineering time than it saves.
Keep the permitted task narrow until the results support expansion. Revisit the example set when the source collection, project model or check changes. The goal is to understand the behaviour of the workflow you actually use, rather than obtain a reassuring score from an unrelated demonstration.
How Arc's ECSS compliance agents fit this workflow
Arc has ECSS compliance agents that work across relevant clauses and propose edits for engineer review. Its connected engineering model gives the team a place to relate requirements, engineering work and supporting evidence. The scope of a particular check should be agreed for the project and inspected through its outputs.
Use one bounded assignment when evaluating Arc: bring a requirement set, its applicable obligations and an evidence example, then ask the team to examine the proposed changes together. Assess whether the findings help your engineers decide what to investigate or correct. The illustrative record above describes a review method, not a claim that every deployed agent produces those exact fields or checks every ECSS clause.
For the wider role of AI, read AI and ECSS standards. Continue with the ECSS Verification Control Document guide when the next task is to organise verification planning and evidence.
Frequently asked questions
What is an ECSS compliance agent?
In this guide, it is an AI-assisted workflow that examines defined project records against relevant ECSS obligations and prepares findings or proposed edits for engineer review. Its useful scope depends on the task, available sources and project context; the name does not establish complete clause coverage.
Can an ECSS agent approve compliance?
Treat agent outputs as proposals for review. ECSS-S-ST-00C Rev.2 assigns the supplier responsibility for demonstrating compliance with project requirements, while applicable project procedures determine the required decisions and approvals.
What should engineers check in an agent finding?
Check the relevant source revision and tailoring decision, the engineering records examined, the reasoning, the proposed action and any missing inputs. Then assess the technical consequence before accepting an edit.
Does Arc offer ECSS compliance agents?
Yes. Arc offers ECSS compliance agents that work across relevant clauses and propose edits for engineer review. Agree and evaluate the scope for the project rather than assuming every standard or clause is covered.
How can a team evaluate an ECSS agent?
Use a bounded, engineer-reviewed example set containing valid records, known gaps and plausible false alarms. Record missed issues, unsupported findings, source quality, reviewer corrections and the effort needed to reach a useful decision.
Evaluate Arc
Put ECSS compliance agents to work on your programme.
Try a clause check and review the proposed edits with your engineers. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.