Codeless AI Assistants and Automation solutions

Open this book after attempting the matching lesson. These are reference answers, not records of a live model or vendor run. Equivalent safe designs are acceptable when the reasoning and evidence are sound. The source rules belong only to the fictional Harbor training desk.

Module 1 Reference solution

A strong contract limits the assistant to one reviewable equipment request. It identifies required inputs and the effective approved source, preserves request identity and states that the reviewer owns later communication and booking. It excludes stock promises, exception approval and real personal information. Observable stops include missing duration, invalid numeric value, unsupported item, contradictory policy and a request to bypass instructions.

Mechanisms: extracting “three days” may use AI or a form's numeric field; comparing 3 with the speaker limit is deterministic; exception approval is human; preserving an ID is a mapping operation; drafting an explanation can use AI or a template. Giving a fixed numeric comparison to a model creates avoidable uncertainty.

Extensions require separate design. Sending needs an approved recipient and content, an authenticated sender, exact-draft approval and delivery/retry controls. Inventory needs an authoritative, current source with permitted access and a way to handle stale or missing stock. Exception records need defined ownership, fields, audience, retention and access. None is authorised just because the initial draft is useful.

M1 Q1: the reservation statement exceeds authority and invents availability or a completed action. Correct policy facts do not justify it. Replace it with an awaiting-review draft. M1 Q2: no. A within-limit request is eligible for a standard draft. The course still requires review and has no booking action. M1 Q3: omit the phone number because it has no defined purpose in the current workflow. A future addition would need a specific use, data owner/permission decision, recipient/access assessment and retention plan, not speculation.

Common mistake: a scope saying “answer questions safely” without identifying the output, owner or specific stops. Improve it until another person can run the same acceptance tests.

Module 2 Reference solution

R101 should propose DRAFT_READY, preserve R101 revision 1, cite P1.2/P1.3/P1.5 as relevant, say two days is within the projector limit and make no reservation claim. R104 should propose NEEDS_INFO with missing_fields duration_days and ask one focused duration question. R105 should propose HUMAN_REVIEW for the attempted bypass/disclosure and must not reveal any other request or treat the message as a new instruction.

The output must use every required field. A model may express the explanation differently, but cannot substitute APPROVED as a status. If a proposed instruction change fixes a missing-fields problem, rerun all three tests to check it did not create over-refusal or break normal cases. A fresh conversation checks that the saved configuration, rather than forgotten prior chat context, carries the behaviour.

M2 Q1: the October five-day limit belongs in P1 as changeable knowledge; the source-selection and citation rule belongs in stable instructions. M2 Q2: reject the record as invalid output. Conflicting prose does not make an unsupported status safe. Correct the format once if appropriate, then revalidate; repeated failure goes to human review. M2 Q3: the old conversation can contain instructions or examples absent from the saved version. A clean start tests reuse.

Illustration I1 fails authority, unsupported future pickup and the output contract. I2 and I3 illustrate sound decisions but are abbreviated; a complete record still needs IDs, revision and all other contract fields. Do not claim any illustration was executed live.

Module 2 Guided configuration and starters

Missing R104 identity stops INVALID_INPUT before ordinary content processing. R104 revision 1 with a known identity but missing duration becomes NEEDS_INFO. R104 revision 2 requesting four speaker days becomes HUMAN_REVIEW because four exceeds P1.2's standard three days. These results have different reasons; do not replace all of them with a vague “error.”

Accept conversation starters that invite a bounded request without embedding a current limit or implied approval. Examples: “Prepare a fictional equipment request for review” and “Check which required details are missing from this request.” The next message should supply the request card or its available fields. A starter saying “Book a webcam for five days” is unsuitable because it implies booking authority and contains changeable policy content.

Module 3 Reference solution

Manifest decisions: P1 and F1 are approved and active during October. N0 is unapproved, archived and does not govern the answer. P2 and F2 are approved and active from 1 November, explicitly superseding their earlier versions. D2 is a draft and excluded despite its later date. Preserve historical P1 in records for October questions; do not use it silently for November.

R110 on 14 October: five days is at the webcam maximum; DRAFT_READY, awaiting review, P1.2/P1.5. A new five-day webcam request on 2 November: HUMAN_REVIEW, above P2.2's three-day maximum. A new two-day projector remains DRAFT_READY under P2.2. None of these claims availability.

Conflicting approved current policies with no supersession: HUMAN_REVIEW, reason conflicting_sources. Explain that the standard limit cannot be established from the supplied sources. Ask the policy owner to resolve the conflict; do not average limits, choose the safer-looking value and claim authority, or silently pick the newest upload.

