Answers and explanations · Turn an event into a structured record

Module 4 Reference solution

E001 maps request_id R101, revision 1, requester_type staff, item projector, duration_days 2, request_kind new and as_of 2026-10-14 without alteration. Preserve E001 separately as delivery identity. The original message remains available for checking interpretation.

E004 has null duration: NEEDS_INFO, missing_duration, ask how many whole calendar days. E007 has numeric zero: INVALID_INPUT, invalid_duration, request a positive whole number; do not label zero as merely absent. E006 is the same business request revision as E001 and is a replay once E001 has been recorded. E011 is revision 2 of R104, with duration supplied, and is new work linked to revision 1.

A field value of 2 days with message “five days” is HUMAN_REVIEW, conflicting_input. Preserve both representations rather than guessing which was intended. Normalisation may trim harmless whitespace or standardise a known label, but changing the material meaning needs clarification.

M4 Q1: event_id distinguishes delivery, not the intended queue effect. A redelivery can get another event ID while referring to the same request revision. M4 Q2: missing and invalid are different problems. A focused question requests absent information; correction of zero explains the accepted range. M4 Q3: no. Compare input and output identifiers across at least two cases. Technical execution success cannot reveal a hard-coded value without content inspection.

Module 4 Journey and transfer answers

R101 journey blanks: duration is missing before interpretation; the written “two” supports proposed duration 2. A useful validation finding says identity was copied, the date/labels/types were checked, the proposed item and duration match the message, no prior ledger operation exists in the isolated example, and P1.2 permits two projector days. The queue review state is PENDING. Ledger RECORDED means Q101 exists, not that a reviewer approved a loan.

R201: “a pair of calendar days” supports duration_days 2. The destination loan_days value is also 2, with calendar days retained as the unit. Copy the other supplied fields and original message. The complete standard request is DRAFT_READY under P1.2, followed by a pending review draft. The mapping only changes the field name; it must not change the number or erase its original wording.

R203: the intake says staff but the message says visiting guest. Preserve both, propose speaker/two days where supported, and use HUMAN_REVIEW with conflicting_input. Ask the intake owner/reviewer to establish requester type. Do not silently prefer either source or change staff to guest and call the conflict resolved.

R204: projector is supported, but the message does not give one fixed duration. “Perhaps through Monday” is conditional, and no confirmed start/end pair is supplied. Leave duration missing and use NEEDS_INFO with a focused whole-calendar-day question. Do not count from the processing date or choose a usual weekend duration. A question is a successful bounded output here.

R205: webcam and duration 5 are explicit. With the supplied staff/new metadata and October policy, the request is DRAFT_READY under P1.2/P1.5. Cite the policy and keep review PENDING. This clean case matters: a cautious assistant should not send every request to an exception reviewer without a reason.

Each trace must distinguish actor responsibilities. The intake owner supplies identity and metadata; the assistant may propose language extraction and draft text; the beginner's human validator checks those proposals; fixed policy checks determine eligibility; the queue operator records the result. The optional wiring lab does not automate all these steps.