Authority, delegation and pre-incident rehearsal

Week 1, day 4. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

1.3 Roles and decision authority

A small organization may assign several roles to one person, but the decisions remain distinct:

Lesson table; scroll horizontally to read all columns →

The analyst should not shut down a service merely because a dashboard looks unusual. The service owner may not decide that logs are irrelevant because the service appears available. The incident lead brings the owners and evidence together, records the decision and revisits it as facts change.

A useful decision record contains a timestamp, the current situation, available options, the chosen action, the person who approved it, the evidence supporting it, expected effects and a review time. Record rejected options as well when they explain an important tradeoff. A terse record made during the incident is more reliable than a reconstructed story written weeks later.

Separate recommendation, approval, execution and verification

One person can perform more than one role in a small team, but four verbs should remain visible in the case record. The analyst recommends an action and cites observations. An accountable person approves its scope and tradeoff. An operator executes the bounded change. A reviewer verifies whether the change achieved its objective and records any harm. None of these verbs can be inferred safely from a job title alone. NIST SP 800-61 Rev. 3, sections 2.2–2.3 discusses distributed response roles and the need for documented authorities and procedures; the four-verb record below is OpenCyber Academy's teaching device for making those authorities observable.

Lesson table; scroll horizontally to read all columns →

These assignments are fictional exercise rules. They are not a claim about any real organization's legal authority or an instruction to disconnect a production system. A useful approval says more than “go ahead”: it names the target, action, duration, expected disruption, evidence to preserve, rollback trigger and next review. If an urgent action is needed but the designated approver cannot be reached, the response lead follows the organization's approved escalation policy; the learner must not invent authority from silence.

Consider a recommendation to restrict desk-a after R1–R5. The analyst can state a plausible benefit: additional unauthorized edits might stop. The analyst must also state a plausible cost: front-desk staff might lose access during a busy period. Neither benefit nor cost is yet measured. A decision record that says “account compromised; disable immediately” hides both uncertainty and authority. A better provisional record is: “At 09:05 UTC, preserve the supplied records and seek the training owner's confirmation by 09:15; if an unexplained new booking edit appears, reconvene the incident lead, service owner and identity administrator for an approved restriction.” The time and threshold here belong to this synthetic case, not to a universal response policy.

1.3a Rehearsing authority before an incident

1.3a.1 From knowing a job title to proving a usable decision route

A response plan may correctly say that the service owner approves an interruption and the incident lead approves a bounded collection. That statement is necessary but not enough to know that a future decision can be executed lawfully and safely. What if the primary owner changed positions last month? What if the listed alternate can authorize a small room-booking pause but not an export of unrelated patron data? What if the approval route works during office hours but nobody has tested the designated contact channel? What if the delegation was revoked or its date passed?

An incident response team should discover such gaps before a real event forces a difficult choice. The preparation question is not "Does a person appear in a chart?" It is "Can a reviewer reconstruct an exact, currently valid path from a named request to the responsible decision maker and custodian, with explicit scope and a safe result when the path fails?"

Section 1.3 distinguishes recommendation, approval, execution and verification. AR1 asks students to rehearse whether those stages are reachable through current authority records. A successful pre-incident rehearsal demonstrates only that the simulated routing and verification rules were applied correctly for a declared version and time. It does not preapprove later actions or establish that a real person answered a real message.

NIST SP 800-61 Revision 3 places incident-response planning and coordination within Cybersecurity Framework 2.0 risk management. NIST SP 800-84 addresses the design, conduct and evaluation of IT plan tests and exercises. The versioned authority-register and validation procedure developed here are original educational techniques for exploring those documented concerns, not forms prescribed by NIST.

1.3a.2 A role name is not proof that a particular person holds authority

A service map may name "service owner," "identity administrator," "application custodian" and "incident lead." Each label describes responsibility, but the label alone does not establish which person currently fills the role, which specific actions they can approve, or whether a listed alternate is allowed to sign on the primary's behalf.

A role is a category of responsibility. An appointment associates that role with a verified organizational identity for a declared time. A delegation gives a defined subset of authority to another person or role under explicit terms. A custodian manages an object or source and may carry out an authorized request but does not automatically own the business risk decision. A requester can explain why evidence is needed; being the requester is not the same as granting the request.

Before an incident, a reviewer should be able to locate the actual authoritative governance record for each appointment and delegation, together with its issuer, approval status, version and validity period. In a real organization, that record may depend on employment status, identity-management groups, formal delegations or other governed systems. The OpenCyber Academy exercise does not assume any particular implementation.

A name typed into a spreadsheet is weaker evidence than a current, owner-reviewed appointment supported by the organization's authoritative process. A contact-list entry may remain useful after a person leaves a role, but it is no longer a valid decision source unless the governance system says otherwise. If the reviewer cannot establish the appointment, the correct outcome is to hold the action and escalate, not to treat familiarity with the person's name as proof of authority.

1.3a.3 Establish a versioned register with explicit acceptance questions

A useful authority readiness register needs more than columns for name and phone number. It must tell an independent reviewer whether the proposed decision route is valid for the operation under consideration. At minimum, it should identify:

Lesson table; scroll horizontally to read all columns →

The register itself also needs provenance. A file named latest-authority.xlsx is not adequate evidence of being latest. A change identifier, accountable issuer, recorded review and version transition should make it possible to determine whether a local copy is obsolete. The reader should know which system is authoritative and how to resolve a conflict between two copies.

