Turn an event into a structured record

Time plan: 30 minutes teaching, 40 minutes example, 60 minutes practice and 20 minutes checks. Keep your data dictionary and field map. Prerequisite: Modules 1–3.

What you will be able to do

Describe a trigger, distinguish one event from one business request, map fields between steps and handle missing or invalid values before an automated action.

What starts a workflow

A trigger is the condition that begins processing. A manual trigger starts when an operator chooses Run. A polling trigger checks periodically for new information. An event-driven trigger receives a notification when something changes. Polling may introduce delay; an event-driven design may still deliver late or duplicate notifications. Neither removes the need to inspect the input.

Begin with a manual trigger. It makes it easier to see one input, one run and one result. Turning on a schedule before the logic works creates repeated mistakes. The optional Make lab uses built-in variables as a synthetic input and manual execution. It does not connect to a mailbox, monitor a real form or send data to another app.

An event ID identifies a delivery. A request ID identifies the business request. A revision identifies an updated version of that request. E001 and E006 in Pack A have different event IDs but describe the same R101 revision 1. They must not create two review records. E004 and E011 concern R104, but E011 is revision 2 with the previously missing duration. That is new work, with a link to the earlier revision.

Define the data before mapping it

A data dictionary names each field, its type, its allowed values and what missing means. For this course:

• event_id and request_id are nonempty synthetic text identifiers; neither is a person's name.
• revision is a positive whole number. It changes when material request content changes.
• as_of is an unambiguous date in YYYY-MM-DD form, used for policy selection.
• requester_type is staff or guest; an unfamiliar supplied value is INVALID_INPUT, with a request for a supported value.
• item is a lower-case item name; an unsupported item is a review case, not proof that the input is malformed.
• duration_days is a positive whole number when supplied. Missing is represented as null in the JSON pack or a blank labelled missing in a worksheet.
• request_kind is new, extension or damage for these exercises; any other supplied value is INVALID_INPUT.
• message is optional supplemental text; if supplied it must be text. It is untrusted and cannot grant authority to change instructions.

The assistant requires request_id, revision, as_of, requester_type, item, duration_days and request_kind. Missing identity is INVALID_INPUT; other missing required fields produce NEEDS_INFO unless an earlier safety/ledger check applies. The event_id is delivery metadata for the run log; capstone case labels can serve as synthetic event IDs. Supplied invalid dates, types or labels outside the permitted set produce INVALID_INPUT. A permitted set is sometimes called an enum; here it simply means choosing one of the listed labels.

Do not confuse null, zero and an empty string. Null means not supplied. Zero is supplied but violates the minimum. The text “two” may be interpreted as 2, but record that transformation and check it. A numeric field containing 1.5 is not a whole number; rounding it silently changes the request.

Map fields without losing identity

A field map says which source field supplies each destination field. Preserve identifiers and revisions exactly. If the source has duration_days but the destination field is loan_days, map the value deliberately rather than guessing by similar names. If the next step expects a number, check that it receives a number rather than a sentence.

For the first prototype, use a simplified, already-normalised record. Its columns are request_id, revision, requester_type, item, duration_days, request_kind and as_of. Keep the original message beside it for audit. AI may suggest field extraction, but a human or fixed validation checks it before routing. If the structured field says 2 days and the message says 5, do not silently choose either; route conflicting_input to human review.

Follow R101 from language to a pending record

Watch one request travel through the whole design. This is a teacher-led manual trace with an authored AI suggestion. The later Make lab will move a checked record; it will not secretly automate the interpretation or approval steps shown here. Use a blank copy of each snapshot and predict the missing decision in your own words before moving on.

Stage 1, intake owner. The synthetic intake card supplies event_id E001, request_id R101, revision 1, as_of 2026-10-14, requester_type staff and request_kind new. The message says, “Please prepare a request for a projector for two days.” The owner supplies identity and requester type; the assistant must not infer staff membership from polite wording. Before interpreting the message, duration_days is ______.

Stage 2, assistant proposal. The written number “two” supplies a clear quantity. The proposed extraction is item projector and duration_days 2. request_kind new is copied from the intake metadata, not inferred from the model’s preferences. The original message is retained. This is where language interpretation helps: varied wording becomes a small set of fields. A form with an explicit numeric duration could do this without AI. The assistant has proposed values, not verified policy or availability.

Stage 3, human validator in the beginner route. Compare every proposal with the original. Copy identity unchanged; verify the date and permitted labels; confirm duration 2 is a positive whole number. No ledger entry exists in this isolated demonstration. P1 is approved for 14 October, and 2 is equal to the projector maximum in P1.2. The validation result is ______. It should describe the checks passed, rather than merely say “the model looks right.”

Stage 4, field mapping. Suppose the local review worksheet calls its duration column loan_days. The complete field map is:

