Arc
Skip to product content

One connected workspace for requirements, architecture and verification.

Arc is requirements management and verification software for space engineering teams. Connect requirements, architecture, tests and evidence, with controlled change and AI agents that keep engineers in control.

How to get started with Arc.

Bring your existing engineering information into Arc, connect it into a living graph and give your team and agents one place to move the programme forward.

  1. 01

    Import & migrate — Bring CSV, Word, Jira, Git and Confluence into Arc. The import agent understands your source material: no reformatting, no data loss and no six-month migration project.

  2. 02

    Build — Arc builds the architecture described in your documents and connects requirements, systems, interfaces and evidence. Your existing information becomes a living engineering graph.

  3. 03

    Collaborate — Review, comment and approve in a simple interface for every engineering discipline. Each discussion and change stays connected to the relevant items in the graph.

  4. 04

    Accelerate — Agents review structure, quality and coverage across the graph. See unverified changes, missing links, broken traces, conflicts and downstream risks immediately, rather than weeks later.

Arc keeps the whole engineering programme connected.

Give systems engineers and every discipline one structured workspace for requirements, architecture, systems and tests, with agents helping the team keep every dependency current as the programme changes.

Single source of truth

Bring spacecraft requirements, architecture, systems and verification into one flexible, structured workspace that models the programme your way. Define the item types, fields and relationships your engineering process needs across the bus, payload and ground segment, so every item stays connected without being forced into a fixed schema.

01
Requirements

Create, assign, review and evolve requirements in one connected record.

VEHICLEStage velocity change UPPER STAGEBurn time MAIN ENGINERated thrustChamber pressureMixture ratio
02
Architecture

Map system structure, subsystem boundaries and the interfaces between them.

UPPER-STAGE PROPULSION FUEL FEEDTank + valves OXIDISER FEEDTank + valves PRESSURISATIONSupply + control MAIN ENGINETCA + ignition FLOWCMD
03
Systems

Organise components, parameters and requirements within each system.

PROPULSION SYSTEMQualified burn MAIN ENGINEREQUIREMENTRated thrustREQUIREMENTChamber pressureREQUIREMENTMixture ratioREQUIREMENTStart sequence
04
Tests

Trace every requirement to its test cases, results and verification evidence.

REQUIREMENTBurn durationPROP-018 TEST CASEIgnition test TEST CASEHot-fire ANALYSISThermal margin RESULTRESULTEVIDENCE

A model that fits your programme — Define the item types, fields and relationships your engineering process needs. Requirements, interfaces, risks and tests keep their own meaning in one flexible data model.

Architecture with engineering context — Build the functional and physical architecture described in your source documents. Connect systems, subsystems and interfaces to the requirements they satisfy and the evidence that verifies them.

Trace from intent to evidence — Follow explicit relationships from a top-level requirement through the system design to tests and results. Each discipline works with the same connected record as the programme evolves.

Collaborative workspace

Use Git-style branches to give spacecraft, payload and ground-segment engineers a safe place to propose changes. Compare diffs, discuss the work in context, resolve conflicts and merge approved updates back into the programme baseline.

01

Team collaboration

Manage permissions, ownership and comments directly alongside the requirement.

System graph · Live 4 active
SystemUpper stage
SubsystemPropulsion
SubsystemFlight control
Requirement · PROP-014Burn duration3 comments
TestHF-027Linked
MM

MoniqueCan we link HF-027 before merge?

02

Branching & merging

Propose changes safely, compare the diff and merge approved work into the baseline.

Change control Baseline · 184
ViewingProgramme baseline ⌄
BaselineApproved record · 2d ago Current
burn-durationJosh · Ready for review +4−2
hotfire-evidenceMonique · Updated now +1
Proposal #184 Update qualified burn duration

2 files changed +4 −2

Requirement diff · PROP-0142 changes
Baseline

−145 s

Qualified burn duration
Proposed

+160 s

Qualified burn duration
No conflicts · 2 approvals

Work in parallel, control the baseline — Explore a change on a branch while the accepted record stays stable. Compare the diff, resolve conflicts and merge the work when the required review is complete.

Review where the work happens — Add comments, mention colleagues and approve changes beside the relevant engineering item. Ownership and permissions give each discipline a clear, intuitive way to contribute.

Keep the decision behind the change — Revisions, discussions, review activity and approvals remain attributable. Reopen a baseline to understand what changed, who accepted it and which evidence supported the decision.

Impact analysis

A single spacecraft requirement or interface change can ripple through dozens of downstream artefacts. See the full blast radius, including affected test cases, design elements and sibling requirements, before you commit.

Impact trace ready Programme dependency graph
Items
125
Levels
7
Tests
25
Affected
67
Seven-level programme dependency tree A top-level qualified engine burn-duration requirement connects to 124 downstream requirements and tests. A change reaches 67 items, including nine severe impacts across levels five to seven.

A proposed change to PROP-001 reaches 67 connected requirements and tests across the programme.

9 severe 8 direct 40 downstream 10 verification

See the connected consequences — Follow a proposed change upstream to its intent and downstream to the systems, interfaces and sibling requirements it affects. Give reviewers the context to make the engineering decision.

Make verification coverage visible — Connect requirements to verification methods and test cases. See which requirements have evidence, which still need coverage and which checks a change puts back into question.