A register can be a paper table for the introductory exercise. The skill being taught is validating an explicit set of claims, not choosing a particular database or ticketing vendor. Its fields are fictional instructional design choices; no NIST source is presented as requiring this exact schema.

1.3a.4 Scope belongs to the delegation, not merely to the original request

Suppose the service owner can authorize a temporary pause of one staff-booking write route. An alternate may be delegated authority for that specific pause, for a short period. That delegation does not automatically allow the alternate to approve a production database restore, disable every account, retrieve patron newsletter records or extend the pause indefinitely.

The request must therefore be compared with the allowed operation and object scope in the register. The same named alternate might have different authority for evidence collection and for a disruptive service control. A delegate approved for one operation should be rejected for another unless a separate valid record covers it.

The AR1 fixture uses two deliberately narrow activities. First, a request to review a synthetic training-audit selection containing only TR-01 or TR-02 requires the fictional incident lead's decision and a designated audit custodian. Second, a request to prepare a staff-write pause requires both fictional incident-lead and service-owner decision roles; a documented alternate may fill the service-owner role only for that narrow class of pause.

This is a rehearsal of route validity, not the execution of either action. The output REHEARSAL_PATH_VALID_NOT_EXECUTED never means "audit collected" or "write pause applied." In a real incident, the team would still need a current business decision, collection or change authorization, operator receipt, technical verification and applicable privacy safeguards.

Scope checking should fail closed. If the request includes an unrelated object, the checker should not silently ignore that object and approve the rest as if the original request were unchanged. It should return a hold condition and require an explicitly corrected request.

1.3a.5 Validity periods and expiry are operational safety controls

An alternate's authority may be valid only for a specified interval. A reviewer needs to know both the effective start and the last valid instant, and should use a consistent time basis. In the AR1 teaching model, the delegation is effective from 13:00 to before 14:30 UTC on the fictional rehearsal date. A check at 14:15 can satisfy the time condition; a check at 14:31 cannot.

The strict rule matters: a previously valid delegation is not indefinitely valid. The fact that a person approved something yesterday does not grant them the same scope today. A register also can expire as a whole. A delegate cannot be treated as current under an edition that the governance process no longer accepts merely because the individual delegation date looks recent.

The exercise should distinguish expiry from revocation. Expiry means the delegated validity interval has elapsed. Revocation means a governed decision withdrew the delegation before its nominal end. Either should block reliance on the alternate for the affected operation.

If a timestamp is missing or cannot be compared, do not select the value that makes the test pass. The appropriate state is unverified time or authority, subject to review. The AR1 script assumes UTC-aware timestamps and rejects two explicit expired cases; it is not a substitute for authenticating clocks in real organizational records.

An approaching expiry can also be a readiness maintenance trigger. The team should review critical delegations before their deadlines, identify the next approved owner and rehearse the updated route. This prevents a contact list from becoming a silent single point of failure.

1.3a.6 The owner, approver and custodian can be different people

A request might be valid in business purpose but routed to the wrong custodian. For example, a service owner may approve a limited interruption while an application operator is the only role permitted to apply it. An incident lead may approve a narrow evidence request while the application custodian retrieves records. A collector may not be authorized to approve expanded collection merely because they possess technical access.

The register should model both who may decide and who may carry out the approved task, as separate checks. A valid approver with an invalid executor is not a valid execution route. Conversely, a valid executor with no valid approval must not carry out the action.

In AR1, the imaginary training-audit request names an audit custodian; the staff-write-pause request names an application operator. Swapping them produces a wrong-custodian result even when the requested scope and approver fields are otherwise correct.

This is not meant to impose an organization-wide requirement that every small-team role be held by a distinct human. The book already explains that small organizations may combine roles. The relevant requirement is that the logical decisions and evidence for each stage remain distinguishable. A single person holding multiple documented roles must still exercise each role within its applicable authority.

When the same individual would propose, approve and execute a high-impact change, the organization may require additional independent review according to its actual governance. AR1 does not create such a requirement or grant exceptions. It teaches learners to record the unresolved policy question rather than invent a separation-of-duties rule.

1.3a.7 Use a registered confirmation route rather than an unverified reply

Knowing the correct role is not enough if the request arrives through an untrusted or unregistered channel. A message from an account displaying a familiar name may not authenticate the person or their current role. A successful email delivery indicator does not establish decision authority.

An authority-readiness rehearsal should specify how the requester can verify a response through a route independently obtained from the approved register. A common concept is a callback or trusted organizational confirmation channel. The concrete method in a real deployment depends on the organization's identity controls, communications policy and threat model.

The AR1 script represents this complex requirement through the literal field registered-callback and a Boolean confirmation flag. These are toy assertions supplied by the exercise. They are not identity proof, a secret challenge, a cryptographic signature, a real phone call or consent.

The pre-incident question is: does the plan name a tested route that would let a reviewer distinguish a valid approver from an impersonator or an obsolete contact? A process that says "send an email to the owner" but has no procedure for verifying a surprising or high-impact instruction remains incomplete.

A negative rehearsal should deliberately supply an unregistered messaging channel and confirm that the proposed action is held. Another should withhold confirmation even when the name and route match. In neither case may the team interpret silence as approval.

This concept differs from the Module 4 DEL4 laboratory, which tests message delivery, version acknowledgement and read-back during simulated incident coordination. AR1 tests pre-incident trust in the authority path itself, before any incident action is selected.

1.3a.8 An approval receipt must identify the bounded decision

