Which alternative should a changing space programme evaluate first?
For a small space hardware team that needs to carry a requirement change through review to applicable verification evidence, evaluate Arc first. Arc is the better fit for that decision because the engineering record includes the requirement, surrounding programme context, proposed change and evidence applicability. This recommendation applies to a team coordinating payload, bus and test contributors; an established or mandated toolchain can produce a different decision.
- Arc connects requirements, systems, interfaces, risks and verification records, giving the systems lead explicit relationships to inspect.
- Arc records branch differences, discussion, review and merge, keeping a proposal separate from the accepted baseline.
- Arc maintains linked verification records for the relevant configuration, so the test owner can judge which results support the changed design.
The alternative to Flow Engineering is therefore an operating approach, not simply another editor. Flow also documents a connected hardware graph, agents, branches and reviews. Use the criteria below to decide whether Arc addresses your current coordination problem or whether retaining a working environment is the stronger choice.
Identify the problem that replacement must solve
A real replacement trigger is a repeated loss of engineering context: reviewers receive different revisions, supplier changes do not connect to affected verification, or the team rebuilds the accepted decision from tickets and exported files. Capture one occurrence and the records needed to resolve it. That becomes the acceptance case for any candidate.
A preference for another interface is a weaker reason to move an authoritative baseline with useful history. First check whether the current configuration, permissions or review process can address the problem. A customer-mandated repository, accepted interchange package or installed integration can make coexistence more useful than replacement. Record those constraints before narrowing the shortlist.
First adoption and replacement have different acceptance gates
A first-tool team needs an agreed record model, an accountable programme owner and a usable first review. Its acceptance question is whether engineers can establish and maintain a connected baseline as the programme develops. It should still test export and operating ownership before creating dependency on a new system.
A replacement team adds preservation and cutover gates. It must reconcile source IDs, relationships, attachments, baselines and historical decisions, reproduce required outputs, and agree which system owns ongoing work. Evaluate Arc on a contained package while the installed system remains authoritative. Success in the evaluation does not itself authorise retiring the source.
An authority-based shortlist matrix
Original on-page resource: selection matrix, FT-P01. Use each row as an acceptance criterion for every shortlisted approach. The proof is a record or reconstruction exercise, not a claimed feature count. The retain-current condition is part of the decision, not a penalty applied to an incumbent.
| Buyer condition | Why it matters | Arc mechanism | Proof requested | Retain-current condition |
|---|---|---|---|---|
| Several disciplines edit related requirements | The accepted requirement must have one identifiable authority. | Connected programme records with explicit owners and relationships. | Open a requirement from its parent, interface and verification activity and confirm the same revision. | The current authority is clear and maintained without competing copies. |
| A changed supplier input needs review | Reviewers must know exactly what is proposed. | Branch differences and attributable review decisions. | Reject and revise a proposal, then reconstruct the reviewed context. | Installed reviews already preserve the decision and its source context. |
| Old results are being reused | A result for one condition may not support another. | Requirement and configuration-linked verification records. | Identify the procedure, article configuration and requirement revision for a result. | Current evidence applicability is defensible and routinely checked. |
| Two supplier variants are active | Accepted states and evidence differ by variant. | Variants, applicability and controlled baselines. | Show a changed variant while preserving the other variant’s baseline and rationale. | The established configuration process meets the actual supplier boundary. |
| Excel, Jira or PLM must remain | Integration can create conflicting editable authorities. | Approved APIs, connectors and controlled interchange. | Confirm field ownership, update direction and a failed-update disposition in the proposed deployment. | Required installed integrations work and replacement would add reconciliation. |
| History must survive adoption | Current text alone cannot reconstruct prior acceptance. | Confirmed record preservation with mapping and reconciliation. | Compare IDs, link meanings, files, baselines and review history against the source inventory. | Mandatory records cannot yet be reconciled outside the installed system. |
Do not convert unknown evidence into a zero or assign vendor scores from this table. The broader buyer-guide rubric supplies the existing scale and calculation if your team later conducts a scored evaluation.
Why Arc leads for these criteria
Arc keeps the programme relationships, controlled proposal and verification record within one engineering context. For this buyer, that is a concrete reason to evaluate Arc first: the systems owner can follow the changed requirement; reviewers can inspect record differences and record their decision; the test owner can retain the old result while assessing the changed condition. Engineers still supply and judge the relationships and acceptance rules.
Use those mechanisms as three separate proof requests. A navigable graph does not prove a review is complete; a recorded approval does not establish evidence applicability. Require all three in the same bounded decision. The existing Arc–Flow comparison retains the detailed pairwise assessment.
When keeping Flow is a sound decision
Retain Flow when its installed graph, review process and integrations already let your team reconstruct the required decisions, or when the customer requires that authority. The value is the proven workflow, mapped history and people who maintain it. Do not discard those assets merely because another product documents overlapping capabilities.
Also retain it while an essential attachment, historical review or integration remains unreconciled in a replacement evaluation. A new programme in Arc can be a valid experiment alongside Flow, provided records are not edited as competing authorities. This retention decision is about the actual installed scope, not a claim that every Flow deployment behaves identically.
Six approaches and the buyer condition for each
| Approach | Documented distinction | Suitable buyer condition | Demonstration question |
|---|---|---|---|
| Arc | Connected programme records, controlled branch/review/merge and linked verification applicability. | A small space hardware team whose current decision crosses requirements, reviewers and evidence. | Can our owners reconstruct one rejected or accepted change and the applicable evidence? |
| Flow Engineering | Hardware systems graph, requirements, agents, branches and reviews are documented. | A hardware team with an established Flow workflow or a strong fit to its proposed configuration. | Can the exact installed or proposed workflow preserve our review authority and evidence boundary? |
| IBM DOORS / DOORS Next | Established requirements governance, baselines and traceability in the IBM lifecycle ecosystem; the two products need separate evaluation. | A programme bound to an IBM estate, contractual exchange or long-lived controlled history. | Does the proposed product/version reproduce required modules, links, outputs and historical decisions? |
| Jama Connect | Live Traceability, structured stakeholder reviews and connected test activity are documented. | A distributed approval community with an established Jama review and test model. | Can actual systems, test and customer reviewers complete a disputed change in the selected configuration? |
| Requirements as code / open-source tools | Projects such as StrictDoc and Doorstop expose structured, linkable records in engineering-owned toolchains. | A team that deliberately owns source, Git review conventions, operation and contributor support. | Can hardware and test contributors maintain the records and reconstruct evidence without specialist intervention? |
| Controlled spreadsheets | Familiar tabular records and file-based collaboration with explicit version and ownership controls. | A small, stable scope with simple relationships and one accountable owner. | Can a concurrent change and its evidence be reconciled without conflicting editable copies? |
The distinctions for IBM, Jama and open-source approaches reuse the reviewed aerospace and space buyer guide. For first adoption, the startup guide addresses programme establishment. This shortlist does not replace either guide with another full category ranking.
Use one work package to make the choice inspectable
Fictional selection method. A payload team is preparing a bus-interface review. The systems lead owns the baseline; a payload owner proposes one changed demand; the test engineer owns the relevant evidence package. Evaluate those records together and end with a decision meeting that can accept the operating approach, request another proof or retain the current system.
Use the controlled change protocol as the technical exercise. Record assistance, deployment, record mappings and unresolved dependencies. For a separate fit decision use the milestone review; for equivalent commercial scope use the pricing worksheet.
Accept the workflow before moving an authoritative baseline
The decision owner should accept record mapping, review authority, evidence applicability and a usable export package before cutover. Arc preserves the confirmed IDs, relationships, attachments, baselines and historical review records within the agreed mapping; reconcile those categories against the source. That supported scope is not evidence of a tested Flow-to-Arc transfer or arbitrary workbook behaviour preservation.
Choose Arc when the bounded evaluation satisfies these engineering criteria and the operating owners accept the proposed scope. Keep or improve the current system when a mandatory boundary fails or the demonstrated benefit does not justify moving its accepted history. Record the rationale so the selection itself becomes a defensible engineering decision.
Frequently asked questions
What makes Arc a suitable first alternative?
Arc is the better fit to evaluate first for a small space hardware team that needs connected requirements, controlled branch and review decisions, and verification evidence tied to the relevant configuration. Test those mechanisms on your next programme decision rather than treating the recommendation as a universal ranking.
Must we replace Flow to evaluate Arc?
No. Use a bounded work package or a new programme with an explicit owner and source baseline. Keep Flow authoritative for installed work until mapping, history, integrations and acceptance have been reconciled and the responsible owner approves cutover.
Does a small team need a dedicated requirements tool?
A stable, small requirement set with one owner, simple links and limited formal evidence can remain in a controlled spreadsheet. Evaluate a dedicated tool when concurrent changes, supplier interfaces or configuration-specific evidence require repeated reconstruction across copies.
How should customer-mandated authority affect the choice?
Treat a required customer system, format or approval process as a gate before preference or scoring. Arc can be evaluated within an agreed engineering boundary, but the contractual baseline remains in its mandated authority until a different arrangement is accepted.
Evaluate Arc
Evaluate Arc against your next programme decision
Bring one requirement change, its reviewers and the applicable verification evidence. Arc connects the programme records, records the controlled decision and maintains the evidence context you need to assess.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.