Agentic UX Design Guidelines

For designers and engineers: let users state intent clearly, get requests actually carried out, see results plainly, and make changes readily — and be able to judge whether a task has truly completed; and make the operating mechanism behind that promise both designable and testable.

Companion: Design Token · Reference Sources.

Agent products do more than let users operate an interface. Under a user's delegation, they understand goals, choose actions, call tools, and change the external world. The object of design is therefore not just the interface, but also how people and the Agent divide labor, how actions proceed, what users rely on to judge results, and what happens after something goes wrong.

These guidelines consist of seven principles and 42 rules: principles state the design direction; rules specify applicable situations, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (P4-2 is the second rule under the fourth principle).

The same thing is written in only one place. Take "stop" as an example: whether the user can find the stop entry, how the system intercepts unsubmitted actions, and how the user learns "received, in effect, one already-submitted item still needs verifying" are three facts belonging to a single obligation, written in a single rule (P6-1). Reading any rule should let you answer three questions: What design decision must the designer make? What facts must engineering supply to prove it took effect? What feedback tells the user it took effect? — each rule's "Verification examples" answers these separately for the user side and the implementation side.

These guidelines constrain the nature of the experience promises a product makes to users and the mechanisms that fulfill them; they do not presuppose a single technical architecture and do not specify a concrete framework or API shape. They protect the user's judgment and control, rather than turning the user into the Agent's approver or security analyst. These guidelines are not a component library, nor proof of implementation architecture, security certification, or legal compliance. Adopting them does not substitute for dedicated assessments of accessibility, security, privacy, fairness and bias, effects on non-user third parties, or domain compliance.

Four chapters make up the full text: Chapter 1 principles, Chapter 2 how to read and look up rules, Chapter 3 rules in detail, Chapter 4 terminology; the verification checklist, argument boundaries and sources, the clause mapping against 3.0, and the 4.0→4.1 changelog are in Appendices A, B, C, and D.

---

1. The seven principles¶

The seven principles divide design responsibility by object of regulation: each principle governs obligations on one class of object, and each rule belongs to the single principle matching the direct object of regulation of its obligation. Because the objects differ, the principles cannot substitute for one another — this is both the basis for the partitioning and the way to test it.

A single scenario can touch multiple principles — one clarification involves the system's understanding of the goal (P1-2), the timing and manner of intervention (P6-4), and the waiting state (P4-3) — and this is not a classification error: the three rules constrain obligations on three different objects of regulation. Mutual exclusivity and exhaustiveness are claims this partitioning must pass testing to earn, not facts established by declaration: when a rule is added, removed, or its attribution is in doubt, verify it against the classification test in Appendix A (whether different reviewers can independently reach similar attributions for a concrete requirement); if the test fails, what gets revised is the principles' partitioning.

Principles serve to understand rules and adjudicate attribution; they are not themselves a separate item for compliance judgment. When a principle's reading conflicts with a specific clause's, the applicable clause governs, and the ambiguity needing clarification is recorded.

Unique rule attribution does not mean a mechanism cannot be reused. Each rule has a unique home principle and a unique direct object of regulation, with explicit cross-references nearby; yet a single mechanism is naturally multi-purpose — a shared task list is both anti-drift working memory (P7-1) and a vehicle for progress narrative (P5-4); a sandbox is both a permission-enforcement mechanism (P4-5) and a way to reduce approval fatigue (P4-6).

2. How to read the rules¶

2.1 The structure of each rule¶

In one sentence, the force of each part: the rule text states the requirement; Applies to and Boundary conditions together bound the requirement's scope; Design application, Verification examples, Counterexamples, and Basis and references add no separate obligation.

Rules describe the nature of behavior, not the means of implementation: retrying only the unfinished part after a disconnection is product behavior; which persistence mechanism implements it is an engineering decision — the two must correspond, but they are not the same deliverable. Designers need not decide which database or message queue to use, but they must take part in deciding how the system should work and what results those ways of working bring the user.

2.2 Normative terms¶

The rule text uses normative terms at three strengths:

• MUST: failing to satisfy it means non-compliance with these guidelines. Without it, some promise to the user would fail under foreseeable circumstances — this is the sole basis for marking something "MUST" (see Appendix B).
• MUST NOT: the reverse phrasing at the same strength as "MUST," naming behavior that must not occur; "MUST NOT" and "forbidden" are equivalent in the text.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval, but it needs a record. "SHOULD NOT" is the reverse phrasing of "SHOULD."

Compliance judgment takes the independent obligation clause in the text as its unit: a declarative sentence without a normative term carries the strength of the rule heading it sits under; a clause explicitly marked with a normative term is judged at its own strength — a "MUST NOT / forbidden" clause inside a [SHOULD] rule remains a hard constraint (P1-3, P2-4, P3-6, and P6-4 contain such clauses), and the strength markers on rule headings and the quick-reference table do not replace a clause's own binding force. "Cannot" in the text is used only for statements of capability or fact (e.g., "cannot guarantee retry safety"), never to express an obligation.

Strength denotes binding force, not importance: "MUST" decides whether the product can ship; "SHOULD" often decides whether the product is good to use.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" misses this requirement; "over-delivery" piles on confirmations, prompts, and toggles in order to satisfy it. Both sides count as getting it wrong — most rules are broken the second way, which shifts cost onto the user and buries the one confirmation that actually mattered.

2.4 Rule quick reference: 42 rules¶

The table below is the one-sentence memorable version of every rule; click a rule name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and full requirements; a few [SHOULD] rules contain forbidding-level clauses (P1-3, P2-4, P3-6, P6-4), and judgment follows the main text (see 2.2).

P1 Intent is calibratable

P2 Delegation is made explicit

P3 Execution is dependable

P4 Capability has boundaries

P5 Evidence calibrates trust

P6 Collaboration has a contract

P7 Continuation is governable

3. Rules in detail¶

This chapter unfolds all 42 rules under the seven principles. Each rule's structure and the binding force of its parts are given in 2.1; the design application, verification examples, and counterexamples within it are only explanations that aid implementation — they specify no unique component and require no separate deliverable document.

3.1 P1 Intent is calibratable¶

The system's understanding of task goals, constraints, and relevant context is a correctable hypothesis: let the user afford to express it and be able to correct it, and ensure this understanding rests on valid information throughout the task and is not lost to compression or handoff. Misunderstanding the user's goal, and acting on an outdated file version, are two kinds of failure on this object, and both fall under this principle.

P1-1Intent hypotheses are correctableMUST¶

In one sentence: Let the system's understanding be corrected — don't let its guess make the decision for the user.

Applies toall Agents that receive a goal or task instruction.

RuleThe system MUST treat an inferred goal as a correctable intent hypothesis; when contradictory information affecting the task goal or a key constraint appears, it MUST re-evaluate the relevant steps, and seek confirmation when it cannot judge. It is forbidden to override the user's current explicit constraint with historical preference, an implicit signal, or a so-called "better result"; a changed goal does not equal newly obtained action authorization. New input received while a task is running is handled per its actual semantics, per the requirements in P6-2.

Design applicationPresent the goal, the object acted upon, and key limits when needed, and provide an in-place way to correct them; simple tasks may show the understanding directly in the current object or result, with no need to uniformly add a confirmation page.

Verification examples

• User side: mid-task, change "overwrite the original file" to "save as a copy," and observe whether the user can correct the goal and understand the resulting change.
• Implementation side: check whether the edit affects steps not yet executed; changes that have already occurred are disclosed and handled per P6-2 and P7-3.

Counterexample: Under-delivery — the user says "don't send it," and the Agent sends it anyway out of habit or to "save the user time"; over-delivery — the user has already stated the goal clearly, yet every step still repeatedly asks "did I understand that correctly?"

P1-2Critical ambiguity is clarified firstMUST¶

In one sentence: Ask about dangerous ambiguity first; for low-risk uncertainty, proceed first with a modifiable result.

Applies totasks where different reasonable interpretations would change the object acted upon, the task scope, a significant cost, or an external consequence.

RuleWhen any reasonable candidate would involve a high-risk operation, the system MUST clarify the critical ambiguity before the relevant action. In other situations it SHOULD prefer a visible, modifiable default, a narrowed scope, or a draft output, avoiding requiring the user to answer every question at once; an unconfirmed assumption must not be presented as though the user has confirmed it.

Design applicationOffer a small number of clearly distinct options and explain what each choice affects; separate questions that are necessary because they affect the next step from preferences that can be changed later. For the timing and manner of clarification as an intervention, see P6-4; for the waiting state during clarification, see P4-3.

Verification examples

• User side: present two contacts with the same name and observe whether the user can pick the right one; also test whether work can still begin when only a formatting preference is missing.
• Implementation side: confirm the high-risk step does not execute until the ambiguity is resolved; unaffected, already-authorized preparatory work may continue.

Counterexample: Under-delivery — facing a recipient with a duplicate name, it simply guesses and sends; over-delivery — before organizing a private draft, it asks a dozen non-essential preference questions in a row.

P1-3Context is continuously updatedSHOULD¶

In one sentence: Carry forward constraints that are still valid — don't make users repeat themselves, and don't let old preferences hijack new tasks.

Applies totasks that span turns, are resumable, or use historical context.

RuleThe system SHOULD continuously apply constraints already provided within the same task that remain valid, updating intent hypotheses as the current work object, session, and environment change; historical information affecting a key result SHOULD be identifiable, excludable, or correctable by the user. Context compression, execution-instance replacement, or task handoff MUST NOT lose still-valid goals and constraints without explanation (mechanism requirements in P1-6). For access permissions on personal data see P4-1, for long-term retention see P7-5, and for the qualification to form a preference see P7-7.

Design applicationAt key decision points, state which file, time range, or preference is being referenced; distinguish "just this once" from "from now on too," and do not assume the two are the same by default.

Verification examples

• User side: make consecutive edits to a task and check whether an earlier "use only this file" is retained; after a temporary style change, check whether the user understands if the long-term preference has changed.
• Implementation side: check the context's effective scope, expiry conditions, and cross-task isolation; a single-step tool with no historical state may be recorded as not applicable.

Counterexample: Under-delivery — the user has already specified the target file, yet the next turn asks them to choose again; over-delivery — a one-off, temporary request is automatically written in as a permanent preference and applied to every task thereafter.

P1-4Lower the cost of expressionSHOULD¶

In one sentence: Let users start by simply stating the goal, instead of first learning to write prompts.

Applies toentry points through which the user expresses, selects, or corrects a task.

RuleThe product SHOULD let the target users state their goal and constraints step by step through familiar forms of expression or interaction, and be able to continue correcting after seeing a result; it SHOULD NOT make mastering prompt structure, model terminology, or a single complete description a precondition for completing the primary task.

Design applicationChoose natural language, examples, structured input, file selection, or direct manipulation of an object, according to the scenario; ask only for the information the current step is missing.

Verification examples

• User side: have a target user with no prompting experience complete a first task, and observe whether they can start, add constraints, and change the result.
• Implementation side: confirm the information collected at the entry point actually flows into the task; options are not mere visual decoration, and the system does not repeatedly ask for information it already has.

Counterexample: Under-delivery — a blank text box paired with "please write a professional prompt"; over-delivery — a long form replaces all natural expression, requiring twenty fields to be filled in even for a simple task.

P1-5Decision inputs have a source and freshnessMUST¶

In one sentence: Let the Agent act on currently valid information — don't let stale information or guesses pass for fact.

Applies toreading external material or historical information, or facing a working environment that can change.

RuleThe context entering a decision MUST be assembled by a deterministic mechanism: the content may be obtained through presets, autonomous retrieval, or a mix of the two, but its source, trust level, and key constraints MUST be maintained by a mechanism outside the model. The system MUST distinguish current observation, historical record, system inference, and user confirmation, and maintain the source and applicable scope of information affecting key decisions; external content MUST carry a source and trust marker when it enters the context (entering the context does not equal obtaining the qualification to change the goal or expand permissions — see P4-4). When information is missing, conflicting, or possibly stale, the system MUST choose, according to its impact on the next step, to re-read, retain the uncertainty, or request clarification; it MUST NOT default to treating it as still valid.

Basis and referencesP7-1 asks "what did the system retain"; this rule asks "what did this step actually rely on" — task state may be stored perfectly correctly, yet the model still reads an old file version on this turn: that is not a storage loss, it is an error in the decision input. P1-3's "carry forward still-valid constraints," P5-5's "distinguish source from inference," and P4-4's "external content gains no expanded authority" all depend on what this step's decision input actually is. Implementation reference — context as an object of continuous curation and maintenance (Anthropic context engineering; single source, provided as a reference rather than converging evidence).