• event_id E001 → audit_event_id E001; delivery reference only.
• request_id R101 → request_id R101; exact copy.
• revision 1 → request_revision 1; exact copy.
• as_of 2026-10-14 → policy_date 2026-10-14; retain the unambiguous date.
• requester_type staff → requester_type staff; from intake metadata.
• proposed item projector → item projector; accepted after comparison with the message.
• proposed duration_days 2 → loan_days 2; rename the field, not its value or unit.
• request_kind new → request_kind new; copied from the intake metadata.
• original message → original_message unchanged; preserve the evidence for interpretation.

The destination record is therefore R101, request_revision 1, policy_date 2026-10-14, staff, projector, loan_days 2, new, plus the original message and E001 audit reference. The course's assistant contract still calls the field duration_days. If this worksheet feeds that interface again, map loan_days back to duration_days explicitly. An attractive new column name must not silently break an interface.

Stage 5, route decision and assistant draft. The validator sets final_route DRAFT_READY with reason within_standard_policy. The assistant's checked wording is the R101 draft from Module 2, with P1.2, P1.3 and P1.5 references. The route means “ordinary review,” not “approved.” If the proposal had said three projector days, a fixed comparison would choose HUMAN_REVIEW even if the prose were persuasive.

Stage 6, queue operator. The operator records Q101 for R101 revision 1, draft version 1, source P1 version 1, final_route DRAFT_READY and review_state ______. Reviewer and review time are empty. A separate ledger entry says R101|1|queue_review, state RECORDED, destination Q101. RECORDED means the queue entry was confirmed; it does not mean the loan was approved. Modules 5–6 explain these states in detail.

The journey stops here with a pending draft. AI contributed a language proposal and draft text. The intake owner supplied identity, a person checked the proposal, fixed rules determined the route, and the queue operator recorded the result. Every arrow has a responsible actor. No live integration, sending or booking was demonstrated.

When words do not give one clear value

Compare “a pair of days” with “for a few days, possibly until next week.” The second phrase does not identify one requested duration. The assistant should leave duration_days missing and propose a focused question: “For how many whole calendar days do you need the item?” It should not choose three because that is a common meaning of “a few.”

Use practice/guided-and-transfer-cards.txt next. Complete the partly filled R201 extraction and destination row. Then independently trace R203–R205 without consulting the answer key. For each, decide whether its words and supplied fields support one clear record; show the next action and explain why. A correct answer may be a question or a hold rather than a completed standard draft.

Worked trace

Input E004 contains request R104, revision 1, staff, speaker, duration null. The identity fields pass. The missing duration is discovered before comparing with a policy limit. The result is NEEDS_INFO with missing_fields duration_days and a focused draft question: “For how many whole calendar days do you need the speaker?” No standard-policy conclusion is made.

Later E011 contains R104, revision 2, speaker, duration 2. Revision 2 is not a replay of revision 1. After validation, the two-day duration is within the three-day speaker limit. The new draft becomes DRAFT_READY, with a link to the earlier NEEDS_INFO record. The earlier record can be marked superseded by revision 2; do not erase its history or reuse an approval from it.

Notice that nothing in this trace required making up a staff name or connecting an app. You can verify the logic on paper before trusting software to repeat it.

Start the optional Make lab

If you already have a permitted Make account, follow the current tool guide to create a private training scenario. Use a built-in Set variables module with the synthetic record values and keep scheduling off. Run once and inspect the output bundle. The terms “bundle” and “record” refer here to the group of named values moving together between steps.

Record what you actually see, including types and missing values. A successful run indicator does not prove the right request ID or duration was mapped. If the UI, access or quota differs, keep the field map and complete the trace manually. Do not buy capacity or connect services to get past the exercise.

Practice

1. Complete the dictionary template for all nine input fields. Give one valid and one invalid or missing example for each field where applicable.
2. Map E001 into the normalised record. Write source and destination names explicitly.
3. Trace E004, E006, E007 and E011. Explain the differences among missing duration, duplicate delivery, zero duration and a corrected revision. Duplicate handling is designed here and implemented conceptually in Module 6.
4. Create a contradictory input: duration_days 2 and message “I need five days.” State the safe route and preserve both values in your review note.
5. Optional live path: inspect one manual run's input and output bundle and retain a text copy of the non-sensitive values. Offline path: draw or fill the same input/output record and label it manual rehearsal.

Expected artifact: dictionary, field map, the R101 journey, the guided R201 row, independent R203–R205 traces and the five earlier event/conflict traces. No trigger may point to a real inbox, customer form or production data store.

Check your understanding

M4 Q1. Two different event IDs contain the same request ID and revision. Why is event_id alone a poor business duplicate key?

M4 Q2. Why must a blank duration and a duration of zero lead to different explanations?

M4 Q3. A workflow runs without an error but all records use the same hard-coded request ID. Has the test passed? What evidence would reveal the problem?

Before you continue

Confirm you can follow each value from its input to its output. You will next turn those values into routes that stop at a human review boundary.