What Do I Want to Keep?

A colleague’s meeting request arrives. Suppose the system can notice it, interpret the request, check a calendar, suggest a response and send one. Suppose, too, that it can predict which response Iris would choose. These are capabilities. They do not tell us how the work should be divided. Checking availability, judging whether to accept and sending a commitment affect different things. An interface that treats them all as one task hides the distinction between them. Those capabilities still leave a question unanswered:

Which parts of this activity does Iris want to keep doing herself, and which does she want the system to do?

She says: “Check when I’m free and prepare a reply. I’ll decide whether this meeting belongs in the week. Show me the draft before sending.”

Her request gives different roles to different parts of the activity. She wants help gathering information and preparing a response. She keeps the judgement about whether to meet, any commitment about the time, and the decision to send. A draft that says Tuesday works could itself settle the answer she reserved. A single label such as “assisted” would leave these differences unspecified. This chapter asks how to express the division she wants without treating it as a personality trait, mistaking it for unlimited permission, or allowing a prepared output to settle the choice before it reaches her.

Three questions

Three questions must stay separate, even when one natural-language request seems to answer all of them.

capability  ≠  desire  ≠  permission

Capability asks whether the system can perform a step competently with the tools and information available. Desire asks whether Iris wants the system to take that role in this activity, or wants to keep the work herself. Permission asks whether a particular operation is authorised, for this actor, here and now. A system may pass one test and fail the others. This chapter concentrates on the desired division of work. Chapter 33 examines the grant itself and how it is enforced. An explicit instruction, however, already constrains the system before any more elaborate mechanism exists.

The answers can differ. A system might be capable of choosing a meeting time while Iris wants to choose it herself. A previously granted permission might allow routine scheduling within certain bounds, while her instruction for this request keeps the decision and the sending with her. A standing grant is not a reason to disregard a more restrictive current instruction. Conversely, wanting help with a draft does not authorise calendar access, disclosure to the colleague, or an external commitment, even when those steps would be convenient.

desired role  ≠  permission for every operation that could serve it

This distinction does not require two separate conversations or a special permission ceremony. “Compare these options; leave the purchase to me” both requests a comparison and places a binding boundary before purchase. The system should be able to extract both meanings. It should not treat permission to compare as permission to reserve, pay for, or contact a third party. Keeping the meanings separate makes later inspection and correction possible.

Nor does the distinction make her retained steps optional until a formal grant exists. “Do not send” constrains the current interaction now. “Leave the final choice to me” is not an ignorable preference just because the system has filed it as one. It is a prohibition on silently taking that role. The desired allocation does not supply every positive permission, but the person’s explicit limits already tell the system what it must not do.

Allocation across steps

The meeting request contains several distinguishable parts:

notice and interpret the request
check possible times and existing commitments
judge whether the meeting belongs in the week
choose what to accept, decline or propose
prepare wording consistent with the chosen response
send the reply

Iris’s instruction assigns information gathering and drafting to the system. It keeps the judgement about importance with her, and it places a handoff, meaning a point where the work returns to her, before any reply is sent. The draft may present alternatives, but it should not state that she has accepted a time when she has not. She might instead want to choose the response before any wording is prepared, or ask for two conditional drafts while she decides. Those are different divisions of the same activity. The system should keep the unresolved choice as unresolved.

One possible vocabulary for describing such roles is:

observe  ·  propose  ·  prepare  ·  decide  ·  execute

These are candidate terms, not a universal ladder of autonomy. Observation and analysis can be highly automated while decision and execution remain with Iris. Preparing a reply does not give permission to send it, and executing a routine step in one workflow does not give the system authority to decide an unfamiliar case. A new fact can return the activity to a judgement Iris kept: the meeting may now require a commitment she has not considered. Progress through a workflow must not silently transfer that judgement to the system.

The division makes her chosen roles explicit in this example. It also suggests a small operational record: the activity, the step, the proposed system role, the retained human role, the boundary before external effects, and any condition that requires a return to Iris. This record is a proposed description of participation, not an authority token. Whether it helps people more than familiar manual, assisted or automatic controls remains untested. More granularity also creates configuration work. The useful boundaries are the ones that change who judges, what can be prepared, and where a handoff must occur, not every keystroke.