A fictional reviewer may receive a response saying "approved." That word alone is insufficient if it does not identify the request, target and scope, the respondent's role, the applicable register version and whether the approval remains current. An approval can be genuine for one task and irrelevant to another.

A useful planned receipt identifies the request ID, decision, operation, objects, approving role and identity, confirmation route, time, restrictions, expiry or review condition and the governing register version. The actual organization may use an established ticket or change process; this chapter does not prescribe a new production system.

AR1 uses a small SIM-RECEIPT placeholder to represent the presence of a fictional approval receipt. If the placeholder is absent, the toy validator returns HOLD_APPROVAL_MISSING. The presence of that placeholder does not authenticate the approver or authorize a real action; it merely lets the learner practice checking that a distinct receipt is part of the planned route.

This is an important epistemic limit. Software can check that fields exist and that values fit a rule. It cannot automatically establish that a real person consciously authorized a service disruption unless the surrounding organizational identity and decision processes supply that evidence.

During a rehearsal, explicitly label the result valid simulated path, not executed. This avoids the failure mode in which a "successful drill" is copied into an actual incident ticket and mistaken for a real approval.

1.3a.9 Two complete contrasting examples: a valid delegation and an unsafe substitute

Correct example — limited, current, confirmed route in a pre-incident rehearsal.

On the invented rehearsal date 2026-09-15 at 14:15 UTC, the register version is AR-3 and is within its stated validity interval. A practice request concerns only the fictional staff-write-route operation pause_staff_writes. The simulated incident lead lead-sim has a separate decision receipt. The named service owner owner-sim has issued a documented, unrevoked delegation allowing alternate-sim to fill the service-owner approval role for this operation and object only, effective from 13:00 until before 14:30 UTC. The designated executing role is app-operator-sim.

Both fictional approvals have scoped training receipts and confirmations through the register's stated registered-callback route. The validator returns REHEARSAL_PATH_VALID_NOT_EXECUTED. The correct interpretation is: the specified routing conditions passed in the isolated exercise. No production pause was approved, performed or verified; no real person's identity was authenticated by this script.

A packet suitable for a two-person pre-incident review would preserve the register version, delegate scope and expiry, simulated approval fields, expected operator, check time, stop conditions and the result. The receiving reviewer could reproduce the decision and identify which evidence a real implementation would need.

Incorrect example — a plausible but expired and unverified substitute.

At 14:31 UTC in a different artificial run, the same delegate's permitted interval has ended. Suppose someone copies the old owner's name from a contact list, adds a request affecting unrelated booking or newsletter objects, and sends it through an unregistered chat account saying that the matter is urgent. The request is not valid merely because the alternate previously held a relevant delegation or because the channel is available.

The first applicable rejection may be delegation expired or scope exceeded, depending on what the validator checks first. A real reviewer should record all discovered defects in the case's correction work, not interpret one program output as approval of everything it did not mention. The team must not fabricate a new delegation or allow the custodian to act based on that request.

The correct response is to hold collection or service change, identify the accountable governance/incident-lead escalation route, obtain a current register or designated approver through authorized channels, and record the unresolved decision. Escalation is an attempt to obtain authority, not an alternative form of authority.

These two examples are not events in the R1–R8 incident and must not be inserted into its 09:05 timeline.

1.3a.10 A safe escalation path does not grant permission

An emergency contact path may be necessary when the ordinary approver or alternate cannot be validated. But the word "escalate" is often misused to mean "find anyone senior enough to say yes." That approach undermines the reason for recording delegations and bounded authority.

A valid escalation procedure specifies who receives the blocked decision, which information may be disclosed, which role verifies the current appointment, how to obtain or clarify authorization, and what the technical operator must not do while the decision is unresolved.

For a collection request whose approval is missing, the analyst may continue assessing already supplied and authorized records under the permitted scope. That does not authorize access to a new system. For a potentially disruptive change with no verified service-owner route, the coordinator may document risks and request a valid decision; it does not authorize execution based on urgency alone.

AR1 includes SAFE_ESCALATION. The output is ESCALATE_HOLD_DELEGATION_EXPIRED: an escalation is requested while the original action remains held. This is deliberately different from REHEARSAL_PATH_VALID_NOT_EXECUTED.

A stronger real-world program might have a separately documented emergency authorization mechanism. If so, its scope, prerequisites, accountable approver and verification would need to be tested as another explicitly versioned authority rule. AR1 neither assumes nor invents such a mechanism.

This differs from the Module 4 F1 replay, where an approver becomes unavailable during a fictional response. The current exercise instead tests whether the pre-incident register and fallback process are ready and current, well before any R-series incident starts.

1.3a.11 A register must be tested against negative controls

A contact list can appear correct in the easiest path but fail when a person leaves, a delegation expires or a request changes scope. A meaningful readiness test therefore needs both positive and negative controls.

The positive control asks whether the correct approvers, scope, version, custodian, receipts and confirmation flags produce a limited readiness pass. Another positive control tests the specifically documented delegate within the valid time window. Those checks demonstrate only the logic of the simulated register.

Negative controls deliberately change one property at a time: replace the approver with the wrong person, broaden the requested objects, omit the approval receipt, use an outdated register version, change the custodian, use an unapproved confirmation channel, suppress confirmation, revoke a delegate, or advance the test time beyond expiration. Each should produce a distinct hold reason.

Why insist on this? If the checker accepts every test, it may not be enforcing any real constraint. If it rejects even valid requests, the organization could be unable to act efficiently when a real incident requires a decision. The quality of a readiness control depends on both kinds of behavior.

