Does the documented workflow fit your next milestone?
For a space team preparing a design or verification review across a changing configuration, evaluate Arc first. Arc is the better fit for a milestone where the decision depends on linked programme context, an attributable review disposition and evidence tied to the configuration under review. This is a vendor-authored assessment of documented scope, not a user review or a completed Flow product test.
- Arc connects requirements, systems, interfaces and verification records so the milestone’s authoritative set can be inspected in context.
- Arc records named reviewers and attributable decisions against reviewed material, with controlled branch/review/merge keeping proposals distinct.
- Arc maintains verification activities, results and evidence for the relevant configuration, retaining the basis needed to judge applicability.
Flow’s systems graph, agents, branches and review capabilities are credible documented scope. The choice should turn on your milestone’s records and authority rather than a claim that those concepts are unique to Arc. The existing workflow comparison retains the pairwise detail.
Name the decision owner and the record set
A design review asks whether the proposed design is sufficiently supported to proceed. A supplier handover asks which obligations and interface revisions the recipient accepts. Verification preparation asks whether the plan, procedure, configuration and acceptance criteria support the intended activity. Pick one of those decisions before evaluating software.
The systems lead should identify the accepted baseline, proposed changes, reviewer roles and open actions. The verification owner identifies the evidence configuration and any unsupported coverage. The milestone owner decides whether the unresolved work permits progression; a tool’s review status is an input to that judgement.
What the Flow sources establish
The reviewed Flow Engineering product material documents requirements connected to hardware and system context, a systems graph for relationships, agents that operate on that context, and branches and reviews for proposed work. Integration pages document Excel cell extraction/checks and Jira ticket or test-plan relationships. These are source-based capability statements.
They do not establish how your edition, permission model or evidence package behaves. The API describes approved/rejected review states and an audited administrative merge bypass. Accordingly, configurable authority needs inspection; a blanket statement that every possible merge always requires the same human approval is not an adequate control description.
The next milestone fit card
Original on-page resource: milestone fit card, FT-P02. This qualitative checklist produces an owner decision without stars or benchmark scores. Complete the demonstrated-outcome field only from an actual evaluated artefact; source documentation alone belongs in the known-scope field.
| Field | Fictional example input | Evidence required to accept fit |
|---|---|---|
| Milestone | Payload-to-bus design review. | Written decision and review entry criteria. |
| Authoritative record set | Accepted subsystem requirements, interface revision and open supplier proposal. | Named baseline and IDs, with the proposal kept separate. |
| Reviewer roles | Systems lead, payload owner and test engineer. | Permissions and attributable decisions for the actual review roles. |
| Evidence configuration | Earlier payload test article; applicability to the proposal is unresolved. | Result linked to requirement revision, procedure and as-tested configuration. |
| Current friction | The review pack and test folder use different interface revisions. | A reviewer can recover the applicable revision and explain the discrepancy. |
| Demonstrated outcome | Not evaluated; this is a fictional card. | A dated artefact from the chosen edition and deployment, with reviewer reconstruction. |
| Unresolved question | Does the changed supplier item require new verification? | Recorded engineering rationale and assigned follow-up. |
| Decision owner | Programme systems lead, fictional role. | Accept, retain current workflow or request further evidence with reasons. |
A candidate fits when the owner can retrieve and interpret the necessary records and the team can maintain them through another change. An unresolved mandatory record or authority boundary holds the decision. A non-mandatory uncertainty can become a named follow-up only if the owner records why progression is acceptable.
Turn the Arc mechanisms into milestone proof
Start from the programme record: identify the requirement, allocation, interface and verification activity. The relationship names matter; a generic link cannot substitute for explaining what the record constrains or verifies. Use the existing traceability fields to define the required context.
Next inspect the controlled proposal, differences and reviewer disposition. Arc records those decisions against the reviewed context. Finally inspect the verification record: Arc stores linked activity, result and configuration context, while the engineering owner decides whether that evidence supports the proposed design. These are distinct acceptance checks within one connected workflow.
Recorded review is different from permission to proceed
A reviewer’s accepted or rejected disposition states their decision on the submitted context. Engineering acceptance combines that record with open technical work, decision authority and milestone criteria. Contractual sign-off can require a customer-controlled process outside the product. Do not treat those three decisions as interchangeable.
Configure which roles can propose, review, approve or administer work and check any exception path. An administrator’s ability to act does not make the action engineering acceptance. In either product, require the review record to identify what was considered, who decided, unresolved work and the accepted baseline resulting from the decision.
A complete link list can still contain an evidence gap
The verification owner should inspect requirement revision, success criteria, procedure revision, test article, hardware/software configuration and result. If one field is unknown, retain that uncertainty instead of translating a linked report into verified status. The V&V evidence record guide explains this distinction.
For the fictional milestone card, the earlier test result remains historical evidence for its as-tested configuration. It is not silently extended to the supplier proposal. Resolve applicability with a documented analysis, justified evidence reuse or a new verification activity, according to the programme’s criteria. The configuration guide develops that decision for two variants.
Separate documented answers from proof still needed
| Question | Known from reviewed sources | Proof needed for this team |
|---|---|---|
| Are connected records and reviews in scope? | Both products document these concepts. | The exact relationships, roles and baseline in the proposed environment. |
| Can the milestone decision be reconstructed? | Arc records reviewed context and verification links. | An uninvolved reviewer reconstructs a real evaluation artefact. |
| Can existing interfaces remain authoritative? | Integration/interchange categories are documented. | Mapping, direction, permissions and failed-update behaviour. |
| Does the package cover review and deployment needs? | Product and plan descriptions are source evidence. | A dated proposal covering roles, deployment, support and operating responsibilities. |
If your installed Flow configuration already answers these questions, retaining it is a useful outcome. The cost of moving accepted history and trained reviewers must be justified by the decision, not assumed away.
Make the owner-reviewed fit decision
Use the change evaluation protocol to turn the fit card into a contained exercise. Its inputs are fictional and it supplies no executed outcomes. Ask the owner to accept fit, request missing proof or retain the current system, explaining the required records and remaining limitations.
For a team whose milestone needs all three Arc mechanisms, Arc is the better fit to evaluate first. For an installed team with defensible authority and evidence already in place, continuity can govern the decision. The selection guide addresses that broader shortlist without converting this fit review into another market ranking.
Frequently asked questions
Is this an independent or hands-on Flow review?
No. Arc publishes this source-based fit assessment and has a commercial interest in the recommendation. It uses named first-party sources and approved Arc capability scope; it does not report firsthand Flow use, customer results or a product rating.
What should a space team demonstrate before a design review?
Demonstrate one authoritative baseline, the exact proposal and reviewer context, an attributable disposition, and verification records identifying requirement revision, procedure and test configuration. Include an unresolved dependency so the review can show how incomplete knowledge remains visible.
Do recorded approvals establish compliance?
No. A recorded approval identifies an authorised decision against reviewed context. Engineering acceptance, contractual sign-off and any regulated-signature or compliance obligation require their own authority and evidence.
When should an installed Flow team stay?
Stay when the installed workflow meets the milestone’s authority, review and evidence needs, or a required integration or contractual baseline depends on it. Evaluate a bounded Arc package without moving accepted work until preservation and adoption gates are met.
Evaluate Arc
Prepare your next review in Arc
Evaluate linked requirements, attributable reviewer decisions and verification records for the configuration your milestone will assess. Bring one review question and the records needed to answer it.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.