#### 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](#exercise-ex024) with two bounded requests, separate addendum referral and an outcome table including unavailable/incomplete results. Compare the [worked answer](#answer-ex024). 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-05-day-03) · [Week 5 index](#ch-05) · [Course index](../SUBJECTS.md) · [Next: Day 25](#week-05-day-05). ### 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](#answer-ex024). ## 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.