ECSS tailoring establishes how the standards and requirements invoked for a project apply to its specific scope. An ECSS applicability matrix, often recorded as an EARM, should preserve the source edition, applicability decision, rationale and agreed wording where relevant. Start from the customer’s requirement set, distinguish proposed changes from agreed decisions, and keep applicability separate from evidence that an obligation has been fulfilled.
What does an applicability decision establish?
The ECSS system description assigns responsibilities on both sides of the customer-supplier relationship. Its customer-side requirements address the applicable requirement set; the supplier side addresses demonstration of fulfilment. This distinction is the foundation of a useful tailoring workflow.
An applicability decision answers whether and how an obligation applies to a defined product or activity. A compliance response answers how the supplier addresses that obligation. If these decisions are collapsed into one green status, a team can mistake an agreed exclusion for demonstrated compliance or overlook an obligation that applies but has no delivery plan.
Scope is essential. A decision that is appropriate for a study may not establish the position for later equipment delivery. Record the product boundary, phase and agreement context rather than assuming that the last project’s matrix can be reused unchanged.
Use the official ECSS EARM as a source resource
The official EARM download is an Excel export of requirements, recommendations and permissions from ECSS modules. The resource includes active and superseded modules. Identify the editions needed by your project before selecting rows.
Keep three things distinct: the source export, your working applicability assessment and the agreed project baseline. The first contains source material; the second contains the team’s analysis; the third reflects the decisions on which delivery proceeds. Saving a copy of the export does not create that agreement.
Record where a requirement came from even when its text is later represented elsewhere. A useful reference includes the standard identifier, revision, clause or requirement identifier and project source. This allows an engineer to inspect the obligation rather than trust an isolated sentence returned by a search or agent.
A practical workflow for building the EARM
- Define the assessment boundary. Identify the contracted product, phase, interfaces and activities.
- Register the source set. Include the customer’s references and the precise editions being assessed.
- Read requirements in context. Consider the scope, definitions and relevant cross-references, not only the row’s isolated text.
- Record the proposed position. State whether the obligation applies unchanged or whether a change is being proposed, with the full proposed wording when necessary.
- Explain the reason. Connect it to the project characteristics and relevant engineering assessment.
- Resolve the decision. Record who agreed it, when and through which project record.
- Connect delivery work. Link each applicable obligation to its requirement, process, deliverable or activity.
This sequence is Arc’s implementation guidance. Follow the specific governing documents for your required format and decision process. The objective is an inspectable record that remains meaningful to someone who did not attend the original discussion.
Which fields make the decision traceable?
| Field group | Suggested information | Review question |
|---|---|---|
| Source | Standard, revision and requirement identifier | Are we assessing the correct source? |
| Scope | Product, activity and phase | Where does this decision apply? |
| Proposed applicability | Position and modified or additional wording | What exactly is being proposed? |
| Rationale | Project context and supporting assessment | Why is the proposal justified? |
| Agreement | Decision owner, state, date and reference | Has the responsible authority agreed it? |
| Delivery relationship | Requirement, procedure, plan or supplier task | How will an applicable obligation be addressed? |
These fields are an illustrative structure, not an official form. ECSS-S-ST-00C Rev.2 section 9.2 describes customer-side applicability documentation, including the formulation of modified and additional requirements. Use that source and the project’s agreement to verify the required content.
Worked example: keep the proposed position visible
The fictional Lark team supplies an attitude-control unit. It imports its customer’s applicable-document list and notices a process obligation whose wording assumes a wider product responsibility than the team believes it has. The team should first investigate the boundary rather than declare the row irrelevant.
| Illustrative record | Working position | Next action |
|---|---|---|
| APP-LARK-01: source and product boundary | Source edition recorded; ownership boundary requires clarification | Systems lead compares statement of work and customer requirement set |
| APP-LARK-02: proposed process adaptation | Proposed wording drafted; agreement pending | Submit rationale through the project’s agreed review route |
| APP-LARK-03: obligation retained unchanged | Applicable; fulfilment still to be assessed | Assign delivery and evidence owners |
The identifiers and positions are fictional. They demonstrate a decision pattern without reproducing or pretending to tailor an actual clause. Notice that APP-LARK-03 can be applicable and still have incomplete evidence. Applicability is a prerequisite to the fulfilment assessment, not its result.
Maintain the decision when the project changes
A changed product boundary, supplier arrangement or contractual reference should trigger a review of affected applicability decisions. Preserve the previous baseline and the explanation for the new position. This is especially useful when one person made the original interpretation and another must assess its consequences months later.
Do not treat a newly available source edition as an automatic change to the agreement. Record the discrepancy, assess its implications and obtain the relevant decision. The ECSS change-impact guide follows a controlled change through the work and evidence that depend on it.
Once applicability is established, use the compliance matrix example to organise the supplier’s response. Linking the records preserves both questions without repeating the same analysis in disconnected files.
How Arc supports ECSS tailoring work
Arc’s flexible model can represent the source, scope, decision and delivery relationships. Its ECSS templates offer a starting structure, and compliance agents can check relevant programme information and propose edits for review.
A useful agent task is to surface records whose stated scope differs from their linked work or whose applicability decision lacks context. The project must evaluate the finding. The tool does not establish which tailoring proposal the customer should accept, and a suggested mapping should remain distinguishable from the agreed requirement set.
Frequently asked questions
What is ECSS tailoring?
Tailoring adapts the applicable ECSS requirement set to a project’s characteristics and agreement. Record what applies, what is modified or excluded, the rationale and the relevant agreement decision.
What is an ECSS EARM?
An EARM records ECSS requirements applicability. The official ECSS resource provides source requirements in an Excel export that projects can use for tailoring. A project must still establish its own agreed applicability set.
Is an EARM the same as a compliance matrix?
They answer different questions. An EARM identifies the applicable obligations. A compliance matrix records the supplier’s position on fulfilling those obligations. One workspace can connect them while retaining the distinction.
Can a supplier simply delete an ECSS requirement?
A supplier’s proposed exclusion is not automatically an agreed change. Record the rationale and resolve it with the responsible customer through the applicable agreement process.
Can Arc support an ECSS applicability matrix?
Arc’s flexible model can represent source references, applicability decisions and links to the work that addresses obligations. Templates can provide a starting structure and agents can propose edits for review; the project determines the agreed applicability.
Evaluate Arc
Bring your ECSS requirements, reviews and evidence together.
Connect agreed applicability decisions to the work they govern. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.