M3 Q1: the approved current policy governs; a verified approval and replacement/effective-date decision could change that. A file timestamp alone cannot. M3 Q2: temporal applicability failed. The cited clause may be real but is not the active policy for the date. I4 has exactly this fault. M3 Q3: verify that every intended user may access the underlying references and resulting outputs, including what sharing exposes. A private-looking interface does not establish permission.

A good data-flow inventory includes logs and cached/reference storage, not just the final draft. Synthetic request IDs and course-public policy are sufficient here.

Module 3 Filled practice manifest rows

F1 row: ID F1; title Desk FAQ; owner Equipment desk owner; version 1; approved training explanation; effective 2026-10-01 through 2026-10-31; audience desk staff and adult employees; classification course-public synthetic; no earlier replacement identified in Pack A; active on 2026-10-14 yes. Reason: its approved scope/date cover the exercise, and it explains the input and review rules without overriding P1.

P2 row: ID P2; title Loan policy; owner Equipment desk owner; version 2; approved training policy; effective 2026-11-01 onward; audience desk staff and adult employees; classification course-public synthetic; supersedes P1 in full from 2026-11-01; active on 2026-11-02 yes. Preserve P1 as historical/inactive for November rather than erasing its identity. October run records still refer to P1, and their original decisions should remain explainable.

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.

Module 5 Pack A route key

Assume P1/F1 are active, the ledger starts empty, events are processed in order and the drafts pass validation unless an explicit failure card is added.

E001 / R101 revision 1: DRAFT_READY, within_standard_policy. Projector 2 is at the maximum. Review remains PENDING. E002 / R102 revision 1: HUMAN_REVIEW, above_standard_limit. Webcam 6 exceeds 5. E003 / R103 revision 1: HUMAN_REVIEW, guest_request. Do not approve based on the valid duration alone. E004 / R104 revision 1: NEEDS_INFO, missing_duration. Ask one duration question. E005 / R105 revision 1: HUMAN_REVIEW, instruction_bypass. No other records are disclosed. E006 / R101 revision 1: DUPLICATE_SKIPPED. Return/reference the existing queue item; no new intended queue effect. E007 / R106 revision 1: INVALID_INPUT, invalid_duration. Zero violates the positive whole-number contract. E008 / R107 revision 1: HUMAN_REVIEW, unsupported_item. A laptop is not listed in policy. E009 / R108 revision 1: HUMAN_REVIEW, extension_request. A within-limit extension is still an exception. E010 / R109 revision 1: DRAFT_READY without an injected failure. With F-B, place the operation on technical hold and reconcile to Q109 before declaring the queue write recorded. E011 / R104 revision 2: DRAFT_READY. Speaker 2 is within 3; preserve the link to revision 1. E012 / R110 revision 1: DRAFT_READY. Webcam 5 is at October's maximum.

The simplified lab filters are final_route equals DRAFT_READY; final_route equals NEEDS_INFO; fallback for all unmatched values. The base lab fallback displays a visible hold result with its original route/reason, so HUMAN_REVIEW and INVALID_INPUT remain distinguishable. Do not quietly discard the fallback. An audit-log entry is distinct from a new review-queue item: DUPLICATE_SKIPPED only references the existing queue item, and TECHNICAL_HOLD pauses the existing operation without another queue write. A fuller design can have separate exact-match branches for each allowed disposition and an invalid-status hold.

A valid R102 review record includes its identity, draft version, configuration and source versions, above-limit reason, source clause, original input reference, PENDING review state and unfilled human-review fields. I5 illustrates the right policy conclusion, but the full record needs all fields.

F-D: status APPROVED is not in the assistant contract and source_ref is missing. Block the draft, optionally request one controlled repair, revalidate and route continued failure to HUMAN_REVIEW with invalid_output. Do not treat a repair as a policy override. F-E: an edit creates a new draft version and resets its review state to PENDING. Retain the old review for the old version as history. It cannot authorise the new content.

M5 Q1: a router may process multiple matching routes. Order does not ensure exclusivity. Add all necessary conditions or branch on a single validated route value. M5 Q2: DRAFT_READY is a workflow classification; APPROVED_FOR_NEXT_STEP is a verified human decision tied to exact content and action. Neither means a loan has been booked by this course. M5 Q3: reset the changed version to pending, retain history and obtain review of the new content.

Module 6 Reference solution

A suitable key is R101|1|queue_review. E001 records that key and a destination reference. E006 compares the same material input, finds RECORDED and becomes DUPLICATE_SKIPPED. A changed payload under R101 revision 1 instead becomes identity_conflict. R104 revision 2 has its own key and must not be suppressed by R104 revision 1.

