#### Day 1 — Model a service transaction before a security signal **Learning decision.** Given a reported change to a class slot, decide which state transition would be acceptable and which dependency could explain a deviation. An event feed cannot answer this until the expected business behavior is written down. [NIST CSF 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) provides high-level risk-management outcomes, while [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) places response within that wider process. The transaction model below is OpenCyber Academy's teaching construction, not a NIST-prescribed schema or a verified CTN implementation. For the separate **W1** rehearsal, suppose a training class has one seat remaining. A client sends reservation request `q-A`; an unreliable network makes the client retry the *same* request; another client sends `q-B`. Specify the intended behavior *before* seeing logs: exactly one successful reservation may consume the remaining seat, a retry of `q-A` must not consume it twice if the service promises idempotency, and a rejected request must not decrement availability. Whether CTN has an idempotency key, a serial transaction or a version check is **unknown**. The model is a question for the application owner, not a reason to assert that CTN satisfies it. The write path and the observation path have different failure points: ```mermaid flowchart LR C["Client request q-A"] --> A["Enrollment API"] --> D["Authoritative slot state"] A -. "proposed audit event" .-> P["Source audit producer"] --> K["Collector"] --> X["Scoped export"] I["Identity service"] -. "session evidence, if emitted" .-> K O["Service owner"] -. "defines acceptable transition" .-> D ``` Edge labels identify the relationship: client → API → authoritative state is the proposed business/data path; API → audit producer → collector → scoped export is the proposed evidence path; identity → collector is another possible evidence path; owner → state supplies the acceptance criterion. Both solid and dotted edges are unverified teaching-model relationships. Solid edges are used on the main data path and the audit/collection chain; dotted edges distinguish the proposed audit branch, conditional identity evidence and owner criterion. Line style does not mean observed versus hypothetical or verified versus unverified. Even a complete export from `X` would not, by itself, establish that `D` committed a valid result. A reservation receipt might be returned before a delayed write, and a notification could be queued before a rollback. Ask the service owner which record is authoritative, which request or version key joins client and write records, and how an authorized isolated test would distinguish a duplicate retry from a second successful booking. If no stable key exists, do not substitute a shared minute or account label for identity of an operation. **Worked example.** Under the *hypothetical* contract, start at one available seat. If `q-A` succeeds, availability becomes zero and its retry returns the same reservation reference without another decrement. `q-B` then fails with an unchanged zero. A displayed success for both requests would violate the contract or indicate that the assumed contract is wrong; a single application log line cannot choose between those explanations. The first supervisor question is therefore “Is idempotency promised on this route, and which authoritative state/version verifies it?” rather than “Which attacker booked twice?” This is an example of deriving a testable question from an invariant, not an observation about C01. **Practice.** Complete [EX001](#exercise-ex001) using C01, but add to its five-row map one proposed W1 invariant and label every graph edge **data**, **evidence**, **authority** or **recovery**. Give one possible falsifier for the API-audit edge and one for the backup-to-restore edge. The existing [worked answer](#answer-ex001) supplies the decision/owner pattern; your extra W1 contract may differ if it states its assumptions and does not assert deployment facts. **Limit:** a diagram documents what to verify; it cannot verify it. [Previous: chapter start](#ch-01) · [Week index](#ch-01) · [Next: Day 2](#week-01-day-02). ### Exercise for this lesson **EX001 — Service dependency map.** Input: `C01` and the six CTN dependencies above. Produce a table with at least five dependencies, a decision each might support, custodian role and one unverified assumption. Assessment: 0 = missing decision/owner; 1 = map with vague assumptions; 2 = actionable, bounded map that does not claim the source is already verified. ## Worked answers **EX001 — Model service map.** A sufficient table includes (1) API audit → identify slot S42 write/request ID → application custodian → scheduled-route coverage unknown; (2) IdP → sign-in/session fields → identity custodian → detailed retention unknown; (3) support → symptom and receipt → support lead → reporter's observation not verified state; (4) change calendar → approved slot scope → service owner → addendum process unknown; (5) backup → candidate restore copy → recovery lead → last isolated restore unknown. This is a *readiness map*. It does not assert that S42 was changed or that these sources were collected at 08:40. Two points require a decision and a real gap in every row; “IT owns everything” earns at most one. **Additional worked reasoning (EX001 — Why each dependency supports a different decision.):** A reviewable map should include five or more rows such as: API audit → “which request changed S41?” → application custodian → scheduled/manual coverage unverified; IdP → “which account/session fields can be produced?” → identity custodian → no after-hours alternate; support → “what was reported and received?” → support lead → no authoritative backend state; change ledger → “was S41 in a permitted task version?” → service owner → addendum process unknown; backup → “can selected slot values be reconstructed?” → recovery lead → restore correctness untested. Every row states *how to falsify readiness*: a missing scheduled route, unusable key, unavailable alternate or failed isolated restoration. C01 does not supply results for these tests. A table simply saying “SIEM: green” has no operational decision linkage. **Week 1 Day 1 extension — worked result.** A possible W1 invariant is “with one seat left, the first accepted `q-A` consumes one seat, its retry consumes none, and rejected `q-B` consumes none.” Label client → API → slot store as **data**, API → source audit → collector as **evidence**, service owner → acceptance criterion as **authority**, and backup copy → isolated restore as **recovery**. The API-audit edge would fail if an authorized scheduled `q-A` test produced no stable request key; the restore edge would fail if a permitted isolated restore returned a slot count different from the approved target. These are **proposed falsifiers**, not executed findings. A response earns the second rubric point only when it distinguishes the intended transaction from a measured implementation and names owners for its proposed checks.