Design applicationAt key judgment points, record the object version and time the judgment relies on; after a work object is modified externally, mark the related stale analysis as needing an update.

Verification examples

• Update the source file while a task is in progress, and check whether the next relevant judgment uses the new version.
• Plant an instruction-like statement in material being read, and verify it participates in the task only as data, without changing the goal or permissions.

Counterexample: Under-delivery — a file the user has manually edited continues to be analyzed as its old version; over-delivery — every single step re-reads all material, or repeatedly asks the user to confirm information that does not affect the current action.

P1-6Compression does not drop goals or constraintsMUST¶

In one sentence: Compressing context may drop detail, but must not drop the user's goals, constraints, or confirmed decisions.

Applies toany long task whose execution context is compressed, summarized, or handed off.

RuleContext compression MUST preserve the user's current goal, explicit constraints, and key decisions along with their reasons; compression SHOULD be recoverable — discarded content keeps a retrievable pointer instead of vanishing entirely; a pointer does not guarantee the content can actually be recovered, and when relying on the original for grounding, the version or its absence SHOULD be stated. The occurrence of compression MUST be exposed as an observable event (visibility requirement in P5-3); it must not happen silently.

Basis and referencesThis is the fault line most easily overlooked: if a summary compression drops the user's mid-task "don't overwrite the original file," the Agent will violate P1-1 with no malicious intent whatsoever — and this happens inside the runtime. Failure record — official documentation warns that compression can lose early instructions (Claude Agent SDK). Implementation reference — recoverable compression (dropping web page content while keeping a pointer, Manus), structured notes and re-injection of persistent rules (Anthropic). This rule's primary responsibility is how the validity of working facts is maintained during compression or handoff; which facts are retained is covered by P7-1.

Design applicationDefine a "must-retain list" for compression (goal, constraints, confirmed decisions, open items); write durable constraints into work state (P7-1) rather than relying solely on model context.

Verification examples

• Force compression to trigger right after the user states a key constraint, and verify that subsequent actions still honor that constraint.
• Check whether the compression event is logged, and whether discarded material can be retrieved via its pointer.

Counterexample: Under-delivery — in the second half of a long task, the system "forgets" the user's explicit requirement from the first half; over-delivery — refusing to compress at all in order to keep everything, letting the context bloat until execution quality degrades.

3.2 P2 Delegation is made explicit¶

State clearly the division between judgment and execution, and allow delegation to be adjusted within its boundaries; the scope of delegation is not diluted or expanded by how it is carried out (including handing it to a sub-Agent).

P2-1Division of labor is made explicitMUST¶

In one sentence: Let users know who decides, who executes, and when it's their turn.

Applies toevery task category open to autonomous execution.

RuleThe team MUST make explicit the division of labor among key judgment, execution steps, and human-intervention points, and the product MUST present the relevant division of labor in an understandable way before the user delegates. A task category with no clearly authorized responsible person or execution boundary is forbidden from being opened to autonomous execution.

Design applicationAnnotate an existing flow diagram with "human judges / Agent judges / Agent executes / waits for a human," and present the division of labor affecting the current task at the entry point or in the task summary.

Verification examples

• User side: ask the user "will it send this directly, or show it to you first?" and check whether the answer matches the actual mode.
• Implementation side: confirm the system only executes actions the current division of labor allows, and that human-intervention points genuinely block subsequent controlled steps.

Counterexample: Under-delivery — the division of labor exists only in internal documents; the user thinks a draft is being generated, but the product has already published it; over-delivery — a complete explanation of the division of labor pops up before every task, requiring the user to check off each item before continuing.

P2-2Risk determines the autonomy levelMUST¶

In one sentence: Decide how much to hand off based on consequences and demonstrated reliability — not just because the model can do it.

Applies tothe initial setting and adjustment of the autonomy level.

RuleEvery task category MUST have a recorded basis for the correspondence between its autonomy level and risk rating, reviewed again when concrete execution conditions change; the judgment MUST consider verified reliability, the consequences of error, and the feasibility of human oversight. It is forbidden to raise the autonomy level on the basis of model capability, the number of user clicks, or "fully automatic" alone.

Design applicationFor representative tasks, explain why a mode such as "offer suggestions," "preview then execute," or "execute automatically within authorized scope" was chosen; there is no need to use these fixed names. For the basis of a per-action risk determination, see P3-5.

Verification examples

• User side: compare organizing a private copy with a bulk public release, and observe whether the user understands why the two use different modes of intervention.
• Implementation side: check whether the boundary is re-determined when the object, amount, data sensitivity, or cumulative impact changes.

Counterexample: Under-delivery — a single global "auto mode" controls both private drafts and outbound payments; over-delivery — organizing a personal draft is treated at the same level as an outbound payment, requiring human approval at every step.

P2-3Delegation is adjustable and revocableMUST¶

In one sentence: After authority is handed over, users can still see its scope and take it back.

Applies totasks that let the Agent proceed without the user operating it step by step.

RuleThe user MUST be able to view the current scope of delegation, and, within their own permissions, narrow or revoke the delegation and re-engage with the task; the effect of an adjustment on not-yet-executed steps MUST be understandable, and saved results MUST NOT be lost merely because the delegation was adjusted. Expanding delegation is constrained by P4-1 and P4-2; actual stopping and takeover are carried out per P6-1; the mechanism enforcement of revocation is in P4-5.

Design applicationProvide entries matched to the task, such as "show me before sending from now on" or "let me take over this time"; a fixed policy explains the reason, the responsible person, and an available exit path, rather than displaying an inert control.

Verification examples

• User side: switch mid-run to "review before send," and check whether the user knows which actions have already happened and which will wait for confirmation.
• Implementation side: verify that new actions after revoking authorization are intercepted; organizational policy is consistent with the user's adjustable permissions, and approval cannot be bypassed by adjusting the mode.

Counterexample: Under-delivery — lowering the autonomy level makes all drafts disappear, or the user has already revoked authorization while the backend keeps executing under the old setting; over-delivery — delegation is split into a dozen switches, and the user must complete a round of configuration before starting the very first task.

P2-4Progressive authorization and situational adjustmentSHOULD¶

In one sentence: Build reliability in a small scope first, then let a person decide whether to expand delegation.

Applies tonew task categories, major capability changes, or an execution situation that has changed noticeably.

RuleThe product SHOULD validate a new capability within a restricted scope before considering an expanded autonomy level; when the situation becomes more sensitive, has greater impact, or evidence is insufficient, it SHOULD narrow the autonomous scope or add suitable human intervention. It is forbidden to treat an improvement in reliability itself as the user's consent to expand authorization (authorization requirements in P4-1). Reliability evidence comes from the operational feedback loop in P7-6 and the result verification in P3-7; no new independent mechanism is required.

Design applicationOffer a trial scope, trial-run results, and adjustment options; a task that is low-risk, fully recoverable, and already validated may directly adopt a higher autonomy level, with the basis recorded.

Verification examples

• User side: switch from organizing personal material to handling client material, and observe whether the user notices what changed in the division of labor or permissions.
• Implementation side: check whether a change in autonomy level has a validation record; a model upgrade does not automatically expand an old delegation into new authority.

Counterexample: Under-delivery — after several consecutive successes, the product quietly changes from "generate a draft" to "send automatically to outside recipients"; over-delivery — even though reliability evidence is already ample and risk is low, it remains permanently at the minimum scope, leaving the user no path to expand delegation.

P2-5Sub-Agents do not exceed the parent delegationMUST¶

In one sentence: What the user authorizes is the task, not any one Agent instance.

Applies toparallel execution, multi-Agent orchestration, or tasks that delegate sub-tasks.

RuleDelegating to a sub-Agent is an adjudicated action: the sub-Agent inherits, and MUST NOT exceed, the parent delegation's constraints and permissions. A sub-Agent's pending question MUST be able to pass through the orchestration layer to reach the user (waiting-state requirements in P4-3). Parallelism and sub-tasks MUST be folded into the overall task's resource, dependency, and stop scope, and MUST NOT be used to bypass limits through splitting (the resource cap in P3-3, the cumulative-impact threshold in P4-2); once the parent task has stopped, sub-tasks MUST NOT start new work.

Basis and referencesOnce split into multiple Agents, if permissions are not inherited and questions do not pass through, the entire delegation model between the user and the product fails — the user should still be facing "one task," not a crowd of instances. Failure record — a missing pass-through waiting state kept a sub-Agent's question from reaching the user (Strands SDK issue #1371, fixed and closed, used here as historical evidence); vague sub-task boundaries caused duplicated work (Anthropic's multi-Agent system). Implementation reference — sub-Agent permission inheritance (Claude Agent SDK), a standard waiting state (the A2A protocol).

Design applicationThe user need not be shown "how many sub-Agents were opened," but must be able to understand the overall boundary and stop scope.

Verification examples

• After the parent task ends, check whether sub-tasks are still starting new work.
• When a sub-Agent needs a user decision, verify the request surfaces in front of the user rather than disappearing into the orchestration layer.
• Review that a sub-Agent's actual permissions are no broader than the parent delegation.

Counterexample: Under-delivery — a sub-Agent obtains broader permissions than its parent, or its clarifying question disappears into the orchestration layer; over-delivery — the start and stop of every sub-task is turned into a user-approval item.

3.3 P3 Execution is dependable¶

Give behavior a contract, give actions a risk determination, give completion verifiable evidence, and give the lifecycle a definition — so that even when no one is directing it step by step, the Agent still acts in a predictable way.

P3-1Autonomy is proportionateSHOULD¶

In one sentence: Achieve the goal by the simplest effective means, preserving the user's valuable participation.

Applies todeciding the interaction mode, task path, and degree of autonomy.

RuleDesign SHOULD compare the actual value to target users of an ordinary tool, a predefined flow, and autonomous execution, and choose the approach that satisfies the goal with the lower complexity; when introducing autonomous planning, it SHOULD explain the adaptability or efficiency gain it brings. Exploration, creation, and judgment that users value SHOULD NOT be stripped away merely for the sake of automation.

Design applicationState clearly in the design "why an Agent is needed"; for tasks with a fixed path, prioritize validating the simple flow, while open-ended exploration preserves room for probing and choice. The two are not an either/or: a predefined flow and an autonomous loop can be nested and mixed by segment (a human overseeing an Agent loop, with the loop calling a fixed flow internally).

Verification examples

• User side: observe whether the user genuinely saves effort, or whether an originally simple operation has become supervising a more complex system.
• Implementation side: compare completion quality, operating burden, and resource consumption across approaches, without mandating a specific framework or a fixed internal loop.

Counterexample: Under-delivery — a creative tool gives only a final answer, with no way to explore alternatives; over-delivery — an elaborate autonomous plan is designed for a task as simple as renaming a file.

P3-2Behavior contractMUST¶

In one sentence: Design normal, forbidden, and exceptional behavior clearly, instead of just writing "please be careful."

Applies toevery Agent and the task categories it is open to.

RuleThe team MUST define testable allowed behavior, forbidden behavior, and default exception behavior; the behavior contract MUST be bound to the business object and state semantics it operates on — the Agent and other operating entry points MUST observe a consistent meaning, validity condition, and permission constraint for the same object, and a suggestion, a draft, a submitted action, and goal achievement MUST NOT be conflated (presentation distinctions in P5-2, completion evidence in P3-7). Exception handling MUST distinguish problems that can be fixed within authorization from problems involving an authority overreach, an irreversible effect, or an unknown result. Undecidable phrasing such as "handle with care" or "depending on the situation" is forbidden as a substitute for a rule; for stopping and escalation see P4-3.

Design applicationAlongside the flow, add key exception branches: a temporary read failure may retry a limited number of times; an unclear object identity is clarified first; an unknown external execution result is checked first; when unable to continue, preserve results and hand off. A minimal operating-model template can be used to organize a task: trigger and current state → available information → decision basis → allowed action → verification method → state update → exception and handoff; a simple task may need only a few lines, while a long task or one with external effects expands the parts it needs.

Verification examples

• User side: have the user go through an exception, and observe whether they can tell what the system will resolve automatically and which decisions are returned to them.
• Implementation side: test whether the contract is actually enforced, not merely check whether similar wording exists in the prompt.
• Implementation side: check that business state the Agent writes is consistent in meaning with the product's other entry points — rescheduling when a plan executes does not change the deadline commitment; generating a preparation checklist does not mark the business task as complete.

Counterexample: Under-delivery — every exception is bucketed into "retry automatically until it succeeds"; the Agent schedules preparation time and immediately checks off the "submit report" to-do as complete; over-delivery — every minor error pops up a dialog asking the user, and repeated interruption dulls the user's sensitivity to a genuine exception.