A division of work must preserve the steps the person has chosen to keep.

One task, worked through

For a trip to Berlin, Iris wants help finding a flight. Searching, comparing, narrowing, recommending, preparing a non-binding booking proposal and purchasing are all possible parts of the activity. The word prepare is not harmless by definition. A service might place a hold, disclose passenger details, start a reservation or incur a charge while preparing. None of those external effects follows merely from permission to compare. And the step labels do not settle who supplies the criteria or decides which trade-offs matter.

agency allocation = activity + steps + retained decisions + handoffs + conditions

She gives the dates and airports, asks the system to compare flights, and says she will choose how much an earlier arrival is worth. After she chooses, she wants a proposed booking assembled for review, without a hold, a charge or any external commitment unless separately permitted. She has not asked the system to purchase. The division can be written down without confusing the roles she wants with a grant for every operation that might implement them:

Desired participation for this Berlin trip

Activity:
- choose and arrange a flight for the stated dates and airports

Iris keeps:
- setting or revising the search criteria
- weighing the trade-off between price and arrival time
- selecting or rejecting an itinerary
- authorising any final purchase

Desired system role:
- search under the stated criteria and disclose the search limits
- compare alternatives without settling Iris's retained trade-off
- prepare a non-binding booking proposal after Iris chooses

Conditions and handoff:
- retain a meaningful comparison of price, arrival and key conditions
- disclose material exclusions, missing coverage and uncertain availability
- return changed price, fare rules or terms to Iris before proceeding
- do not place a hold, disclose payment data or purchase without separate authority
- wait for Iris's decision and the required purchase approval

This records the roles Iris wants for one trip. Her actual instruction authorises the requested comparison, subject to applicable access and data-use rules, and reserves the final choice and the purchase. The broader description does not, by itself, authorise account access, use of stored passenger details, a reservation, a hold or a transaction. Nor is a proposed role proof that the system can perform it competently. The next chapter separates operational grants from this desired division. The boundary against purchase already applies here.

The handoff matters as much as the role labels. Suppose the system treats “find a good flight” as “find the cheapest flight” and removes every earlier, more expensive option. It then presents three cheap departures and asks Iris to approve one. The final click remains hers, but the price-versus-arrival decision has already been made upstream. A human can be left nominally in control while the system controls the alternatives from which she is allowed to choose.

In this constructed case, keeping the trade-off means receiving alternatives that make it possible to weigh it: a cheaper later flight and a more expensive earlier one, with prices that include stated fees, arrival times, cancellation terms, and the source of each comparison. If a fare is provisional or availability is uncertain, the handoff must say so. Iris needs to see which criteria were hers, which ranking was a recommendation, and which candidates were excluded by search limits or unsupported data. She must be able to revise the criteria, reject all the presented options, and request another comparison. A shortlist that cannot be challenged is a form of upstream decision, not merely helpful compression.

This does not mean showing every flight. Filtering on criteria Iris has actually settled can serve her decision, and some options may be unavailable or lie outside the searched sources. The handoff should distinguish those reasons from preferences the system inferred on her behalf. Part II’s coverage lesson applies here: a shortlist cannot prove that unseen alternatives do not exist. Silently replacing an unsettled trade-off with the system’s preferred ranking takes away the choice. A recommendation must remain a recommendation wherever Iris has kept the judgement.

Now suppose preparation reveals that the selected fare has different cancellation terms, a higher total price or a changed departure time. Her earlier choice does not settle this new one. The system must return the changed, decision-relevant terms to Iris rather than presenting a completed purchase for acknowledgement. A fresh price and availability check is useful, but a new check is not permission to accept the new terms. If preparation itself would cause an external hold or fee, the system must stop before that effect unless the required authority exists.

human handoff  ≠  approval click after the substantive choice is gone

Why someone keeps a step

Iris might keep a judgement because she has information the system lacks. But missing information is not the basis of her right to keep it. Even if a model predicts her choice correctly, she can still want to make the choice herself. Nor should the system treat a retained decision as a nuisance to be optimised away once its forecast becomes more accurate. Capability and prediction do not answer the participation question.

