LEARN. PRACTICE. GROW.Plan authority and required information
An urgent change can arrive through an informal call, but the team needs to know who decides and with what information. In analysis planning, define channels, roles, delegations, escalation criteria and decision records appropriate to the project. Someone who understands the requirement may lack authority to commit budget or accept operational risk. The model uses a fictional list of authorized decision makers to demonstrate that distinction; it authenticates no person and validates no signature. In an actual environment, consult applicable governance and retain evidence of authority. Adapting formality to risk can simplify small changes, but does not turn every request into approval.
Approval has an identifiable subject
In the exercise, CR7 proposes moving R from v1 to v2 against baseline B1. The proposal retains a fingerprint of baseline content; the decision also retains a fingerprint of the proposal. This detects differences in the simulation. If someone changes the proposal to v3 after approval, the earlier decision no longer matches the package. The response is not to edit the approval identifier to remove the error: clarify the difference, update analysis and obtain the applicable decision. A fingerprint allows content comparison; it does not establish who approved, whether they had actual authority or whether the original information was true. Those controls need additional mechanisms and evidence.
Concurrent changes and reference versions
While CR7 awaits implementation, another team can update the baseline. Even if CR7 retains the same text, its evaluated context has changed. The teaching policy rejects implementation when the current baseline no longer matches the analyzed one. The BA and technical manager should examine differences, dependencies and conditions of the earlier decision before reusing it. This does not mean that every concurrent change always invalidates approval in every organization; applicability needs to be demonstrated under the local process. Preserve the earlier baseline and rationale for the new decision to reconstruct the sequence. Under close pressure, a link to the original request is insufficient if nobody confirms the reference version.
Approve, implement and accept are different states
Approval of CR7 does not automatically change R. In the exercise, R stays at v1 until a transition receives the matching decision and explicit checks for changed elements. A deferred or rejected state does not permit that transition; textual yes also does not replace the boolean required by the fixture contract. These details expose state assumptions rather than prescribe a universal API. The transition creates a new baseline, retains the old one and records the decision. Test T stays at v1: being a review candidate neither modifies it nor marks it approved. Model checks are synthetic inputs, so they do not establish an actual deployment, test execution or business acceptance.
Close the communication and evidence loop
After the decision, communicate the outcome to affected teams, identify documents needing updates and track actions until sufficient evidence exists. For a cutoff change, the runbook, monitoring, test criteria and user information may need separate review. Reporting should distinguish approved, implemented and accepted, with owners and outstanding actions. Both lab runs passed 36 checks, including altered proposals, stale baselines and withdrawn delegation. This demonstrates the executed synthetic contract. It does not establish legal signature validity, graph completeness or effectiveness of an actual committee. Summarize the decision, the exact approved subject and what remains to be confirmed before closing the request.
# Fictional teaching policy; these are not authenticated approvals.
proposal = propose(B1, 'CR7', {'R': 'v2'})
approval = decision(proposal, 'business-owner', 'approved', authority)
B2 = implement(B1, proposal, approval, authority, {'R': True})
# B1 is retained; B2 records history.
# Changed proposal or baseline: reassessment required by this model.
# A supplied True is not external implementation evidence.CR7 approved for B1/R-v2 cannot be reused in the model for R-v3 or a later baseline.
Common pitfalls
A request as approval; a hash as a signature; earlier approval as unlimited authorization; implementation as automatic acceptance.
Related topics: Requirements management · Estimates and dependencies · Change control and acceptance
Tie decisions to the evaluated version, preserve history and close only states supported by available evidence.
Reference: 6.5 Configuration Management · Five-domain ECO / verified 2026-10-01