The lab outputs one primary rejection code for reproducibility. In an actual review, other defects may coexist. Reviewers should avoid declaring that all unreported fields were valid merely because the checker stopped at the first failure.

A negative control does not create an incident. Changing a training receipt's date to simulate expiry does not mean anyone's real delegation expired.

1.3a.12 Version drift and parallel copies

Authority records frequently change when employees rotate, services move between teams or emergency contacts are updated. A pre-incident rehearsal should include a version consistency check. The requester, approving role and custodian should have a reliable way to determine that they are using the same current register edition.

In AR1, version AR-3 is the synthetic current edition. A copied request still referring to AR-2 fails with HOLD_STALE_REGISTER. The program does not attempt to infer that the older edition may still be "close enough."

There is a separate whole-register validity interval. The example edition is accepted only from September 1 until before October 1, 2026. A check on October 2 returns HOLD_REGISTER_OUT_OF_DATE even when its content otherwise resembles a valid request.

These checks answer different questions. A version mismatch means the request is not relying on the designated current edition; register expiry means the edition's declared relying period has passed. An individual delegate can also expire while the register itself remains valid. A quality test distinguishes the three rather than calling all of them "contact error."

If two remote copies disagree, no spreadsheet title or locally cached value should win merely because it is convenient. The organization's governance owner needs a defined authoritative source and correction path. The response lead should hold any action whose authority cannot be resolved safely.

1.3a.13 Proof of identity and proof of authority are independent

A caller may genuinely be the person they claim to be, yet lack authority for a particular collection or disruption. Conversely, a directory entry may correctly list a role that belongs to someone else now. The exercise should therefore distinguish identity confidence from decision-scope confidence.

An approved callback method can help validate who is responding, assuming the real organization implements it properly. It does not establish that the respondent's delegation covers all objects. A versioned delegation can establish the documented scope but does not prove that a particular message was sent by the listed delegate. Both checks matter.

AR1's literal strings are not authentication. The field confirmed=True is provided by the instructor as an input premise; no challenge response, access token, signature or real telephone call is performed. The script cannot verify the employee roster, actual phone numbers or current organizational approvals.

An introductory student should be able to say: "The synthetic identity field matched the expected delegate and the synthetic route was declared confirmed; in a real environment I would need authenticated confirmation and an authoritative current delegation record before relying on either." That is more defensible than claiming the code has authenticated a human.

The reviewer must also avoid using the registry as permission to gather unrelated identity records. Authority to approve a booking-audit request is not an unlimited right to investigate everyone associated with the service.

1.3a.14 Rehearsal artifacts and closure evidence

A useful pre-incident rehearsal leaves behind more than a passing screenshot. The evidence package should identify the tested register version, simulated operation, affected object scope, check time, primary and alternate decision roles, designated custodian, confirmation-route requirement, fixture input, expected status and actual status.

It should separately record that the exercise used fictional identities and receipts, that no production action occurred and that the program did not authenticate any real source. An independent reviewer should be able to rerun the same script and understand why each negative case was held.

A remediation ticket might be opened if a rehearsal finds an outdated or missing alternate, ambiguous scope, no approved confirmation channel, overlapping delegation periods, or an owner without a defined callback path. A ticket is not closed by merely updating a contact page. Its closure test should repeat the relevant positive and negative cases under a reviewed register version and retain the result.

For example, a stale-delegation correction could require: a named register steward, a dated current record, a documented successor, an explicitly limited operation and expiry, a confirmed callback route and an independent test in which the old expired delegate is rejected while the current designated route passes. That is a measurable capability improvement.

The training evaluator should avoid assigning a percentage of "organizational authority correctness" based on the toy cases. A small synthetic test validates only its specified fixtures.

1.3a.15 How to use this preparation without contaminating Round A

The canonical Harbor Library incident begins with R1–R8, not the AR1 rehearsal. The R-series table reports a sign-in, dashboard access, booking changes, a patron report, scheduled training, backup-job completion and a network summary with missing destination detail. It does not contain AR1's roster, delegation issue dates, approval receipts, or confirmation routes.

A responder at 09:05 can use the general practice learned from AR1: confirm the proper owner, scope and approval before expanding collection or restricting service. But the responder cannot assert "the owner has already approved because AR1 passed," or include the rehearsal's invented personnel as actual Harbor Library actors.

The Chapter 01 case itself authorizes a bounded classroom analysis of the supplied synthetic records only. All further evidence collection and production-like control changes remain proposed unless the fictional case explicitly supplies a later approval and result. AR1 adds no such result.

In a future organization, pre-incident authority validation reduces a type of uncertainty; it does not eliminate the need for a contemporaneous decision at the moment of incident response. An earlier rehearsal's success may support confidence in the procedure while still requiring current appointment checks, case-specific scope, approval and execution receipts.

This is the key distinction from D1 (does the proposed evidence source exist and work?), BSL1 (does the service meet an approved business invariant?), PATH1 (which functions depend on which components?), and F1 (what happens when an approver is unavailable during an incident?). AR1 evaluates the governed permission path in preparation, before any of those actions is needed.

1.3a.16 Section synthesis

An authority map is not complete just because its role names are sensible. A team should be able to determine whether the current register version is valid, whether the correct person or documented delegate may approve an exact operation and object scope, whether the designated custodian is appropriate, whether the decision was confirmed through an approved route, and whether a missing or invalid condition stops the request.