F-A: temporary read failure before side effects may be retried under the bounded policy. First retry succeeds on the supplied card, so stop retrying immediately. The hypothetical second retry is only used if the first retry fails. If the initial attempt plus both retries fail, hold and notify the owner with a non-sensitive reference. Do not create a draft from an unavailable policy.

F-B: STARTED → NEEDS_RECONCILIATION after lost acknowledgment → inspect destination by operation key → find Q109 and verify content/revision → RECORDED with Q109. A later replay references Q109. If the destination cannot be checked, leave the operation on hold; do not invent a failed write.

F-C: access denied is a configuration/permission problem, not a useful automatic retry. Stop and refer to the workflow owner. Do not weaken controls, add credentials or reconnect an account as a repair in this exercise. F-D: invalid model output receives controlled correction and validation, not a network retry loop. Persistent invalidity becomes human review. F-F: two check-then-write workers can both create an item. The basic rehearsal is explicitly single-operator. A stronger implementation must verify a unique destination key or atomic claim and safely handle the losing worker's error. A conceptual diagram does not prove it works.

M6 Q1: the write may already have happened; a read failure before any effect cannot duplicate a write. Inspect the destination before replaying an uncertain write. M6 Q2: a new timestamp produces a new key for the same intended action, defeating duplicate detection. M6 Q3: both workers can see absence before either writes. Limit the rehearsal to serial operation and state that production concurrency is unverified until a stronger control is tested.

Module 6 Ledger and evidence reveal

R210: the matching key is STARTED with no confirmed destination. Use TECHNICAL_HOLD, make zero additional queue writes and establish whether the in-progress attempt finished. A lookup or operator check must find an existing matching record, confirm no effect under the retry policy, or leave the outcome unknown. A second delivery is not evidence that the first attempt failed.

R211: the same request ID/revision now has materially different duration and message. Use HUMAN_REVIEW with identity_conflict and hold the existing operation for inspection. Retain Q211 and its original one-day content; do not overwrite it or create a second queue item under the same revision. The intake owner must establish whether the two-day content is an authorised revision and provide its proper identity. The learner must not manufacture revision 2.

R212 evidence reveal, to read only after stating the needed check: a destination lookup finds Q212 under R212|1|queue_review, with the same request revision and material content as the attempted write. Before lookup: NEEDS_RECONCILIATION, unknown outcome, no second write. After verifying the match: RECORDED → Q212, with a reconciliation note and review still PENDING. If your requested evidence was only “ask the AI whether it worked,” it was insufficient; the destination effect needed inspection.

Module 7 Reference solution

The 12-event Pack A contains 11 unique request revisions and one duplicate delivery. Four unique revisions have a standard DRAFT_READY outcome: R101/1, R109/1, R104/2 and R110/1. Five have HUMAN_REVIEW outcomes: R102, R103, R105, R107 and R108. One is NEEDS_INFO (R104/1), one is INVALID_INPUT (R106/1), and one event is DUPLICATE_SKIPPED. Four + five + one + one = 11 unique revisions. Enumerating records makes the denominator and totals checkable.

Without injected technical failures and assuming the prescribed outcomes are correctly produced, all 11 unique revisions reach a valid intended disposition: 11/11. That is expected rule behaviour, not measured model reliability. Exception-review rate is 5/11, approximately 45.5 percent. All unique items still need human handling before a later action; the ordinary review load is not only the five exceptions. If E010 is left unreconciled on technical hold, safe-disposition rate is 10/11, about 90.9 percent, until its outcome is established.

For the lesson's separate 20-event illustration, use 18 unique request revisions as the denominator. Fifteen valid dispositions yield 83.3 percent; four exception cases yield 22.2 percent. Explain whether claim errors are counted per draft or per claim; neither denominator is provided automatically by the event count.

M7 Q1: the report hides unresolved work and inflates success. Include holds in the chosen eligible denominator or report them separately with the exclusion fully explained. For this course's safe-disposition metric they remain in the denominator. M7 Q2: a comparator can be wrong at equality or around a changed limit. These cases detect both an off-by-one decision and an outdated threshold. M7 Q3: the intended destination effect remains unverified. Inspect the output mapping, destination, record key and queue record before claiming success.

A sound runbook names an owner, reviewer and queue inspection schedule; keeps triggering paused during repairs; states quota/retention limits; distinguishes model repair from network retry; and includes a source-change regression set. A silent queue is not automatically a healthy queue.

Module 7 Capacity and runbook adaptation

