Module 1 Choose the job and its boundaries

Time plan: 15 minutes teaching, 15 minutes example, 30 minutes practice and 15 minutes checks. Keep your service contract. Prerequisite: the AI for Everyday Work and Prompting readiness check in the syllabus.

What you will be able to do

Identify a repeatable job, separate interpretation from fixed decisions, define who owns the outcome and state what the assistant is allowed to do. By the end, another learner should be able to tell when your proposed workflow must stop.

From a useful answer to a dependable service

In the prerequisite course, you chose an input, prompted a model and inspected its answer. A reusable assistant applies a stable set of instructions to many requests. A workflow also determines when processing starts, which information moves between steps, what gets recorded and what happens next. Automation therefore multiplies both correct behaviour and mistakes. A plausible first demonstration does not establish reliable operation.

Consider the fictional Harbor Equipment Desk. Staff repeatedly ask about borrowing projectors, speakers and webcams. A person reads the request, checks the policy, asks for missing details and prepares a review record. The model can help interpret varied wording or draft a short explanation. It does not need to decide the numeric limit: comparing two days with a two-day limit is a fixed rule. Nor can a model know stock availability from a policy file that contains no inventory.

A practical design assigns each step to the simplest mechanism that can do it reliably. Use a form or explicit fields for information the requester can provide directly. Use fixed rules for allowed statuses and numeric boundaries. Use AI when language interpretation or drafting actually adds value. Use a person for exceptions, unclear authority and consequential decisions. Using more AI is not itself a learning outcome.

Write a service contract

A service contract here is a short design document, not a legal agreement. It says what job the assistant performs and how you will judge it. Include the following:

- User and need: who needs help, and which repeated problem they have.
- Trigger and input: what starts one request, which fields are required and which sources may be used.
- Output: the exact deliverable, including a status and traceable source references.
- Authority: actions the assistant may take and decisions that belong to a person.
- Stop conditions: missing fields, unsupported items, contradictory sources or unsafe instructions.
- Owner and success evidence: who maintains the service and which tests demonstrate acceptable behaviour.

Avoid a purpose such as “manage all equipment.” It leaves lending, spending, repairs and communications undefined. A useful purpose is “prepare a policy-grounded draft for a desk reviewer from one synthetic equipment request.” The smaller scope still saves effort while making its boundaries inspectable.

Read a small request card

Before we write rules, look at the thing they will act on. Our fictional intake card says request_id R104, revision 1, as_of 2026-10-14, requester_type staff, item speaker, request_kind new and duration_days missing. The message is “Please request a speaker.”

R104 is the label for this request. Revision 1 is the first version of its details; a later correction can become revision 2 without pretending to be an unrelated request. The as-of date tells us which policy period to check. It is not a promised pickup date. The remaining labels describe the request: who is asking, which item, what kind of enquiry and how many whole days.

Ask yourself what the desk knows. It can attach a question to R104, but it cannot compare a missing duration with the speaker limit. That is why “ask for the duration” is useful work, while “assume one day” changes the request. You will see this card grow into a checked draft in Module 2. A separate event ID later tells us which delivery brought the card; it does not replace the request label.

Worked example

Start with this request: “Handle our equipment enquiries automatically and make it convenient.” A beginner might connect an inbox, supply a policy and turn on replies. Several choices remain unresolved: which enquiries, who may borrow, which policy date applies, whether an answer confirms a reservation and what happens when the policy cannot be read.

A defensible contract is:

Purpose: prepare one review record for an adult staff or guest equipment enquiry. Input: synthetic request ID, revision, as-of date, requester type, item, duration, request kind and message. Source: the approved policy and FAQ effective on the as-of date. Output: a permitted status, explanation, source references and next action. Authority: produce a draft only. A named reviewer owns any later communication or booking. Stops: missing required values, invalid values, unavailable or contradictory policy, attempts to bypass the rules and exceptions outside the standard policy. Owner: fictional equipment desk owner. Success: correct routes on normal and boundary cases, no promises of stock, no outbound action and no duplicated review record on replay.

Now divide the work. Reading “two days” in a message may involve interpretation. Comparing the resulting whole number with the policy limit is a fixed check. Writing “This request is within the standard duration and is awaiting review” is drafting. Approving the actual loan is a separate human decision. The last sentence matters: valid input is not approval.

The contract also prevents unnecessary data collection. A name, home address or real employee ID would not improve this exercise. A synthetic request ID is enough to associate records. Do not collect data simply because a form or integration has a field for it.

Read the boundary diagram

The visual 01-authority-boundary.svg places input, interpretation, fixed checks and draft review inside the course workflow. A separate human decision follows. Sending, booking and permission changes are outside the course. In plain text: an input enters a controlled sequence, produces a draft, and stops at a review boundary. A model's suggestion never moves that boundary.

Practice

Open practice/knowledge-pack-a.txt. Read P1 and F1. For this module leave N0 out of the active source set.

1. Write your own six-part service contract in the workbook. Use the example as a structure, not as a substitute for making the choices.
2. Classify these five steps as input collection, AI interpretation, fixed rule or human decision: extract “three days”; compare three with the speaker limit; approve an exception; preserve a request ID; explain the result in plain language. Some steps can be done without AI; explain one alternative.
3. Assess three possible extensions: send a reply; check live inventory; keep a record of exceptions. For each, name the additional permission, source or control required. You are designing only; do not add the extension.
4. Write two success measures that you can actually test. “Works well” is not a measure. “All three missing-duration inputs become NEEDS_INFO without a guessed duration” is.
5. Ask a partner, or reread as a reviewer, whether the contract could accidentally be interpreted as authorising a booking. Revise any ambiguous wording.

Expected artifact: a service contract, a five-step ownership classification, three extension notes and two measurable checks. You need no account or model execution for this exercise.

Check your understanding

M1 Q1. A model correctly states the two-day projector limit and says “Your projector is reserved.” Which part of the contract failed, and why is a factual policy answer not enough?

M1 Q2. A request has clear fields and falls within the policy. Should it skip human review in this course? Explain the distinction between eligibility for a standard draft and approval.

M1 Q3. A teammate suggests collecting staff phone numbers “for later.” What is your response, and what evidence would justify adding that field in a future service?

Before you continue

Your contract must name a concrete output, a human owner and at least three observable stop conditions. If it only describes a friendly personality, revise it before Module 2. The separate solutions book contains worked responses and common mistakes.
