An ECSS compliance matrix records how a supplier addresses the ECSS obligations applicable to its project. Start from the agreed requirement set, preserve each source reference, and connect the supplier’s response to evidence, gaps and actions. The worked example below shows an illustrative matrix that develops from an honest tender position into a traceable engineering assessment.
What does the ECSS compliance matrix demonstrate?
Section 9.3 of ECSS-S-ST-00C Rev.2 describes supplier-side compliance documentation and identifies an ECSS compliance matrix as a recommended method. The record concerns the applicable ECSS requirement set and the supplier’s indication of compliance, including justification where deviations are identified.
A useful matrix makes a claim inspectable. A reviewer should be able to locate the obligation, understand the position being asserted and follow the information supporting it. A green cell with no source, configuration or explanation does not offer that route.
The article’s sample adds practical fields to support that investigation. They are Arc’s suggested working structure. The project must check the format and content requested by its customer, including how tender responses and delivery assessments are distinguished.
Keep four different records conceptually separate
| Record | Primary question | What it should not be mistaken for |
|---|---|---|
| EARM/applicability record | Which obligations apply, and how? | Evidence that those obligations are fulfilled |
| ECSS compliance matrix | What is the supplier’s fulfilment position? | A list of product requirements alone |
| Requirements traceability matrix | How are requirements connected to their sources and related records? | An automatic judgement that every relationship is adequate |
| Verification control record | What verification is planned, performed and assessed? | A complete account of every management or process obligation |
The official EARM resource concerns tailoring inputs. The verification standard identifies the Verification Control Document among its expected documents. These purposes can be represented in one connected workspace without using one status to mean all four things.
For a general RTM explanation, use the existing requirements traceability matrix guide. This page concentrates on the supplier’s response to applicable obligations.
A practical ECSS compliance matrix template
Start with stable identifiers and record the source edition. Then add enough context for a reviewer to understand the claim. The following groups form the downloadable illustrative example.
| Information | Recommended fields | Reason for retaining it |
|---|---|---|
| Obligation identity | Record ID, source reference and applicability link | Connects the response to the agreed obligation |
| Supplier position | Response and explanation | States what the team is actually claiming |
| Demonstration | Evidence or deliverable reference and relevant configuration | Lets a reviewer examine support for the claim |
| Incomplete work | Gap, action and accountable owner | Keeps planned work visible |
| Decision | Review state and decision reference | Separates the working assessment from accepted closure |
Use the customer’s agreed response categories. If an internal team uses labels such as planned, evidence available and review pending, explain them. Do not present an internal status vocabulary as an ECSS-mandated taxonomy.
Worked supplier example: three different obligations
The fictional Lark attitude-control unit has a customer performance requirement, a verification-planning obligation and a procedure-related obligation. The examples below use original project identifiers. The ECSS references are thematic references for teaching; they are not a validated clause-by-clause mapping for an actual programme.
| Illustrative record | Supplier position | Supporting record or gap | Next action |
|---|---|---|---|
| REQ-LARK-010: maximum steady-state pointing error 0.15 degrees | Development analysis available | AN-LARK-01 reports 0.12 degrees; applicability to delivery configuration requires assessment | Review inputs and configuration before claiming delivery fulfilment |
| OBL-LARK-VER: verification planning | Plan in preparation | Methods and owners proposed; review is outstanding | Complete planning record and obtain the required decision |
| OBL-LARK-CM: change procedure | Procedure draft available | Responsible change authority remains to be recorded | Resolve responsibility and review the procedure |
The first row is a customer performance requirement, not an ECSS clause. It appears in the broader project example to demonstrate why the source type must remain visible. An ECM addressing only ECSS obligations would distinguish its own subset rather than silently relabel every project requirement as ECSS.
The second and third rows illustrate why a compliance workflow includes processes and deliverables. A pointing analysis cannot demonstrate that a change procedure has been established. Each claim needs the appropriate kind of supporting work.
Develop the matrix from tender to delivery
At tender stage, a response often explains the intended approach and identifies assumptions or gaps. During delivery, replace an assumption with the resulting decision and connect a completed activity to its actual evidence. Preserve enough history to explain why the position changed.
Review the evidence rather than only checking whether a file is attached. Ask what product and revision it represents, what conditions and inputs it used, which acceptance question it addresses and what limitations remain. The answer may support part of the obligation while leaving another part unresolved.
If a review accepts closure, retain the decision with the material that was reviewed. If a later change affects that material, reopen the assessment through the appropriate process rather than letting the previous status persist unexamined. The change-impact example demonstrates this transition.
Review coverage without hiding the exceptions
Use three passes. First reconcile the obligation set with the applicability baseline. Second inspect the supplier response and supporting records. Third examine unresolved items and the decisions required to close them. This is a recommended review routine rather than an official scoring method.
Any coverage number needs an explicit denominator. An assessment of ten selected clauses is not an assessment of the complete project. Keep excluded scope, unresolved applicability and incomplete evidence visible instead of treating missing rows as success.
Download the ECSS compliance matrix CSV example. It contains original illustrative records and source context. Adapt it to the project’s required scope and response categories before using it for real work.
How Arc connects the compliance position to engineering work
Arc’s flexible data model can connect applicable obligations with product requirements, process work, evidence and decisions. Its ECSS project templates help teams establish a starting structure, while compliance agents check relevant programme information and propose edits for review.
This allows an engineer to investigate a finding in its programme context rather than maintain the response only as a disconnected cell. The project still determines applicable scope, assesses evidence and agrees closure. See how Arc supports an ECSS workflow for the complete product explanation.
Frequently asked questions
What is an ECSS compliance matrix?
An ECSS compliance matrix records the supplier’s position against applicable ECSS obligations. It connects the obligation with an indication of fulfilment and the justification, evidence or outstanding actions needed to explain that position.
What should an ECSS compliance matrix template contain?
Begin with the applicable source requirement and the supplier’s compliance indication. A useful working extension includes evidence references, configuration, owner, gap, action and review decision. Confirm the required content and format with the project’s governing documents.
Is an ECSS compliance matrix the same as an EARM or RTM?
An EARM addresses applicability; an ECSS compliance matrix addresses the supplier’s fulfilment position. An RTM connects requirements to other engineering records. A verification control record tracks verification planning and results. Keep those purposes distinct.
Can a tender-stage matrix claim work that is only planned?
Describe planned work as planned and explain the intended approach. Do not present a future activity as completed evidence. Use the customer’s response categories and identify any assumptions or gaps.
Can Arc replace a spreadsheet compliance matrix?
Arc can organise the underlying obligations, requirements, processes and evidence as connected programme records. Whether a project also needs a spreadsheet or another delivered format depends on its agreed outputs; this guide does not claim a prescribed export.
Evaluate Arc
Bring your ECSS requirements, reviews and evidence together.
Connect each compliance response to its owner, evidence and open actions. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.