Define the decision object
The lab manifest identifies artifact hash, target, configuration, expected revision, and window. Each field answers a different question: which content, where, with which parameters, starting from which state, and when. Changing the target while retaining the package does not preserve approved scope. The script changes one field at a time and checks that the manifest digest changes. This is a teaching model connecting assessment with execution, not an approval system. In a fictional APS change, compare the candidate manifest with the reviewed one and describe differences to the applicable authority. Do not overwrite the reference merely to make a discrepancy disappear.
Separate digest and trust
The code serializes its small JSON object with sorted keys and computes SHA256. Changing only key order does not change that result; changing configuration or target does. This serialization belongs to the exercise and is not presented as a universal JSON signing standard. A digest compares content with a reference but identifies neither its approver nor whether the reference is trustworthy. It also does not establish functional correctness. A real process needs identity, reference integrity, permissions, and decision evidence. When reporting the result, state that content matches the reference and keep separate the question of who had authority to establish it.
Use expected state as a prerequisite
A plan prepared for revision=7 may become unsuitable when an urgent mitigation leaves the service at revision eight. The lab uses two SQLite connections: one reads seven and another changes the row to eight. An UPDATE conditioned on seven affects zero rows and preserves the intervening state. SQL executed without a syntax error but did not apply the change. This exposes an outdated premise. Do not remove the condition to obtain a changed row; reconcile the plan with current state. Even if a new technical condition passes, a valid decision about the new context remains necessary. A single-row guard does not authorize an external deployment.
Make identity and time rules explicit
The exercise defines two local rules: requester and approver have distinct subject identifiers, and start time belongs to [start,end). Alice and Duty approver have different names but the same subject u17, so they fail the first rule. A start exactly equal to end fails the second because the final endpoint is excluded. These rules are lab assumptions, not BNP Paribas policies or universal tool behavior. The script does not authenticate people. When designing a real control, identify the applicable rule, trusted sources of identity and time, authorized exceptions, and evidence needed to explain a decision. A passing model cannot replace those operational arrangements.
Calculate the window from instants
The fictional window begins at 01:30+01:00 and ends at 02:30+00:00 on the same date. The instants are 00:30 UTC and 02:30 UTC, giving 120 minutes. Subtracting only displayed times would give sixty and lose the offset. The code uses explicit offsets; it does not consult daylight-saving rules or establish an organization’s clock configuration. In an international plan, retain the date and time reference of each boundary and provide a clear display for local teams. Distinguish authorized end, latest safe recovery start, and each participant’s availability. A meeting invitation does not change any of these limits.
Add capacity to the dependency graph
The plan has a ten-minute freeze, followed by a twenty-minute snapshot and fifteen-minute configuration; a 25-minute deployment waits for both, and validation takes fifteen. Without staffing constraints, validation ends at seventy. However, snapshot and configuration need the same DBA full-time. Placing configuration after snapshot moves completion to 85. With an additional reserve of 35, the plan needs 120 minutes rather than the ninety authorized in this second fixture. A precedence graph is not automatically a resource-feasible schedule. Show the conflict, corrected sequence, and options: change scope, separate preparation where possible, obtain qualified capacity, or negotiate another window through a valid decision.
python3 content/labs/change-evidence/run.py
# Package equality does not cover target, configuration or expected state.
# Explicit offsets: 01:30+01:00 -> 02:30+00:00 = 120 minutes
# Resource-feasible execution: 85; recovery reserve: 35; total: 120The approved package stays identical, but overnight mitigation changed the service revision. The team compares the new manifest and recalculates the window before selecting the execution target.
Common pitfalls
Confusing hash with signature, label with identity, observed state with authorization, or a resource-unconstrained critical path with an executable window.
Related topics: Technical project management · Git · CI/CD
Authorization has scope and conditions. The plan must remain valid for the content, state, people, and time actually available.
Reference: Guide for Security-Focused Configuration Management of Information Systems · BigSavant Change Management 2026.1; independent technical curriculum