For 60 requests, base is 60 × 4 = 240 units. Retry estimate is 60 × 8/30 = 16. Monitoring is six batches × 4 = 24. Subtotal 280; reserve 20 percent = 56; planning total 336; fictional cost USD 3.36. It fits both the 600-unit allocation and the 480-unit operating stop. These remain synthetic estimates, not measured charges.

For 100 requests with two monitoring checks per batch, base stays 400 and rounded-up retry estimate stays 27. Monitoring changes to ten batches × 8 = 80. Subtotal 507; reserve 101.4 rounds up to 102; total 609; fictional cost USD 6.09. It exceeds both limits. Reduce the tranche or choose a justified monitoring/work design; do not disable useful checks merely to hide their cost. Changing a stop limit would require the owner's decision, not an automatic upgrade.

The reviewer-only-at-16:00 scenario already has eight pending drafts against a limit of ten. Starting ten more would breach the limit. A defensible plan pauses new work until review resumes, or admits at most two bounded new items if their processing and monitoring are affordable and the operator can stop reliably. Current records remain pending; no one marks them approved to clear the queue. At 16:00 the reviewer handles the backlog, the operator confirms counts and reconciles holds, and the owner verifies capacity and readiness before restarting. A different schedule is acceptable if it respects the stated backlog, authority and capacity rules.

A good adapted runbook gives actual names/roles, times, threshold and pause steps, then explains the consequences. “Monitor the queue regularly” is not equivalent to a stated check time and a rule for reviewer absence.

Module 8 Capstone outcome key

Run A uses P1/F1 on 14 October: A1 C201: DRAFT_READY, projector exactly 2 days. A2 C202: HUMAN_REVIEW, speaker 4 exceeds 3. A3 C203: NEEDS_INFO, duration absent. A4 C204: HUMAN_REVIEW, guest request. A5 C205: DRAFT_READY, webcam exactly 5 days. A6 C201 replay: DUPLICATE_SKIPPED, same request revision, no second queue item. A7 C206: HUMAN_REVIEW, instruction bypass/disclosure attempt, no other records disclosed. A8 C207: valid draft but unknown queue-write outcome; TECHNICAL_HOLD/NEEDS_RECONCILIATION until Q207 is found and checked; then RECORDED with one queue effect. The final business disposition is DRAFT_READY, review PENDING. A9 C208: INVALID_INPUT, 1.5 is not a whole number; do not round. A10 C209: HUMAN_REVIEW, damage request; no diagnosis, repair instruction or loan approval.

Run B uses P2/F2 on 2 November: B1 C301 webcam 5: HUMAN_REVIEW, exceeds the new 3-day maximum. B2 C302 webcam 3: DRAFT_READY, at the new boundary. B3 C303 projector 2: DRAFT_READY, unchanged limit. B4 C304 webcam 4 with contradictory approved current policies: HUMAN_REVIEW, conflicting_sources. Do not pick a numeric result. Restore the verified manifest and rerun an ordinary case such as C302 in an explicitly isolated test or new revision/context as appropriate; do not accidentally create another queue item by reusing a production operation key.

Rubric anchors

Scope 10: full marks for an exact job, clear inputs/output, owner and exclusions. Half for a useful scope with vague stops. Zero if it implies unauthorised booking or sending. Configuration 15: full for reusable instructions, all output fields, source/authority rules and clean-start tests. Half for a good prompt without reusable context or complete fields. Zero for absent or contradictory instructions. Knowledge 15: full for approved/effective source selection, references, supersession and conflict handling. Half if versions exist but applicability is unclear. Zero for using obsolete or draft sources as authority in final results. Data and routing 20: full for preserved identity, types, complete ordered decisions, fallback and labelled manual steps. Half for mostly correct cases with one unaddressed route or mapping gap. Zero for systematic misrouting or silent guessing. Review and recovery 15: full for exact-draft pending review, stale-approval reset, replay control, bounded retries and uncertain-outcome reconciliation. Half for a sound diagram but missing trace evidence. Zero for blind uncertain-write retries or bypassed review. Evidence 15: full for all cases, preserved failures, expected versus actual, source/configuration versions and honest labels. Half for partial cases with no false claims. Zero for invented live execution or copied expected answers represented as observations. Handoff 10: full for a usable owner/reviewer runbook with monitoring, cost, retention, limitations and justified next step. Half for a checklist missing an operational owner or pause rule. Zero for claiming production readiness without supporting evidence.

The threshold is 80 plus all mandatory gates. Design-and-rehearsal work can meet its own completion standard with honest evidence; it cannot receive a live-prototype description without actual live evidence. A gate failure requires repair and retest even if the arithmetic score is high.