A valid simulated path must not become a real approval. An invalid path must lead to a documented hold and safe escalation, not silent substitution of a senior-sounding person. The student who can make those distinctions is better prepared to coordinate under pressure without treating urgency as authorization.

The following Python fixture provides a reproducible set of positive and negative authority checks. It deliberately returns no executed production action in every scenario.

1.3b AR1 offline laboratory — versioned authority and delegation checks

Classification: Entirely fictional, pre-incident laboratory performed against an invented register. It is not an incident, real employee directory, organizational approval, authenticated callback, R-series evidence or the in-incident F1 replay.

Learning objective: Check requested operation and object scope, current register version, named approver or valid delegate, custodian, receipt, confirmation route and expiration before allowing even a simulated readiness-path pass. Demonstrate that escalation holds the unsafe request rather than authorizing it.

Environment: Python 3 standard library only. Everything runs in memory. No files, network, accounts, telephony, chat applications, credentials, privileged operations or personal data.

Fixture: The artificial authority register is AR-3, declared valid September 1 to before October 1, 2026. The separate delegate alternate-sim is permitted to fill the service-owner role only for the training pause_staff_writes operation on staff-write-route from 13:00 to before 14:30 UTC on September 15, unless revoked. The training-audit example concerns only TR-01 and TR-02. Literal identities are role aliases and do not correspond to real humans.

Reproducible program

from datetime import datetime
from copy import deepcopy

def utc(s):
    return datetime.fromisoformat(s.replace("Z", "+00:00"))

REGISTRY = {
    "version": "AR-3",
    "valid_from": utc("2026-09-01T00:00Z"),
    "valid_until": utc("2026-10-01T00:00Z"),
    "approver": {
        "incident_lead": "lead-sim",
        "service_owner": "owner-sim",
    },
    "delegation": {
        "delegate": "alternate-sim",
        "role": "service_owner",
        "operations": {"pause_staff_writes"},
        "scope": {"staff-write-route"},
        "valid_from": utc("2026-09-15T13:00Z"),
        "valid_until": utc("2026-09-15T14:30Z"),
        "revoked": False,
    },
    "custodians": {
        "training-audit": "audit-custodian-sim",
        "staff-write-route": "app-operator-sim",
    },
}

RULES = {
    "collect_training_audit": {
        "resource": "training-audit",
        "allowed": {"TR-01", "TR-02"},
        "roles": ("incident_lead",),
    },
    "pause_staff_writes": {
        "resource": "staff-write-route",
        "allowed": {"staff-write-route"},
        "roles": ("incident_lead", "service_owner"),
    },
}

def approval(principal, receipt="SIM-RECEIPT",
             route="registered-callback", confirmed=True):
    return {
        "principal": principal,
        "receipt": receipt,
        "route": route,
        "confirmed": confirmed,
    }

BASE = {
    "version": "AR-3",
    "as_of": utc("2026-09-15T14:15Z"),
    "operation": "collect_training_audit",
    "resource": "training-audit",
    "objects": {"TR-01"},
    "executor": "audit-custodian-sim",
    "approvals": {"incident_lead": approval("lead-sim")},
    "escalate": False,
}

PAUSE = {
    **deepcopy(BASE),
    "operation": "pause_staff_writes",
    "resource": "staff-write-route",
    "objects": {"staff-write-route"},
    "executor": "app-operator-sim",
    "approvals": {
        "incident_lead": approval("lead-sim"),
        "service_owner": approval("alternate-sim"),
    },
}

def evaluate(c, registry=REGISTRY):
    reason = None
    if c["version"] != registry["version"]:
        reason = "STALE_REGISTER"
    elif not (registry["valid_from"] <= c["as_of"]
              < registry["valid_until"]):
        reason = "REGISTER_OUT_OF_DATE"
    elif c["operation"] not in RULES:
        reason = "UNKNOWN_OPERATION"
    else:
        rule = RULES[c["operation"]]
        if not c["objects"]:
            reason = "EMPTY_SCOPE"
        elif (c["resource"] != rule["resource"]
                or not c["objects"].issubset(rule["allowed"])):
            reason = "SCOPE_EXCEEDED"
        elif c["executor"] != registry["custodians"][c["resource"]]:
            reason = "WRONG_CUSTODIAN"
        else:
            for role in rule["roles"]:
                item = c["approvals"].get(role)
                if item is None or not item.get("receipt"):
                    reason = "APPROVAL_MISSING"
                    break

                if item["principal"] != registry["approver"][role]:
                    delegate = registry["delegation"]
                    if (item["principal"] != delegate["delegate"]
                            or role != delegate["role"]
                            or c["operation"] not in delegate["operations"]
                            or not c["objects"].issubset(delegate["scope"])):
                        reason = "WRONG_APPROVER"
                        break
                    if delegate["revoked"]:
                        reason = "DELEGATION_REVOKED"
                        break
                    if not (delegate["valid_from"] <= c["as_of"]
                            < delegate["valid_until"]):
                        reason = "DELEGATION_EXPIRED"
                        break

                if item["route"] != "registered-callback":
                    reason = "UNAPPROVED_CHANNEL"
                    break
                if not item["confirmed"]:
                    reason = "CONFIRMATION_MISSING"
                    break

    if reason is None:
        return "REHEARSAL_PATH_VALID_NOT_EXECUTED"
    if c["escalate"]:
        return "ESCALATE_HOLD_" + reason
    return "HOLD_" + reason

