Request the smallest discriminator that changes a decision

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 24 — Request the smallest discriminator that changes a decision

Theory and mechanism. A discriminator request is designed backward from a decision: which permitted observation would change the next response step? Name the hypothesis component, source/fields, valid time/scope, acquiring role, authority, expected artifact and result interpretation. “More logs” has neither a clear stopping rule nor a defined failure. A precise request can return a useful answer, an explicit contradiction, missing coverage or an access block; those outcomes must remain distinct.

At 09:26, one request addresses current service impact: an owner-approved read-only S42 state/version and relevant last-change reference, with source and observation time. Another addresses technical origin: a preserved job/application record for q-144 around the reported 09:01 event, with run/task version, produced request identifier and slot selection, if available. First ask whether the source actually emits a comparable request key. Do not silently join batch-17 to a similarly named job or expand to every account when the field is absent. The C11 addendum belongs in a separate referral to the change authority, even if a coordinator can route all three.

Worked contrast. Request A asks the application owner to verify S42 and the last-change reference, under an approved minimal read. If the result is currently wrong, it can raise service-impact attention; if correct, it can narrow current harm. Neither result alone establishes the historical 09:01 state. Request B asks the scheduler/application custodians to establish a run/request relationship. A validated match may strengthen H1's origin component; a complete, semantically comparable exclusion can weaken that path; an incomplete export is inconclusive. One request cannot be used as the other's answer.

A common error is to request “the batch-17 run that changed S42.” That phrase presupposes the contested job origin and state effect. Ask instead whether a preserved run record supports or excludes the supplied q-144 relationship, identify its namespace and let the custodian report unavailable fields. The expected artifact should include the actual selection/method, source/version, collection time, limitations and receiving record. At present these are proposed artifacts, not supplied receipts.

Priority and authority. Compare decision value, reported source-loss risk, acquisition sensitivity, time to obtain an answer and owner availability. C08's reported 10:00 loss condition remains relevant to identity preservation; it does not establish that every scheduler source expires then. Ask each source owner for its actual bounds. A state check and job-run request may proceed concurrently through separate approved paths while the earlier identity-provenance gap remains tracked. The analysis must not erase a time-sensitive preservation request merely because another request is easy to run.

For a classroom plan, propose a 09:35 supervisor checkpoint or earlier review on a usable source receipt or verified major harm. This is an analyst-selected proposal, not an observed CTN event. If the permitted method is unavailable, escalate the blocked question and the residual loss/decision risk; do not borrow credentials or grant yourself approval. If a broader query is necessary, specify the amendment and pause the overlapping collection until authorized.

Practice and limit. Complete EX024 with two bounded requests, separate addendum referral and an outcome table including unavailable/incomplete results. Compare the worked answer. A well-designed request improves the next decision but does not guarantee the source can answer it or that any collection has occurred.

Continue studying — course Day 24: Previous: Day 23 · Week 5 index · Course index · Next: Day 25.

Exercise for this lesson

EX024 — Minimal next request. Objective: select bounded observations that change a decision. Input: the 09:26 record and Day 24. Specify two proposed requests addressing current S42 state and possible job/request origin, with accepting custodian, selectors/time semantics, minimum fields, actual versus pending authority, expected receipt and review/stop rule. Give match/contradiction and incomplete/unavailable outcomes without treating a future current-state read as historical reconstruction. Record C11's addendum referral separately. Rubric: 0 = presupposed origin, bulk export or claimed execution; 1 = useful requests with incomplete receipt, permission or outcome handling; 2 = two actionable discriminators and separate authorization referral with honest pending status. 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.

EX024

Open the prompt →Compare with the worked answer →

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX024 — Model next requests. Request 1: service owner authorizes an application custodian to retrieve current S42 state, last change/request ID and a privacy-limited uncached view; if state is incorrect, service impact/containment review rises, while a correct state could narrow the harm claim. Request 2: job/application custodians provide a bounded batch-17 run record and the semantics connecting its request ID to q-144, under case approval; a validated match favors H1, while a missing or mismatched run leaves H1 unproven and H2 open. Ask separately for a C11 addendum if available. Do not claim any of these results has been received.

Additional worked reasoning (EX024 — Two bounded owner requests.): First, service/application owner to confirm current S42 state, version, last change/request ID and observed time by an authorized read-only selection, without other learner data; a wrong state would raise immediate service consequence, while a correct state changes the impact hypothesis. Second, job/application custodians to provide a preserved q-144 run record, producer ID, relevant task version and approved slot list, with verified identifier semantics; a valid match changes H1, a mismatch or missing source leaves it open. The C11 addendum question should be recorded separately. No response or collection receipt is supplied at 09:26.

Week 5 Day 24 — worked requests and inconclusive outcomes. Request A: application/service owner to authorize an S42-only read of state/version, last-change/request reference and observation time, with minimal fields and source/method/receipt. A wrong current value affects harm assessment; a correct value narrows current impact, not necessarily earlier harm; inaccessible or ambiguous data leave the question pending. Request B: job/application custodians to decide a permitted window around 09:01 and supply any preserved run/task version, request-ID semantics, slot selection and source pointer for comparison with q-144. Do not assume batch-17 identifies a real run. Validated match strengthens origin; validated complete exclusion weakens that route; partial/field-missing/unauthorized results remain inconclusive. Ask the change authority separately for the C11 document, effective time and scope. A proposed 09:35 review can expose blocked acceptance or imminent loss, but is not a source event. C08's 10:00 warning applies to its described identity source, not automatically to every scheduler record.