Preserve the accepted state and identify each variant’s evidence
Arc is the better fit to evaluate first when configuration-specific requirements and applicable verification evidence govern a supplier change. Arc connects programme records, controls branch/review/merge before accepted baseline changes and links evidence to the requirements and configurations it verifies. Arc also represents variants and applicability.
Flow documents branching and configuration scope too. The buyer’s decision is whether the proposed workflow preserves the accepted baseline and makes variant-specific evidence defensible. Do not use the existence of branches as a claim of exclusive capability or complete configuration control.
Distinguish baseline, branch and applicability
An accepted baseline identifies the record set accepted by the programme’s authorised process. A working branch holds a proposal relative to that state. Applicability states which requirement revision, supplier option, hardware/software configuration or evidence record belongs to which variant. Those three concepts serve different purposes.
A merge can update a controlled record set when permitted by the accepted process; it does not by itself establish engineering acceptance or contractual release. A variant label also needs a definition. “Supplier B” alone cannot identify the as-built and as-tested state that a verification result represents.
What Flow’s branching and configuration sources establish
Flow Engineering Branching documents branches, review and branch export in PDF, DOCX and CSV. The API documents approved/rejected review states and an audited administrative merge bypass. Inspect the configured authority and resulting baseline rather than relying on an absolute approval slogan.
The 5 October 2026 pricing snapshot, rechecked 6 October, documents one configuration for Basic and unlimited configurations for Pro. Those are package allowances. They do not establish how requirements, supplier changes and test evidence are controlled in the chosen environment. Use the commercial scope guide to confirm entitlement separately from technical acceptance.
Extend the shared protocol without inventing qualification results
Fictional variant method. Variant A retains the accepted supplier arrangement in B1. Variant B is a proposed alternative supplier arrangement under review. Both must meet the identified electrical interface; no assertion is made that either has completed qualification. The shared baseline definition and power change supply the original IDs and arithmetic.
Here the new decision is applicability, not another full power exercise. Treat supplier identity, article configuration and requirement revision as explicit fields. Variant B’s proposal does not alter Variant A’s accepted state. The deliberately incomplete thermal relationship remains unresolved for the affected proposal; introducing variant labels does not repair it.
A two-variant applicability matrix
Original on-page resource: variant applicability matrix, FT-P06. “B1 accepted revision” and “proposed revision” are descriptive states for the fictional protocol, not invented version labels. Potential result references below are evidence to identify in a real evaluation; no test result has been produced here.
| Requirement / state | Supplier configuration | Verification activity | Result revision / status | Disposition | Authority and rationale |
|---|---|---|---|---|---|
| PAY-PWR-014, B1 accepted revision. | Variant A, accepted supplier arrangement. | TEST-PWR-02 for the B1 condition. | Actual result/revision not supplied in this protocol. | Preserve B1 and original evidence scope. | Systems and test owners identify any real result’s original article and condition. |
| PAY-PWR-014, proposed revision/context. | Variant B, alternative supplier proposal. | TEST-PWR-02 scope requires review for the proposal. | No executed Variant B result. | Evidence applicability unresolved; no automatic carry-over. | Test owner determines analysis or test work needed for the changed configuration. |
| IF-PWR-003, B1 interface requirement. | Both variants are intended to satisfy the interface; proof is separate. | TEST-IF-03. | No shared result or qualification claimed. | Compare article/setup and supplier implementation before reuse. | Interface and test owners record the applicability rationale. |
| PAY-THM-005, thermal requirement. | Variant B proposal; investigate affected scope. | AN-THM-04 is available, with a deliberately incomplete relationship. | No thermal applicability result. | Keep the missing relationship and physical assessment open. | Thermal owner supplies and reviews the dependency model. |
For real records, add actual revision IDs, source baseline, serial or build references, procedure revision, result and review decision. A row is accepted only when the responsible authority can explain its applicability; an empty evidence field remains unknown.
Propose the supplier change without overwriting accepted state
Capture Variant B’s proposed requirement and supplier context in a controlled branch. Inspect differences against the identified source baseline, affected interfaces and proposed verification work. Reviewers should see which variant changes and which accepted records remain unchanged.
Arc records the proposal, review context and attributable decisions before a controlled baseline change. Require an actual evaluation to show reject/revise/accept state and the authorised decision. An administrator permission or merged record is not a substitute for the programme’s engineering and contractual authority.
Decide reuse explicitly and retain historical evidence
Compare requirement revision, supplier implementation, hardware/software build, test setup, environment, procedure and acceptance criteria. If the differences are irrelevant under a justified applicability rationale, the responsible owner can accept reuse. If they change the verified condition, plan the needed analysis or test. If their significance is unknown, keep reuse unresolved.
The earlier result stays linked to its original scope; it does not disappear because a proposal changes. The evidence-applicability guide separates accepted design, realised unit and test configuration. No result for Variant A automatically closes Variant B’s verification row.
Reconstruct the variant decision from controlled records
In an actual evaluation, ask a reviewer to identify each accepted baseline, proposed supplier change, requirement revision, evidence scope and rationale from the approved package. Record which relationship and review information is in the export and what remains in the application. A PDF or CSV format label alone does not prove complete programme reconstruction.
The protocol execution-status section explains the evidence needed. No screenshots or executed variant exports are published here. When a proof is missing, record it rather than declaring the exercise passed.
Keep specialist configuration authorities explicit
The configuration authority matrix distinguishes engineering requirements from CAD, PLM, BOM, build and test records. Arc maintains the configuration-specific requirement, review and evidence context; the agreed specialist system can remain authoritative for product definition or realised-unit data.
Before adoption, reconcile baseline membership, identifiers, applicability relationships, historical decisions and references to specialist records. Retain a mandated PLM or established Flow workflow when it already preserves those controls or cannot yet be reconciled. Choose Arc for the stated criteria once the actual variant workflow and operating boundary are accepted; product choice alone does not qualify hardware or approve a contractual baseline.
Frequently asked questions
Is a branch an accepted baseline?
No. A branch can hold a proposed change. An accepted baseline is the identified record set accepted by the authorised process. Review disposition, permissions and the resulting accepted state must be explicit before proposed content becomes authoritative.
Does one test result apply to both variants?
Only with a justified engineering applicability decision. Compare requirement and procedure revisions, supplier configuration, article, setup and operating conditions. Preserve the original result and record the rationale for any reuse; a linked report does not automatically verify another variant.
Does configuration pricing establish workflow capability?
No. Flow’s displayed configuration allowances identify package scope: Basic has one configuration and Pro has unlimited configurations in the 5 October 2026 snapshot. Demonstrate variant-specific review, baseline preservation and evidence applicability separately in the proposed edition and deployment.
Can Arc replace the authoritative PLM record?
Arc controls configuration-specific engineering requirements, baselines and evidence. That does not establish ownership of CAD, BOM, serialised manufacturing or authoritative PLM records. Keep the agreed specialist authorities and reconcile their references unless a different boundary is separately accepted.
Evaluate Arc
Review a variant change in Arc
Connect supplier applicability, a controlled proposal and the evidence records for each configuration. Evaluate how Arc preserves the accepted baseline and the rationale for evidence reuse.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.