Day 2 — Bind approval to one versioned action envelope
Learning decision. Decide whether a favorable approval record still applies to the operation the operator is about to perform. An action envelope is a tuple, not a verb: case / revision / purpose / operation / target / environment / selected fields or affected objects / time range / operator / service consequence / expiry / verification / rollback owner. A changed target, environment, operator or method is a changed request. The safe transition is new review, even when the button label has the same English verb. A reference number records the decision; it does not authenticate the sender or prove that the operator acted.
In W2 only, suppose SIM-DEC-01 declares approval of revision 1 for a read-only export of selected S42 fields in a training environment, covering 13:50–14:10 UTC, with a training custodian as operator and a 14:20 UTC expiry. It says nothing about production, S40, all identity events, a session restriction, or svc-training-enroll disablement. An operator proposal that expands the object set to ALL_SLOTS must be returned for a new scope and business-impact decision. Editing the old request in place would make the approval receipt appear to cover a decision never made. Store the original proposal and the new revision separately.
The following Python 3 standard-library, offline, read-only fixture tests tuple matching and an expiry boundary. It is a classroom classifier; its invented approval reference, role name and timestamp are not a signature, identity proof, collection receipt or production authorization. Predict the five lines before running it in a local Python interpreter.
from datetime import datetime
approved = {
"revision": 1, "action": "read_export", "target": "S42",
"environment": "training", "fields": ("slot", "event_time", "request_id"),
"range": "13:50..14:10 UTC", "operator_role": "training_custodian",
"valid_until": "2026-05-01T14:20:00+00:00", "reference": "SIM-DEC-01",
}
bound = ("revision", "action", "target", "environment", "fields", "range", "operator_role")
request = {key: approved[key] for key in bound}
def gate(proposal, decision, at):
if decision is None or not decision.get("reference"):
return "NO_DECISION_RECORD"
if any(proposal.get(key) != decision[key] for key in bound):
return "REAPPROVAL_REQUIRED"
if datetime.fromisoformat(at) >= datetime.fromisoformat(decision["valid_until"]):
return "EXPIRED"
return "MATCHES_DECLARED_TUPLE_ONLY"
print("original:", gate(request, approved, "2026-05-01T14:10:00+00:00"))
print("wider_target:", gate({**request, "target": "ALL_SLOTS"}, approved, "2026-05-01T14:10:00+00:00"))
print("new_revision:", gate({**request, "revision": 2}, approved, "2026-05-01T14:10:00+00:00"))
print("at_boundary:", gate(request, approved, "2026-05-01T14:20:00+00:00"))
print("missing_record:", gate(request, None, "2026-05-01T14:10:00+00:00"))
Expected exact output, reproduced for this fixture:
original: MATCHES_DECLARED_TUPLE_ONLY
wider_target: REAPPROVAL_REQUIRED
new_revision: REAPPROVAL_REQUIRED
at_boundary: EXPIRED
missing_record: NO_DECISION_RECORD
The output is deliberately not AUTHORIZED_TO_EXECUTE. This small function cannot validate delegation, approved service impact, the authenticity of SIM-DEC-01, the operator's identity, an execution receipt or effect. The at_boundary line makes the comparison inclusive: at 14:20, the declaration is expired. That expiry is an approval limit, unrelated to C01's ambiguous data-retention “24 hours.” A real procedure must also handle clock source, revocation and concurrent revisions. A passing fixture result is never a reason to perform a tenant action.
Worked example. The cloud tool offers a checkbox labeled “include all slots” while the W2 approval names only S42. Selecting it changes target to ALL_SLOTS; the classifier returns REAPPROVAL_REQUIRED. The operator should stop, record the mismatch, and ask whether a wider, separately assessed request is appropriate. They must not claim that the selected S42 export was collected. If the original narrow export later runs, an independent source receipt and selection check are still needed before calling its result verified.
Practice. Work EX007 with the main C02 checkpoint, keeping approval, operator, execution and verification pending. Add a new revision column for a hypothetical scope expansion and state exactly why the old revision does not cover it. Compare with the worked answer and its Week 2 application. Limit: the W2 code checks declared fields only, and C02 has no approval specimen at all. Previous: Day 1 · Week index · Next: Day 3.
Exercise for this lesson
EX007 — Action request. Input: the cloud colleague's “disable now” question at 09:04. Draft a proposed action record with target, trigger, service risk, approval, operator, expiry and verification. Fields unsupported by C02 must say pending, not contain invented receipts. A 2-point result recommends a bounded first step rather than asserting account misuse.