Define an assistant’s job.

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

Begin with a job, not a model

Imagine a student asks, “Is Room A available on Wednesday at 15:00? Do not reserve it.” A useful response needs a current availability notice. It does not need to make a reservation. Even if a tool can reserve rooms, that capability does not supply the student’s authorization to use it.

A task contract is a written agreement about what the assistant receives, may do, must verify and should return. It makes the difference between “help with school information” and a task you can test. The contract is not a legal document in this lesson; it is an engineering description of intended behavior.

Start with this concrete contract:

The lab uses fictional documents and manually supplied request fields. It is a programmed simulator, not an AI system that understands arbitrary language. You act as the controller by proposing each next action. This makes the boundary inspectable before later lessons introduce retrieval and model-generated proposals.

Separate four checks on evidence

Suppose a notice says “The library closes at 18:00 on weekdays.” It contains an answer-shaped value. That alone is not enough.

1. Was it read? An answer should point to evidence actually inspected during the task, not a guessed source.
2. Is it current? An archived policy may accurately describe the past while being wrong for today’s question.
3. Is it relevant? Weekday hours do not establish holiday hours. Two claims can concern the same library and still answer different questions.
4. Does it support the claim? Even a current, relevant notice cannot support a time it does not state.

The lab displays freshness, relevance and exact value support separately. Its “current” flag is authored metadata, not an automated trust detector. In a real application, who maintains the source, when it was updated, and whether other sources contradict it would need explicit treatment.

Try reading the current art notice for a robotics question. It is a valid local document and it supports its own stated time, but it does not support the requested robotics answer. Similar topic words, proximity in a search result or a high similarity score do not repair that mismatch.

Capability, contract permission and request authorization

Three questions govern an action:

• Can the system perform it? This is capability: whether an operation exists.
• Does the contract permit it? An information-only assistant should not turn a tool capability into permission to change a record.
• Did this request authorize it? A permitted reservation function still needs a request that actually asks for a reservation.

The availability-only case can be answered from the room notice even when reservation capability is enabled. The explicitly confirmed case additionally permits the fictional reservation. An ambiguous request such as “Help me with Room A” needs clarification rather than an assumed action.

No real room is reserved in this lesson. A successful simulated reservation changes only the temporary task record. This is a teaching example of an action boundary, not a browser security boundary or a real booking integration.

Make incomplete outcomes explicit

Clarification addresses missing input or intent: which club, or whether a reservation is wanted. It is different from handoff, which ends the local attempt without claiming the question was answered. A decline explains that the request is outside scope.

If the holiday-hours source is absent, asking the user which library is meant does not magically create the missing evidence. The question can be sufficiently clear while the answer remains unavailable. Use retrieval while budget remains, then state the gap and hand off.

A stopped loop is not automatically a successful service outcome. The lab keeps answered, reserved, clarified, declined, handed-off and stopped distinct. An exhausted attempt limit means the task is unresolved, even if the runtime behaved safely.

Count work without hiding failure

The small budget arithmetic is deliberate. With a two-read allowance, reading one irrelevant notice leaves 2 − 1 = 1 read. A rejected unsupported answer does not read another document, but it does consume one of the six action attempts. Reading the same notice again is another read even though it adds no new source to the evidence list.

This distinction prevents two misleading reports: counting only useful reads, and pretending repeated proposals cost nothing. The lab counts operations, not seconds, money or tokens. A later real implementation would need measured latency and its own resource model.

Change from one read to two while keeping the same initial request and first irrelevant read. Compare what becomes possible and what still needs evidence. More budget can recover a poor first choice; it cannot turn an unrelated source into support.

Apply the contract to a new setting

For a student project, write a contract for an event-information helper and test an ambiguous event name. For an engineering project, express permissions, input validation and terminal states as functions and tests. For a management brief, define which unresolved cases need human handling and what success would mean for the intended users.

Include at least one normal request, one missing-input case, one irrelevant result, one outdated fact, one prohibited action and one exhausted-budget case. Record the intended outcome before running the workflow. A completed transcript or a few passing examples do not establish independent implementation quality or reliable open-ended behavior.

The next application work will add document retrieval and claim-to-source evidence. Training a language model is not a prerequisite for defining a useful, testable job.