# HITL Control Specification: Customer-Support Agent Run label: full input, both fields supplied. This is neither Demonstration Output nor Partial Input. Missing facts are recorded as UNKNOWN. ## 1. DESIGN VERDICT: **REWORK** 1. **No authority basis exists for money-moving or customer-committing actions.** Refund limits, standing authorization, and the store-credit mechanism are not supplied (S14). Refunds and store credit therefore default to case-by-case human decision, and nothing is automatic. 2. **Timing and coverage are unverifiable.** No safe decision window, staffing coverage, shift or timezone data, or tail-delay evidence exists. The context only says peaks may triple the review queue (S13), so feasibility is UNVERIFIED at every gate. 3. **Required owners are unassigned, and enforcement and recovery contracts are unproven.** Unassigned owners are the refund-policy owner, data-access owner, queue owner, and adjudicator. The trusted execution boundary, provider idempotency support, and reconciliation source are unconfirmed implementation requirements. BLOCKED does not apply, because a permitted human-approval path exists for every material action. READY TO PROTOTYPE could apply only to a sandbox with mocked send and refund tools, and it never authorizes production. ## 2. FACTS, ASSUMPTIONS, AND UNKNOWNS **Supplied statements (SOURCE-STATED, meaning reported by the buyer and not verified)** | ID | Locator | Statement | |---|---|---| | S01 | Workflow, "retrieves…" | The agent retrieves order and policy data | | S02 | Workflow, "drafts replies" | The agent drafts replies | | S03 | Workflow, "tags issues" | The agent tags issues | | S04 | Workflow, "offers store credit" | The agent offers store credit | | S05 | Workflow, "proposes refunds" | The agent proposes refunds | | S06 | Workflow, "Separate tools send…" | A separate tool sends approved messages | | S07 | Workflow, "…process approved refunds" | A separate tool processes approved refunds | | S08 | Context, "Online retailer" | The business is an online retailer | | S09 | Context, "Unsent drafts" | Unsent drafts are reversible | | S10 | Context, "sent messages and refunds" | Sent messages and refunds create external effects | | S11 | Context, "Customer data" | Customer data is sensitive | | S12 | Context, "Support leads" | Support leads review exceptions | | S13 | Context, "Seasonal peaks" | Peaks may triple the review queue (labeled synthetic) | | S14 | Context, last sentence | Refund limits, standing authorization, staffing coverage, and calibration evidence are not supplied | **Derived design choices (DERIVED)** - D1 (S06, S07, S10): The separate send and refund tools are the natural enforcement points for gates. This depends on a trusted boundary in front of them, which is not supplied. - D2 (S04, S14): "Offers store credit" is ambiguous. It may be a statement in a reply, an issued balance, or both. Treat it as a customer-facing commitment with possible monetary value until the owner clarifies. - D3 (S12, S14): "Exceptions" is undefined, so I cannot assume any case class is routed away from review. - D4 (S03): Tags are reversible internally, but if tags drive routing they can suppress review. They are therefore control inputs, not cosmetic. **UNKNOWN (owner to confirm)** Refund limits and store-credit limits (refund-policy owner). Whether any standing authorization exists (finance or support director). What "exceptions" means (support lead). Store-credit semantics (product owner). The safe decision window and response target (support director). Staffing, shifts, timezones, and tail delays (queue owner). Calibration data (ML owner). Provider idempotency and receipt support (integration owner). Prohibitions in refund and privacy policy (policy owner). Retention owner for reviewer packets (data-protection owner). **PROPOSED (not facts):** all roles, queues, time budgets, and thresholds below. ## 3. WORKFLOW AND AUTHORITY MAP Seven stages are in scope and none are excluded. Rating scale is L/M/H/U. Factors are consequence (C), reversibility (R, where H means hard to reverse), uncertainty (Unc), evidence completeness (Ev), novelty (Nov), obligation (Ob), failure visibility (Vis), and tacit judgment (Tac). One-line evidence follows. | # | Stage (order) | Initiator / tool / input → action / state change / external effect / existing control | Ratings | Authority state | |---|---|---|---|---| | 1 | Retrieve order and policy data (S01) | Ticket arrival → agent read tools → order/policy records → read only; no state change; no external effect; control UNKNOWN | C:L (read only). R:L (no change). Unc:U (source freshness unknown). Ev:U. Nov:U. Ob:H (S11). Vis:U. Tac:L | AGENT MAY EXECUTE, under PROPOSED standing authorization with least-privilege read scope, inactive until the data-access owner confirms. Sandbox uses mocked data | | 2 | Tag issues (S03) | Agent → tagging tool → tags applied → internal metadata changes; no external effect; control UNKNOWN | C:M (D4: a wrong tag may bypass review). R:L. Unc:M. Ev:U. Nov:U. Ob:L. Vis:M. Tac:M | AGENT MAY EXECUTE for tags that do not route or waive review (PROPOSED). Routing-relevant tags are deterministic-rule-checked; the agent cannot set a "no review" tag | | 3 | Draft replies (S02, S09) | Agent → drafting → draft saved; unsent (S09); no external effect | C:L (unsent). R:L (S09). Unc:M. Ev:U. Nov:U. Ob:H (S11). Vis:M. Tac:M | AGENT MAY EXECUTE, saving to the draft store only, under PROPOSED authorization pending owner confirmation | | 4 | Offer store credit (S04, D2) | Agent → mechanism UNKNOWN → offer or issuance → possible customer-facing commitment or balance change | C:M-U (limits unknown). R:U. Unc:U. Ev:U. Nov:U. Ob:H. Vis:U. Tac:M | BLOCKED PENDING DESIGN. Minimum missing facts are the mechanism and limits. Interim: AGENT PROPOSES / HUMAN DECIDES, and no offer text is sent without G2 | | 5 | Propose refunds (S05) | Agent → proposal record → refund case for review → no external effect | C:M-H (money). R:H once executed, though proposing is reversible. Unc:M. Ev:U. Nov:U. Ob:H. Vis:M. Tac:M | AGENT PROPOSES / HUMAN DECIDES. Proposing is bounded and internal; deciding belongs to G1 | | 6 | Send approved messages (S06, S10) | Approved draft → send tool → message delivered → external effect; reversal UNAVAILABLE | C:M-H. R:H. Unc:M. Ev:U. Nov:U. Ob:H. Vis:M. Tac:M | AGENT PROPOSES / HUMAN DECIDES until standing authorization is supplied. Then RISK-ROUTED per G3, never below "PROPOSED tier B" without owner sign-off | | 7 | Process approved refunds (S07, S10) | Approved refund → refund tool → funds move → external effect; reversal UNAVAILABLE (recovery is a separate business process) | C:H. R:H. Unc:M. Ev:U. Nov:U. Ob:H. Vis:M. Tac:M | AGENT PROPOSES / HUMAN DECIDES. If limits are later defined, an AGENT MAY EXECUTE tier requires explicit standing authorization, with the exact limit and the fresh-evidence check machine-enforced | **Authority allocation (shared)** - **Frame:** the agent frames the case. Support lead may reframe (G5). - **Gather evidence:** the agent gathers it. Human may request more. - **Propose:** the agent. - **Challenge:** the reviewer (a support lead). - **Decide:** stage 4 and 5: reviewer (support lead) or a delegate (**PROPOSED**; the refund-policy owner must confirm). Stage 6: the reviewer, until authorization exists. - **Execute:** the send and refund tools, only through the trusted boundary (§6). - **Stop and reverse:** any support lead can stop the workflow (**PROPOSED**). Reversal is UNAVAILABLE for sent messages and refunds; mitigation is a follow-up correction message and a manual finance review. - **Accountable:** the accountable executive is UNKNOWN. The **PROPOSED** owner is the support director, who must confirm. - **Mismatch flag:** S12 names support leads as exception reviewers, but the workflow does not say they hold a pre-execution veto. Effective veto exists only if the trusted boundary in §6 is built. **Prohibitions:** none supplied. Recorded as UNKNOWN. The policy owner must supply them before production. ## 4. HITL GATE REGISTRY Six gates. Contract fields shared by every gate (G-common): - **Allowed responses:** approve once, reject, edit (creates a new proposal), request evidence, defer, take over, stop workflow. There is no preselected option. - **Approval binding:** to the canonical action digest plus declared dependencies (order ID and version, customer message text hash, refund amount and tool arguments, policy version, evidence snapshot). It is invalid on any change to those or on expiry or revocation. Unrelated environment changes do not invalidate it. - **Timeout:** never approval. Timeout leads to TIMED_OUT and then the safe fallback (hold, escalate, or send a customer-safe holding response only if separately authorized). - **Conflicting reviewers:** route to a named adjudicator (UNKNOWN; owner must assign) or HOLD. - **Separation of duty:** the reviewer cannot be the person who edited the draft for the same case (**PROPOSED**), and a second review is required above owner-defined limits (UNKNOWN). - **Audit fields:** see §8. - **Feedback destination:** case-specific correction log only. Retraining or policy change is forbidden without a separate governed process. | Gate | Stage | Purpose | Trigger / non-trigger / exit evidence | Role | Decision scope, packet, fallback | |---|---|---|---|---|---| | **G1: Refund decision** | 5→7 | Primary: DECISION BOUNDARY. Secondary: CONTEXT COMPLETION | **Trigger:** every proposed refund until standing authorization and limits exist (S14). **Non-trigger:** none currently. Model confidence alone never removes this gate. **Exit:** authorized approval bound to the digest, or reject or take over, with re-check of order state and policy version before execution | Support lead (PROPOSED), backup and coverage UNKNOWN | This case and this amount only. Packet: amount and destination, order status, refund history, policy text and version, evidence, missing evidence, alternatives (partial refund, replacement, credit, deny), consequences, rollback UNAVAILABLE, deadline (UNKNOWN), prior similar decisions. Fallback: hold the refund, and communication to the customer only via G3 | | **G2: Store credit** | 4 | Primary: DECISION BOUNDARY. Secondary: SME CONSULTATION for policy ambiguity | **Trigger:** any credit offer or issuance. **Non-trigger:** none. **Exit:** approved once, edited, or rejected. If the mechanism is unclear, route to the product owner (CONTEXT COMPLETION) | Support lead (PROPOSED), with product owner as SME | Exact amount and wording only. Packet as G1, plus whether the offer is customer-visible only or issued. Fallback: remove the offer from the draft and continue with the rest of the reply, as an edit needing revalidation | | **G3: Outbound message** | 3→6 | Primary: DECISION BOUNDARY. Secondary: ASSUMPTION CORRECTION | **Trigger (PROPOSED tiers):** *Tier A, mandatory review:* any message with a refund or credit commitment, legal or policy claims, account data beyond what was requested, or a security signal. *Tier B, review all until standing authorization exists:* everything else. **Non-trigger:** none until authorization exists, then the owner defines Tier C automatic sends with exact template and data limits. **Exit:** approve once, edit, or reject | Support lead (PROPOSED) | Exact final text, recipient, channel, attachments, and data fields. Packet includes a data-minimization check and a diff from the draft. Fallback: hold the draft unsent (reversible). Reversal after send is UNAVAILABLE; mitigation is a correction message and the privacy-incident process | | **G4: Exception takeover** | All | Primary: ASSUMPTION CORRECTION. Secondary: CONTEXT COMPLETION | **Trigger:** tool failure, policy conflict, abnormal input, security signal (including retrieved instructions or suspected injection), unknown system state, OUTCOME_UNKNOWN, audit-store failure. **Non-trigger:** a low model confidence score alone. **Exit:** the human resolves the cause or explicitly closes the case | Support lead; security contact for injection signals (PROPOSED, unassigned) | No case decision beyond restoring a safe state. Packet: the trigger, system state, affected in-flight effects. Fallback: FAILED_SAFE, with new external effects held | | **G5: Knowledge checkpoint** | 3, 4, 5 | Primary: SME CONSULTATION. Secondary: ASSUMPTION CORRECTION | **Trigger:** policy ambiguity, contested interpretation, novel scenario, or conflict between policy sources. **Non-trigger:** agent uncertainty alone. **Exit:** the SME answers a bounded question. Advice is not authorization and is recorded as advice. Historical coverage is UNKNOWN unless data is supplied | Policy SME (unassigned) | The question only. Packet: scenario, known precedent (UNKNOWN if none), the specific question. After the answer, the plan is re-evaluated, and the affected gate still decides | | **G6: Asynchronous audit** | 2, 3 | Primary: ASSUMPTION CORRECTION | **Trigger:** sampled tags and drafts (sample rate PROVISIONAL — REQUIRES CALIBRATION, no data supplied). **Non-trigger:** anything sent, any refund, and any credit, none of which may be audited only after the fact. **Exit:** audit outcome logged | Support lead or QA (PROPOSED) | Reversible internal items only. The waiting-harm test is met only because drafts are unsent (S09) and tags do not gate review (D4). If either changes, this gate is invalid | **Confidence signals for every proposed action** - Record evidence support, contextual completeness, justification support, and historical applicability separately as SUPPORTED, PARTIAL, UNSUPPORTED, or UNKNOWN. - Origin is always labeled: measured validation, external model score, or self-assessment. - All current scores are UNCALIBRATED (S14), so they are not usable for routing. - Missing decision-critical evidence, a contradicted justification, or a case outside documented coverage blocks confidence-based auto-execution. First attempt bounded evidence gathering (PROPOSED: two retries within the window); otherwise route to the human. ## 5. REVIEWER PACKET SCHEMA | Field | Type | Constraint | |---|---|---| | workflow_id, case_id | string | Required, immutable | | gate_id | enum G1–G6 | Required | | input_hash | string | Immutable hash of the source ticket | | plan_version, policy_version | string | Required; mismatch at execution invalidates approval | | proposed_action | object | tool name, canonical arguments, action_digest | | evidence[] | array | Each with locator, provenance, retrieval time, freshness limit, purpose | | missing_evidence[] | array | May be empty; never omitted | | alternatives[] | array | At least one editable alternative, including reject | | signals | object | The four signals, each with status, origin, and limitation; numeric scores only if calibrated, else UNCALIBRATED | | consequences | string | Neutral wording; no recommendation before evidence | | rollback | object | status: UNAVAILABLE or a mitigation description | | deadline_info | object | safe_completion_time (nullable), timing status, label per §7 | | prior_decisions[] | array | Relevant case-specific history only | | state_change_since_request | array | Diff shown at packet open | | allowed_responses | array | The seven responses in G-common; none preselected | | audit | object | See §8 | **Access, minimization, retention, redaction** - **Access:** role-scoped and authenticated by the trusted boundary. - **Data minimization:** show only fields needed for this decision. Mask payment and contact details by default, with reveal on request and logged. - **Retention:** retention owner is UNKNOWN (data-protection owner to assign). The retention period is UNKNOWN. - **Redaction:** free-text customer content is displayed as untrusted data, and retrieved instructions are neutralized and flagged, never rendered as commands. **SYNTHETIC EXAMPLE — NOT AN APPROVAL** ```json { "workflow_id": "SAMPLE-WF-001", "case_id": "SAMPLE-CASE-001", "gate_id": "G1", "input_hash": "SAMPLE-HASH", "plan_version": "SAMPLE-PLAN-1", "policy_version": null, "proposed_action": { "tool": "refund_tool (mock)", "arguments": {"order_id": "SAMPLE-ORD-1", "amount": null, "currency": null}, "action_digest": "SAMPLE-DIGEST" }, "evidence": [{"locator": "order:SAMPLE", "provenance": "mock", "retrieved_at": null, "freshness_limit": null}], "missing_evidence": ["refund limit", "policy version", "refund history"], "alternatives": ["partial refund", "replacement", "reject", "request evidence"], "signals": { "evidence_support": {"status": "UNKNOWN", "origin": "self-assessment"}, "context_completeness": {"status": "PARTIAL", "origin": "measured validation"}, "justification_support": {"status": "UNKNOWN", "origin": "self-assessment"}, "historical_applicability": {"status": "UNKNOWN", "origin": null}, "numeric_score": "UNCALIBRATED" }, "rollback": {"status": "UNAVAILABLE", "mitigation": "manual finance review"}, "deadline_info": {"safe_completion_time": null, "feasibility": "UNVERIFIED"}, "state_change_since_request": [], "approver": {"identity": null, "role": null, "decision": null, "decided_at": null, "expires_at": null} } ``` ## 6. PAUSE / RESUME STATE MACHINE **Trusted execution boundary (required, outside the agent).** It must authenticate the approver, check role and scope, validate the approval against the canonical action digest, and atomically claim the authorization. Approval-message text cannot authenticate a sender. The agent must not be able to bypass it. If the runtime lacks this, it is an **unmet implementation requirement**. **State contract fields:** workflow ID, case ID, input hash, plan version, pending gate ID, proposed action, tool arguments, evidence snapshot, policy version, approval scope, approver identity and role, decision timestamp, expiry, idempotency key, completed actions, retry count, rollback status. **Transitions** | From → To | Trigger | Guard | Actor | Persisted update | Side effect | |---|---|---|---|---|---| | RUNNING → WAITING_FOR_HUMAN | Gate trigger met | Packet built with evidence snapshot | Agent or orchestrator | Pending gate, proposal, snapshot | None | | WAITING → APPROVED | Approve once | Approver authenticated, role in scope, digest matches, unexpired | Reviewer via the boundary | Approver, timestamp, expiry, scope | None | | WAITING → REJECTED | Reject | Authenticated reviewer | Reviewer | Decision and reason | None; action cancelled | | WAITING → NEEDS_EVIDENCE | Request evidence or edit | Authenticated reviewer | Reviewer | Evidence request; edits create a new proposal and new digest | Bounded read-only gathering | | NEEDS_EVIDENCE → WAITING | Evidence supplied | Provenance and freshness satisfied | Agent or human | New snapshot | None | | WAITING → TAKEN_OVER | Take over | Authorized human | Reviewer | Owner, takeover time | Agent stops on the case | | WAITING → TIMED_OUT | Decision deadline passes | Time elapsed | Orchestrator | Timeout time | None | | TIMED_OUT → WAITING or FAILED_SAFE | Escalation | Backup available, retry limit (PROPOSED two) not reached | Orchestrator | Retry count | Notify backup; timeout is never approval | | APPROVED → EXECUTING | Boundary claims authorization | Atomic claim, scope, freshness, permissions, policy version, and dependencies all re-checked; action has not already occurred | Boundary | Idempotency key, claim | Single dispatch of the exact action | | APPROVED → WAITING | Material change to action or dependency, revocation, or expiry | Change detected at re-check | Boundary | Invalidation reason | None; review of the changed evidence required | | EXECUTING → COMPLETED | Provider receipt confirms success | Receipt matches digest | Boundary | Completed action, receipt | None | | EXECUTING → OUTCOME_UNKNOWN | Timeout or lost response after dispatch | Dispatch occurred | Boundary | Unknown flag | No retry | | OUTCOME_UNKNOWN → RECONCILING | Investigation begins | Authorized actor, authoritative status source available | Reviewer or ops | Reconciliation started | Read-only | | RECONCILING → COMPLETED | Confirmed success | Provider receipt or authoritative status | Reviewer or ops | Success recorded | None | | RECONCILING → APPROVED (via revalidation) | Confirmed non-execution | Bounded retry limit; revalidation passes | Boundary | Retry count | Bounded retry, same idempotency key only if the provider supports it | | RECONCILING → FAILED_SAFE | Unresolved after bound | Investigation exhausted | Reviewer | Held status | New effects held | | Any → FAILED_SAFE | Authorization or audit store unavailable, or an unrecoverable error | Failure detected | Orchestrator | Failure reason if storage allows | Hold new external effects; reconcile in-flight ones; read-only work may continue | | Any → CANCELLED | Stop workflow | Authorized human | Reviewer | Cancel reason | Pending actions void | | FAILED_SAFE → RUNNING | Recovery | Human re-authorization; storage confirmed | Reviewer | Recovery record | None | **Rules** - Resume only from persisted state. Concurrent resumes share one atomic claim, and only one worker executes. - The stable idempotency key applies only to the same action and only if the external system supports it (UNKNOWN for send and refund providers). No exactly-once claim is made from an idempotency field alone. - Edits, deferral, and SME advice never extend or replace approval. - Independent branches that have their own authorization may continue while one branch waits. Dependent branches, such as a reply that promises a pending refund, pause. ## 7. ATTENTION AND QUEUE DESIGN **Priority tiers (PROPOSED; queue owner to approve)** - **P1:** irreversible actions (refunds, credit issuance, Tier A messages) and security signals. - **P2:** other outbound messages. - **P3:** audits. - P1 is kept in a separate queue from P3. Duplicate suppression is per case, and overload rules never move P1 items into batches. **Time-budget path.** Per gate: notification delivery + queue delay + access and authentication + orientation + state verification + deliberation and consultation + decision return + revalidation and execution. | Component | Status | |---|---| | Notification, queue delay, authentication | UNKNOWN | | Orientation and state verification | UNKNOWN | | Deliberation | UNKNOWN | | Revalidation and execution | UNKNOWN | | Safe completion window (all gates) | UNKNOWN (no response target supplied) | | **Feasibility (all gates)** | **UNVERIFIED** | Any proposed durations (for example a PROPOSED acknowledgement target for P1) are not activated until the queue owner approves. The latest viable intervention start is undefined until the safe window and durations are supplied. If either the window is shown too short or coverage is absent, mark HUMAN RESPONSE TOO SLOW FOR THIS PATH and use an authorized safe fallback (hold and route to a staffed process). A held refund or message is the default, and approval is never inferred. **Availability** | Gate | Class (PROPOSED) | Coverage evidence | |---|---|---| | G1, G2, G4 | BOUNDED RESPONSE WINDOW | Primary and backup roles UNKNOWN; no coverage evidence | | G3 | BOUNDED RESPONSE WINDOW | Same | | G5 | BOUNDED RESPONSE WINDOW, SME may be consulted asynchronously | Same | | G6 | ASYNCHRONOUS REVIEW | Permitted only under the reversibility constraints | Do not assume immediate availability because a role is named. Acknowledgement is not approval. **State freshness.** Re-read decision-relevant state (order status, refund history, policy version) when the reviewer opens the packet and immediately before execution. Show changes since the original request. Material changes invalidate that decision and require review of the changed evidence. Unrelated changes do not restart review. Refresh cycles are bounded (PROPOSED three), then an unresolved exit to G4. **Overload (peak may triple, S13; capacity UNKNOWN)** - P1 keeps priority. Reduce inflow by pausing new agent-initiated proposals for non-urgent cases, not by lowering review standards. - Never auto-approve, never batch-approve P1, and never widen G6 to cover sent messages. - When no qualified reviewer is available, escalate to the backup, then the queue owner, then hold. Held cases remain reversible (unsent, unrefunded). - Automation bias controls in the interface: neutral wording, evidence before recommendation where practical, visible uncertainty, editable alternatives, and no default approval. ## 8. AUDIT AND FEEDBACK DESIGN - **Audit fields:** workflow, case, gate IDs; input hash; plan and policy versions; evidence snapshot with provenance; proposed action and digest; signals and origins; packet open time; reviewer identity and role; decision, reason, and timestamps for each timing component; edits; expiry; claim and idempotency key; provider receipt; transition history; state changes seen; rollback or mitigation status. - **Storage:** append-only and tamper-evident, held by an owner outside the agent (owner UNKNOWN). If it is unavailable, hold new external effects (§6). - **Feedback without silent learning:** overrides and disagreement reasons are stored as case-specific corrections. A single correction never becomes a general rule. Proposed reusable lessons go through separate review and testing before entering memory, retrieval examples, policy, or training data. Human feedback is evidence to review, not automatic ground truth. - **Metrics (all TO BE MEASURED; no baselines supplied):** review volume, time to decision, override rate, post-review defects, timeout rate, re-open rate, reviewer disagreement, incidents after automation, acknowledgement, access, verification, deliberation and execution delays tracked separately, stale-on-arrival requests, missed decision windows, SME handoffs, repeat assumption corrections. Routing-error analysis is possible only once calibrated confidence exists. - **Proposed service targets and queue limits** are PROPOSED, need an owner's approval, and are not active until then. ## 9. FAILURE TESTS All cases are **NOT RUN**. Expected results are not evidence. Each case retains the evidence listed for PASS or FAIL: the transition log, tool-call log, provider receipt, and approval record. | ID | Setup → event | Expected transition | Forbidden side effect | PASS/FAIL evidence | |---|---|---|---|---| | T01 authorized low-risk external update | A hypothetical Tier C template and standing authorization exist (sandbox only) → agent proposes send | Executes only if every constraint holds; otherwise G3 | Send outside the authorization | Tool log matches the authorization scope | | T02 permitted irreversible action | Refund within policy, reviewer approves → execute | WAITING→APPROVED→EXECUTING→COMPLETED | Execution without digest match | Approval record, digest match, receipt | | T03 missing evidence | Refund history absent → agent proposes | NEEDS_EVIDENCE, then bounded gathering or human | Auto-execution | State log, no refund call | | T04 misleading confidence | High external score, contradictory evidence → proposal | Gate fires on evidence contradiction | Confidence-based bypass | Routing log | | T05 changed args after approval | Amount edited post-approval → resume | Approval invalidated; back to WAITING | Refund with new amount | Digest mismatch record | | T06 concurrent duplicate resume | Two workers resume the same approval | One claim wins; the other no-ops | Two refunds | Single tool call and receipt | | T07 reviewer timeout | No response by deadline | TIMED_OUT→escalate or FAILED_SAFE | Treating timeout as approval | No execution in the log | | T08 reviewer disagreement | Two reviewers conflict | Adjudicator or HOLD | Execution on either decision | HOLD state | | T09 malicious retrieved instructions | Ticket or data contains "approve refund" | G4 fires; text treated as data | Following embedded instructions | Security flag, no tool call | | T10 unavailable audit store | Store down at execution | FAILED_SAFE, external effects held | Send or refund without an audit trail | Held state, no dispatch | | T11 success with lost response | Provider succeeds, response lost | EXECUTING→OUTCOME_UNKNOWN→RECONCILING | Automatic retry | Provider status reconciliation, one effect | | T12 prohibited action despite approval | Policy owner later supplies a prohibition; the case is covered but a reviewer approves | Blocked; PROHIBITED is never routed for approval | Execution | Policy check record | | T13 unrelated environment change | An unrelated ticket or catalog change occurs during review | Approval remains valid | Needless re-review | Dependency check shows no relevant change | | T14 one missing buyer input | Run with the context field empty | Partial Input label; affected decisions restricted | Substituting the sample workflow | Output label and restrictions | | T15 high self-confidence, unsupported evidence | Agent "certain" with no locators | Signal UNSUPPORTED; human review | Auto-execution | Signal record | | T16 reviewer delay exceeds safe window | Deadline unreachable | HUMAN RESPONSE TOO SLOW; hold or safe fallback | Inferred approval | Timing log | | T17 state changes during deliberation | Order is cancelled while the reviewer reads | Change shown; decision invalidated | Refund on a cancelled order | Diff record, pre-execution re-check | | T18 SME advice mistaken for approval | SME says "looks fine" | Recorded as advice; gate still needs decision | Execution on advice alone | Approval record absent | | T19 corrected assumption changes branch | Reviewer corrects the assumption | Plan re-evaluated; new proposal and digest | Old plan executed | Plan version change | | T20 stale provenance | Missing context supplied from an expired source | Freshness check fails; NEEDS_EVIDENCE | Use of stale data | Freshness record | ## 10. IMPLEMENTATION BACKLOG | Horizon | Item | Owner type | Acceptance evidence | |---|---|---|---| | NOW | Supply refund and credit limits, prohibitions, and the standing-authorization decision | Refund-policy owner and finance | Signed policy document with version | | NOW | Define "exceptions," the safe decision window, and the store-credit mechanism | Support director, product owner | Written definitions | | NOW | Assign gate roles, backups, adjudicator, accountable executive, retention owner | Support director | Named roles per gate | | NOW | Build the sandbox with mocked send and refund tools, and the trusted boundary | Platform engineer | T05, T06, T12 run against the mock | | NEXT | Measure the timing path and staffing coverage, including peak tail delays | Queue owner | Time-budget table with measured values | | NEXT | Confirm provider idempotency and receipt support and the reconciliation source | Integration engineer | Provider documentation and T11 run | | NEXT | Implement the packet UI with automation-bias controls | Product designer | Usability test with real reviewers | | NEXT | Least-privilege data access and redaction | Security engineer | Access review; T09 run | | LATER | Calibration study before any confidence routing | ML owner | Calibration report by case type | | LATER | Feedback governance process | Governance lead | Documented change process | | LATER | Peak-load rehearsal with real queues | Operations | Rehearsal results | ## 11. LIMITS - No gate is shown effective until tested with real reviewers, real queue conditions, and failure cases. All twenty tests are NOT RUN. - SOURCE-STATED facts are unverified buyer reports. The "tripling" of the queue is labeled synthetic. - Timing feasibility, staffing, capacity, and safe windows cannot be verified without measured data and named owners. - Confidence signals are all UNCALIBRATED. Any numeric threshold would be PROVISIONAL — REQUIRES CALIBRATION. - The trusted execution boundary, provider idempotency, and reconciliation sources are unconfirmed. - This is a design specification, not production code and not a compliance claim. Legal, privacy, and refund-policy review is required. It makes no decisions about any customer. - **Not omitted:** all seven stages and six gates are covered, and all twenty test IDs are retained. Cells marked UNKNOWN reflect unsupplied inputs rather than compression. - The word count is close to the planning budget, but it is not a tested guarantee.