She might say, “I want to write this part because I’m practising,” or “Help me compare, but I want this commitment to be my decision.” She might value authorship, learning, accountability, enjoyment, or remaining involved in a project she owns. These are reasons she may declare, but she need not justify a retained step to the system. Hesitation, repeated editing or a refusal to delegate do not license an inference that she is anxious, inefficient or generally opposed to automation.

A declared learning objective does not establish a learning result. Keeping a step might serve the practice she wants, but this example does not show that the division improves skill, understanding, ownership or outcomes. It gives the channel an objective and a boundary to respect. An experiment would need to measure what she learned as well as whether the task was completed. No optimal division of human and system work has been demonstrated that the channel could substitute for her choice.

Allocation belongs to the activity

The Berlin division applies to one activity under stated conditions. It does not establish that Iris is a person who “prefers low autonomy”. That would repeat the mistake of Part III, which turned scoped evidence into a theory of the person. The same person can retain a judgement about a costly flight, delegate the mechanical comparison, and explicitly allow a routine formatting operation. These are decisions about particular work, not contradictory personality data.

The relevant conditions can be concrete:

activity          routine scheduling or consequential commitment
cost              amount, fees and possible financial exposure
reversibility     refundable, cancellable or irreversible terms
familiarity       established procedure or unfamiliar case
people affected   private preparation or commitment to another party
declared time     ordinary review or explicitly stated deadline
stage             comparison, choice, preparation or external execution

Agency allocation belongs to the activity, not to the person as a permanent trait.

This does not require starting from nothing on every occasion. Iris can deliberately accept a division for a bounded class of activities: “For refundable hotels below this amount, prepare a comparison and ask me before purchase.” The price threshold, the refundable condition, the preparation limits and the handoff all belong to that standing division. It is still different from “Iris delegates travel”. A standing participation rule is not, without more, permission to spend money, reveal information or perform an operation for a particular destination.

A temporary departure needs its own bounds. “For this trip, bring every choice back to me” changes participation for this trip. It does not silently rewrite the standing division for later trips, and it does not reveal a durable psychological trait. If the system has already prepared a plan under the old division, it must reconsider any pending steps that would now cross her retained boundary. A deadline may explain the urgency of her request, but it does not license an inference about stress or a reason to transfer decisions away from her.

The case that shows why

Suppose earlier hotel bookings were inexpensive and refundable. The system completed them under the confirmations or scoped permissions that applied at the time. Now it finds a non-refundable hotel costing €1,800. The amount and circumstances are illustrative, as is the assumption that the hotel remains available. The earlier decisions concerned different terms and different consequences.

The system remembers the earlier bookings correctly. But if it converts them into “Iris hands hotel booking over to me”, it has invented a standing division from a history of completed acts. If it purchases this hotel, it has also turned that inferred division into present authority. The history may support a proposal about routine, refundable bookings. It cannot settle the non-refundable commitment or silently extend a prior grant. Accurate recollection alone justifies neither transition.

previously authorised acts  ≠  current desired division  ≠  current authority

Even an explicitly accepted division for smaller refundable bookings would not settle this case. The new cost and terms place it outside that scope. The system should return the unresolved choice to Iris: consider this expense and cancellation risk, or search for alternatives? It need not ask her to restate the dates and every already-settled criterion. Good handoff preserves the effort already made without taking over the decision that remains hers.

Legitimately retained observations of repeated choices might support a bounded proposal: “Would you like this division to apply to refundable hotels below the same amount?” Such observations do not silently become a standing allocation or a transaction grant. The system should identify the evidence and the permitted scope. It should not imply that repeated outcomes establish what Iris wants forever. Behaviour under a temporary mode keeps its provenance and cannot be promoted as though it described ordinary participation.

If Iris declines the proposal, the promotion is refused. The system does not update the standing division anyway, keep learning towards the rejected change, or treat later repetition as grounds to increase its own role. A declined proposal also should not cause the same question to reappear at every subsequent booking. Reconsideration remains something Iris initiates or explicitly accepts, not an escalation earned by frequency.

Two kinds of preference

“Use a table for exact comparisons” concerns presentation. “Research this, but let me implement it” concerns participation. “You may submit this pull request” concerns authority for an external operation. These three statements have different objects. Choosing a clear layout does not decide who judges the answer, and wanting the system to prepare a change does not necessarily permit it to publish that change. A concise view can support a decision Iris retains. A detailed explanation can accompany work she has chosen to hand over.

