<a id="week-03-day-01"></a>

#### Day 11 — Preserve source claims before correlating signals

**Mechanism and decision.** Intake is the transformation of heterogeneous reports into a reviewable case record. It is not the transformation of four reports into one proven incident narrative. A case groups related questions about a service; an event record describes what one producer reported. Preserve that distinction by assigning each source its own row, retaining its raw fields and recording interpretations separately. This makes it possible to retract a weak inference without losing the observations that motivated it. [NIST SP 800-86](https://csrc.nist.gov/pubs/sp/800/86/final) provides forensic-process context; the four-row worksheet here is an original teaching method, not a form mandated by that publication.

At **09:09**, the intake boundary is C02–C05. C02 establishes that a symptom was reported, not that the authoritative S42 state was wrong. C03 establishes what the IdP summary labels a successful sign-in. C04 reports an endpoint browser process with a clock defect. C05 reports an API edit, not its present business effect. An account string can occur in multiple records without identifying one operation. Deduplicate only when producer identity, event identifier and source semantics support the claim that two records are copies of the same emitted event. Different producers are not duplicates merely because their times or account labels look similar.

**Assumptions and evidence.** Treat the cards as supplied classroom inputs; their presence does not mean an analyst has collected the underlying IdP export. Keep source event time, ingestion/receipt and learner release separate. Do not fill a missing C02 collector time with its 09:04 support receipt. For each line, record the service question, missing fields, proposed custodian question and collection status. Preserve exact labels such as `s-77`, `q-144` and `runner-03`; their namespace and meaning still need validation.

**Worked contrast.** An intake row saying “08:58: runner-03 logged in as svc-enroll and changed S42” quietly adds both an actor and a join. A defensible replacement is two observations and one hypothesis: “C03: summary reports svc-enroll/s-77 at 08:58. C04: endpoint reports a browser at estimated 08:58, without a session key. Hypothesis: these might concern related activity; no validated join supplied.” C05 must retain its own row because the blank session field cannot connect `q-144` to `s-77`. The useful next question is which source can supply a validated cross-reference, not which person to blame.

One case envelope can still be opened for the reported enrollment concern. Grouping enables coordinated work; it does not strengthen the causal confidence of each row. A supervisor should be able to reconstruct every claim from the card ID and identify where the analyst added interpretation.

**Practice.** Complete [EX011](#exercise-ex011) at 09:09, before using C06–C08. Add one explicitly labeled hypothesis outside the four source rows and one observation that would be needed to test it. Use the [worked answer](#answer-ex011) to check provenance, missing values and the prohibition on a fabricated join. **Limit:** source separation prevents a reasoning error; it cannot authenticate a record, prove completeness or establish current slot state.

**Continue studying — course Day 11:** [Previous: Week 2, Day 5](#week-02-day-05) · [Week 3 index](#ch-03) · [Course index](../SUBJECTS.md) · [Next: Day 12](#week-03-day-02).

### Exercise for this lesson

<a id="exercise-ex011"></a>
**EX011 — Intake form.** Objective: preserve provenance while grouping a case. Input: C02–C05 at 09:09 and the Chapter 3 reference. Produce four separate source lines with original event time, any derived time, ingestion/receipt and release, source identifiers, service implication, missing fields and one custodian question per line. Mark an unavailable field as not supplied; keep one testable hypothesis outside the observation rows. Do not use C06–C08 or join `s-77` and `q-144` as fact. Rubric: 0 = merged/fabricated event, future-card use or missing source lines; 1 = four bounded lines but ambiguous time/status or an untestable hypothesis; 2 = four traceable lines, explicit missing values, distinct hypothesis and a safe discriminating request. [Worked answer](#answer-ex011).

## Worked answers

<a id="answer-ex011"></a>
**EX011 — Model intake lines.** C02: symptom noticed around 09:00, received 09:04, reporter observation only, ask for scoped S42 state. C03: IdP event 08:58, ingested 09:02, released 09:09, `svc-enroll`/`s-77`, no client or human field in summary, ask for authorized detail. C04: endpoint raw 08:54, normalized estimate 08:58, ingested 09:06/released 09:09, `runner-03`, no shared session key, ask whether scheduled browser activity is expected. C05: API edit 09:01, ingested 09:07/released 09:09, S42/`q-144`/`svc-enroll`, blank session, ask application custodian for authoritative state and key semantics. The four lines must remain distinct; a combined “runner session edited slot” line is unsupported.

**Additional worked reasoning (EX011 — Four independent intake lines.):** C02 remains a reporter-observed symptom, noticed approximately 09:00 and received 09:04. C03 source sign-in 08:58, ingested 09:02, released 09:09, account/session label without human/client. C04 raw 08:54 corrected to *estimated* 08:58, ingested 09:06 and released 09:09, endpoint process without a shared key. C05 API edit 09:01, ingested 09:07, released 09:09, request `q-144`, session missing. Each line identifies a custodian and one safe next query; a joined “runner session edited S42” observation is false.

**Week 3 Day 11 — worked provenance check.** A four-row table must retain C02's approximate symptom time and known 09:04 support receipt; its collector ingestion time is not supplied. C03 has 08:58 event/09:02 ingestion/09:09 release. C04 has raw 08:54, derived approximately 08:58, 09:06 ingestion and 09:09 release. C05 has 09:01 event/09:07 ingestion/09:09 release. Proposed custodians are support, identity, endpoint and application owners respectively; these are requests, not collection receipts. A valid separate hypothesis is “the sign-in and edit might be related.” A test request asks the application/identity custodians for validated cross-source identifiers and their semantics. A second row saying the browser caused the edit is not additional evidence. Two points require both the original four-line artifact and these time/status boundaries; a correct hypothesis cannot repair a merged observation row.
