Validate a request relationship without inventing a human actor

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Public activity · 30d

—Participating browsers

—Page views

—Reading sessions

—Exercise opens

Counts reflect browsers that allowed analytics. A reading session requires 30 seconds on a visible page. Browsers are not people.

Day 31 — Validate a request relationship without inventing a human actor

Learning task. Explain why C20 strengthens a mechanism claim while preserving actor and intent uncertainty. A mechanism claim identifies a component and an operation that produced a particular outcome. It requires more than a matching account label or minute. Ask which producer emitted the identifier, its uniqueness scope, whether retries or transformations reuse it, how it reached the other record and which source connects the operation to state. A label copied into a self-reported field is weaker evidence of origin than a producer-supported transaction relationship. Even a trustworthy technical relationship need not identify the person who created the component.

At 09:46, C20 supplies the preserved runner-03 scheduler record: sync-override registered at 08:47, a run at 09:00, and API request q-144 for S42. The custodian and application owner compare a known-good request across scheduler and API sources and validate that C20 and C05 refer to the same request in the same namespace. C13 separately connects S42's stored version 19 to the last recorded request q-144. This chain supports “the recorded task run issued the S42 edit.” Registration time, run time, API event time and case release remain distinct fields. The run at 09:00 and C05's 09:01 event are different producer observations, not a reason to silently change either timestamp or invent an extra operation.

Worked contrast. At 09:26, a defensible graph could draw C12's batch-17 as a claimed-provenance edge only. At 09:46, version the graph: C14's complete manifest for the particular approved run excludes q-144; C20 supplies a different task and a validated request relationship. Add a source-backed task-run→request edge and retain the older hypothesis version. Do not relabel C12 as trusted scheduler metadata or pretend C20 was available to the earlier analyst. A task issuing an API request and a person intentionally installing it are different propositions.

Consider the tempting alternative: “The ID matches, therefore s-77 registered the task and its user is the attacker.” C20 does not supply a session-to-registration record or a human actor. The shared account and runner-03 labels cannot fill those missing edges. Nor does a registration at 08:47 establish a link to the separately released 08:52 recovery-method event; that card is not available at this lesson's checkpoint. Maintain unknowns without calling the validated mechanism merely a guess. Evidence can support a strong narrow conclusion and leave a wider conclusion unsupported.

Evidence design. A four-part claim record should be reproducible by another responder: claim; source chain; exact scope; a result that would force revision. For this case: C20 scheduler run, custodian namespace validation, C05 request and C13 state support one task/request relationship. A trustworthy contradictory mapping or mismatched transaction would force re-examination. Other runners, copies, registration author and upstream session remain open. The validation described in C20 is a supplied fictional case fact; the learner has not independently rerun a real custodian check. Do not invent a byte digest, request contract document or exact source-query receipt absent from the cards.

Offline practice. Draw two versioned edge lists at 09:26 and 09:46. Give each edge a type and source; cross out no raw record. Mark the old job-origin lead weakened for the specified approved run and the new task/request mechanism supported. Then remove C20's namespace validation in a clearly hypothetical third column: the equal q-144 strings would again require a semantic/provenance check. This adverse case tests what the conclusion depends on; it does not revise C20.

Limits and decision. Complete EX031, including its forbidden actor claim and disconfirming source question, before reading the worked answer. The mechanism justifies preparing a task-specific response contract, not execution. C20 does not renew the expiring hold, authorize task disablement or settle motive.

Previous: Week 6, Day 30 · Week 7 index · Course index · Next: Day 32.

Exercise for this lesson

EX031 — Mechanism versus actor. Objective: defend a validated technical relationship without actor attribution. Inputs: C05/C12/C13/C14 and C20 at 09:46, plus Day 31. Produce a claim/source/scope/discriminator ledger covering the supported task-request-state mechanism, weakened approved-run interpretation and forbidden session/human claim. Preserve registration, run, API and release times; show how removing the namespace premise would weaken a hypothetical join. Use no later card or invented operation. Rubric: 0 = human/session attribution or future evidence; 1 = correct task link but incomplete provenance, time or scope; 2 = validated q-144 chain, bounded exclusion and a meaningful disconfirming check. Worked answer.

Practice the exercises

Open a prompt, write your response, then compare it with the worked answer. Five-choice practice appears where a reviewed question is available.

EX031

Open the prompt →Compare with the worked answer →

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX031 — Model claim ledger. Supported mechanism: C20's preserved scheduler record names sync-override run at 09:00 with q-144, and the custodian verified that this request ID matches C05's API namespace and C13's S42 change. Weakened interpretation: C12's batch-17 tag alone suggested the approved job, but C14's complete manifest for that run lists only q-140 and q-141. Forbidden attribution: neither C20's run nor C03/C09's s-77 fields identifies the person who registered or operated the task. At this 09:46 exercise checkpoint, C20 does not identify the task registrant or motive; later identity evidence is not yet available.

Additional professional worked reasoning: At 09:46, the scheduler task-to-q-144 relation is a validated mechanism, and the registrant's identity and motive remain unknown. For the later full-chapter checkpoint only, C23's 09:54 inventory comparison adds the separate unapproved-change classification; do not use it in the Day 31 decision. The C14 complete approved batch-17 run excludes q-144, not all possible runners; a self-reported batch label is weaker than validated producer/request semantics. Cite C20, C05 and C13 separately; attach C23 only in the later version rather than compressing checkpoints into an attacker narrative.

Week 7 Day 31 — worked mechanism boundary. At 09:46, record C20's 08:47 registration, 09:00 run and q-144 emission separately from C05's 09:01 API event and C20 release time. The supplied custodian/owner known-good comparison validates request-ID semantics; C13 adds the state relationship. C14 excludes that request from one complete approved batch-17 run, weakening C12's self-reported origin tag. A hypothetical missing namespace check would reduce the equal strings to a relationship requiring validation; a trusted contradictory mapping/transaction would reopen the mechanism. No source joins s-77 to task registration, names a human, proves intent or renews the hold. Preserve the 09:26 graph and append a 09:46 revision instead of backfilling C20.