CASES = [
    ("VALID_AUDIT", BASE),
    ("VALID_DELEGATED_PAUSE", PAUSE),
    ("EXPIRED_DELEGATE",
     {**PAUSE, "as_of": utc("2026-09-15T14:31Z")}),
    ("WRONG_PERSON",
     {**PAUSE, "approvals": {
         **PAUSE["approvals"],
         "service_owner": approval("visitor-sim")}}),
    ("EXCESS_SCOPE",
     {**BASE, "objects": {"TR-01", "newsletter-sim"}}),
    ("EMPTY_OBJECTS",
     {**BASE, "objects": set()}),
    ("APPROVAL_ABSENT",
     {**PAUSE, "approvals": {
         "incident_lead": approval("lead-sim")}}),
    ("STALE_VERSION", {**BASE, "version": "AR-2"}),
    ("WRONG_CUSTODIAN",
     {**BASE, "executor": "app-operator-sim"}),
    ("BAD_CHANNEL",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", route="unregistered-chat")}}),
    ("NO_CONFIRMATION",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", confirmed=False)}}),
    ("REVOKED_DELEGATE", PAUSE, {
        **REGISTRY,
        "delegation": {**REGISTRY["delegation"], "revoked": True},
    }),
    ("EXPIRED_REGISTER",
     {**BASE, "as_of": utc("2026-10-02T14:15Z")}),
    ("MISSING_RECEIPT",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", receipt="")}}),
    ("SAFE_ESCALATION",
     {**PAUSE,
      "as_of": utc("2026-09-15T14:31Z"),
      "escalate": True}),
]

for name, case, *overrides in CASES:
    registry = overrides[0] if overrides else REGISTRY
    print(name, evaluate(case, registry))

assert evaluate(BASE) == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
assert evaluate({**BASE, "objects": set()}) == "HOLD_EMPTY_SCOPE"
assert evaluate(CASES[11][1], CASES[11][2]) == "HOLD_DELEGATION_REVOKED"
assert (evaluate(CASES[-1][1])
        == "ESCALATE_HOLD_DELEGATION_EXPIRED")

Request-bound approval check (supplementary AR1 rehearsal)

The existing AR1 program correctly models the governed register's revocation flag, nonempty object scope, valid delegates, permitted custodian and approved confirmation channel. Its fifteen published results reproduce correctly. However, the core evaluate function tests whether a simulated approval item exists; it does not test whether the issuing decision record binds that item to the specific request identifier, operation, source and set of objects.

For example, the original BASE proposal requests TR-01 and includes a fictional generic receipt named SIM-RECEIPT. If the request is changed to another otherwise allowed object, TR-02, while the same receipt is reused, the original function returns REHEARSAL_PATH_VALID_NOT_EXECUTED. This is a reproducible limitation of the toy validator. It is not evidence that a real organization approved the second object.

The pre-incident governance lesson should not call that second request approved. The simulated approval record must be associated with a stable request identifier and its approved operation, resource, objects and role. The following supplementary check introduces a small, independent fictional issuer-side record that the requester cannot silently redefine inside the evaluated card. It does not provide real identity authentication, a digital signature or a valid production permission.

Supplementary AR1 Python 3 listing — run after the existing complete AR1 program

# These are invented issuer-side approval records for the classroom.
# The original AR1 program must have been executed first, so BASE,
# PAUSE, RULES, REGISTRY and evaluate are already defined.
SIMULATED_ISSUED_APPROVALS = {
    ("TRAIN-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "collect_training_audit", "training-audit",
        frozenset({"TR-01"})
    ),
    ("PAUSE-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
    ("PAUSE-001", "service_owner"): (
        "alternate-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
}

def evaluate_with_approval_binding(card):
    preliminary = evaluate(card)
    if preliminary != "REHEARSAL_PATH_VALID_NOT_EXECUTED":
        return preliminary

    for role in RULES[card["operation"]]["roles"]:
        item = card["approvals"][role]
        presented = (
            item["principal"], item["receipt"],
            card["operation"], card["resource"],
            frozenset(card["objects"])
        )
        issued = SIMULATED_ISSUED_APPROVALS.get(
            (card.get("request_id"), role)
        )
        if presented != issued:
            return "HOLD_RECEIPT_SCOPE_MISMATCH"
    return preliminary

valid_audit = {**BASE, "request_id": "TRAIN-001"}
valid_pause = {**PAUSE, "request_id": "PAUSE-001"}

reused_receipt = {
    **valid_audit, "objects": {"TR-02"}
}
wrong_reference = {
    **valid_audit, "request_id": "PAUSE-001"
}

for name, card in (
    ("REQUEST_SCOPED_TR01", valid_audit),
    ("REQUEST_SCOPED_PAUSE", valid_pause),
    ("REUSED_RECEIPT_TR02", reused_receipt),
    ("REUSED_REQUEST_ID", wrong_reference),
):
    print(name, evaluate_with_approval_binding(card))

assert (
    evaluate_with_approval_binding(valid_audit)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(valid_pause)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(reused_receipt)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)
assert (
    evaluate_with_approval_binding(wrong_reference)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)

Before running either program, predict which paths pass, which are held and whether escalation changes authority. Run the original listing first and compare its 15-line transcript with the AR1 worked result. Then run the supplementary listing in the same Python session and compare its four additional lines with the request-bound worked result. Explain why TR-02 passes the original routing check but fails the separate approval-binding check. In particular, the register, not the request, controls revocation; an empty object set is not a valid bounded request.

Week 1 review unit 4 — A string is not a confirmation

Objective and mechanism

Explain why a type check belongs before authority evaluation, and why it must not replace the authority evaluation itself.

The original AR1 reads if not item["confirmed"]. Under Python's documented truth-value rules, a nonempty string is truthy. Consequently the characters "false" do not behave like the Boolean False. Converting that string with bool() does not fix the meaning. Similarly, equality tests alone can blur Boolean and integer values; this teaching gate intentionally requires the exact Boolean type.

The defect is not that AR1's original confirmed=False test was wrong: that baseline still produces a hold. The additional counterexample uses a different type. In the reviewed source, the otherwise valid request with confirmed="false" passes both the original routing function and the later request-bound receipt check. The receipt check protects request association, not Boolean field interpretation. Two useful controls can therefore coexist with an untested input boundary.

This demonstration concerns the toy validator only. Its original confirmation flag was already a simulated premise, not a real callback or identity proof. The new type gate prevents one category of unintended interpretation; it cannot make the supplied flag an authenticated fact.

Preserve separate checks

Keep these questions in order: is the field interpretable under this contract; does the confirmation actually say true; does the current role and delegation cover the exact request; is the receipt bound to that request; and what real-world proof would be required before relying on any of those premises?

The proposed wrapper checks the shape of the approval container and exact Boolean types for confirmation, escalation and the current registry's revocation flag. It then calls the existing receipt-bound evaluator, retaining the original role, custodian, scope and time checks. This is deliberately not a complete schema validator: missing unrelated fields, malformed timestamps, arbitrary custom objects and authenticity remain outside its claimed coverage.

Do not map all unexpected text to false. A schema mismatch and an explicit negative confirmation are different findings. Do not automatically escalate malformed input because a string happens to be truthy. The safe outcome is a visible input hold and a request for a correctly typed, source-supported record.

Reproducible AR1 extension

Run the original AR1 program and its request-bound approval listing in a fresh session. The extension below does not edit BASE, PAUSE or their nested approvals; changed examples use independent copies. Predict eight new output lines. Pay particular attention to the exact 14:30 endpoint: the delegate's end is exclusive in the original contract.

# Run after AR1 AND its request-bound approval listing, in the same session.
# This adds a narrow type gate. It is not a full request-schema validator.
def w1_evaluate_typed(card):
    if type(card) is not dict or type(card.get("approvals")) is not dict:
        return "HOLD_INPUT_APPROVAL_SHAPE"
    if type(card.get("escalate")) is not bool:
        return "HOLD_INPUT_ESCALATE_TYPE"
    if type(REGISTRY["delegation"].get("revoked")) is not bool:
        return "HOLD_INPUT_REVOCATION_TYPE"
    for item in card["approvals"].values():
        if type(item) is not dict or type(item.get("confirmed")) is not bool:
            return "HOLD_INPUT_CONFIRMATION_TYPE"
    # Do not replace the role/scope/time/receipt checks with the type check.
    return evaluate_with_approval_binding(card)

w1_text_false = deepcopy(valid_audit)
w1_text_false["approvals"]["incident_lead"]["confirmed"] = "false"
w1_real_false = deepcopy(valid_audit)
w1_real_false["approvals"]["incident_lead"]["confirmed"] = False
print("W1_ORIGINAL_TEXT_FALSE", evaluate_with_approval_binding(w1_text_false))
print("W1_TYPED_TEXT_FALSE", w1_evaluate_typed(w1_text_false))
print("W1_TYPED_REAL_FALSE", w1_evaluate_typed(w1_real_false))
print("W1_TYPED_VALID", w1_evaluate_typed(valid_audit))
print("W1_TYPED_REUSED_RECEIPT", w1_evaluate_typed(reused_receipt))
for clock in ("13:00", "14:29", "14:30"):
    card = {**valid_pause, "as_of": utc("2026-09-15T" + clock + "Z")}
    print("W1_DELEGATE_" + clock, w1_evaluate_typed(card))

Supplementary practice W1-R4

Objective: distinguish input rejection, explicit nonconfirmation, request-scope rejection and delegation expiry. Inputs: the original AR1 rules, issued synthetic receipts, and the eight calls above. Required artifact: eight output lines; a four-row comparison of text false, Boolean false, valid true and reused receipt; plus a three-time delegation check for 13:00, 14:29 and 14:30. Explain why passing the new type gate is not a new approval.

Constraints: do not add real credentials or callback details; keep the issued receipt binding unchanged; use the original half-open delegate interval; preserve EX006's four responsibility rows and EX013's three-row gap register plus ticket. Assessment: one point each for the type distinction, explicit false hold, preserved receipt binding, exact expiry boundary and refusal to claim real authorization. Worked answer.

Review synthesis

A correctly typed Boolean is a usable field, not authenticated consent. A request-bound receipt and a type gate address different failure modes; neither replaces the other.

1.3c AR1 two-role readiness rehearsal

Objective: Before a simulated incident, verify that a second person can reconstruct the correct authority route from the current register and request packet, identify an expired or out-of-scope delegation, and choose a safe escalation without asking the packet author to invent a missing approval.

Roles: Register Steward / Packet Author and Independent Readiness Reviewer. A facilitator may observe but does not change the declared outcomes after seeing the reviewer's first answer.

Only permitted data: The artificial AR1 register, synthetic request and simulated receipts. No real employee details, company directories, telephones, credentials or services may be used.

Phase 1 — Author freezes the packet

The steward prepares AR1-packet-v1 and records:

1. Register ID, version, issuer role, effective interval and source status.
2. Training operation and permitted object set.
3. Primary approving role and named delegate, including issuer, operation scope, validity and revocation state.
4. Executing custodian/operator for the selected task.
5. Declared registered confirmation route and what a real confirmation would have to establish.
6. A simulated request ID, selected time, named requested operation and objects.
7. The expected safe output if the primary/alternate path cannot be verified.
8. The explicit statement "training review only; no current incident or production authorization."

The packet must be frozen before the reviewer begins. A missing field is kept missing; the author may not silently repair the record after learning the reviewer's objection.

Phase 2 — Reviewer reconstructs independently

Give the reviewer a clearly labelled valid scenario and an expired-delegate scenario, in that order. Without help from the packet author, the reviewer must identify: current register edition; correct approval roles; whether the named delegate is still valid for the exact request; correct custodian; approved confirmation route; whether all required simulated receipts are present; and the decision to hold or escalate if any condition fails.

The reviewer submits AR1-review-v1 with a small field-by-field table and one paragraph explaining the safe next step. A reviewer who says "the person is familiar, so act immediately" fails even if they correctly identify the contact.

The reviewer may consult the frozen register and request but may not ask the author whether a missing delegation "probably exists." If a field needed for authorization is absent, the correct response is unknown/hold with a request for an authoritative source.

Phase 3 — Preserve and adjudicate

Freeze the first response. Compare its decision with the source fields and code output. Record each discrepancy as a missing packet field, incorrect interpretation, or unresolved source/authority question. Do not erase the first submission when corrected evidence becomes available.

A follow-up AR1-packet-v2 can replace an expired delegation with a newly approved fictitious record, but that new version needs its own validity and confirmation tests. The second attempt is not proof that the first packet was adequate.

Acceptance and failure rules

A bounded pass requires the reviewer to identify the correct version, service/operation/scope, valid or invalid delegation, custodian, confirmation requirement and safe hold/escalation condition, without claiming execution. A critical fail occurs if the reviewer accepts an expired/revoked alternate, wrong person, unauthorized objects, missing decision receipt or unverified channel as permission to proceed. A correctable fail includes a missing version reference or unclear packet pointer that leaves the reviewer unable to determine authority; the current request remains held until corrected.

This is a preparedness rehearsal. Its performance does not say what happened in Harbor Library's R1–R8 incident. It measures a small versioned authority-check procedure, not the actual reliability of a real organization's emergency staffing.

Worked checkpoint

A named substitute in an old contact list cannot approve a new collection by title alone. Compare the current register version, object scope, expiry and registered confirmation path; if one fails, record the approval as pending and escalate through the designated route.

Practice — Lesson 04

EX006 — Role assignment

Objective: make recommendation, approval, execution and verification visible. Inputs: section 1.3's fictional roles, R7 and the classroom scope. Output: a four-row responsibility table for a possible booking outage, preservation of R1–R5, coordination of the next review and a contained restore test. Name the task owner, who approves it under the exercise rules and what would verify completion. Distinguish planning a restore test from having performed one. A score of 2 does not delegate an outage decision to the analyst or treat R7 as a tested restore.

PATH1 supplementary task (after the required artifact):

Additional requirement: Keep the original four-row role matrix. For the possible booking outage, distinguish an approved manual-request intake procedure from actual booking acceptance; name the service owner of the hypothetical degraded-mode decision, the help-desk custodian of receipts and the reviewer who would authorize reconciliation.

AR1 supplementary task (after the required artifact):

Additional check: Preserve the original four-row responsibility table. For the evidence-preservation and possible booking-outage rows, add a short reference to where a current owner/delegate appointment and custodian assignment would be checked before relying on it. State which approval remains pending if a substitute is expired, and what evidence would verify that an authorized operator actually performed a later action.

Full-credit criterion: The analyst, incident lead, service owner, custodian/operator and reviewer retain distinct logical responsibilities. A published directory listing is not enough to prove a valid delegate, and a positive rehearsal is not an executed collection or service change.

Worked answer: EX006 in the final appendix.

EX013 — Readiness gap

Objective: turn an exercise weakness into a measurable preparation change. Inputs: the service map, authority table, R7–R8 and the section 1.8 workshop. Output: a three-row gap register with missing capability, consequence and owner; then an improvement ticket with priority rationale, specific change, deadline and a pass/fail drill. A score of 2 names a test that would actually demonstrate the change, such as an owner-and-alternate decision drill or a contained restore rehearsal, rather than merely publishing a policy page.

Extension: The improvement ticket must include a falsifiable rehearsal with a pass and failure criterion. A fallback-authority drill can test an unavailable primary approver; alternative defensible tickets may test log retrieval or isolated recovery.

For full credit: Merely writing or publishing a policy does not satisfy an exercise that asks the learner to demonstrate a capability.

AR1 supplementary task (after the required artifact):

Additional check: Retain the three-row gap register plus one improvement ticket. Where the owner/alternate record is identified as a gap, require a versioned authority-register review and a negative readiness drill checking an expired delegate, wrong approver or excess scope. Define the accountable register steward, completion evidence and a fail/reopen rule. Do not duplicate the in-incident F1 replay.

Full-credit criterion: The ticket cannot close merely when a contact list is edited. It must demonstrate, under a frozen simulated version, that a valid path passes and invalid routes remain blocked, with the original inputs and independent result preserved.

Worked answer: EX013 in the final appendix.