Start with the decision you must reconstruct
Evaluate Arc first when you need to reconstruct one changed requirement, the review decision and applicable verification evidence. Arc connects the requirement to programme context, records branch differences and named review decisions, and maintains verification records for the relevant configuration. Those three mechanisms are the basis for the recommendation; this page supplies a protocol, not a completed demonstration.
Engineers supply the relationship model and decide whether the proposal is acceptable. The exercise must expose missing knowledge rather than reward a graph that appears complete. Execution status: no Arc or Flow run has been performed for this article. All programme records below are fictional teaching inputs, preserving the shared evaluation definition.
Define the accepted fictional baseline B1
B1 has payload demand of 18 W, other demand of 36 W and supply of 59 W in the same illustrative peak operating condition. Total demand is 54 W and available margin is +5 W. Accepted baseline and proposal must remain distinguishable throughout the exercise.
| Record | Protocol content | Explicit evidence/context |
|---|---|---|
| SYS-PWR-001 | Peak demand must be ≤59 W. | Links to AN-PWR-01. |
| PAY-PWR-014 | Controls payload demand; the B1 demand is 18 W. | Links to TEST-PWR-02. No additional payload requirement limit is specified here. |
| IF-PWR-003 | Electrical interface is 28 V ±1 V. | Links to TEST-IF-03. |
| PAY-THM-005 | Plate temperature must be below 50 °C. | AN-THM-04 is available, but the relevant thermal relationship is deliberately incomplete. |
Keep these IDs and meanings stable. The 18 W input is not an invented requirement cap. The presence of a thermal analysis record does not establish a verified-by relationship or a solved physical dependency. Record any additional assumption needed to execute the exercise before using it.
Inspect the 18 W to 24 W proposal
The fictional proposal increases payload demand to 24 W while other demand and supply remain unchanged. The calculation is demand arithmetic for the stated operating condition; it is not a thermal model or a validated flight power budget.
| Quantity | B1 | Proposal |
|---|---|---|
| Payload demand | 18 W | 24 W |
| Other demand | 36 W | 36 W |
| Total demand | 18 + 36 = 54 W | 24 + 36 = 60 W |
| Supply | 59 W | 59 W |
| Margin: supply − demand | 59 − 54 = +5 W | 59 − 60 = −1 W |
The proposal exceeds SYS-PWR-001’s 59 W total-demand limit by 1 W under these assumptions. It therefore cannot simply enter the accepted baseline. A feasible alternative, a formally authorised requirement change or another justified disposition is required. The calculation does not establish how much heat the plate produces or whether the voltage requirement is satisfied.
Keep the proposal outside B1
In an agreed future evaluation workspace, capture the proposed payload value in a branch or controlled proposal. Inspect record-level differences, the reason for change and the responsible owner. Confirm that B1 still identifies the accepted 18 W case and that no result becomes accepted for the proposal merely through an edit.
Arc stores branch differences, discussion, review and merge. Require an inspectable record showing what changed, which baseline is being compared and who can act. Record product version, execution date and permission scope when the exercise is run; this publication makes no claim that those actions have occurred.
Follow explicit links and preserve the thermal gap
Inspect the power requirement and AN-PWR-01, the payload requirement and TEST-PWR-02, and the voltage interface and TEST-IF-03. For each relationship, retain endpoints, revisions, meaning and applicability. Arc’s traceability exposes the stored engineering context; the engineer determines its completeness.
Then ask the thermal owner about PAY-THM-005. AN-THM-04 exists, but the relevant thermal relationship is deliberately missing. The appropriate evaluation finding is unresolved thermal context requiring investigation. Do not silently attach the analysis, declare the plate requirement verified or interpret the absence of a trace as absence of a physical effect. The change-impact guide explains the wider dependency sweep.
Record what the owners accept and what remains open
Proposed fictional review disposition: return the 24 W proposal for rework because the stated power limit is exceeded; retain B1; assign the payload owner a feasible option, the systems owner the power/interface assessment and the thermal owner the missing dependency investigation. The test engineer identifies evidence that needs applicability review. This is an authored reference disposition, not a recorded product outcome.
When executed, require the review to retain the proposal, named decision makers, rationale, disagreement and open actions. Arc records attributable decisions against reviewed context. Use the decision-record fields to distinguish analysis acceptance from permission to change a controlled baseline. Check administrative and API exception authority separately.
Keep historical evidence and judge the changed case
For TEST-PWR-02 and TEST-IF-03, inspect the linked requirement revision, procedure, success criteria, test article and configuration. The protocol does not supply completed test results. If an evaluation package includes an earlier result, preserve its original scope and state rather than treating it as proof for the 24 W case.
Arc connects verification activities, results and evidence to requirements and configurations. The engineer must decide whether reuse is justified, another analysis is needed or a test must be repeated. Evidence for a different condition remains valuable history without becoming applicable by association.
What has and has not been executed
No screenshots, product exports, permission captures or executed review records are supplied. This is a complete protocol-only release, and none of the expected checks below is marked passed. No Flow exercise or timing comparison has been run.
A future run should capture the actual product version/date, record IDs and revisions, relationship view, branch difference, role permissions, attributable review/rejection/approval context and controlled export package. Only approved, appropriately handled outputs can become demonstration evidence. Input records, actual product outputs and editorial acceptance judgements must be labelled separately.
Have another reviewer reconstruct the decision
Give a reviewer the approved exported package from a future run. Ask them to identify B1, the changed payload input, the +5 W to −1 W arithmetic, the unresolved thermal relationship, the review disposition and the evidence applicability decision. They must distinguish proposed state from accepted state without relying on a narrated demo.
If the package omits relationships, review context or evidence configuration, record the missing information and keep the acceptance decision open. A readable report alone does not prove reconstructable programme data. Record what was exported, what remained in the application and what the reviewer needed to ask.
Record evidence maturity step by step
Original on-page resource: evaluation record, FT-P03. The current evidence references are deliberately honest: they point to protocol inputs or state that execution has not occurred. In an actual run, replace them with approved artefact references and label each outcome demonstrated, partly demonstrated or unresolved with the reviewer’s rationale.
| Step | Expected inspectable artefact | Actual evidence reference | Reviewer | Current outcome | Unresolved limitation |
|---|---|---|---|---|---|
| Baseline | B1 record/revision and relationship inventory. | Fictional definition in this protocol. | Systems owner. | Execution unresolved. | No product baseline capture. |
| Proposal arithmetic | 24 W proposal, 60 W total and −1 W margin. | On-page authored calculation. | Payload and systems owners. | Arithmetic supplied; product execution unresolved. | Simplified fixed operating assumptions. |
| Controlled change | Differences, unchanged B1 and permission context. | No executed artefact. | Systems owner. | Execution unresolved. | No branch or role capture. |
| Missing thermal relationship | Visible gap and assigned investigation. | Deliberate protocol gap. | Thermal owner. | Technical resolution unresolved. | AN-THM-04 presence does not resolve applicability. |
| Review | Named disposition, rationale and open actions. | Authored reference disposition only. | Systems, payload and test owners. | Execution unresolved. | No actual review/rejection/approval record. |
| Evidence | Requirement, procedure, article and configuration references. | No executed result or applicability record. | Test engineer. | Execution unresolved. | No demonstrated evidence reuse or new verification. |
| Reconstruction | Export inventory and independent reviewer explanation. | No executed export. | Reviewer outside the exercise. | Execution unresolved. | No export-completeness claim. |
Use the fit review for the milestone decision and the variant extension for configuration-specific applicability. Neither a clean trace nor a proposed AI finding can replace the accountable engineering decision.
Frequently asked questions
Does a clean trace prove all physical dependencies are modelled?
No. A trace shows the relationships present in the record model. This protocol deliberately leaves the thermal relationship incomplete even though PAY-THM-005 and AN-THM-04 exist. Engineers must investigate physical dependencies beyond the linked path before accepting completeness.
What happens to the old test result?
Keep the result and its original requirement, procedure and as-tested configuration references. It remains historical evidence for that condition. The responsible engineer must assess whether it supports the changed proposal or whether new analysis or testing is needed.
Was the same exercise run in Flow?
No. This page is a protocol-only publication. It contains fictional inputs, transparent arithmetic and expected evidence checks; it reports no executed Arc or Flow run, screenshots, exports or comparative performance result.
Can AI approve the changed baseline?
AI can surface context, check records and propose work within configured permissions. It does not replace the named engineering approval authority. Inspect role permissions and administrative exception paths separately, and record the authorised decision against the reviewed proposal.
Evaluate Arc
See your next engineering change in Arc
Bring a representative requirement, a linked test and the review decision your team needs to make. Evaluate Arc’s connected context, controlled proposal and applicable verification records within an agreed scope.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.