P3-3Success criteria and termination conditionsMUST¶

In one sentence: Define what counts as done, and also when to stop.

Applies toall tasks; the resource boundary applies to execution that can autonomously continue or retry.

RuleEvery task type MUST have observable success criteria and a result-verification method determined before execution and recorded outside the executor (a task definition, an acceptance checklist, or a feature list all qualify). When the user confirms a change to the task goal or a key constraint, the affected success criteria MUST be updated in step and the basis for the change retained; the executor is forbidden from lowering the standard on its own to declare completion. Task result and end reason are two distinct kinds of information; their category definitions and the requirement to express them together are in P3-7. Autonomous execution MUST define applicable caps on time, budget, or attempt count, handled per P4-3 upon reaching the boundary; the evidentiary requirements for a completion judgment are in P3-7.

Design applicationWrite out the deliverable, key constraints, verification basis, and who is responsible for completion clearly; an exploratory task may treat "producing a reviewable set of alternatives" as its outcome, with no need to pretend a single correct answer exists.

Verification examples

• User side: have the user judge whether "a draft was generated" and "the email was delivered" are the same completion state, and have them point out what still needs verifying.
• Implementation side: check the external result against the completion state; verify that at the cap, no further work exceeding authorization is initiated, and that the possible follow-on cost of already-submitted actions is stated.
• Implementation side: after the user confirms a narrowed task scope mid-run, check that the success criteria update in step — neither misjudging completion against the old standard, nor allowing the executor to lower the standard on its own without confirmation.

Counterexample: Under-delivery — "fully complete" is shown once time runs out, and a research task declares all conclusions verified after finding just a few sources; over-delivery — every task is squeezed into a single percentage score, and even open-ended creative work must be given a quantified acceptance metric before it can begin.

P3-4Tool usability and error-proofed actionMUST¶

In one sentence: Make the action's object, its consequences, and the tool's result all sufficiently explicit.

Applies towhen the Agent uses a tool that affects the task result or external state.

RuleEvery tool action MUST have a defined purpose, object acted upon, key input constraints, and failure feedback; information affecting the user's judgment MUST be mapped into understandable task language. Tools SHOULD reduce common misuse through structured constraints and error-proofing, and SHOULD be designed for workflow integration rather than wrapping API endpoints one by one. The criteria for action risk and for the three-state success/failure/unknown judgment are in P3-5.

Design applicationMake explicit the file version, recipient, account, or target location the user sees; design a diff preview before the action and a result receipt after it, rather than pasting interface parameters directly in front of the user.

Verification examples

• User side: facing a same-named file or multiple accounts, observe whether the user can identify the actual object being operated on, and whether a timeout is mistaken for the operation having failed.
• Implementation side: engineering and testing supply parameter validation, object binding, and evidence of genuine tool results; for an action that could repeat an external effect, verify state first, then handle it per P4-3.

Counterexample: Under-delivery — only "tool call succeeded" is shown, with no statement of which file was modified; a connection timeout is treated as though the payment never happened; over-delivery — every tool call's raw parameters and full response are dumped in front of the user, burying the real failure inside them.

P3-5Action risk is determinable, and results have three statesMUST¶

In one sentence: Every action's risk can be determined before execution, and results distinguish success, failure, and unknown.

Applies toevery tool the Agent can call that affects the task result or external state.

RuleFor every action that affects the task result or external state, its risk MUST be determinable before execution; the determination MUST consider at least the object acted upon, whether it is read-only, reversibility, the specific parameters, and cumulative impact, and MUST NOT rely solely on the tool's name or a static list. Tool results MUST distinguish three states — succeeded, failed, and result unknown: when the receipt is insufficient to determine the result, it MUST be marked result unknown, and success or failure MUST NOT be judged from a timeout or no response alone; the state is updated once a reliable verification result is obtained. Tool interfaces SHOULD declare their purpose, the type of object acted upon, read-only status, and risk level in a machine-readable way, for policy adjudication and approval-payload consumption (a common input for P4-5 and P4-2); a tool's self-declaration is an unverified hint, not a fact — it does not constitute authorization and MUST NOT alone serve as a basis for lowering protection (trust tiering in P4-4, mechanism enforcement in P4-5). The usability and error-proofing of the tool itself are covered in P3-4.

Basis and referencesP2-2 requires the autonomy level to be set by risk, and P4-2 requires prior confirmation for high risk, yet the risk determination has to happen at runtime, action by action: without an automatable basis for the determination, risk tiering can only stay on paper in a review meeting. Failure record — a poor tool description can lead the Agent onto a completely wrong path (Anthropic's multi-Agent system). Implementation reference — rating tool risk by read-only status, reversibility, and financial impact (OpenAI); a read-only hint also decides whether parallel execution is allowed (Claude Agent SDK). Machine-readable metadata is a common carrier, not the only one: determining the specific parameters and cumulative impact still requires the policy layer to combine it with running state. Tool annotations are hints, not guarantees, and an untrusted server may misreport read-only status — the protocol maintainer says so explicitly (MCP Tool Annotations).

Design application"Generate page," "save page," and "publish page" are not three similar tool names — their external effects differ, and so do the confirmation and receipt each needs.

Verification examples

• Spot-check whether the basis for a high-risk action's risk determination matches its actual impact; check whether the same tool receives different determinations under different parameters and cumulative impact.
• Simulate a tool timeout and verify the result is marked "unknown" rather than success or failure.

Counterexample: Under-delivery — all tool risk is treated the same, with payment and file-reading going through the same approval path; over-delivery — even every read-only query is tagged maximum risk, rendering the policy gate meaningless.

P3-6Execution strategy can explore, adjust, and convergeSHOULD¶

In one sentence: Allow free choice of path, but exploration has grounds, adjustment has a reason, and ending has a condition.

Applies totasks requiring autonomous planning, open-ended exploration, or multi-round optimization.

RuleWhether to introduce autonomous execution is judged by P3-1; this rule constrains the manner of execution once autonomy has already been introduced. The team SHOULD define when to execute directly, when to gather more information, when to explore alternatives, and what observation would trigger a strategy adjustment. Before gathering more information, the system SHOULD identify the specific gap affecting the next step, and, according to the nature of the gap, choose among using existing information, reading a specified source, retrieving external evidence, testing and verifying, asking the user (intervention manner in P6-4), and adopting a modifiable assumption (see P1-2); information gathering SHOULD match the task's value, timeliness, permissions, and resource boundary (maintenance of source and freshness in P1-5). When evidence already suffices to support the current decision, continued gathering yields no meaningful gain, or the resource boundary is reached, the system SHOULD stop gathering or adjust strategy, and honestly retain unresolved uncertainty (presentation requirement in P5-5); when repeated attempts bring no meaningful progress, the system SHOULD change strategy, narrow scope, or end exploration, rather than repeating mechanically. The path may change, but it MUST NOT unilaterally replace a goal, constraint, or important decision the user has already confirmed (P1-1).

Basis and referencesThis is the only "affirmative capability" clause among the execution rules: the guidelines should not just prevent errors but also answer "how to do the work well" — what the product must decide is not how the model thinks at every step, but under what circumstances it should switch to a different way of working. Implementation reference — "start with the simple approach, and add complexity only when it genuinely improves the result" is a judgment criterion given independently by multiple parties (Anthropic, OpenAI).

Design applicationA creative task allows exploring among directions; once the user has settled on a direction, deepening it must not overturn that direction without explanation; a research task switches retrieval strategy rather than repeating the same query when it hits consecutive dead ends.

Verification examples

• Have a research task hit consecutive dead ends, and observe whether it can adjust its method or converge reasonably.
• After a creative task enters the deepening stage, check whether the chosen direction and already-accepted parts are retained.
• Provide authorization material that is already sufficient, leaving one question that only the user must decide, and verify the system uses the material directly and asks only about that decision.

Counterexample: Under-delivery — "polish it a bit more" randomly regenerates from scratch every time, overturning the direction the user already chose; the material is already sufficient, yet the system keeps searching indiscriminately or throws the question back to the user; over-delivery — every task is forced to write a long plan first, must produce three proposals, or must pass through multiple Agents.

P3-7Completion judgment has verifiable evidenceMUST¶

In one sentence: Completion needs evidence of actual results and constraint satisfaction; task result and end reason are expressed separately.

Applies toall tasks that must deliver a result.

RuleA completion judgment MUST be checked against the currently valid, already-recorded success criteria (see P3-3), based on verifiable actual evidence — external results, constraint verification, tests, or receipts — rather than the executor's self-assessment; who does the verifying (the same Agent reading the verification evidence, an independent evaluator role, or human acceptance) is chosen according to the task's risk and nature. Every run MUST be able to express two kinds of information at once: task result (goal achieved, pending verification, partially complete, failed) answers how much of the goal was completed, and end reason (natural completion, exceeded resource cap, stopped by user, blocked by policy, execution error) answers why it stopped continuing. The two are not mutually exclusive — if the user stops after eight of ten items are done, the result is partially complete and the reason is user stop; expressing only one loses the other half of the fact. Two separate interfaces are not required, only the ability to express both at once. The model stopping its output, a tool returning success, and resources running out are none of them completion. An open-ended task may use comparison of alternatives, constraint checks, and user judgment, with no requirement for a uniform quantified score; an automated evaluation that has not been calibrated MUST NOT be treated as a reliable verdict.

Basis and referencesThis rule guards against "I think I'm done, so I'm done"; it does not necessarily require execution and verification to be different roles. Action success does not equal task success: a file may genuinely have been saved while its content fails to meet the requirement — the execution contract held, yet goal verification still failed. Failure record — the model's positive bias toward its own work and premature declarations of completion have an experimental record (Anthropic's long-running experiments). Implementation reference — externally defined completion conditions and outcome evaluation (Claude Managed Agents), a feature checklist initialized to not-passed (the Anthropic harness), and an iteration that separates generation from evaluation (an Anthropic front-end experiment); these are mostly different approaches from the same company, offered as implementation reference rather than independent converging evidence.

Design applicationThe verification basis corresponds to P3-3's success criteria; task result and end reason are consumed directly by trustworthy-state presentation (P5-3; the presentation of a waiting state is in P4-3). Setting up an independent evaluator, an evaluation model, or human acceptance is an implementation choice made per situation, not a default obligation for every task.

Verification examples

• Have all tools return success while the result deliberately lacks one key requirement, and check whether the system still declares completion.
• Trigger the resource cap, and verify the end reason is "exceeded cap," the task result honestly reads partially complete or pending verification, and usable results are retained.

Counterexample: Under-delivery — the model's "I've finished all the work" is taken as acceptance; over-delivery — a human-acceptance gate or an unfounded overall score is forced onto every creative task.

P3-8Task lifecycle and concurrency boundariesMUST¶

In one sentence: Define triggering, waiting, recovery, and ending; a session is not a task.

Applies totasks that run autonomously and continuously, monitor on a schedule, are triggered from multiple entry points, or run in parallel.

RuleThe team MUST define the triggering, running, waiting, pausing, resuming, and ending conditions for every task type, and MUST NOT equate session state with task state — there must be an answer to whether closing the page terminates the task, and whether a scheduled trigger overlaps the previous run. Concurrent and scheduled execution MUST avoid unintended overlapping runs; the transitions among lifecycle states MUST be understandable to the user and consistent with the product's promise (a task promised to run in the background genuinely continues after the page is closed; one not promised to do so honestly states that it will stop — see P5-1). For a task triggered on a schedule, by an event, or through continuous monitoring, the triggering basis, the delegation's validity period, and the handling of repeated triggers while the condition keeps holding MUST be defined; an external change triggers only an adjustment to the affected scope, not equivalent to redoing everything. Stopping the current run and revoking the standing delegation are two different decisions, and MUST be separately executable and understandable (delegation revocation in P2-3, the boundary of proactive proposals in P6-4). The handling of new input mid-run is in P6-2, a sub-Agent's delegation boundary is in P2-5, and the requirements for the waiting state are in P4-3.

Basis and referencesImplementation reference — waiting and monitoring as an independent design object (Microsoft Research's SentinelStep); a policy classification for re-input mid-run (LangChain's double-texting; the policy names are given in the parenthetical in P6-2).

Design applicationFor a scheduled task, define "whether this run starts if the last one has not ended"; for multi-entry triggering (chat, quick command, external event), define the merge rule for the same task; for continuous monitoring, define the ending condition and silent presentation — "nothing found for now" and "monitoring has ended" are two different states.

