One connected workspace for requirements, architecture and verification.
Arc is a connected workspace for requirements, architecture, systems, tests and verification evidence. It helps fast-moving space teams control parallel change, understand impact and keep the engineering record current without returning to a network of spreadsheets and file links.
Move from spreadsheets to a connected record in reviewable stages.
Start with a contained programme slice. Arc can import existing requirements, fields, links and verification evidence, then give discipline owners a clear path to validate the new structure before it becomes the working authority.
01
Import & migrate
Bring the existing requirement set, fields, links and evidence into a controlled workspace.
02
Build
Configure item types, relationships, ownership and views around the programme’s operating model.
03
Refine
Let systems engineers and discipline owners validate structure, resolve gaps and improve traceability.
04
Review
Inspect the mapped record, agree the baseline and expand only when the team trusts the result.
Import & migrate → Build → Refine → Review
03 Product system
One programme model. Four connected ways to stay current.
Move from isolated documents to a structured engineering record, give contributors a controlled way to change it, inspect every dependency before approval and use agents to keep context from going stale.
03.01 Product feature
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.
Configurable programme modelModel the engineering record around your programme.
Create the requirement, architecture, system, interface, risk, test and evidence types your process needs, then connect them with explicit relationships instead of relying on copied identifiers and fragile file links.
01 · Requirements modelTrace mission intent into verifiable engineering requirements.
Follow each need through requirement derivation, subsystem allocation, satisfaction and verification.
02 · System architectureConnect what the system must do to the elements that perform it.
Separate functional behaviour from physical structure, then make allocations and interfaces explicit.
03 · Product breakdownNavigate from the mission system to segments, subsystems and equipment.
Keep the product hierarchy explicit without mixing programme organisation into the engineered system.
04 · Verification modelConnect each requirement to its method, test configuration and evidence.
Keep the planned verification case, test article, procedure, execution, result and closure traceable.
03.02 Product feature
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.
Controlled parallel changeGive contributors room to work without losing the baseline.
Permissions, ownership, contextual comments, formal reviews and attributable approvals keep proposed work visible while the accepted programme record stays controlled.
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?
LucJoshMoniquePavan
02
Branching & merging
Propose changes safely, compare the diff and merge approved work into the baseline.
Change controlBaseline · 184
ViewingProgramme baseline⌄
BaselineApproved record · 2d agoCurrent
burn-durationJosh · Ready for review+4−2
hotfire-evidenceMonique · Updated now+1
Proposal #184Update 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
03.03 Product feature
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.
Connected impact evidenceReview the affected system before approving the change.
Follow upstream intent and downstream dependencies across requirements, interfaces, tests and verification evidence so reviewers can assess the engineering consequence, not only the edited field.
The graph contains 100 requirements and 25 test cases arranged across seven levels. Severe impacts include test case HF-002 and eight items across the final two levels; unaffected branches remain neutral.
03.04 Product feature
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.
Human-controlled assistanceLet agents maintain context while engineers retain authority.
Configure agents around requirements, traceability, risk, verification, compliance and change impact. Read-only agents surface issues; drafting agents propose work for an engineer to review before the programme changes.
04 Product evidence
Evaluate the complete operating model, not a feature checklist.
These are the practical capabilities to test with a live programme slice. Each link points to Arc’s reviewed capability or deployment evidence.
01 · Flexible data model
A single source of truth shaped around the real system
Configure item types, fields and relationships for requirements, architecture, systems, interfaces, risks, tests and evidence. An intuitive interface gives every discipline a current view without forcing the programme into a fixed schema.
Model functional and physical architecture beside requirements, interfaces and verification so a reviewer can follow why an item exists, what satisfies it and how it will be proven.
Trace upstream and downstream relationships across requirements, architecture, interfaces, tests, results and evidence. Surface missing coverage while the programme is moving, not only before a review.
Protect the accepted record while work moves in parallel
Branches isolate proposed work from the accepted baseline. Diffs, impact analysis, comments, reviews and attributable approvals make the engineering decision inspectable before it is merged.
Use ownership, permissions, contextual comments and @mentions to bring the right contributors into a requirement or change without separating the conversation from the programme record.
Define verification methods and test cases, track coverage and connect results and evidence to the requirements they verify so review preparation starts from the current record.
Retain the history behind every controlled decision
Keep revisions, comments, review activity, approvals and baseline changes attributable so teams can reconstruct what changed, who accepted it and which evidence supported the decision.
Use a governed intelligence layer without handing over engineering authority
Read-only agents can monitor context and surface gaps. Drafting agents can propose updates, while engineers remain responsible for meaningful changes and approvals.
Arc supports managed cloud and customer-controlled deployment discussions, including on-premise and firewall-contained environments, with processing rules shaped for each deployment.
Pilot one real change from requirement to evidence.
Import a contained programme slice, reproduce its relationships, propose a cross-subsystem change and reopen the affected verification work. Measure whether daily contributors can understand and review the result without a separate reconstruction exercise.
Use these answers to define the first conversation, then confirm programme-specific migration, security and deployment requirements with Arc.
What is Arc?+
Arc is a requirements management and verification platform for fast-moving space engineering teams. It keeps requirements, architecture, systems, tests, evidence and controlled changes in one connected programme record.
Can Arc import our existing requirements spreadsheets?+
Yes. Arc can import existing requirements, fields, links and verification evidence, map them into a connected model and let the team review that structure before a wider rollout.
How do branches and baselines work in Arc?+
A branch gives contributors a safe place to propose work without changing the accepted baseline. Reviewers can inspect the diff, comments, approvals and affected engineering context before an approved proposal is merged.
How does Arc use AI while keeping engineers in control?+
Read-only agents can monitor programme context and surface gaps. Drafting agents can propose changes, but engineers remain responsible for meaningful updates and approvals.
Which deployment options does Arc support?+
Arc supports managed cloud and customer-controlled deployment discussions, including on-premise and firewall-contained environments. Exact security, processing and retention controls are defined for the selected deployment.
07 See Arc with your programme
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.
