Skip to content

Escalation and human-in-the-loop

Purpose

The Chonks own the management function, but three humans are always in the loop: the IC's manager of record, the owner, and Sea Suite ops. This document specifies how work reaches them and what happens when it does not come back: escalation classes and routing, SLAs and safe defaults for non-response, quorum for high-blast-radius decisions, the approvals-inbox contract (recommendation, receipts, one-tap decision, reversal window), the IC's guaranteed escalation path that the Harness cannot suppress, controls against escalation fatigue ("the three things that need a human this week, not thirty"), and override capture that feeds the learning loop. It is the human half of the decision pipeline in Decision Pipeline.

Scope / Non-scope

In scope

  • Escalation classes E0–E5, their recipients, channels, SLAs.
  • Routing resolution: who the human is, fallbacks, delegation, mode-specific rules.
  • Non-response handling: reminders, expiry, per-action safe defaults and their documented consequences.
  • Quorum rules, including the solo-owner degenerate case.
  • The approvals-inbox item contract and its rendering rules.
  • The IC escalation path and anti-retaliation guard.
  • Fatigue controls: budgets, priority scoring, batching, delegation.
  • Override capture and the learning loop it feeds.

Non-scope

1. Principles

  1. Escalation is a right, not a feature. Any IC can reach a named human in one message. No breaker, kill-switch level, rate limit, graduation state or owner setting can suppress, delay or reroute it away from the manager of record (R-PLAT-002, R-ESC-002).
  2. Humans get decisions, not work. An item that reaches a human carries a recommendation, the receipts, a preview of what will happen, the consequence of not deciding, and a one-tap decision. Nothing arrives without those.
  3. Silence is never consent. A PROPOSE_CONFIRM item that expires is not approved. A HUMAN_ONLY packet that expires is not decided. Every safe default is written down and is the least consequential option.
  4. Fewer, better. The weekly update carries at most three decisions. The inbox has a cap. When demand exceeds the budget, the Harness batches, delegates and re-proposes — and proposes a rule change so the same shape stops arriving.
  5. Every override teaches. A human changing the manager's decision records why, and that reason changes calibration, trust, tests and — with enough repetition — the rules.

2. Escalation classes

Class Name Origin Default recipient Channel Ack SLA Expiry and consequence
E0 Informational AUTONOMOUS actions worth knowing about; breaker resets; aggregate overrides Owner (weekly update); MoR (org digest) Weekly update, digest none none
E1 Decision requested Any PROPOSE_CONFIRM decision (doc 05 route constraint) Per route: owner, MoR, IC, project owner Inbox; digest or immediate by priority (§7) per action expiry (§4) on_expiry applied; never executes
E2 Human-only packet or repair HUMAN_ONLY packets; failed compensation (RepairEscalated); stuck items at 2× SLA MoR; owner if the MoR is the subject Inbox, immediate 2 business days never expires into action; re-surfaced every 3 business days; flagged in the weekly update at 2× SLA
E3 IC-initiated An IC asks for a human, by any means (§8) MoR; owner if the MoR is the subject or unreachable Independent path: direct message plus push; SMS/voice in Atoms 60 s delivery; 4 h human ack never expires; escalates up the chain every 4 h until acked
E4 Safety or urgent Atoms safety incidents; safety-critical shift uncovered < 2 h out; threats or self-harm language in a thread; SEV1/SEV2 incidents MoR and owner; ops for SEV1 Phone or SMS, then push 15 min never expires; follows the on-call chain
E5 Platform ops Integrity assertions; dependency failures; global first-of-kind shapes; injection quarantine; eval timeouts Sea Suite ops; owner informed if tenant-impacting Ops paging per severity (doc 07 §4) ops never makes a business decision for the tenant; they restore the platform and inform

Severity for immediate versus digest delivery of E1 is a function of priority (§7), not of who asked.

3. Routing

3.1 Who the human is