The same boundary applies to temporary context. “Be brief; I have five minutes” changes the communication request. It does not mean “Make the decision for me.” A deep-study mode does not automatically reserve every operation to her either. When an explicit current instruction changes participation, the change has that instruction’s scope. The system must not manufacture a transfer of work from an inferred mood, fatigue, urgency or appetite for autonomy.

Communication policy can shape how a handoff is presented, but it must still preserve the alternatives, assumptions, missing information and changed terms that the retained judgement needs. Brevity is not permission to remove the option that makes a trade-off meaningful. If a compact handoff cannot carry the decision-relevant distinctions, the system should offer a more detailed comparison or say that a safe short version is unavailable. This is Chapter 19’s preservation rule applied to delegated work.

Testing whether the decision was really retained

The argument suggests a controlled comparison, not a demonstrated result. Give readers the same constructed meeting and flight decisions, with fixed underlying option sets and predeclared choices they wish to keep. Compare four conditions: manual work, a coarse “assisted” mode, step-level allocation with a minimal approval screen, and step-level allocation with a source-linked, revisable handoff. Hold the underlying information and available permissions constant, so that a better outcome cannot simply be attributed to one condition receiving better data.

The test should distinguish formal retention from effective retention. Formal retention means the step is labelled as Iris’s. Effective retention means she can still exercise the judgement. Record whether the system respected the declared step boundaries, whether the available alternatives preserved the participant’s unresolved trade-offs, whether changed terms were returned before action, and whether any unauthorised hold, disclosure or purchase occurred. Measure decision correctness on cases with independently specified constraints. Also measure time and effort, the ability to reject every option, and whether the participant can explain or revise the final choice. Ask separately how much control the participant felt they had. A reported feeling is not evidence that the options were actually preserved. Include cases with missing search coverage, a persuasive but narrowed shortlist, a repriced fare, a conflicting standing rule, and a non-refundable exception.

No reader study or model evaluation is reported here. A scripted checker could verify explicit allocation boundaries and side-effect gates, but that would not prove that a person received a meaningful choice or that the proposed vocabulary reduces effort. One possible outcome is that coarse controls with good handoffs work just as well. The design must leave room for that result.

Where this leaves us

For the Berlin trip, the desired division is explicit. Iris keeps the criteria, the price-versus-arrival judgement, the selection or rejection of an itinerary, and authority over any final purchase. The system’s desired role is to search under those criteria, offer a faithful comparison, and prepare a non-binding proposal. The handoff must preserve alternatives, search limits and changed terms, so that her retained decisions remain real rather than ceremonial.

This is an allocation for an activity, its steps and its conditions. It is not an autonomy score for Iris. Its clarity is a design proposal, not evidence that fine-grained controls will always outperform simpler ones. The relevant question is whether the chosen division preserves real participation without imposing more configuration, inspection and correction work than it saves. The automation literature has long separated information acquisition, analysis, decision selection and action implementation. This chapter builds on that functional separation but asks an additional question: which parts does this person want to keep in this particular activity?

what Iris wants to keep and what she wants help with
        ↓
what the system is actually permitted to do

Her present instructions already matter. A step Iris explicitly retains cannot be taken away while the system waits for a more formal grant, and an approval button does not repair a decision already made through hidden filtering. But wanting help with an activity does not authorise every operation that could advance it. Even when she has settled who should do which part, the acting system faces a separate test: which actor, operation, data access and external effect have actually been authorised, and under what current conditions? That is where Chapter 33 begins.

References

• Parasuraman, R., Sheridan, T. B. & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics—Part A: Systems and Humans, 30(3), 286–297. DOI: 10.1109/3468.844354. (Background for separating information acquisition, analysis, decision and action implementation; not evidence for the proposed allocation interface.)
• Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. DOI: 10.1016/0005-1098(83)90046-8. (Background for the consequences of leaving humans nominally responsible while altering the work available to them.)
• Amershi, S. et al. (2019). Guidelines for Human–AI Interaction. Proceedings of CHI 2019, Paper 3. DOI: 10.1145/3290605.3300233. (Background on controllability, correction and scope; not a validation of the chapter’s proposed design.)