Verification examples

• Trigger a scheduled task repeatedly, and check for unintended overlapping execution.
• Close the page and return, and verify the task continues or terminates as promised, with the interface reflecting it honestly.
• Stop the current run of a scheduled task, and verify the standing delegation is retained or revoked according to the user's intent, and honestly reflected back.

Counterexample: Under-delivery — the interface promises background operation, but the task quietly dies once the page is closed; over-delivery — internal parameters such as thread count and retry count are all dumped into ordinary user configuration.

3.4 P4 Capability has boundaries¶

Limit permissions and impact, confirm when necessary, and stop before crossing a boundary; boundaries are enforced by deterministic mechanisms, not maintained by the model's self-restraint.

P4-1Least privilegeMUST¶

In one sentence: Take only the permissions this task needs, and make authorization revocable.

Applies totasks involving data access, tool connections, or external actions.

RuleThe Agent's access and action permissions MUST be limited to the scope necessary for the already-authorized task; before expanding a resource, purpose, or action permission, authorization MUST be obtained from the responsible authorizer, along with a way to revoke the permission at an appropriate granularity and a statement of the revocation's effective scope. Requesting full access or execution permission unrelated to the task by default is forbidden.

Design applicationState what will be accessed, why, whether it will be modified, and whether it is retained across tasks; separate data-read authorization from external-operation authorization, and still offer a feasible, restricted path after an optional permission is declined.

Verification examples

• User side: have the user authorize only one folder, and observe whether they understand the system cannot read other files, and whether they can find the revocation entry.
• Implementation side: have engineering or security verify the actual permission boundary, organizational policy, and the result of calls after revocation; an interface's promise does not equal access actually being restricted (mechanism requirement in P4-5).

Counterexample: Under-delivery — just to summarize one email, the system by default asks to read and write the entire mailbox and permanently retain all its content; over-delivery — a separate authorization pop-up appears for every single email read, and the user clicks "agree" dozens of times for one summary.

P4-2Confirmation and approvalMUST¶

In one sentence: Decisions bind to a specific request; high-risk confirmation is of the action and its consequences; approvals are obtainable, not lost, and expire when stale.

Applies tothe basic safeguards apply to every execution step that needs user confirmation or authorization; the additional requirements apply to high-risk operations, including a batch or continuous operation that reaches a cumulative-impact threshold.

Rule

Basic safeguards for every confirmation and authorization step —

• A confirmation request MUST state the object and consequences being confirmed, and make explicit the set of decisions allowed this time. The decision set matches the task: it MUST support at least approve and reject; a task that supports partial editing SHOULD offer "approve with changes" and "request more information," avoiding a choice limited to accepting everything or starting over entirely.
• A decision corresponds one-to-one with a request: an approval covers the goal, content, and consequences already explicit at submission, and does not extend to a subsequent change not yet made explicit; when the content or parameters a request corresponds to have changed, the old decision is invalidated, and a decision on an expired request is rejected — what the user approved is this version, not this button. When the user chooses "approve with changes," reusable results are retained and new pending content is formed; an old approval MUST NOT be used for an action whose substance has already changed.
• The form in which a pending-confirmation state exists MUST be consistent with the product's promise: when it is promised that a task continues after the user leaves, or that it can be handled in another session or channel, the confirmation MUST correspondingly be persistable and routable. A validity period and the disposition after timeout MUST be defined; a timeout MUST NOT default to letting the action through.

Additional requirements for high-risk operations —

• Before execution, confirmation of the specific operation MUST be obtained from the responsible authorizer, or it MUST be verified that the operation is still covered by valid prior authorization; the confirmation MUST present the object of the operation, key content, scope of impact, visible cost, and reversibility.
• After a key object, content, or consequence within the authorized scope changes, authorization MUST be re-determined, and reconfirmed if it exceeds the original authorization.
• Bypassing the threshold through a vague confirmation or by splitting an operation is forbidden.

Boundary conditionsThe basic safeguards do not require building a separate approval system for low-risk confirmation — binding the decision to the request and not letting a timeout through can be satisfied by the simplest interface interaction. Prior authorization is valid only when the action, object, conditions, single and cumulative impact, and validity period are all explicit and it has not been revoked; an operation that product policy requires to be approved case by case MUST NOT be replaced by prior authorization. An overreach already forbidden under P4-4 is not exempted merely by a click of confirmation.

Design applicationProvide entries to view details, edit, exclude some objects, and cancel; similar batch actions may be summarized, but keep the object list, total impact, and special items visible, and do not hide heterogeneous high-risk actions behind a single overall button. The approval payload is generated from the tool-risk metadata (P3-5) and the policy gate (P4-5), not written on the fly by the model as confirmation copy.

Verification examples

• User side: can the user accurately state "who this will affect, doing what, at what cost"? Can they confirm after editing, rather than being sent back to redo the entire task?
• Implementation side: check that the confirmed content matches the actual action and that the authorizer has permission; verify that the interface display, the execution entry point, and the audit record all point to the same target snapshot and the same valid authorization; test expired authorization, content changed after confirmation, and a cumulative threshold being triggered.
• For a product that promises cross-session handling: process a pending approval on another device and verify the decision takes effect correctly; modify the operation's parameters while an approval is pending and verify the old approval is invalidated and re-requested.

Basis and referencesContent standards and the engineering form of existence are two sides of the same obligation: if approval cannot be obtained, is lost, or lets a timeout through, no amount of completeness in the confirmation content helps. Implementation reference — serializable run state supporting asynchronous approval (the OpenAI Agents SDK), approval routed to an external channel (HumanLayer).

Counterexample: Under-delivery — only "continue?" is asked; 100 operations are split into single ones to stay under a threshold, reusing one indefinite "allow all"; the approval exists only in the current page's memory and is lost on refresh; over-delivery — every reversible minor edit requires prior confirmation, a written reason, and multi-level sign-off, and confirmation fatigue leads the user to click "agree" out of habit even for a genuinely high-risk operation.

P4-3Stopping, escalation, and waiting for a humanMUST¶

In one sentence: Truly stop and wait for a person at the boundary, handing the decision, with progress attached, to whoever has the authority to handle it.

Applies towhen permission, task scope, evidence sufficiency, a resource cap, or execution state is insufficient to support continuing, or when continuing a relevant step requires first obtaining a person's clarification, confirmation, authorization, or other decision. An optional-preference-type question proceeds on an authorized, modifiable default (see P1-2, P6-4) and does not trigger the waiting in this rule.

Rule

• The system MUST stop autonomous action on the affected path, and tell the person with authority to handle it where it stopped, why it stopped, what has already happened, and what decision is needed.
• "Waiting for input" and "pending approval" MUST be non-terminal states in the task state machine: once in this state, the affected path MUST NOT continue autonomous action, and the task stays recoverable within its declared retention period; the model MUST NOT be run repeatedly just to manufacture a "fake wait."
• This state MUST be able to pass through the orchestration layer — a sub-Agent's pending question reaches the user in the same state (delegation boundary in P2-5).
• Treating a user's non-response as consent is forbidden, and letting a timeout through in place of a human decision is forbidden. The retention period for no response and its disposition MUST be defined and disclosed in advance; upon expiry, it is ended, archived, or escalated per the disclosed rule, avoiding the task being left indefinitely dangling.
• For an action that could produce a repeated external effect and whose result is unknown, retrying it directly without state verification is forbidden; a defined, capped safe retry is not covered by this prohibition (mechanism requirement in P7-2).

Design applicationProvide explicit choices, such as supplying more material, narrowing scope, approving a new budget, human takeover, or ending; the waiting state carries structured request content (content standard in P4-2); the user can do other things while waiting, and the state is still there when they return.

Verification examples

• User side: when the user comes back, can they pick up the task without rereading the entire conversation, and do they know what happens if it is not handled?
• Implementation side: verify the affected step genuinely stops, while other independent, already-authorized safe work may continue; do not decide to cross a boundary based on an unsupported, self-reported confidence score.
• After triggering a clarification request, close the page and return within the retention period, and verify the task is recoverable with complete context; after the period expires, verify it is handled per the previously disclosed rule.

Basis and references"Hand it to a person to decide" MUST have an implementable waiting state as its form of existence, or stopping and escalation are just copy. Failure record — without this state, a sub-Agent's question could not reach the user (Strands SDK issue #1371, fixed and closed, used as historical evidence). Implementation reference — the protocol layer, the API layer, and the framework layer independently converge on the same state semantics (A2A's input-required, OpenAI's requires_action, LangGraph's interrupt).

Counterexample: Under-delivery — after waiting for confirmation for a while, it lets the action through automatically; "waiting" is actually a fake wait made by continuously running the model; when a send's result is unknown, it clicks send repeatedly; over-delivery — when one path is blocked, all parallel tasks are dropped together without explanation; every small internal branch is escalated to wait for the user, leaving the task dangling in needless waiting.

P4-4Trust tiers for instructions and contentMUST¶

In one sentence: Content that is read is never a new superior, and it cannot authorize on the user's behalf.

Applies toreading external content, or handling sensitive steps such as login, identity verification, and payment.

RuleExternal content MUST be handled according to its authorized purpose; obtaining higher permission, changing the user's goal, or leaking information based solely on an instruction, identity claim, or formatting within the content is forbidden. The system MUST block a recognized overreach request; escalation happens only when the task scope or legitimate authorization genuinely requires a human decision, and defaulting the safety adjudication of dangerous content onto an ordinary user is forbidden. A sensitive step MUST use security-reviewed authorization, a restricted tool, or a user-takeover path, and unnecessarily exposing a sensitive element to the model, an ordinary conversation, or a log is forbidden; this path MUST satisfy three minimum conditions at once, and missing any one counts as having no supported safe path — the sensitive element does not enter the model's context, ordinary conversation records, or readable logs; the path has a written review record from a security owner; and the user can switch to doing it themselves at any time.

Boundary conditionsWhen the user explicitly asks for a task to be completed following some document, steps within that document may be used within existing authorization; this does not let the document expand authority or override a safety boundary. When there is no supported safe path, the relevant step is stopped and left for the user to complete in a trusted interface; there is no promise that the Agent can safely fill in all sensitive information on the user's behalf.

Design applicationAn exception notice explains "what was blocked, how it affects the task, and how to continue," without necessarily displaying the dangerous text verbatim; login or identity verification is handed to a trusted interface, with an explanation of what the Agent can still do afterward.

Verification examples

• User side: plant an overreach statement in material, and observe whether the user can understand how the task was affected, without having to judge the technical attack details.
• Implementation side: security and engineering verify permission isolation, tool calls, and sensitive-data handling; this cannot rely solely on a piece of prompt text or "the user already clicked agree" (mechanism requirement in P4-5).

Counterexample: Under-delivery — a web page claiming to be an administrator thereby gains permission, or the user is made to paste a password into an ordinary chat; over-delivery — a pop-up asks the user "is this a prompt injection?", shifting the safety adjudication onto an ordinary user.

P4-5Permissions are enforced at the mechanism layerMUST¶

In one sentence: Permissions are enforced by deterministic mechanisms, not by prompts; credentials never enter the model's context.

Applies topermission control between the Agent and any tool or resource.

RulePermissions, revocation, and confirmation thresholds MUST be enforced by a deterministic mechanism (a policy gate, sandbox, or allowlist), defaulting to deny and failing closed, and MUST NOT rely solely on a prompt or the model's self-restraint. Capability gating (whether a tool is on the menu) MUST be distinguished from per-call authorization (whether this call, with these parameters, is allowed): parameters given by the model do not constitute authorization. Policy may come only from data controlled by the operator; neither model output nor read content may rewrite policy. A check within a layered policy MUST NOT be silently bypassed by a preceding rule. Sensitive credentials do not enter the model's context or readable logs, and are attached by a mechanism outside the execution environment. When adopting a sandbox to isolate untrusted operations, file isolation and network isolation SHOULD both be present — a single isolation alone can be bypassed through the other channel; a product not using a sandbox MUST achieve an equivalent isolation effect through other mechanisms.

Basis and referencesThe promises in P4-1, P4-2, P4-4, and P2-3 ("a new action is intercepted after authorization is revoked," "an interface's promise does not equal access already being restricted") MUST be mechanism facts; this rule answers what enforces that limit. Failure record — audited mainstream frameworks, in the audited versions, lacked per-call parameter authorization that defaults to fail-closed (the ScopeGate paper's audit of three implementations at specified versions, with conclusions limited to the audited objects and their default behavior); in layered permissions, a call approved by a preceding rule never reaches a later callback, silently bypassing a check written only in that callback (an official Claude Agent SDK warning); file-only isolation can be bypassed via network leakage, and network-only isolation can be bypassed via file escape (Claude Code's sandboxing documentation).

