Arc provides ECSS project templates to help teams get started. Use a template as the starting structure for your project, then adapt it to the supplier scope, applicable requirements, agreed tailoring and engineering work. A useful first setup connects the obligations you must address with responsible people, planned deliverables and evidence, while making unresolved decisions visible.
What an ECSS project template should help you establish
Arc's ECSS project templates provide a starting point for organising a project. The practical objective is to reduce the effort of establishing a consistent working structure. The instructions below describe the decisions and relationships to work through with that structure. They are not a catalogue of shipped fields or a screen-by-screen account of a particular template version.
For a first-time supplier, the valuable starting point is a project that makes its obligations legible. A colleague should be able to identify the customer requirement, understand who is addressing it, find the planned verification or deliverable and see what still needs agreement. A large populated workspace is less useful if those relationships cannot be explained.
Before importing a broad standards collection, define the outcome of the initial setup. Choose one supplier deliverable and enough connected work to demonstrate the process. Expand after the team can follow the information through a real review question.
Begin with a short project brief
Record what your organisation is supplying, who your direct customer is, the project phase and the technical scope. Identify the source documents and revisions you have received. Mark assumptions made for a bid separately from requirements agreed for delivery. Those distinctions prevent a template from giving uncertain inputs the appearance of an accepted programme baseline.
ECSS-S-ST-00C Rev.2, clauses 6 and 9.2 explains how standards and tailored requirements become applicable through the customer-supplier agreement. Use that actual project context to decide what the workspace needs to represent. The presence of a standard in a library does not, by itself, establish that it applies to your product.
| Project question | Useful starting record |
|---|---|
| What are we supplying? | Deliverable boundary and the responsible organisation |
| What information governs the work? | Source documents, revisions and current agreement status |
| What remains uncertain? | Assumptions, clarification questions and owners |
| How will the team make decisions? | Responsibilities and the applicable review route |
| What will the customer receive? | Planned technical deliverables and the required exchange arrangements |
This is an editorial project-brief checklist. Adapt it to the contract rather than creating empty records simply because a checklist mentions them.
Keep project templates, EARM and compliance matrices separate
An ECSS project template is a workspace starting structure. The official ECSS Applicability Requirement Matrix resource supports tailoring and contains exported requirements, recommendations and permissions. The export also includes active and superseded standards for which modules are available, so the source revision and applicable status need attention.
A compliance matrix records the supplier's response to the obligations made applicable. A VCD organises verification planning and evidence. These records can be connected in one project without becoming the same thing. Assign a clear purpose to each so an engineer does not interpret “included in the template” as “applicable”, or “applicable” as “fulfilled”.
Use the ECSS tailoring and EARM guide for applicability decisions and the worked compliance matrix for supplier responses. This article owns the setup task: making those decisions usable within the engineering project.
Set up one connected example before expanding
Use the fictional Lark attitude-control unit as a small setup exercise. Its abbreviated product requirement REQ-LARK-010 sets a maximum steady-state pointing error of 0.15 degrees. An existing analysis reports 0.12 degrees under recorded assumptions. The illustrative Lark programme records are teaching records; the values are not ECSS requirements and the example is not a ready-to-use flight specification.
| Relationship to establish | Illustrative Lark content | What it helps the team answer |
|---|---|---|
| Source to product requirement | The customer source and REQ-LARK-010 | Why is this performance target in the project? |
| Requirement to responsible product | Pointing requirement and attitude-control unit | Who owns the engineering response? |
| Requirement to verification planning | Candidate analysis activity with its intended scope | How does the team propose to demonstrate fulfilment? |
| Activity to evidence | The analysis report and its recorded assumptions | Which result is being relied upon? |
| Evidence to review decision | The assessment of whether the report supports the requirement | What is agreed and what remains open? |
Keep the obligation to plan verification separate from the pointing-performance requirement. The former concerns a project activity and its documentation; the latter concerns the product. Relating both to the relevant work avoids turning every ECSS clause into a new spacecraft performance requirement.
Agree the minimum record rules your team will use
Decide how the team identifies records, names owners and distinguishes proposals from accepted information. Explain what relationships mean. “Derived from”, “allocated to” and “supported by evidence” answer different questions. Even a small project benefits from writing down those meanings before several contributors start creating links.
Define what information is needed at the current stage. A verification plan can identify intended work while results remain unavailable. The VCD document requirements in Annex B explicitly distinguish the initial planning content from later evidence and close-out content. An early project therefore needs visible planned work and gaps, not invented completed records.
Make the working states understandable. For example, a clarification question can be awaiting a customer response while an associated engineering activity remains planned. Avoid a single “done” label that conflates a completed task, an approved requirement and accepted evidence. These are recommended model-design decisions, not prescribed default names in Arc.
Use a bounded agent review to test the setup
Arc has ECSS compliance agents that work across relevant clauses and propose edits for engineer review. Once the team has established the example's scope, use a suitable configured check to examine the records. Review what the agent considered and whether its suggestions help improve the project information.
For a useful exercise, include a deliberate question such as an analysis record with an unclear applicability statement. Ask the engineer to assess the proposed finding. The result should reveal whether the source and project context are sufficient for this task. It should not be treated as a demonstration that all clauses or all possible omissions have been covered.
Keep any suggested edits in the review process. A template helps establish a consistent starting structure, but the decisions still require the people who understand the contract and product. The agent-review guide explains how to inspect those proposals.
Check whether someone else can use the project
Before expanding the setup, ask a colleague to follow one requirement from source to intended evidence without an oral explanation from its author. Give them an open question to investigate. Note where they cannot identify the current revision, understand a link or determine who owns the next step.
Then walk through the example change from a 0.15-degree maximum to a proposed 0.10-degree maximum. Can the team distinguish the existing baseline from the proposal and locate the old analysis result? The exercise tests the information structure; it does not establish that the proposed engineering change should be approved.
Agree how project information will be shared with the customer and suppliers. Confirm required fields, review material and delivery formats against the actual agreement and available configuration. A tidy internal model is useful only if the team can also provide the information needed by the people accepting the work.
Adapt the template around the engineering work
Arc's flexible connected model supports organising requirements, systems, verification work, evidence and review context. Use that flexibility to represent the project's actual responsibilities and information relationships. Where an obligation concerns a procedure or deliverable, connect it to that work rather than forcing it into a product requirement.
Begin with the smallest scope that demonstrates a complete working path, then add the next subsystem or deliverable using the same conventions. Record any changes to the setup decisions so later contributors understand them. This creates a practical route from an available ECSS project template to a project your engineers can maintain.
If you are still deciding whether Arc fits your process, use the ECSS compliance software evaluation guide. It covers the wider product decision; the setup exercise here shows what to work through once you start.
Frequently asked questions
Does Arc offer ECSS project templates?
Yes. Arc provides ECSS project templates to help teams get started. Adapt the available template to the actual supplier scope, applicable requirements, agreed tailoring and engineering process; this guide does not assert an exact shipped field set.
Does an ECSS template make a project compliant?
A template supplies a starting structure. ECSS-S-ST-00C Rev.2 assigns the supplier responsibility for demonstrating compliance with the applicable project requirements. The team still needs to perform the work, maintain evidence and complete the required decisions.
Is an ECSS project template the same as EARM?
No. The ECSS EARM resource supports requirements applicability and tailoring. A project template helps organise a workspace. A compliance matrix and VCD have further distinct purposes, even when the project connects these records.
What should a first ECSS project setup contain?
Start with the supplier boundary, governing source revisions, owners, open assumptions and one connected requirement-to-work-to-evidence example. Expand the structure once another engineer can use it to answer a real review question.
Can Arc agents help review the template setup?
Arc ECSS compliance agents can propose edits for engineer review within their configured scope. Use a bounded example to evaluate the suggestions against relevant clauses and project context, without assuming complete coverage.
Evaluate Arc
Bring your ECSS requirements, reviews and evidence together.
Adapt your first ECSS workspace to the agreement you need to deliver. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.