An ECSS Verification Control Document, or VCD, connects the requirements to be verified with their planned methods, levels and stages, then records evidence and close-out as work progresses. AI can help a team prepare questions and proposed updates around those records. Useful verification control still depends on technically appropriate plans, applicable evidence and the project's required decisions.
What is the VCD for?
ECSS-E-ST-10-02C Rev.1, Annex B describes a VCD that develops with the product lifecycle. Its initial issue contains the verification matrix; later issues incorporate planned activities, execution evidence and ultimately verification close-out. The VCD therefore serves a different purpose from a static list of tests or a final folder of reports.
The distinction matters when you bid for your first ECSS-governed contract. You need to understand the intended proof before promising a delivery date. An attractive specification can conceal a verification activity that needs unavailable equipment, missing supplier data or an operational condition that has not been defined. Building the planning record exposes those questions while the team can still act on them.
Keep the boundary clear: a VCD controls product verification information. A clause-level compliance response also needs to address applicable process and deliverable obligations. ECSS-S-ST-00C Rev.2, clause 9.3 addresses the supplier's demonstration against project requirements. Your ECSS compliance matrix and VCD may link to one another without being interchangeable.
Plan the method, level and stage for each requirement
The verification standard identifies test, analysis, review of design and inspection as verification methods. It distinguishes the product level from the verification stage and calls for an agreed verification approach. These concepts appear in clauses 4.2 and 5.2.1; the applicable project configuration determines their implementation.
| Planning question | Record to establish | Common ambiguity to resolve |
|---|---|---|
| What must be demonstrated? | Requirement identity, revision and technical meaning | The requirement omits the relevant operating conditions |
| How will it be demonstrated? | Method and a link to the relevant planning material | “Test” is entered without explaining the measurement |
| At what product level? | The level at which the verification is performed | Equipment evidence is treated as proof of an integrated behaviour |
| At which verification stage? | The applicable stage, such as qualification or acceptance | A result is reused without checking its intended role |
| For which configuration? | The represented product and evidence configuration | A report cannot be related to the delivered unit or design |
This table is a planning aid, not a reproduction of the full VCD document requirements definition. In particular, configuration context and a short ambiguity note are useful working additions. Check the actual Annex B requirements and your customer deliverables before deciding that a compact spreadsheet contains everything required.
Worked example: planning verification for the Lark unit
For the fictional Lark attitude-control unit, REQ-LARK-010 specifies a maximum steady-state pointing error of 0.15 degrees. The abbreviated statement deliberately leaves questions for a project engineer: which reference frame, disturbances, operating mode, interval and error definition are intended? These details need to be established before a result can support a reliable conclusion. The value is an illustrative project requirement, not an ECSS-prescribed threshold.
Suppose the team proposes analysis as part of the verification approach. The planning record should explain the model, inputs, assumptions and acceptance comparison. It should identify the represented product level and the proposed verification stage for agreement. Further methods may be needed for the complete requirement; the example does not prescribe a universally sufficient pointing-verification strategy.
| Example record | Illustrative entry | Engineering question |
|---|---|---|
| Requirement | REQ-LARK-010, maximum error 0.15 degrees | Have operating conditions and the measured quantity been defined? |
| Candidate activity | Pointing performance analysis | Are the model and assumptions appropriate to the requirement? |
| Existing result | 0.12 degrees under recorded assumptions | Does the report address the intended configuration and conditions? |
| Comparison | Reported value is below the stated threshold | What else must be established before close-out? |
The illustrative Lark programme records provide the common requirement and change scenario used across this cluster. Treat them as connected teaching records. They are not a completed VCD or a substitute for a technically justified verification plan.
Keep compliance status and close-out status distinct
Annex B, section B.2.1, verification control data includes requirements and traceability, methods, levels, stages, planning references, supporting documentation, compliance status, close-out status and reasons. This distinction lets a reviewer ask both what the evidence indicates and whether the required verification decision has been completed.
A team can otherwise accidentally make “report uploaded”, “result acceptable” and “requirement closed” mean the same thing. Use explicit working states that preserve the differences. A report may exist but await technical review; an acceptable result may depend on unresolved assumptions; a completed review may still need the customer-facing disposition specified for the project.
Reference the evidence precisely enough to be useful. A link to a large document does not tell the reviewer which analysis or measurement supports the requirement. Add the relevant report revision and location, represented configuration, key assumptions and the reason for the recorded conclusion. These are practical information-management recommendations for making the underlying evidence easier to examine.
Where can AI help prepare a VCD review?
Use AI assistance to prepare bounded questions: which requirements have no proposed method, which evidence references point to a different revision, or which recorded close-out reasons need explanation? Specify the records to inspect and ask for reviewable proposals. The task is to help the engineer examine the evidence chain, not to infer acceptance from a matching document title.
For a first project, begin with one verification subject and compare the proposals with the team's own review. Include a correctly open requirement and a record with intentionally incomplete information. You want to see whether the workflow distinguishes a genuine omission from work that is simply planned for a later stage.
AI assistance is also useful as an editorial aid to a review package: request a concise explanation of open questions and their owners, then check it against the records. Do not present this suggested use as proof that a particular tool has already performed every check. Evaluate the actual agent and configuration through representative examples.
What happens when the requirement changes?
In the Lark example, a proposal tightens the maximum from 0.15 to 0.10 degrees. The old reported value of 0.12 degrees now exceeds the proposed threshold. Preserve the report and the earlier requirement revision. The result has not changed; the claim being assessed has changed. The team must investigate whether the existing analysis remains appropriate and what further work follows if the proposal is approved.
Clause 5.4.3 addresses re-verification after changes including requirements changes following initial verification. It places determination of the extent with the supplier, subject to customer agreement, and requires affected requirements to remain open in the VCD until the specified re-verification and close-out are completed. This is more precise than assuming every edit requires every test to be repeated.
Record the decision and the affected evidence scope. A revised wording that clarifies an existing condition can have different consequences from a tighter performance target. The engineer's assessment should explain that difference. See ECSS change impact analysis for the broader baseline and approval workflow.
How Arc can support the verification information
Arc connects requirements to verification activities and evidence in its flexible programme model. That supports organising the information behind a VCD: what must be demonstrated, the intended activity, supporting records and the associated review context. Arc's ECSS agents can propose edits for engineer review within the relevant clause context.
When setting up the project, map the required VCD information to the configured records and identify how the customer will receive it. Confirm the actual output format and content needed for your agreement; this guide does not claim a particular VCD export or a fully populated document is supplied automatically.
Bring an open requirement, an evidence report and one proposed change into an Arc evaluation. Ask the team to reconstruct the planning and fulfilment position from those records. That exercise tests whether the workflow makes the next verification decision clearer, which is the practical purpose of keeping the information connected.
Frequently asked questions
What is an ECSS Verification Control Document?
ECSS-E-ST-10-02C Rev.1 Annex B describes a document that lists requirements with the selected verification methods, levels and stages, and develops to include evidence and close-out information. It contains the verification matrix and is maintained as verification progresses.
Is a VCD the same as an ECSS compliance matrix?
No. A VCD controls the product verification information described in the verification standard. An ECSS compliance matrix addresses the supplier response to applicable ECSS obligations, including obligations fulfilled through processes or deliverables. The records can be linked without being interchangeable.
Can AI close requirements in a VCD?
Use AI to prepare findings and proposed updates for review. Under the verification standard, verification completion involves the VCB and customer approval of its conclusions. A generated summary or proposed status change does not establish that those steps are complete.
Does a changed requirement need re-verification?
ECSS-E-ST-10-02C Rev.1 clause 5.4.3 addresses requirement changes after initial verification. The supplier determines the extent of re-verification and agrees it with the customer. Requirements subject to that work remain open until re-verification and close-out are completed as specified.
Can Arc support ECSS verification planning?
Yes. Arc can connect requirements, verification activities, evidence and review context. The project must map its required VCD information to its configured records and establish the deliverable content and format needed by the customer.
Evaluate Arc
Put ECSS compliance agents to work on your programme.
Connect verification planning to the evidence and decisions behind closure. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.