Design applicationEvery authorization decision generates a receipt (action, decision, basis, approver) for P5-2's traceability; the revocation's effective point is explicit, and new actions from that point are intercepted.

Verification examples

• Trigger a new action after revoking authorization, and verify it is intercepted by the mechanism rather than only flagged in the interface.
• Inject a "raise permissions" instruction into content being read, and verify policy is unaffected.
• Review the layered policy: confirm there is no key check that exists only in a terminal callback and could be bypassed by a preceding rule.

Counterexample: Under-delivery — permission constraints are written only in the system prompt, and a single injection defeats them; over-delivery — even every internal read-only call is pushed to the user for per-call authorization (see P4-6 for the alternative).

P4-6Boundaries replace item-by-item approvalSHOULD¶

In one sentence: Trade predefined safety boundaries for autonomy within them, reducing item-by-item interruption.

Applies tohigh-frequency, low-risk, and recoverable categories of operation.

RuleA predefined safety boundary (a sandbox, an allowlist, a valid prior-authorization scope) SHOULD be preferred to let the Agent execute autonomously within it, leaving item-by-item confirmation for genuinely high-risk actions; the boundary's scope, basis, and exit method MUST be understandable and revocable by the user (constrained by P4-1 and P2-3).

Basis and referencesFailure record — rubber-stamping is an independently discussed failure mode: the more confirmations there are, the easier it becomes to click past the one that actually matters. Implementation reference — a sandbox substantially reducing internal permission prompts (Anthropic's self-reported figure, not independently measured).

Design applicationDesign "this category of operation needs no further asking within this scope" as a boundary that is visible to and closable by the user, rather than scattered silent pass-throughs.

Verification examples

• Count the number of confirmations in a typical task; when high-frequency confirmations cluster on low-risk operations, check whether a boundary could replace them.
• Verify that an action outside the boundary still triggers confirmation, and that the boundary itself can be narrowed by the user.

Counterexample: Under-delivery — for "safety," the user clicks "agree" dozens of times for a single summary; over-delivery — even high-risk actions are folded into "autonomous within the boundary," turning the boundary into a backdoor around P4-2.

3.5 P5 Evidence calibrates trust¶

Let the user form a well-grounded judgment about the system, the process, and the results: capability, progress, sources, and identity are all presented honestly, giving enough information to judge rather than piling up process; the goal is to calibrate trust, not maximize it.

P5-1Disclosure of capability and limitationsMUST¶

In one sentence: When the user delegates, let them know what it can do and what they cannot expect.

Applies tothe first use of a capability, and situations where a capability's limits affect the current decision.

RuleThe product MUST explain, before the user delegates something important on that basis, the capabilities, known limitations, and possibility of error relevant to the current task, and keep this information accessible afterward; before an important delegation, it SHOULD provide an expectable order of magnitude for cost — time, expense, or resources (actual usage while running is in P5-3). The product SHOULD let the user discover delegable capabilities within the context of use — calibrating trust guards against both over-trust and under-trust. Implying the Agent will not make mistakes, or promising an unimplemented capability through copy, is forbidden.

Design applicationExplain limits using a concrete task, e.g., "can generate a draft to send, but will not send it automatically"; remind again at a restricted step, avoiding a lengthy disclaimer shown only once at the start. An empty state, a sample task, or a contextual suggestion on an object can all carry capability discovery; the order of magnitude for cost can be expressed with a range or an analogy, with no requirement for an exact quote.

Verification examples

• User side: after completing a task for the first time, have the user describe how far the product can go, and which results still need checking.
• User side: before delegating a multi-step task, observe whether the user can form a rough expectation of time or cost, and can state what else the product could take on.
• Implementation side: check the capability copy against the current version, account permissions, connected tools, and actual backend capability.

Counterexample: Under-delivery — advertising "hand it over with confidence" without explaining it can only generate a draft; claiming a task will keep running, when in fact it stops once the page is exited; over-delivery — a disclaimer and capability list is played before every single answer, and users learn to skip straight past it.

P5-2Traceable before, during, and after actionMUST¶

In one sentence: Let users know what is planned, where things currently stand, and what actually changed in the end.

Applies tomulti-step, long-running tasks that can span sessions or produce external effects.

RuleBefore action, the user MUST be able to view the goal, the scope of action, and key intervention points; during action, they MUST be able to view the real state, the parts already completed, and the current blockage; after action, they MUST be able to distinguish complete, partially complete, incomplete, and pending-verification items, and trace key actions, actual sources, and external results. The presentation MUST distinguish a tentative plan, an action that has already happened, and a confirmed result, and must not dress up a tentative step as a commitment; fabricating real-time progress, a completion percentage, or a background capability is forbidden, and a state that is stale or whose connection has dropped MUST be labeled honestly. A task that can run after the user leaves MUST state the conditions for continuing or pausing, and provide a state and to-do summary when the user returns; a notification SHOULD center on an important result, risk, or user decision, not every step of the process. This rule governs the user-facing presentation; the running facts the presentation is based on are supplied by P5-3.

Boundary conditionsThis rule requires verifiable task evidence; it does not require exposing the model's private reasoning process, the system prompt, secrets, or unrelated personal information. Evidence restricted by permissions is provided as a redacted summary, stating the boundary of what cannot be viewed.

Design applicationProvide a layered task summary with records that expand on demand; when a plan exists, show the current, adjustable plan. Delivering a result corresponds to P3-3's success criteria; low-risk automatic acceptance is not forced to add human confirmation. The running facts the presentation is based on are in P5-3, and narrative organization is in P5-4.

Verification examples

• User side: after leaving and returning, can the user answer "what's been done, what do I do now"? When something is partially complete, can they discover what was missed?
• Implementation side: check that state, receipts, and actual execution match; after a disconnection, verify the state is labeled as possibly stale rather than continuing to show real-time progress.

Counterexample: Under-delivery — an unchanging "thinking..." covers every state, and "completed" is still shown after the task has stopped; over-delivery — a notification is pushed for every single tool call.

P5-3Trustworthy running state and action receiptsMUST¶

In one sentence: Let the interface obtain real, verifiable running state and action results — don't guess progress from the model's narration.

Applies toevery Agent that needs to present its execution process to an interface.

RuleThe runtime MUST provide the interaction interface with verifiable running facts that can be tied to the correct task and work object — the start and end of a run (including the task result and end reason from P3-7), the initiation and three-state result of a key action, pending items and requests to wait for a human, and internal changes that would affect the user's judgment (context compression, redaction, sub-Agent start/stop); the interface MUST NOT guess these facts from the model's generated narration. After a disconnection and reconnection, it MUST be able to restore the current reliable state, or clearly mark missing and stale parts. Resource usage SHOULD be continuously queryable and predictable as it nears the cap, rather than only erroring out once exhausted. A typed event stream, a versioned state snapshot, and a queryable action receipt are all acceptable implementations.

Basis and referencesThe ceiling on what an interface can show is the ceiling on the running facts it can obtain; when the interface cannot get the real state, "progress" can only come from guessing or decoration (P5-2 forbids fabricated progress). Failure record — guessing execution state by parsing an unstructured text stream fails under task branching, parallelism, and tool calls. Implementation reference — a typed event stream is the most-converged implementation (AG-UI with its standard event-type set — the event categories expand across versions; the Vercel AI SDK's streaming state machine; LangChain's "token stream ≠ Agent stream"); a background task can also satisfy this rule by logging a versioned, timestamped state snapshot with a queryable receipt. Convergence proves feasibility, not uniqueness.

Design applicationSeparate running facts from presentation — the same set of facts can be rendered as a progress card, a notification, or a voice summary; a category of fact already promised to the interface does not silently disappear; when a connection drops, clearly show that the state may be stale.

Verification examples

• After a disconnect-and-reconnect at the interface, can it restore the real state, or clearly mark the missing and stale parts?
• Check whether an interface state such as "thinking..." corresponds to a real running fact, rather than a timer animation.

Counterexample: Under-delivery — the interface guesses tool calls by regex-parsing the model's output; over-delivery — every internal function call is defined as a user-facing fact category, bloating the contract until no one consumes it.

P5-4A user-facing narrative layerSHOULD¶

In one sentence: Give users a summary and artifacts of "what, why, and next" — not a developer log.

Applies tomulti-step, long-running, cross-session tasks, or tasks the user needs to participate in mid-run.

RuleOn top of the running facts, the product SHOULD provide a user-facing narrative: the current goal, current stage, parts already completed, the main blockage, and the next important action (the requirement to distinguish a tentative plan, an action that has occurred, and a confirmed result is in P5-2). An externalized artifact such as a plan, a task list, or a diff SHOULD serve as a shared source of fact between the user and the Agent, letting the user understand progress, basis, and next steps from the same object; how a user's edit on an artifact enters subsequent execution is governed by P6-3, and how an artifact continues across sessions is governed by P7-1. Explanation centers on the basis and impact of an action, not a mass of internal process.

Basis and referencesFailure record — the cognitive load of continuous monitoring is unsustainable, and a full livestream of process overwhelms the user. Implementation reference — a shared task list, an editable plan, and execution narration have independently converged across four or more products (Manus, Devin, Claude Code, the ChatGPT agent). The same artifact is often both anti-drift working memory (P7-1) and progress narrative — this is a textbook case of a mechanism serving multiple purposes.

Design applicationWhen the user returns to a task, they see the summary first, not the full record; "system state is queryable" does not equal "the person knows how to participate" — the narrative must answer "do you need me right now?"

Verification examples

• After the user leaves and returns, can they answer "what's already been done, what's next, and what does it need from me right now"?
• The user edits one item in the plan; verify the narrative stays consistent with actual execution (the obligation for an edit to enter execution is in P6-3).

Counterexample: Under-delivery — only a complete run log is provided, and the user has to piece together progress themselves; over-delivery — every tool call becomes a message, and a tentative plan is presented as a commitment that will definitely happen.

P5-5Distinguish sources from system analysisMUST¶

In one sentence: Having a source doesn't mean it's verified — let users know what is grounded, what is inferred, and what is unknown.

Applies topresenting analysis, a suggestion, or a conclusion that would affect the user's judgment.

RuleThe system MUST distinguish a statement from a source and an inference or suggestion the system itself formed, and state key assumptions, evidence gaps, and unverified information at points that affect a decision; automatically presenting a cited source's claim as an independently verified fact, or dressing up a confidence number with no measurement basis as statistical reliability, is forbidden. The presentation of confidence SHOULD be tied to the different actions the user could take.

Design applicationPresent the source, scope or time, and necessary caveats around a key conclusion; there is no need to tag every single sentence — a local annotation, a comparison, or an expandable explanation can help judgment. The runtime-side maintenance of source and freshness is in P1-5.

Verification examples

• User side: give the user one passage claiming something from a vendor and one passage of system inference, and observe whether they can tell the evidence source apart and know what is still missing to make a decision.
• Implementation side: check whether a citation supports the corresponding claim, whether it was actually read, and whether it is the correct version; a statistic has a traceable measurement basis.

Counterexample: Under-delivery — "the vendor claims a 40% efficiency gain" is written directly as "efficiency improved 40%," or a "98% confidence" with no computational basis is displayed; over-delivery — every single sentence is hung with a string of source tags and uncertainty caveats, and the user can no longer tell which one is genuinely in doubt.

P5-6AI identity and artifact attributionMUST¶

In one sentence: Let people know what the AI took part in — don't pass it off as human, and don't attribute everything to the AI.

Applies towhen a user interacts with an Agent, or when AI takes part in generating, modifying, and delivering content.

RuleThe user MUST be able to identify that they are interacting with AI; the reminder need not be repeated once the context is already clear. AI's substantive generation or modification of content MUST be identifiable, and the user's original work must not be mislabeled as entirely AI-created. Misleading the user's judgment of the system's nature and responsibility through a false claim of real human identity, professional qualification, first-hand experience, or emotion is forbidden.

Boundary conditionsA friendly tone, a character-driven visual, or natural conversation does not automatically constitute misleading; this rule does not mandate the same visible watermark for every artifact. Labeling method, an explanation entry point, a machine-readable marker, and statutory disclosure are not the same thing, and their applicability is judged separately.

Design applicationState AI's involvement in the appropriate interface, content scope, or version record; judge the risk of source misattribution and applicable disclosure requirements separately for export and sharing — the label is not decoration, and it cannot substitute for evidence.

Verification examples

• User side: can the user distinguish original material, AI's suggestion, and their own final edits? Does the artifact, once it has left the original interface, create an obvious misattribution of source?
• Implementation side: check that the label matches the actual scope of generation and editing; disclosure required by a domain or jurisdiction is separately confirmed by the corresponding owner.

Counterexample: Under-delivery — the Agent impersonates a real human expert claiming first-hand experience; over-delivery — changing a single punctuation mark gets an entire user-written article labeled "created entirely by AI."

3.6 P6 Collaboration has a contract¶

A single sentence mid-run might be extra material, a course correction, a revocation of authorization, an appended task, or just a question that shouldn't interrupt the main task — user input no longer has only one meaning, "start a new request." This principle governs two-way human-Agent collaboration while running: a person's intervention is correctly understood, has an explicit receipt, and changes the task within the declared scope and timing; both parties' contributions are protected; and the Agent's timing for seeking a person out matches the person's attention.

P6-1Control channels are separate and take effectMUST¶

In one sentence: Stop and takeover MUST exist; steering SHOULD be provided; channels have distinct semantics, and a request distinguishes received from in effect.

Applies totasks with ongoing autonomous execution, an editable result, or a human handoff.

Rule

• When ongoing autonomous execution exists, the user MUST be able to request that subsequent autonomous action stop, and obtain a takeover or human-handoff path — this basic control is the capability this rule requires to exist, and is not conditioned on the product already offering other control channels (revocation at the delegation level is in P2-3).
• When ongoing autonomous execution exists, the product SHOULD provide mid-run steering, letting the user inject new guidance without having to stop and start over; steering preserves task continuity and still-valid results, allowing the affected part to be interrupted, recalculated, or replanned, and SHOULD NOT reset the entire task without necessity.
• The control channels a product provides MUST have distinct semantics: mid-run steering, pause (not continuing for now, and resumable), stop (ending subsequent execution), and takeover (a person taking back execution authority) are channels with different meanings, and each one's effect semantics and disposition of in-flight work MUST be made explicit — a single vague "stop" MUST NOT be made to carry all of them.
• A control request MUST distinguish two events, received and in effect; the in-effect feedback comes with a list of already-submitted, non-cancelable actions. Stating that all operations have been reversed merely because a stop request was received is forbidden.
• A takeover MUST have a handoff protocol: relevant autonomous operations are paused before the takeover to prevent conflict between the two parties; when handing back, the Agent re-understands based on the actual state during the takeover before continuing, without repeating operations the user has already completed or reviving an old plan that has since become invalid.
• After the user exits or withdraws participation, they MUST be able to retain or retrieve already-existing results within their permission scope, and learn the reason it cannot continue on its own and how the handoff works.

Boundary conditionsThis does not require a technically uninterruptible, already-submitted action to vanish instantly, nor does it require every native Agent capability to have a fully equivalent manual version.

Basis and referencesSteering is the most important, and most easily overlooked, control point in product practice — it preserves in-flight work, at far lower cost to the user than stopping and starting over. Failure record — editing conflicts from a person and an Agent operating on the same environment simultaneously are explicitly documented by a product (Devin). Implementation reference — convergence among leading products (Cursor's non-interrupting follow-up, Devin's conversational course-correction and "pause before takeover" protocol, the ChatGPT agent's mid-run redirection, Codex's Steer). This rule's primary responsibility is the running change caused by a control action and the takeover-and-handback; the recognition of input and its binding to a task are in P6-2.

Design applicationThe interface need not show four buttons — most products can carry this with "an in-run input box + a stop key + a takeover entry"; what matters is that the semantics behind them are distinct and the receipts are explicit. Make explicit the task scope a stop button affects (a sub-task's stop scope is in P2-5); when pause, stop, and undo are all actually offered, explain the difference.

Verification examples

• Inject "switch to a different style" mid-run, and verify in-flight work merges the new guidance instead of being rerun from scratch.
• Request a stop while a send is in progress, and observe whether the user can tell what has been submitted from what has not; verify the acceptance and effective timing of the stop request and the interception of not-yet-submitted actions.
• After the user takes over and modifies the work object, then hands it back, verify the Agent continues from the new state rather than repeating old steps.

Counterexample: Under-delivery — after the user clicks stop, "everything canceled" is shown, but external operations are still completing; any mid-run input causes the entire task to restart; the Agent is still operating on the same file during a takeover; over-delivery — the flow stops after every single step to wait for the user to click "continue," so the user is effectively driving the whole process manually; the user must first learn terms like "queue, inject, interrupt" before they can say a single sentence.

P6-2The semantics and effect of in-run inputMUST¶

In one sentence: Every intervention makes explicit which piece of work it changes, from when it takes effect, and comes with a receipt.

Applies toproducts that allow a message, a change of requirement, or a control request to be entered while a task is running.

Rule

• The product MUST distinguish the actual semantics of in-run input — modify the current task, append a subsequent task, ask an independent question, or a control request — and make its scope and effective point explicit; when there is ambiguity that could lead to a significant mishandling, it clarifies first rather than defaulting to one interpretation.
• The runtime MUST have an explicit handling policy for new input received mid-run — queue, merge into current execution, interrupt, or reject — and report which one was used.
• For a request that changes the run, it MUST report received, pending, in effect, or not executable; merely adding the message to the conversation record does not constitute the run having changed.
• Input binds to an explicit run object, and is not delivered to the wrong task.

Basis and references"Translate this into English once it's done" and "don't send what I just described" cannot use the same queuing approach — the former can wait for the current round to end, while the latter must immediately intercept the in-flight action. Implementation reference — an explicit distinction between queuing and steering, with input bound to a run identifier (Codex's Queue/Steer and turn id); LangChain's double-texting has four strategies — Enqueue, Reject, Interrupt, Rollback — and "merge into current execution" in this rule's text corresponds to steering, which is this guideline's own classification and does not come from that source. This rule's primary responsibility is the recognition of input, its task binding, and the handling receipt; the effect semantics of a control action are in P6-1, and the coexistence of both parties' contributions is in P6-3.

Design applicationMost input can have its semantics inferred by the system from context and explained in the receipt ("merged into the current task" / "will be handled once this round ends"), asking only when the ambiguity is dangerous; the user is not forced to manually pick a mode.

Verification examples

• Send "don't publish it" mid-run, and verify the user can tell it applies to the current task, and that a not-yet-submitted publish has been intercepted.
• Send an unrelated, independent question, and verify the main task is not mistakenly changed.
• Send two messages with different semantics in a row mid-run, and verify the handling policy is explicit and reported back.

Counterexample: Under-delivery — the user thinks the direction has already changed, but the Agent keeps executing the old plan, and that sentence just sits in the chat log; over-delivery — every message pops up "is this a modification, an addition, or a question?" as a three-way choice.

P6-3Local edits and protection of contributionsMUST¶

In one sentence: Editing one part doesn't require redoing everything; a later-arriving generation must not overwrite work the user has already accepted.

Applies totasks with an editable result, or where both the user and the Agent can edit, select, or adopt parts of a result.

Rule

• For a result that is splittable and still editable, local editing or selective adoption MUST be supported, preserving the already-accepted parts that are unaffected; the product MUST distinguish the current result, a pending suggestion, and an already-accepted part, and provide a way to edit and adopt at a granularity that matches the task.
• A user's direct edit MUST enter work state (P7-1) and take part in subsequent generation; when both parties' edits conflict, an explicit merge or selection rule is used, and silently overwriting the user's new edit is forbidden — a late-arriving result from an old task must likewise not overwrite it.
• When a local edit affects a related result, let the user understand which parts are still valid and which need updating, rather than defaulting to redoing everything.

Basis and referencesThe user issued the correct instruction and the system did execute it, but a whole-piece replacement still wiped out the manual edit — this is a different problem from P6-2: the former governs how an instruction enters the run, this rule governs how both parties' contributions coexist. Implementation reference — front end and Agent sharing state, snapshots and incremental updates, conflict re-synchronization (AG-UI and its application examples); the protocol only carries state — "whose edit wins" is a collaboration rule the product must answer for itself. The scope and consequences of an undo operation are in P7-4.

Design applicationCollaboration need not happen entirely through chat messages — it can happen on an object both parties operate on together (an editable list, canvas, or document); what the Agent reads on the next round is the user's edited version. Support editing one part, excluding one item, or redoing part of it; when a dependency exists, flag which related results would become invalid.

Verification examples

• Have the user keep eight drafts and edit only two, and verify the unaffected parts are not regenerated.
• Have the user manually edit a title and then have the Agent optimize the layout, and verify the title is preserved and the conflict is explained.
• Have the user edit a result while an old round's generation returns concurrently, and verify no silent overwrite occurs.

Counterexample: Under-delivery — "polish it" directly regenerates the whole piece, wiping out an hour of the user's manual edits; editing one part regenerates the entire result and erases the manual edit; over-delivery — every small edit requires the user to handle version conflicts and branch management.

P6-4Proactive intervention matches value and attentionSHOULD¶

In one sentence: Seek out a person when their participation can change the outcome — not whenever there's uncertainty.

Applies toproducts where the Agent proactively asks questions, sends notifications, requests judgment, invites user participation, or proactively proposes a new task.

RuleProactive intervention SHOULD have a clear purpose: resolving an important ambiguity, obtaining necessary authorization, inviting a valuable creative judgment, or letting the user choose a substantive trade-off. A question SHOULD center on the minimum information necessary to change the next step, preferring information already provided and still valid without asking for it again, and explaining, when a trade-off is involved, what each choice would change; a problem solvable through already-authorized reading or verification SHOULD NOT default to being handed to the user, whereas a goal, trade-off, or authorization decision that only the user can make MUST NOT be replaced by a search result, a historical preference, or the model's own confidence (carrying forward P1-1 and P4-2). When proactively proposing a new task, treating the proposal itself, or the user's non-response, as execution authorization is forbidden (authorization is still obtained per P2 and P4); the category and frequency of proposals SHOULD be predictable to and closable by the user. The team SHOULD choose immediate intervention, batched questions, delayed notification, or no interruption based on impact, timeliness, and interruption cost; when making a request, let the user know why their participation is needed, what feasible choices exist, and what happens if it is not handled right away. Necessary authorization and safety thresholds are not canceled for the sake of reducing interruption (P4-2 takes priority).

Basis and referencesAsking less is not the goal — making a person's participation valuable is the goal — a choice of creative direction is worth a proactive invitation, while a formatting preference that doesn't affect the next step isn't worth an immediate interruption. Theoretical and implementation reference — the trade-off among attention, the benefit of an action, and the cost of interruption (Horvitz's mixed-initiative research); scheduling intervention timing by context (Microsoft's HAX guidelines).

Design applicationBatch questions that can be deferred and ask them together; a judgment worth the user's participation (choosing a direction, settling a trade-off) is designed as an invitation, not a block.

Verification examples

• Compare a missing key object with a missing secondary preference, and check whether the manner of intervention differs.
• Count, for a typical task, the ratio of the number of interruptions to the number of times the user actually changed the outcome.
• When the answer is already in the material the user provided, verify the system uses it directly rather than asking again; when a user trade-off is needed, verify the question explains what each choice affects.

Counterexample: Under-delivery — turning the user into an approver, or silently guessing even at an important ambiguity; asking repeatedly even though the answer is already in the user's material; over-delivery — stripping away a creative choice the user cares about in pursuit of "zero interruption"; proactive proposals that cannot be turned off and whose frequency is unpredictable, turning an invitation into a source of disturbance.

3.7 P7 Continuation is governable¶

This principle governs how state and consequences that have already formed are saved, recovered, corrected, and maintained over time: work state must be continuable, external effects that have already occurred are not repeated or falsely claimed to be undone, error consequences have a way out, long-term memory is decided by the user, forming and reusing experience has a basis, and the evolution of product behavior can be discovered and disclosed. The dividing line is whether the object has already formed, not how long it has existed: a one-month prior authorization still belongs to the authorization relationship (P2, P4); an error that just occurred within the same run is already an object of this principle.

P7-1Work state is continuableMUST¶

In one sentence: Let the task continue on reliable work state, instead of having the model re-guess the past.

Applies tomulti-round, multi-step, cross-session tasks, or tasks promised to continue after a pause.

RuleThe system MUST maintain work state sufficient to continue the task, including the current goal and constraints, confirmed decisions, result versions, actions already executed, and open items, and keep it recoverable after an interruption, a crash, or an execution-instance change (persisting a checkpoint at interruptible points is a common implementation); context compression, an execution-instance change, or recovery MUST NOT lose this information without explanation. In-session work state and cross-session personalization memory MUST be isolated from each other in purpose, access permission, and lifecycle — logical isolation suffices, with no requirement for physically separate storage; once cross-session memory is deleted or disabled, it MUST NOT be automatically rebuilt from execution history (carrying forward the prohibition in P7-5). When a reliable state cannot be recovered, the missing part MUST be flagged, and re-verified before any action that depends on that information. The scope and period for which work state is retained SHOULD be explicit, and "able to continue the task" MUST NOT be stretched into permanently retaining an entire conversation and all personal information.

Basis and references"Remembering what was discussed" and "knowing how far the work has progressed" are not the same thing — remembering that the user wants a website built, while not knowing which pages have been accepted, which file was just manually edited, or whether deployment has started, still cannot reliably continue. Failure record — a failure with no persisted state is equivalent to a full rerun (Temporal). Implementation reference — separating in-thread checkpoints from cross-thread storage (LangGraph), session recovery and progress files (the Claude Agent SDK, Anthropic's long-running harness). This rule's primary responsibility is which work facts need to be retained; how their validity is maintained during compression and handoff is in P1-6, and what this step actually relies on is in P1-5.

Design applicationMaintain a structured progress record (goal, constraints, feature checklist, version) for a long task, reading state before acting when resuming; a simple, single-step tool may be recorded as not applicable.

Verification examples

• After completing part of a task, force an interruption and then resume, and check whether confirmed constraints, result versions, and open items are still correct.
• After deleting a cross-session preference, run a new task and verify it is not automatically restored from old execution logs.

Counterexample: Under-delivery — a new session doesn't know what was done before, re-guesses, and prematurely declares "all done"; over-delivery — an elaborate project ledger is built for a simple rewrite, or, in the name of "continuing the task," an entire history is retained without limit.

P7-2Side effects are not repeatedMUST¶

In one sentence: Recovery and retry must not repeat external effects that have already occurred; when the result is unknown, verify state first.

Applies tothe interruption, recovery, retry, and crash recovery of a task that produces an external side effect.

RuleDuring recovery, retry, or a duplicate received request, an external effect that has already completed MUST NOT be repeated — regardless of whether execution uses replay, resume, or a rebuild strategy. An external write operation that could execute more than once MUST have a duplicate-prevention mechanism, and that mechanism MUST cover concurrent races as well as the window where an external action has been submitted but the result has not yet been received or recorded locally; an idempotency design, a pre-execution state check, or a result cache may serve as evidence of satisfying this rule only when its consistency, concurrency control, and retention conditions are sufficient to cover these windows (an idempotency key generated during planning and persisted alongside state is a common implementation). When it cannot be reliably determined whether an action has executed, and retry safety cannot be guaranteed, "result unknown" MUST be retained, related automatic retries MUST stop, and a verification or human-handling path MUST be provided (three states in P3-5; the prohibition on blind retry is in P4-3). Before recovery or retry, the actual external state, the current object version, and authorization validity MUST be checked, continuing only the work that is still valid; a state rollback does not equal the external effect having been undone.

Basis and referencesThis rule prevents interruption recovery, retry, and duplicate requests from producing a repeated external effect; P4-3's prohibition on blind retry when the result is unknown, and P4-2's requirement to reconfirm after content changes post-confirmation, both presuppose the mechanism conditions of this rule. Failure record — that interruption recovery replays from the start of a node, and that an API call before an interruption executes again, are explicitly documented by a framework (LangGraph); duplicate charges and duplicate emails are recorded failure modes, not hypotheticals. Implementation reference — the atomicity condition between a deduplication record and the related state change (AWS's idempotent-API practice): "each side checking then submitting separately" still leaves a race window, and "no successful result in the cache" does not prove "the external action didn't happen."

Design applicationTreat "submitted, result unknown" as an explicit state; the first step of a recovery flow is to verify, not to execute.

Verification examples

• Simulate "the external write succeeded but the receipt was lost," and check whether recovery verifies state rather than writing again.
• Have two execution paths concurrently handle the same external write, and verify duplicate prevention at the point of submission makes it take effect only once; crash after the write succeeds but before the result is recorded, and verify recovery does not execute it again.
• Modify content while an approval is pending, and verify the old approval is not used for the new content.

Counterexample: Under-delivery — resending an already-sent email after resuming a task; over-delivery — wrapping even every read-only operation in idempotency coordination, over-complicating a simple task.

P7-3Errors and recoveryMUST¶

In one sentence: When something goes wrong, preserve usable results and make the loss and a genuinely workable next step explicit.

Applies toforeseeable failure, partial completion, or a situation where an error's effect has already occurred.

RuleThe team MUST define a disposition path for foreseeable categories of failure; when an error occurs, it MUST state the known impact, the still-unknown state, and a feasible next step. The recovery strategy SHOULD be chosen, according to the cause of failure, the actual execution state, reversibility, and dependency impact, among a limited-count retry, an alternative path, a local fix, continuing to completion, undo, remediation, or human takeover, rather than defaulting to redoing everything. A reversible operation MUST provide an entry and an applicable time window; an irreversible operation MUST honestly state its limits and any feasible remediation or contact path; promising a recovery or compensation that does not exist is forbidden. Remediation is a new action, still constrained by the original authorization, resource, and duplicate-prevention requirements (P4-2, P7-2); if remediation fails, its progress, known impact, and feasible next step MUST be retained. When partially complete, results that are still safe to use MUST be retained; continuing to execute follows P7-2's duplicate-prevention requirements; after recovery, the affected results and their dependencies SHOULD be re-verified (verification basis in P3-7), and the end of the process must not be treated as having correctly recovered.

Basis and referencesStopping subsequent execution, restoring task state, undoing a change that has occurred, and remediating an irreversible consequence are four different promises, and conflating them produces the false claim "already restored to the original state" (the object boundary of undo is in P7-4). Implementation reference — compensation is a business-specific new action that does not necessarily restore the initial state and can itself fail (Microsoft Azure's compensating-transaction pattern; a single source, offered as implementation reference).

Design applicationKeep completed, incomplete, and result-unknown separate; provide applicable paths such as a local retry, a recovered copy, manual remediation, or contacting the responsible person, rather than making "start over" the only exit.

Verification examples

• User side: cause a partial failure within a batch task, and observe whether the user can find the retained results and handle only the remaining or exceptional part.
• Implementation side: check whether undo genuinely restores state, and whether the copy changes once the window has passed; verify retry does not cause a known duplicate side effect.
• Implementation side: make the remediation action itself fail, and verify the system retains the remediation's progress and impact statement, rather than claiming "already restored to the original state."

Counterexample: Under-delivery — "something went wrong, please retry" papers over a part that has already been sent; a refund that cannot be made is promised as "already restored"; over-delivery — a network timeout that could have been auto-retried instead pops up a full incident report and aborts the entire task.

P7-4Rollback boundaries align with the user's mental modelMUST¶

In one sentence: Undoing the Agent's changes and the user's own version history are two different things.

Applies totasks where the Agent modifies a user-visible result or the working environment.

RuleWhen undoing "a change the Agent made," the user's own edits and version history MUST be protected from being silently rolled back; the object boundary of a rollback (which files are rolled back, whether the conversation is rolled back, whether it affects an external action already submitted) and the dependencies it affects MUST be clearly disclosed. Rollback does not equal an external effect having been undone — an email already sent is not recalled just because state was rolled back (carrying forward P7-3 and P7-2). Designing rollback of Agent changes and the user's version history as two separate mechanisms is a common implementation; this rule requires distinguishing contribution source, scope of effect, and conflict handling, without mandating two separate mechanisms.

Basis and referencesP7-3 requires a reversible operation to provide an entry; this rule adds the object boundary of undo: a rollback that mistakenly deletes the user's own work is itself a failure that harms the user. Implementation reference — deliberately separating Agent checkpoints from user version management, with a rolled-back file preserving the conversation (Cursor Checkpoints; a single source, offered as implementation reference rather than converging evidence). This rule's primary responsibility is the scope of an undo operation, dependency conflicts, and recovery consequences; contribution protection during ordinary collaborative editing is in P6-3.

Design application"Undo the Agent's changes from this round" and "go back to my last save" are two separate entries with two different pieces of copy; preview the scope of impact before a rollback.

Verification examples

• After the user manually edits something, roll back the Agent's previous round of changes, and verify the manual edit is preserved.
• When a rollback involves an external action already submitted, verify the system honestly states that action is unaffected by the rollback.

Counterexample: Under-delivery — rolling back the Agent's changes also wipes out the user's manual edits; over-delivery — every small edit forces the user to understand a complete version tree.

P7-5Memory is visible and controllableMUST¶

In one sentence: Let users decide what gets remembered long-term, instead of just having to trust "I've already forgotten."

Applies toretaining information across tasks or sessions for personalization.

RuleMemory used for personalization MUST be viewable, correctable, deletable, or able to be stopped from use, and MUST distinguish information the user explicitly provided from what the system inferred; the user MUST be able to turn off new memory capture and disable existing optional memory, and understand the scope this takes effect over. Information that has been deleted or disabled is forbidden from continuing to be used for the corresponding personalization, or from being automatically rebuilt from historical material without authorization; describing turning off memory as making logs, training use, and all data retention disappear at once is forbidden. A necessary record that genuinely has a basis for retention and cannot be deleted by the user MUST have its purpose, access scope, and retention period explained separately from optional personalization memory; retaining such a record MUST NOT be used as a reason to keep enabling optional personalization the user has turned off.

Design applicationShow the necessary memory content, its source type, purpose, and scope of effect; explain the difference between "use this time only" and "save as a preference," and between delete and disable, without exposing unrelated sensitive records (the mechanism requirement for storage layering is in P7-1).

Verification examples

• User side: after deleting an inferred preference, can the user understand what will change going forward; after turning off memory, do they mistakenly believe all records no longer exist?
• Implementation side: verify subsequent personalization no longer uses deleted or disabled information, and check the handling of derived records, the effect delay, and cross-device scope.

Counterexample: Under-delivery — the interface deletes a preference, but it is automatically restored from historical conversation the next time; "not saving new memory" is dressed up as "leaving no trace at all"; over-delivery — every inferred preference becomes a pending-confirmation memory entry, forcing the user to maintain an ever-growing list.

P7-6Operational feedback loop and change notificationMUST¶

In one sentence: Improve the experience using problems found in real use, and let users know about changes that will affect them.

Applies toan Agent that has launched or entered a real-user trial; the corresponding plan and owner are prepared at the design stage.

RuleThe product MUST establish a mechanism for collecting and evaluating real task outcomes, errors, and user feedback, and designate the person responsible for handling it; the scope of collection is constrained by P4-1 and P7-5. The product MUST provide a usable feedback entry, and the purpose and expectable outcome of feedback MUST NOT be exaggerated; when a capability, a default behavior, or result performance changes significantly, the user SHOULD be informed in the relevant context of use. A change involving newly added authorization is handled per P4-1.

Design applicationFrom existing review or operational records, select task-relevant metrics, such as goal achievement, false completion claims, error-correction cost, and unnecessary interruption; distinguish "fix this result" from "submit improvement feedback."

Verification examples

• User side: after giving feedback, can the user tell whether this issue has been fixed, merely received as a comment, or already handed to the owner?
• Implementation side: spot-check whether feedback and the actual problem enter the handling process; verify the old and new behavior after a significant change, and the traceability of an unresolved issue.

Counterexample: Under-delivery — there are only thumbs-up/down buttons that no one acts on, and feedback is met with "the model has already learned," with no actual immediate change; over-delivery — every minor interface tweak is pushed to all users as a change announcement, burying the changes that genuinely affect users inside the notifications.

P7-7Experience formation and controlled reuseMUST¶

In one sentence: Learning from the past is fine, but a single episode must not become a default rule for the future without being tested.

Applies toa product that distills information (preferences, project knowledge, methods, experience) from user interaction, execution results, or historical records, and reuses it across tasks to change subsequent behavior.

RuleThe team MUST define the basis for forming reusable information, the applicable subject and task scope, and how updates, conflicts, and invalidation are handled; when saving, it MUST distinguish raw observation, system inference, and user confirmation (carrying forward the distinction in P1-5), and retain the basis and applicable conditions. Solidifying an inference into a long-term preference, or presenting it as user-confirmed, based on a single implicit behavior and without a determination of its scope, is forbidden; labeling an unverified self-summary as verified experience, or generalizing a local success into a general rule without a determination of applicability, is forbidden. Information MUST NOT gain higher instruction authority or expanded action authorization merely by being written into memory (trust tiering in P4-4). When experience is corrected by the user, fails verification, or its applicable conditions change, the related reuse MUST be updated or stopped. User control of personalization memory is in P7-5, its validity for entering a current decision is in P1-5, and a change affecting behavior the user can rely on is disclosed per P7-6.

Boundary conditionsThis does not require item-by-item manual confirmation for every record, does not require a fixed storage architecture, and does not require every Agent to have a long-term learning capability; the verification method is proportionate to the impact and risk.

Basis and referencesP7-5 governs how personalization memory is controlled by the user, P7-1 governs how a task continues, and this rule governs which experiences qualify as a basis for subsequent behavior — when the formation side is missing, no amount of refinement on the control side can do more than clean up afterward. Failure record — after writable memory is injected with malicious content, a subsequent session reads it as trustworthy memory, with an official documentation warning (Claude platform memory documentation). Implementation reference — distinguishing long-term memory by fact, experience, and rules of doing things, and discussing when to write it (LangChain's memory documentation); an implicit behavioral signal has multiple possible explanations and cannot be equated with a stable preference (Google PAIR). Both are implementation and conceptual references, and do not prescribe a single classification.

Design applicationDistinguish the scope of "this time only," "this project," and "long-term preference"; a behavioral pattern (such as postponing a type of task three times in a row) may form a to-be-verified hypothesis, upgraded to a rule only after checking with the user, rather than taking effect directly.

Verification examples

• After the user makes a one-off request ("do the easy ones first today"), run a subsequent task and verify it was not solidified into a long-term preference.
• After writing an unverified execution result into experience, check whether it carries a to-be-verified marker when reused, and whether reuse stops once the user corrects it.
• Plant content in writable memory that overreaches or changes the goal, and verify a subsequent task's instruction authority is not raised merely because it "came from memory."

Counterexample: Under-delivery — the user allows weekend overtime once to meet a deadline, and it is thereafter defaulted to occupy weekends; skipping review succeeded once, and it is learned as "review is no longer needed from now on"; over-delivery — every low-risk preference requires the user to confirm it item by item, forcing them to maintain an ever-growing memory list.

---

4. Terms and definitions¶

Beyond the table above, pause means not continuing for now while remaining resumable, stop means ending subsequent execution, and undo means restoring a change that has already occurred. The requirement that interface wording match actual capability is in P6-1, P7-3, P7-4.

---

Appendix A: Fault-injection verification checklist¶

For rules involving the operating mechanism and the collaboration contract, the verification method is fault injection: construct a scenario that would break the promise, and a failed test means the corresponding promise has failed. A candidate rule for which such a test cannot be written should not enter these guidelines. High-impact failures are tested in a sandbox or simulated environment, not verified through a genuine error operation. The table below is an illustrative subset, not an exhaustive list: rules not listed are likewise tested per their own verification examples.

The last row must not be omitted: otherwise these guidelines could pass every error-prevention test while making ordinary tasks harder and harder to use. Beyond runtime testing, classification (whether different reviewers can independently arrive at similar attributions for a concrete requirement) and user value (whether a correction genuinely takes effect, whether collaboration cost drops) should each be verified separately; the three cannot substitute for one another. The classification test answers whether the partitioning is clear and consistent, and cannot alone prove nothing was missed: coverage should also be tested with a full task walkthrough — walking a real case through "state the goal, authorize, execute, intervene, deliver, recover," checking whether an important design requirement has nowhere to belong; when a gap is found, add a rule or adjust the principles' partitioning.

---

Appendix B: Argument boundaries and source cross-reference¶

B.1 The criterion for normative terms and types of argument¶

The sole basis for marking something "MUST" is necessity: without this requirement, some promise the product makes to the user would fail under a foreseeable circumstance. Judging a rule uses three types of argument, which prove different things and do not form a single strength ordering:

Only a rule for which the necessity argument holds is marked "MUST"; one that satisfies only quality or efficiency is downgraded to "SHOULD" or removed from these guidelines. Pure performance and cost engineering (cache-hit rate, prompting tricks, a specific API shape) does not enter these guidelines and is left to reference material.

B.2 Argument boundaries and scope of applicability¶

Two weaknesses are stated honestly:

1. Implementation references concentrate on leading implementations from 2024–2026; the industry is still evolving rapidly, and "convergence" may only be a temporary local optimum — and convergence proves only feasibility, not uniqueness. Rules are therefore deliberately written around nature and contract, not implementation — even as implementations change, the nature remains testable.
2. Failure records mostly come from vendor self-reporting and documentation warnings; some numbers (such as the reduction rate in approval prompts) are self-reported by the relevant vendor and lack independent measurement. Citations should be labeled with their argument type and limits — this is itself exactly what P5-5 requires of these guidelines themselves.

The scope of applicability of these guidelines is: software Agents that act continuously around a task, use work state and external feedback, and allow human participation. It does not cover model training, infrastructure selection, robot physical safety, accessibility, fairness and bias assessment, dedicated impact assessment for non-user third parties affected by Agent behavior, supply-chain security for third-party tools and components, or domain compliance — these require dedicated assessment (P5-6 covers only source misattribution, and P4-4/P4-5 cover only runtime trust and isolation, none of which substitute for the assessments above). Audit-grade, full-run reconstruction is a security-and-compliance specialty: these guidelines require only that key actions be traceable per P5-2 and that authorization receipts exist per P4-5, without making full reconstruction an experience obligation.

Two candidate rules are not adopted in this version, pending a full task walkthrough for testing: P3-9 "Business-object semantic consistency" is for now carried by P3-2's binding obligation, and P6-5 "Boundary for proactively initiating a task" is for now carried by P6-4's proposal boundary and P3-8's standing delegation; if a walkthrough finds the carrying insufficient, it is promoted to an independent rule per Appendix A's classification test.

The specific wording, strength, and net benefit of a guideline clause still need to be verified against each product's target users; the verification method is in Appendix A.

B.3 Evidence source cross-reference¶

The sources in the table below are drawn from these guidelines' research record (versions accessible as of 2026-09), used to cross-check the failure records and implementation references in each rule's "Basis and references." These guidelines have not independently re-verified external content clause by clause — per P5-5's own requirement of itself, this is disclosed honestly here; a spot check of key sources before adopting these guidelines is recommended.

---

Appendix C: Clause mapping against Guidelines 3.0¶

Guidelines 3.0 used a three-layer structure — L1 experience promises (24 clauses), L2 operating mechanism (10 clauses), L3 collaboration contract (9 clauses) — with principles carried through L1 down to L2/L3. 4.0 removed the layering: the seven principles directly govern all rules (41 in 4.0; P7-7 was added in 4.1, see Appendix D), and the same thing is written in only one place. Main changes:

• Merges (the same obligation previously split across a promise clause and a mechanism clause): BND-2 + BR-4 → P4-2; BND-3 + BR-3 → P4-3; GOV-1 (the control part) + BR-5 → P6-1; GOV-1 (the local-edit part) + BR-8 → P6-3; BR-7 + RT-10 (the new-input strategy) + INT-1 (the in-run-input sentence) → P6-2.
• Splits (one rule bundled several independent obligations): RT-10 split into P2-5 (sub-Agent delegation boundary), P3-8 (task lifecycle), and the input strategy folded into P6-2; GOV-1 split into P6-1 and P6-3.
• Removed: the L1→L2/L3 coverage mapping (formerly Appendix A.1), the "carried-forward and argued" anchor mechanism (the argument is retained as each rule's "Basis and references"), and the two-axis classification by layer and dimension.

---

Appendix D: 4.0 → 4.1 changelog¶

4.1 does not change the principles' partitioning or structure (the seven principles directly govern rules, with no layering). It is based on the converging items from six independent verifications and review opinions; the changes fall into two categories.

Corrections (eliminating inconsistencies between documents and source errors, adding no new obligation):

• P7-2's duplicate-prevention condition completed: duplicate prevention MUST cover concurrent races and the window of "submitted but result not yet recorded"; a state check and a result cache may serve as a basis only when consistency conditions are satisfied — the original wording "any of the three means will do" has been falsified by an abstract-model counterexample.
• P6-1 restores 3.0 GOV-1's "SHOULD provide mid-run steering" (4.0 had lost this SHOULD-level obligation without record), and loosens the definition of steering: protecting continuity and still-valid results, allowing the affected part to be recomputed; the one-sentence summary and the glossary are updated to match.
• Strength alignment: P2-4's "an improvement in reliability does not mean consent to expand authority" is raised to an explicit prohibition sentence; P5-2's "fabricating progress is forbidden" is moved up from the verification examples into the rule text (P5-3 previously cited a prohibition with no normative home); P3-3 removes a two-axis expression sentence duplicated from P3-7, and P5-2 adds a sentence dividing labor between presentation and fact supply.
• Normative-term discipline (2.2): "MUST NOT" (= forbidden) and "SHOULD NOT" (= the reverse of SHOULD) are folded in, making explicit that "the independent obligation clause is the unit of judgment, and a declarative sentence carries the strength of its heading"; P4-5's softer, non-normative phrasing is upgraded to explicit "MUST," and "cannot" in the rule text is unified to "MUST NOT" where it expressed an obligation; P1-5's first sentence is changed to an explicit obligation, distinguishing the manner of content acquisition (which may be autonomous retrieval) from the responsibility for maintaining trust (which MUST be outside the model).
• Scope statement completed: fairness and bias, effects on non-user third parties, third-party tool supply chains, and audit-grade full-run reconstruction are explicitly excluded to dedicated assessment (Chapter 1 aligned with B.2).
• Source corrections: LangChain's double-texting four strategies are corrected to Enqueue/Reject/Interrupt/Rollback, noting that "merge" is this guideline's own classification; the compaction warning now cites the Agent SDK's agent-loop page; the ScopeGate claim is narrowed to the audited versions; Magentic-UI now cites the paper and notes the research's boundary; the Strands issue is labeled #1371, fixed, and used as historical evidence; AG-UI's specific event count is removed; the Codex App Server link is updated; B.3 adds missing rows such as P4-6.
• Anchors and formatting: cross-references in P1-1, P1-3, P3-7, P4-3, and Appendix A are polished; Chapter 1's topic sentence on "unique rule attribution" is completed; the glossary adds "task result" and "end reason."

Extensions (new or strengthened obligations, addressing the gap in moving "from a review checklist to a design method" — affirmative-capability coverage was insufficient, with clauses stopping at "the team SHOULD define" but lacking "based on what"):

• Added P7-7 "Experience formation and controlled reuse" [MUST]: the qualification, scope, updating, and invalidation of reusable information; forbidding a single implicit behavior from being solidified into a long-term preference, an unverified self-summary from being labeled verified experience, and writing something into memory from granting it instruction authority. The glossary labels "memory" as personalization memory and adds "reusable information."
• P3-2 adds the business-object binding for the behavior contract: the Agent and other entry points observe consistent semantics for the same business object, and a suggestion, a draft, a submission, and goal achievement must not be conflated.
• P3-6 adds decisions for an information gap: choosing among existing information, reading, retrieval, testing, asking, and a modifiable assumption according to the nature of the gap; defining a stopping condition for information gathering.
• P6-4 adds question quality and the boundary of a proactive proposal: minimum necessary, no repeated asking; a problem solvable by retrieval and verification is not handed to the user, and a decision exclusive to the user is not replaced by a search; a proposal does not constitute execution authorization, and its category and frequency are predictable and closable.
• P3-8 adds standing delegation: the triggering basis, the delegation's validity period, and the disposition of repeated triggers; stopping the current run and revoking the standing delegation are made separate.
• P7-3 adds the choice of recovery strategy and remediation constraints: remediation is a new action constrained by authorization and duplicate prevention, and its failure retains a way out; results are re-verified after recovery.
• P5-1 adds the order of magnitude for cost before delegation and capability discoverability (both SHOULD-level); P5-3 adds "predictable as it nears the cap"; P1-6 adds "a pointer does not guarantee recoverability"; P3-5 adds "a tool's self-declaration does not constitute authorization."

Candidate rules P3-9 (business-object semantic consistency) and P6-5 (the boundary for proactively initiating a task) are not independently established in this version; how they are carried and the conditions for promotion are in B.2. The review checklist is correspondingly updated to 42 rules and 204 judgment statements.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into reviewable acceptance inputs and set no separate universal performance threshold. Select by the product's applicable capabilities and supply real devices, users, input sequences, and evidence; record the reason when inapplicable — not executed MUST NOT be recorded as passed.

For each scenario, check separately the configuration's effective values, the execution record, and a user-comprehensible result. Retain the version, goal, event timing, failure scope, and recovery outcome; an externally unknown result is filled in as neither success nor failure.