Bring affected evidence into review — Keep test results and supporting evidence alongside the requirement they verify. Surface affected tests and unverified changes so the team can decide what to review or repeat.

Agents

Use read-only agents to monitor space-programme context, check coverage and surface issues. Use drafting agents to propose suggested changes for engineers to review, so your team stays in control.

Check the whole engineering graph — Agents review structure, requirement quality and coverage across the connected model. Missing links, broken traces and requirement conflicts become visible immediately, before they turn into programme risks.

Turn findings into reviewable work — Read-only agents flag issues and explain the affected context. Drafting agents propose fixes for an engineer to review; meaningful changes and approvals remain with your team.

Keep assistance inside your boundary — Use agent permissions and processing controls that fit your programme. Choose SaaS, on-premises or air-gapped deployment, with customer-owned databases available across all three.

Implement Arc with your team.

Start with a useful slice of your programme, connect the people and systems around it, then make Arc part of the team’s everyday engineering work.

  1. 01

    Import a representative requirement set

    Choose a real system or subsystem with requirements, interfaces and verification context. Let the import agent bring it into Arc, then inspect the connected result with its owners.

    A connected starting point
  2. 02

    Connect the tools your team uses

    Bring in the relevant documents, issues and Git repositories. Agree which systems own each piece of information and how those sources connect to your engineering graph.

    Your tools in context
  3. 03

    Invite the people who do the work

    Add systems, hardware, software and test engineers. Set ownership, access and reviewers so everyone can find their work, contribute and understand what needs approval.

    A shared team workspace
  4. 04

    Start working from the accepted baseline

    Agree the initial baseline, then begin using branches, comments and reviews for real changes. Connect test evidence and use agent findings to keep coverage and traceability current.

    A working engineering record

Use Arc through MCP, with the engineering record still in control.

Arc’s MCP server gives compatible AI tools permission-aware access to search, traceability and controlled actions. This worked example shows exactly what that means using an illustrative CubeSat power change.

Explore Arc MCP →
  1. 01

    Search through MCP

    Ask a compatible AI client to find requirements, systems, interfaces, risks, tests and evidence that the Arc user is permitted to access.

    Permission-aware retrieval
  2. 02

    Follow the trace

    Move from PAY-PWR-014 to its electrical interface and verification plan instead of searching separate files for the surrounding context.

    Cited connected records
  3. 03

    Assess the numbers

    In the illustrative example, a 24 W payload proposal raises total peak demand from 54 W to 60 W against 59 W available, changing margin from +5 W to −1 W.

    Explicit units and arithmetic
  4. 04

    Prepare, then review

    Use MCP to prepare proposed records or a change branch. An engineer inspects the diff and decides whether the accepted baseline should change.

    Human-controlled merge

Product questions, answered.

Answers about importing your information, configuring the model and working with your team in Arc.

Which files and tools can Arc import requirements from?

Arc supports CSV, Word, Jira, Git and Confluence. Its import agent reads and understands the source material, bringing existing requirements and engineering context into a connected workspace without first reformatting the source files.

Will we lose information when we migrate to Arc?

Arc imports the source information without data loss or a six-month migration project. Start with a representative requirement set so your team can inspect the imported items, source context and connections before establishing the working baseline.

Can Arc build architecture and traceability from our documents?

Yes. Arc builds the architecture described in imported documents and connects requirements, systems, interfaces, tests and evidence into a living graph. Your engineers can inspect the resulting structure and relationships, then extend the model as the programme develops.

Can we configure our own engineering item types and fields?

Yes. Arc has a flexible data model for defining item types, fields and relationships around your programme. Requirements, architecture, interfaces, risks, tests and evidence can retain their engineering meaning while remaining connected in the same workspace.

How do engineers collaborate without changing the accepted baseline?

Engineers propose work on branches, add contextual comments and review changes alongside the affected graph items. Reviewers compare diffs, resolve conflicts and approve work before it is merged into the accepted baseline. Ownership, permissions and attributable history keep the process clear across disciplines.

How does Arc connect requirements to tests and verification evidence?

Arc links requirements to verification methods, test cases, results and supporting evidence. Coverage views show where proof is present or missing, and change-impact analysis surfaces affected verification work so engineers can decide what needs review or retesting.

What can Arc’s agents find, and can they change the baseline?

Agents review the graph’s structure, quality and coverage, immediately flagging unverified changes, missing links, broken traces, requirement conflicts and downstream risks. Read-only agents surface findings; drafting agents propose fixes. Engineers retain responsibility for meaningful changes and approvals to the accepted baseline.

Can we use Arc from an AI assistant through MCP?

Yes. Arc’s MCP server lets compatible AI clients search permitted programme records, follow traceability, assess change impact and prepare controlled updates. Arc applies the user’s permissions, and material changes can remain on a branch for review before merge.

Where can Arc run, and can we keep our own database?

Arc supports multi-tenant SaaS, on-premises and air-gapped deployments. Bring your own database is a data-ownership configuration available across all three. Choose model-provider, processing, retention and access controls for your deployment with the Arc team.

Bring one real workflow. Test the connected record.

Try Arc for free, or review the comparison library before deciding which requirements-management approach fits your team.

Request an Arc trial from the homepage Open comparisons