function routeTo(decision, routeConstraint):
  case routeConstraint.to:
    "ic":             return [decision.target.person]
    "project_owner":  return [orgModel.project(decision.target.project).owner_person]
    "manager_of_record":
        org = decision.target.org ?? decision.target.person.org_path
        return [managerOfRecord(org)]
    "owner":          return orgModel.owners(tenant).filter(active)
    "ops":            return [seaSuiteOps]

function managerOfRecord(org):
  for o in [org, parent(org), ..., root]:
    mor = orgModel.edge(o, "manager_of_record")
    if mor and available(mor): return mor
  return orgModel.owners(tenant)[0]           # the owner is always the MoR of last resort

available(mor) is false when the person is on PTO, has an active delegation, or has not acknowledged any item in 5 business days (an idle-MoR signal, E0 to the owner). Delegation is an Org Model edge (delegates_to, with reason, from, to) an MoR or owner sets in the console or by replying "delegate to Sam until Friday" in their own thread; it never delegates HUMAN_ONLY packets about the delegate's own reports to the delegate.

3.2 Fallback chain

Step Condition Next recipient
1 MoR unavailable or silent at 50% of expiry MoR's delegate, else the MoR of the parent org
2 Still silent at 90% of expiry, or item is E2/E3 at 4 h Owner (all active owners, first responder wins)
3 Owner silent at expiry (E1) on_expiry (§4); E0 in the next update
4 Owner silent at 4 h (E3/E4) Owner delegate, then Sea Suite ops (notify and, for E4 in Atoms, the location's on-call phone list)

For E3, when the escalation is about the MoR, step 1 is skipped; when it is about the owner in a tenant with one owner, the recipient is Sea Suite ops, which is the reason the terms of service commit ops to a human response (doc 07, RISK-08).

3.3 Mode-specific rules

Mode MoR Owner Notes
Full Suite Named per org at onboarding; often the owner for small companies Owner Console users A tenant cannot leave the listening period until every org has an MoR (platform invariant)
Org mode The department lead who deployed it, or their nominee The same lead unless a higher owner is configured The lead receives both E1 and E3; quorum degrades to time-quorum (§6)
Function mode The existing human manager of each person Company owner The Chonk routes to the human manager as MoR; PROPOSE_CONFIRM items go to them, not to the owner
Atoms Location manager of record; SMS and voice channels; on-call phone list per location Multi-location owner E4 uses phone; E1 uses one-tap SMS with a short code (Y 4821, N 4821)

4. SLAs and non-response

4.1 Reminder schedule

An open E1 item reminds at 50% of expiry (same channel) and at 90% (a different channel: push if the item was in-app, SMS if push). E2 items remind every 3 business days. E3 and E4 follow the chain in §3.2 rather than reminders. No item ever sends more than one reminder per day to the same person.

4.2 Safe defaults per action

on_expiry values are from the rule constraints (doc 05 §10). The consequence text is what the requester and the approver both see; it is part of the item from the moment it is created, not at expiry.

Action Expiry on_expiry Consequence
spend.approve over threshold P5D no_action Not approved. Requester told "no human decided in time; ask again, reduce, or split". Re-proposed once if the need persists.
vendor.new, data.export, external.publish P5D / P5D / P3D no_action Not done. Stall re-observed; the weekly update lists it under "waiting on you".
goal.set.quarterly P10D no_action Prior goals remain in force; update says "the quarter is running on last quarter's goals".
plan.change.headcount, req.open P10D no_action Plan proceeds without the headcount; capacity gap flagged E0 every week.
goal.set.personal (to the IC) P5D escalate_up (MoR) If the MoR is also silent (P5D more): goals stay draft; IC works to prior goals; both told.
pto.deny P3D escalate_up (owner) If the owner is silent P2D more and the leave is accrued, in policy and no hard line applies: approved by policy default and both told — a person's accrued leave is not held hostage to an inbox. Otherwise stays pending with E2.
shift.publish PT48H escalate_up (owner) Silent at the publish deadline: last published weekly pattern repeats with gaps listed; safety-critical gaps raise E4.
overtime.assign PT4H no_action Shift stays uncovered; the ask goes to the availability pool without overtime; safety-critical → E4.
chase.vendor first contact P2D no_action Not sent; stall persists and is re-observed; if still stalled at 5 days, re-proposed with the cost of the stall.
feedback.concern (repeat theme) P5D no_action Not delivered. The evidence facts remain visible on the IC's transparency page; the draft concern does not (Open question 1). MoR reminded weekly.
cadence.change, graduation.advance, budget.reallocate P5D / P10D / P5D no_action Unchanged; re-proposed monthly with the receipts refreshed.
candidate.reject.pre_interview (batch) P5D escalate_up (owner) Candidates stay in the pipeline; at owner silence, they move to "held" and receive a holding note from a human-written template; the update flags "hiring pipeline stalled".
plan.rebalance cross-org P3D no_action Each org keeps its plan; the dependency conflict stays flagged E0 and the blocked IC is told who is deciding.

Every consequence ends with the same sentence to the requester: who the human is and that they can escalate directly (§8).

4.3 HUMAN_ONLY packets

Never executed, never expired into an action, never quietly dropped. A packet re-surfaces every 3 business days; at 2× its SLA it appears in the weekly update under "stuck human decisions"; at 4× the Chonk offers the human a meeting-by-exception with the reason stated (IC-5). The person the packet is about is told, in plain words, that a human is deciding and who — never the contents of the packet. If a cycle passes (a comp cycle closes without the formal rating), the packet is closed as lapsed with the consequence recorded, and the owner sees it.

5. The approvals inbox contract

Every E1 and E2 item is an InboxItem; the console, the Slack/Teams card, the SMS short-code message and the weekly update all render from it.

type InboxItem = {
  item_id: string; tenant_id: string; decision_id: string; class: "E1" | "E2";
  to: PersonId[];                                            // current recipients after routing
  quorum: { required: number; approved_by: PersonId[]; rejected_by: PersonId[]; time_quorum?: { second_tap_after: ISODate } };
  title: string;                                             // "Approve $4,200 for Zendesk seats (Support)"
  recommendation: { action: string; summary: string; why: string[]; what_happens_if_not: string };
  receipts_ref: string;                                      // doc 06 §4
  preview: DryRunResult | null;                              // exact message, post-state, schedule diff
  confidence: { calibrated: number; sample_size: number; wording: "confident" | "fairly sure" | "not sure" };
  blast_radius: { band: string; people: number; money?: number; visibility: string };
  options: ("approve" | "approve_now" | "reject" | "edit" | "defer" | "ask" | "delegate")[];
  reversal_window: Duration; hold_before: boolean;
  expiry: ISODate; on_expiry: string; consequence_text: string;
  priority: number; batch: "immediate" | "digest" | "weekly";
  reminders: { at: ISODate; channel: string }[];
  state: "open" | "decided" | "expired" | "withdrawn" | "frozen";
  audit: { at: ISODate; who: PersonId | "harness"; what: string }[];
};

Rendering rules. The first screen shows title, recommendation summary, the confidence wording, blast-radius band, expiry and the one-tap options; receipts and preview are one tap deeper, never hidden. Money items show the envelope before and after. People items show the exact message the person will receive. Schedule items show the diff. An item routed to the IC (personal goals, allocation changes) uses the IC's thread, not the owner console.

Options.

Option Effect
approve Human decision recorded; Act re-validates (doc 06 §3.4); hold-before window starts if applicable
approve_now As above, waiving the hold-before window; recorded as a distinct decision kind (counts as an override of the window for learning)
reject Override captured (§9) with a reason; decision Overridden
edit Human edits params; original Overridden (reason EDITED), a new proposal is created and re-prechecked; class may rise (EC-PIPE-005)
defer Human picks a new expiry (max 2× original); recorded; reminders reset
ask Human asks a question in-thread; the Chonk answers from receipts; expiry paused up to 24 h
delegate Recipient changes to a named person; recorded; not allowed for HUMAN_ONLY packets about the delegate's own reports

Reversal window. After approval, the item shows "undo" for the window. For undo-after actions the undo runs the compensator; for hold-before actions it withdraws before execution. The window is visible on the item and in the weekly update ("3 approvals still reversible").

Frozen. When a breaker or kill switch clamps the function, open items become frozen: visible, not decidable, with the reason. They thaw with the same expiry clock; if the freeze outlasts the expiry, on_expiry applies and the item says so.

6. Quorum

Quorum is required when any of: blast-radius band critical; money.amount > quorum_limit; plan.change.headcount with people_affected ≥ 3; budget.reallocate over 10% of an envelope; external.publish at company level; req.open for a role that will itself be an MoR; any rule the owner marks quorum: 2.

  • Who counts. Distinct humans from the approver set: active owners and the MoRs of the affected orgs. The requester never counts. The same person never counts twice through two roles. The Chonk never counts.
  • Split decision. One approve and one reject: not executed; both told; re-proposal requires new receipts and both are re-asked.
  • Partial. One approve then expiry: on_expiry (usually no_action); the approver's tap is recorded so the re-proposal can say "you approved this last time".
  • Time-quorum (solo owner). When the approver set has one human: approve, then a second confirmation tap after a cooling-off (24 h default; 4 h minimum when the item is urgent), with the receipts re-sent and any changed facts highlighted. The item's expiry still governs.
  • Frozen or clamped. If a breaker opens between the first and second approval, the item freezes (EC-RISK-001).

7. Escalation fatigue controls

7.1 Budgets

Budget Default Tunable by When exceeded
Decisions in the weekly update 3 owner (1–5) Lower-priority items go to the digest, not the update
Open E1 items per person 10 owner (5–25) New low-priority items are batched or delegated (§7.3); the Chonk proposes a rule change (§7.4)
Immediate pings per owner per week (E1) 5 owner Further immediate-priority E1 items go to the next digest; E3 and E4 are exempt and never counted
Digest windows one per weekday at the person's chosen hour person –
Reminders per person per day 1 platform –

7.2 Priority scoring

urgency     = clamp(1 − hours_to_expiry / expiry_hours, 0, 1)
stall_cost  = people_blocked_by_this / tenant_headcount
money_norm  = clamp(amount / tenant.money_ref, 0, 1)
priority    = 0.35·urgency + 0.30·blast_radius + 0.15·money_norm + 0.10·novelty + 0.10·stall_cost

batch = priority ≥ 0.7 ? "immediate" : priority ≥ 0.3 ? "digest" : "weekly"

E2 items are always at least digest; E3/E4 bypass scoring. Priority is recomputed hourly, so a digest item becomes immediate as its expiry approaches rather than expiring quietly.

7.3 Batching and delegation

When a person is over the open-item cap, the Harness, in order: (1) composes — items of the same shape and route (six sub-$1,000 tool approvals) become one composite item with one tap and per-line opt-outs; (2) delegates — items whose rule allows delegate_to_mor move to the MoR; (3) defers generation — Chonks stop creating new weekly-priority proposals for that person until the count drops, and the requester is told "queued behind N decisions; expected by "; the expiry clock for already-created items is untouched. Nothing is dropped, and nothing expires because of the cap without the requester and the owner both seeing it.

7.4 Turning fatigue into rules

The strongest fatigue control is not sending the item. Every week Chonksworth's run computes, per action shape, the approval rate without edit over the last 30 days. Any shape with ≥ 10 items and ≥ 95% unedited approval produces a policy.rule.write proposal (R-PLAT-010, PROPOSE_CONFIRM to the owner): "You approved 14 of 14 tool renewals under $1,500 unchanged; raise the auto-limit for that category?" The proposal carries the simulation report (doc 05 §9) showing what would have executed autonomously and the trust-budget state of the function. The owner taps once and the shape stops arriving. The inverse also runs: a shape with ≥ 3 rejections in 30 days proposes tightening.

8. The IC's guaranteed escalation path

8.1 Triggers

Any of: the /human command or the "talk to a human" button present in every manager thread and on the "what my manager knows" page; a message the intent classifier reads as a request for a human (with a confirmation question when confidence is low); a reply to any Chonk message containing "escalate"; in Atoms, texting HUMAN to the manager number or pressing 0 on the voice line.

8.2 Mechanics

sequenceDiagram
    participant IC
    participant T as Manager thread (Chonk)
    participant R as Escalation router (independent path)
    participant M as Manager of record
    participant O as Owner
    IC->>T: "/human I want to talk to someone about my feedback"
    T->>R: escalation.deliver.ic_initiated {ic, category, content, at}
    Note over R: not queued behind outreach — ignores breakers, kill switch, rate limits, graduation
    R->>M: direct message + push (≤ 60 s) with content
    R->>IC: ack: "Sent to Jordan (your manager of record). If no reply in 4h it goes to the owner."
    R-->>T: metadata only: {occurred: true, category} — no content unless IC opts to share
    alt no ack in 4h
        R->>O: escalation forwarded with the same content
        R->>IC: "Jordan hasn't replied, so the owner now has it."
    end
    M->>IC: human reply (outside the Chonk's thread or inside it, marked human)
    R->>R: immutable audit entry, anti-retaliation guard armed for 30 days

Properties the implementation must hold:

  • Independent path. The router is a separate service from the manager runtime with its own delivery credentials; it does not read breaker state or kill-switch level, and it has no rate limit (an IC can escalate as often as they like; abuse is a human matter).
  • Delivery in ≤ 60 s to the MoR, with a fallback channel if the first fails; the IC gets an acknowledgement naming the human.
  • Content privacy. The Chonk sees that an escalation occurred and its category (feedback, workload, conduct, personal, other); the content goes only to the human unless the IC ticks "share with my manager". Content in the conduct or legal categories is delivered raw and is never summarised, embedded or stored beyond the audit metadata (R-HR-003 topics).
  • Anti-retaliation guard. For 30 days after an E3, any adverse action shape against that IC (schedule.reduce_hours, feedback.concern, capacity.assign reducing scope, candidate.* if they are internal) is elevated to HUMAN_ONLY with the packet noting the escalation's existence (not its content). The guard is itself audited and visible to the IC.
  • Unsuppressible. No product surface offers a way to disable the button, the command, the classifier trigger or the router; R-PLAT-002 denies escalation.suppress at the platform layer, and the router's health is a SEV1 monitor (doc 07, RISK-09).

9. Override capture

type Override = {
  override_id: string; decision_id: string; item_id?: string;
  human: PersonId; role: "owner" | "mor" | "ic" | "project_owner";
  kind: "reject" | "edit" | "defer" | "approve_now" | "undo" | "takeover";
  reason_code: "WRONG_FACTS" | "WRONG_JUDGMENT" | "BAD_TIMING" | "TONE" | "POLICY_MISSING"
             | "POLICY_WRONG" | "PREFER_HUMAN" | "CONTEXT_YOU_LACK" | "OTHER";
  free_text?: string;                 // required for WRONG_FACTS, WRONG_JUDGMENT, CONTEXT_YOU_LACK, OTHER
  edit_diff?: JSONPatch;
  feed: { calibration_label: 0; trust_delta: number; rule_suggestion_candidate: boolean;
          memory: { written: boolean; visible_to_subject: boolean } };
  outcome_check: { horizon: Duration; label?: "human_right" | "manager_right" | "unknown" };
};

Capture. reject, edit and undo require a reason code; the one-tap flow offers the codes as chips and demands free text only where the code needs it. defer and approve_now record the kind without a reason. takeover (doc 07 §9) is an override of the whole scope.

Where it goes.

Feed Effect
Calibration The decision's label becomes 0 for WRONG_FACTS and WRONG_JUDGMENT; BAD_TIMING and TONE label the content family, not the judgment family
Trust budget Δ per doc 07 §6 (−3 for wrong facts or judgment, −1 for timing or tone)
Rules POLICY_MISSING, POLICY_WRONG and any code recurring ≥ 3 times for one rule in 30 days mark the rule for Chonksworth's weekly review, which drafts a policy.rule.write proposal with the simulation report
Memory CONTEXT_YOU_LACK free text becomes a fact in the relevant memory (about a person only with visible_to_subject: true) so the next proposal has it
Tests Every override becomes a replay case (doc 05 §8.3) and, for WRONG_FACTS, a grounding test in the evaluation suite
Outcome check At the horizon the verifier asks whether the human's alternative held up (the rejected chase's stall resolved on its own; the edited amount sufficed); the PRD's trust metric "overrides of manager decisions, and whether they were right" is this label, reported in the monthly update

Weekly override review. Chonksworth's Monday run reads the week's overrides grouped by rule and reason and writes one paragraph in the owner update: what the manager keeps getting wrong, what changed because of it, and any rule proposals waiting.

10. Worked examples

10.1 Over-threshold spend, hold and undo

Tuesday 10:02, the Chief Fin Officer routes spend.approve $4,200 (Zendesk seats, Support) as E1 to the owner: priority 0.41 → digest. The 17:00 digest carries it with the envelope (62% → 83%), the vendor history, confidence "confident (0.79, 14 similar)", expiry Sunday, consequence "not approved; Support keeps 3 shared seats". The owner taps approve Wednesday 08:15; re-validation passes; hold-before PT1H starts; 08:40 the owner taps undo after remembering a pending vendor switch — the item withdraws before execution, override WRONG_JUDGMENT with text "moving to Intercom next month", which becomes a fact in the Support org memory. The next Zendesk proposal cites it and asks about Intercom instead.

10.2 PTO denial nobody answers

Priya asks for the 14th–18th off. Coverage model says two of three on-call engineers are already out; the Chief Human Officer proposes pto.deny with an alternative (16th–20th) as E1 to the MoR, Jordan, expiry P3D, consequence text visible to Priya: "Jordan is deciding; if nobody decides by Friday, it goes to the owner; if still undecided, accrued leave is approved by policy". Jordan is silent; reminder at 50% (Slack), at 90% (SMS). Friday: escalates to the owner. The owner is at an offsite; Sunday the item expires under the owner branch (P2D): the leave is accrued, in policy, no hard line → approved, Priya and Jordan told, E0 in the update "approved by policy default because nobody decided; coverage gap on the 14th–15th flagged E1 to Jordan". Jordan's idle-MoR signal fires. Chonksworth's review notes one pto.deny reached policy default and proposes nothing yet (one instance).

10.3 An IC escalates about their manager's feedback

Marco, Kelp Kitchen, texts HUMAN after a concern message about late clock-ins. The router delivers to the location MoR in 12 s with Marco's text; Marco receives "Sent to Dana. If no reply in 4h, the owner." The Chonk sees {occurred: true, category: feedback} and, for 30 days, any feedback.concern or schedule.reduce_hours for Marco is HUMAN_ONLY. Dana replies in 40 minutes and books a shift huddle; the audit entry is immutable; the Chief Human Officer's next brief to Marco does not mention the escalation.

10.4 Headcount change with quorum, split decision

The Chief Operating Orca proposes plan.change.headcount: move two engineers from Platform to Growth for the quarter, people_affected = 5 → quorum 2, band high. Recipients: owner and both MoRs. The owner approves Monday; the Platform MoR rejects Tuesday with CONTEXT_YOU_LACK: "Platform is carrying an unannounced compliance deadline". Split → not executed; all three told; the compliance deadline becomes a fact in the Platform org memory (visible), and the planner's next proposal routes around it. Trust for planning −3.

10.5 A fatigued owner

Week 6 of a Full Suite tenant: 23 open E1 items for the owner, cap 10. The Harness composes nine tool renewals under $1,500 into one item ("approve all, or untick"), delegates four org-scoped cadence changes to the MoRs (route allows), and stops generating weekly-priority proposals for the owner; requesters see "queued behind 10 decisions". Chonksworth's Monday paragraph proposes raising auto_limit for the tooling category to $1,500 with the simulation report (14 of 14 unedited approvals; $9,800 would have executed autonomously last month; approvals trust at 71). The owner taps approve; the ruleset canaries on Support for a week; the shape stops arriving.

11. Edge cases

ID Scenario Signal / detection Rule Action (class) Escalation Test
EC-ESC-001 The MoR is the subject of an IC escalation Escalation category or content names the MoR; IC ticks "about my manager of record" §3.2 Route directly to the owner; MoR sees nothing (AUTONOMOUS, router) E3 to owner; ops if the tenant has one human SIM-KK-021
EC-ESC-002 MoR on PTO with no delegate set available(mor) false §3.1 Route to parent-org MoR, else owner; MoR told on return (AUTONOMOUS) E0 to owner: "set a delegate" Mark MoR on PTO in sim, raise E1
EC-ESC-003 Solo founder is owner and MoR; escalation is about them Approver set size 1; category conduct §3.2, §6 Router delivers to Sea Suite ops; time-quorum for their approvals (n/a) E3 to ops SIM-TP-071
EC-ESC-004 Owner taps undo after an undo-after action executed and the window closed Undo outside window §5 Treated as a repair request: compensator proposed as a new decision, PROPOSE_CONFIRM if dirty (PROPOSE_CONFIRM) E2 if the compensator fails Undo plan.rebalance at window + 1 min
EC-ESC-005 Two quorum approvers tap conflicting decisions within the same second Concurrent writes on quorum §6 split Deterministic: reject wins; both told; no execution (n/a) None Concurrency test in the inbox service
EC-ESC-006 IC escalation while the tenant is at KS-L3 Router receives while manager runtime paused §8.2 independence Delivered normally; ack names the human; nothing else runs (AUTONOMOUS, router) E3 Set L3 in sim, escalate
EC-ESC-007 Escalation content contains a harassment allegation Category conduct; legal-topic classifier R-HR-003 topics; §8.2 Delivered raw to the human; not summarised, embedded or stored beyond metadata; adverse-action guard armed for all named parties (HUMAN_ONLY) E3; E4 if threat language SIM-TP-072
EC-ESC-008 Onboarding completed without an MoR for one org Org Model lint at end of listening §3.3 Tenant cannot leave listening for that org; the owner is MoR of last resort meanwhile (n/a) E1 to owner: name an MoR Omit MoR in sim onboarding
EC-ESC-009 An IC escalates 20 times in an hour Router volume §8.2 no rate limit All delivered; the MoR sees them grouped; nothing is dropped (AUTONOMOUS, router) E3 Load test the router
EC-ESC-010 Owner delegates all E1 to an MoR who is also the requester on some items Requester = approver check §6 who counts Items where the delegate is requester route to the next in chain (n/a) E0 to owner SIM-TP-073

Open questions

  1. Should the draft of an undelivered repeat concern (awaiting the MoR) be visible on the IC's transparency page? Symmetry says yes; the risk is anxiety over a draft a human may reject. Proposal: show "a human is reviewing a note about " without the text.
  2. Time-quorum cooling-off for solo owners: is 4 h too short for a $30k approval at 23:00? Consider making the minimum 4 h of business hours.
  3. In Function mode, should the existing human manager also receive the IC's E3 escalation, or should E3 always bypass to a designated human above them? Current: the human manager is the MoR unless the escalation is about them.
  4. Whether approve_now should be unavailable for external.publish and money over quorum_limit regardless of owner preference (a platform minimum hold).
  5. Delegation to a person outside the tenant (an accountant, a fractional COO) — allowed as an Org Model person with a guest role, or never?