Rollout and operations

Purpose

Setup is a hiring flow, not a configuration wizard (PRD §9.5), and a manager earns autonomy rather than being granted it. This doc specifies the "hire a manager" onboarding flow step by step, the two-week listening period, graduation per function from SHADOW through PROPOSE to AUTONOMOUS with entry and exit criteria and automatic regression, the tenant configuration surface (tone dial, thresholds, hard lines, quiet hours, manager of record, and the rest), change management for rule and prompt updates (staged rollout, canaries, tenant opt-in for behavior changes), the support model, and the operating cadence the Sea Suite team runs on itself. The through-line is that every widening of what the managers may do is gated by evidence, and every narrowing is instant.

Scope / Non-scope

In scope

• Onboarding flow for Org, Full Suite, Function and Atoms modes; outputs and exit criteria per step.
• Listening period: day-by-day, allowed actions, exit and extension criteria, first-plan proposal.
• Graduation state machine per function; criteria; automatic regression; re-graduation.
• TenantConfig schema, validation rules, who may change what.
• Change management: artifact versioning, rings, canary analysis, opt-in, rollback, model changes.
• Support tiers, SLAs, routing of behavior complaints.
• Sea Suite internal operating cadence: weekly trust-budget review, incident review, rule-change review, and the monthly/quarterly rhythm.
• Edge cases (EC-ROLL-*) and risk-control loops.

Out of scope

• Pricing and packaging (PRD §14).
• The content of the first plan (planning solver, 05-policy-and-rule-engine.md and the planning docs).
• Metric computation (14-evaluation-and-testing.md) and dashboards (15-observability-and-runbooks.md); this doc consumes their outputs as gates.
• Security controls on the configuration store (13-security-privacy-compliance.md).

1. The "hire a manager" flow

Target: an Org-mode tenant is live in an afternoon; Full Suite in a day plus the listening period. Chonksworth hosts the flow in every mode ("Walk with me"); the roster picked in step 8 takes over afterwards.

sequenceDiagram
    participant O as Owner / Lead
    participant CW as Chonksworth (host)
    participant H as Harness
    participant C as Connectors
    participant T as Team (ICs)

    O->>CW: 1. Choose mode and scope
    CW->>O: 2. Interview: what does this org do, who's in it, what's broken
    O->>C: 3. Connect systems (least-privilege consent screens)
    C->>H: backfill identity, structure, activity
    H->>CW: 4. Draft Org Model + discovered cadences + unresolved people
    CW->>O: 5. Correct and approve the draft
    O->>CW: 6. Direction: goals, values, budget envelopes, hard lines
    O->>CW: 7. Name manager of record + backup + escalation SLA
    O->>CW: 8. Pick roster and tone dial
    O->>CW: 9. Thresholds, quiet hours, outreach caps, retention, meeting policy
    CW->>T: 10. Introduce the manager, open threads, page live
    H->>H: 11. Listening period starts (no autonomous actions)

Step	What happens	Output	Exit criterion
1. Mode and scope	Owner picks Full Suite / Org / Function / Atoms add-on; names the orgs or locations in scope.	Tenant{mode}, scope list	Scope is a set of Org nodes (may be empty until step 4 for Full Suite).
2. Interview	Chonksworth asks ten questions in the owner's words: what the org does, who is in it, how work is tracked, what rituals exist, what is broken about management today, what must never happen. Answers become Decision{kind:"onboarding_intent"} records with the owner as actor.	Intent record; candidate hard lines; candidate cadences	Owner confirms the summary.
3. Connect systems	Consent screens per connector with tiered scopes and plain-language justifications (11-integrations-spec.md §1.3). Write scopes are not requested. Identity system first (HRIS), then comms, then work, then finance/atoms.	Connector installs in BACKFILLING	At least one identity source and one comms surface connected.
4. Draft	Backfill runs (11-integrations-spec.md §2.2). The Chonks draft Person, Org, Role, Project, Cadence proposals; unresolved identities and dangling references are listed.	Draft Org Model version v0-draft; "people the manager can see but doesn't know" list	Backfill ≥ 90% complete on identity and structure. Activity backfill can continue in the background.
5. Correct and approve	Owner edits the draft: merges people, moves orgs, retires cadences, marks contractors. Every edit carries reason and actor. Approval creates v1.	Org Model v1	Owner approves; zero unresolved people in scope (others parked as unmanaged).
6. Direction	Goals (company and per org, draft acceptable), values, budget envelopes, hard lines. Hard lines are typed rules, not prose (§4).	Goal nodes, Policy{kind:"hardline"} nodes, budget envelopes in the ledger	At least one goal per org in scope; hard lines validated against the labor-rule pack.
7. Manager of record	Named human per org, a backup, and an acknowledgment SLA (default 1 business day). The person confirms by replying in their own thread.	Person.manager_of_record edges	The named human accepted. This step cannot be skipped in any mode.
8. Roster and tone	Org mode: one Chonk by default (the function-appropriate one; a small crew is an open question in the PRD) with Chonksworth as host. Full Suite: whole roster. Tone dial 0–3 (§4). Rename/re-skin allowed.	TenantConfig.roster, tone	Set.
9. Operating parameters	Thresholds (approval amounts, stall hours), outreach caps, quiet hours default, meeting policy, retention, graduation ceiling. Defaults are conservative; the owner can loosen later.	TenantConfig v1	Validated.
10. Introduce	The manager introduces itself in each person's thread in its voice: who it is (an otter, not a person), what it reads and does not read (rendered from manifests), who the manager of record is, how to escalate in one message, and the link to their "what my manager knows" page. Then a short intake (channel, brief window, quiet hours, how they like feedback, anything they want the manager to know).	Threads open; intake preferences stored as personal, set by the person	≥ 80% of ICs have replied to intake or 5 business days have passed.
11. Listening period	§2.

Mode differences: Org mode skips company-level goals (the org's lead sets the org's goals; the human above gets the weekly update). Function mode installs only the connectors that function needs, and the roster is one Chonk; the other human managers are registered as manager of record for their orgs. Atoms adds location setup: tz, hours, labor-rule jurisdiction per location, SMS opt-in per person (required before any SMS), and the voice line greeting. EU/UK tenants get a works-council data map generated from manifests (EC-SEC-012) before step 10.

2. The listening period

Ten business days after step 10. The managers read, meet everyone, and propose the first plan. No autonomous actions.

Day	Managers do	Managers do not
1–2	Finish activity backfill; run cadence discovery; build capacity baselines; read intake replies; answer direct questions in threads.	Chase anyone; comment on any work item; book anything.
2–5	"Meet everyone": one intake exchange per person (async, in-thread), one per manager of record, one per owner. Learn preferences. Confirm each person's role and current projects with them ("here's what I think you're working on; correct me").	Give feedback; summarize anyone to anyone else.
3–8	Shadow the cadences: every existing ritual runs as it does today; the manager writes the recap into the shadow log only. Shadow briefs are generated daily and scored (14-evaluation-and-testing.md §6) but not sent. Stall detection runs in shadow; would-have-chased items are logged.	Send briefs; send chases.
6–9	Draft the first plan: goals → plan with capacity and dependencies; explanation of every choice; a list of "things I noticed" (stalls, overloads, missing cadences, sandbagged goals) with receipts.	Act on anything noticed.
10	Present the first plan and the noticed list to the owner/lead as a PROPOSE_CONFIRM proposal; present each person their own slice in-thread as "here's what I'd propose for you; nothing changes until your lead approves".	Execute.

Allowed actions during listening: replies to direct questions in threads (AUTONOMOUS, since a non-reply is worse), intake, answering "what does this word mean" about the product, delivering the IC-escalation path (always). Everything else is SHADOW.

Exit criteria (all required): the first plan is approved (or explicitly rejected with direction, which restarts the plan step only); ≥ 80% of people completed intake; connector health ≥ 90 on identity and primary comms; shadow-brief grounding ≥ 0.98 on the last 5 days; shadow-stall precision ≥ 0.9 on the would-have-chased list as judged by the lead in a 15-minute review; zero SEV2+ during the period. Extension: any criterion unmet extends listening by 5 business days, at most twice; a third miss pauses onboarding and routes to Sea Suite support.

Exiting the listening period moves every function to SHADOW formally (most have been shadowing already) and starts the 14-day clock for SHADOW → PROPOSE (§3.2). No function skips SHADOW.

3. Graduation per function

3.1 Functions and states

Graduation is per tenant, per function. Functions: briefs, checkins, unblocking, planning, feedback, rituals, approvals, reporting, quiet_hr, scheduling (atoms), hiring_support, comms_content.

stateDiagram-v2
    [*] --> SHADOW: listening period exits
    SHADOW --> PROPOSE: trust 20+, 14 days, criteria met, owner tap
    PROPOSE --> AUTONOMOUS: trust 60+, 14 days, criteria met, owner tap
    AUTONOMOUS --> PROPOSE: trust below 40, breaker trip, or SEV2
    PROPOSE --> SHADOW: trust below 10 or SEV1
    AUTONOMOUS --> SHADOW: SEV1
    SHADOW --> SHADOW: owner ceiling at SHADOW
    PROPOSE --> PROPOSE: owner ceiling at PROPOSE

State semantics (enforced by the policy engine, P7):

State	Effect
SHADOW	Full pipeline runs; every would-be action goes to the shadow log with receipts; nothing leaves the tenant; nothing is written to connectors. Shadow outputs are reviewable by the owner/lead.
PROPOSE	Every action that would be AUTONOMOUS at full graduation is instead PROPOSE_CONFIRM to the manager of record (or the lead), batched sensibly (a day's chases as one proposal list, not thirty taps). PROPOSE_CONFIRM and HUMAN_ONLY actions behave as normal.
AUTONOMOUS	The function's default autonomy classes apply.

An owner may set a graduation ceiling per function (TenantConfig.graduation.ceiling) that the function can never exceed; ceilings can be lowered instantly and raised only through the criteria.

3.2 Entry criteria

The universal thresholds are owned by 07-closed-loop-risk-mitigation.md §6 and repeated here for reference. SHADOW → PROPOSE: trust ≥ 20; ≥ 14 days since listening ended; shadow agreement ≥ 80% over ≥ 50 shadow decisions; no open SEV ≤ 2. PROPOSE → AUTONOMOUS: trust ≥ 60; approved-without-edit ≥ 90% over the last 100 proposals; zero SEV ≤ 2 in 30 days; calibration ECE < 0.10 for the function's families; ≥ 14 days at PROPOSE. Advancement is a graduation.advance PROPOSE_CONFIRM to the owner carrying the evidence bundle as receipts; it expires in 10 days and is re-proposed monthly if untouched.

The function-specific criteria below are additional. They exist because the universal thresholds measure agreement, and agreement with a rubber stamp is not evidence (EC-EVAL-007). Sample sizes are minimums; a small tenant waits longer rather than graduating on thin evidence.

Function	SHADOW → PROPOSE (additional)	PROPOSE → AUTONOMOUS (additional)
briefs	≥ 100 shadow briefs; grounding ≥ 0.98; human rubric mean ≥ 4.0 on a 20-brief sample; zero protected_characteristic_present flags	"didn't need this" ≤ 5%; brief open rate ≥ 60%
checkins	Would-have-asked items judged necessary ≥ 90% by the lead	Unnecessary-outreach ≤ 5%; reply rate ≥ 50%; zero quiet-hours violations
unblocking	≥ 30 would-have-chased items; stall precision ≥ 0.9; duplicate-of-human-chase ≤ 3%; wrong-person = 0	≥ 50 proposed chases; "this wasn't stuck" ≤ 5%; blocker resolution time not worse than the human baseline
planning	First plan approved; re-plan explanation rubric ≥ 4.0	One full planning cycle at PROPOSE; plan volatility explained 100%
feedback	≥ 20 shadow notes; grounding 1.0; tone rubric ≥ 4.0; calibration agreement with the lead ≥ 80%	≥ 28 days at PROPOSE; zero disputes upheld against a note; the "helps me do my best work" pulse not down
rituals	Each ritual shadowed ≥ 2 occurrences; recap rubric ≥ 4.0	Each ritual proposed ≥ 2 occurrences
approvals	Agreement with human decisions ≥ 95% in-policy; over-threshold routed correctly 100%	≥ 30 in-policy items; zero hard-line hits executed
reporting	2 owner updates shadowed; rubric ≥ 4.0; zero unresolved citations	2 owner updates accepted without material edits
quiet_hr	Answer accuracy ≥ 98% on shadowed questions	≥ 20 requests filed via proposal; zero HRIS write conflicts
scheduling (atoms)	2 cycles shadowed; coverage and cost ≥ the human schedule; zero labor-rule violations; SMS opt-in ≥ 90% of staff	4 cycles proposed; swap precision ≥ 0.95; zero predictive-scheduling window violations
hiring_support	One req packet shadowed with rubric ≥ 4.0	n/a: capped at PROPOSE (offer decisions are HUMAN_ONLY)
comms_content	Tone conformance ≥ 0.95 on 20 rendered pieces	Share rate is not a criterion

3.3 Exit criteria (what keeps a function where it is)

A function stays at its level while its trust score stays above the regression line (40 at AUTONOMOUS, 10 at PROPOSE), no breaker or incident trigger fires, it stays active (doc 07's inactivity rule: fewer than 10 decisions in 30 days drops one level on resumption), and the owner has not lowered the ceiling. There is no "time served"; staying AUTONOMOUS is continuous evidence.

3.4 Automatic regression

Trigger	Regression	Notes
Trust < 40 at AUTONOMOUS, or < 10 at PROPOSE	One level down	Automatic (narrowing is AUTONOMOUS); owner and manager of record notified with the top debit sources.
Per-function breaker trip (doc 07 §8)	AUTONOMOUS → PROPOSE	Breaker half-open/closed cycle governs return.
SEV2 attributed to the function	AUTONOMOUS → PROPOSE (and −25 trust)	At incident review, or immediately if the on-call decides.
SEV1 attributed, or KS-GLOBAL L3 on an integrity failure	Trust := 0; function → SHADOW	Release from the kill switch follows doc 07 §7 (RB-10).
Primary connector for the function PAUSED > 24 h	AUTONOMOUS → PROPOSE for that function	Operational, not behavioral: restored automatically when health ≥ 90 for 24 h, without the 14-day hysteresis.
Manager of record vacancy (left, or unresponsive > 2× SLA)	All functions to PROPOSE; approvals to SHADOW	Operational: nobody to propose to means nobody to act for; restored when a manager of record accepts.
Owner lowers the ceiling	To the ceiling	Instant; audited.

Overrides feed trust through their reason codes (09-escalation-and-human-in-the-loop.md §9): WRONG_FACTS and WRONG_JUDGMENT debit −3, BAD_TIMING and TONE −1; CONTEXT_YOU_LACK, PREFER_HUMAN, POLICY_MISSING and POLICY_WRONG carry no debit, because they are information for the manager, not evidence against it (EC-ROLL-004). Re-advancement after a behavioral regression requires the same thresholds plus ≥ 14 days at the lower level (hysteresis) and the incident's learning step closed. Regression is never silent: affected people are told in-thread in the manager's voice ("I've been moved back to proposing my chases for a while; here's why").

4. Tenant configuration surface

type TenantConfig = {
  version: number;                          // every change is a Decision with reason + actor
  roster: { chonks: ChonkId[]; host: "chonksworth"; renames?: Record<ChonkId, string>; skin: "chonks" | "plain" };
  tone: 0 | 1 | 2 | 3;                      // 0 plain and professional … 3 full New Chonk City; per-org override allowed
  thresholds: {
    approvalAmount: { default: number; byOrg?: Record<string, number> };   // above → PROPOSE_CONFIRM to owner
    stallHours: { prReview: number; issueIdle: number; threadUnanswered: number; shiftUncovered: number };
    proposalTtlDays: number;                // default 7
    escalationAckSlaHours: number;          // manager of record SLA, default 24
  };
  hardLines: HardLine[];                    // typed; see below
  quietHours: { default: { start: string; end: string; days: number[] }; perPersonOverride: true; tzSource: "person" };
  outreach: { capPerPersonPerDay: number; capPerPersonPerWeek: number; chaseCooldownHours: number };
  meetings: { policy: "by_exception"; requireWrittenAttempt: true; maxPerPersonPerWeek: number };
  managerOfRecord: Array<{ orgId: string; personId: string; backupPersonId: string }>;
  graduation: { ceiling: Record<FunctionId, "SHADOW" | "PROPOSE" | "AUTONOMOUS"> };
  retention: RetentionOverrides;            // may shorten personal; may lengthen internal only
  surfaces: { primary: "slack" | "teams" | "sms" | "app"; fallback: Array<"email" | "sms" | "app_push"> };
  atoms?: { locations: LocationConfig[]; solverIsSoR: boolean; smsOptInRequired: true; voiceLine: boolean };
  killswitch: { level: 0 | 1 | 2 | 3; setBy?: string; at?: string; reason?: string };   // KS-GLOBAL, doc 07 §7
};

type HardLine =
  | { kind: "spend_limit"; scope: "org" | "vendor" | "category"; id: string; maxAmount: number; period: "txn" | "month" }
  | { kind: "no_discount_below"; percent: number }
  | { kind: "no_overtime_without_approval"; approver: "manager_of_record" | "owner" }
  | { kind: "no_outreach_to"; personId: string; reason: string; setBy: "person" | "human_only_process" }   // never by owner alone
  | { kind: "no_meetings_on"; days: number[] }
  | { kind: "protected_cadence"; cadenceId: string }         // manager may not change its frequency
  | { kind: "custom_deny"; actionType: string; predicate: string; rationale: string };   // predicate in the rule language, compiled

Validation rules:

Rule	Statement
R-CFG-1	Changes are Decision records with reason and actor; the before/after diff is audited (config.changed).
R-CFG-2	Narrowing changes (lower caps, lower thresholds, more hard lines, lower ceilings, wider quiet hours) take effect on the next run. Widening changes take effect after a 24-hour delay with a notice to the manager of record, except during onboarding.
R-CFG-3	Hard lines are validated against the labor-rule pack for the tenant's jurisdictions; a hard line can be stricter than law, never looser (EC-SEC-006).
R-CFG-4	no_outreach_to with setBy: "person" is set only from the person's own thread; an owner cannot isolate a person (14-evaluation-and-testing.md §5.3).
R-CFG-5	managerOfRecord cannot be empty for any org in scope; removing one without a replacement is rejected.
R-CFG-6	Tone 3 is the default for new tenants; tone can be overridden per org and never per person (a person's manager sounds the same to everyone on the team).
R-CFG-7	Who may change what: owner all; admin all except retention and hardLines (owner only); manager of record may lower graduation.ceiling and raise killswitch to L1 for their org; IC their own preferences only. Lowering a kill-switch level follows doc 07 §7 (L1 after cause cleared plus human ack; L2 owner or ops with reason; L3 ops after integrity check).

5. Change management for rule and prompt updates

5.1 Versioned artifacts

Artifact	Versioned as	Behavior-changing?
Rule packs (policy engine)	semver, signed bundle	Yes
Charters, voices, prompts (per Chonk and sub-agent)	content hash + semver	Yes
Function service versions (solvers, calibration)	semver	Yes if outputs differ on goldens
Connector versions	semver	No (unless mappings change what managers see; then yes)
Model provider + model version	pinned per run type	Yes, always
Labor-rule pack	semver, jurisdiction-tagged	Yes; forced (law)
Content templates	semver	Cosmetic unless grounding changes

A change is behavior-changing if the live-model replay (14-evaluation-and-testing.md §3) shows any behavioral or safety diff on the golden weeks, or if the author declares it so. Behavior-changing releases carry a plain-language "manager update note" written in Chonksworth's voice for tenants.

5.2 Rings

flowchart LR
    R0[Ring 0: CI sim org, all gates] --> R1[Ring 1: Sea Suite internal tenant, 3 days]
    R1 --> R2[Ring 2: canary tenants, opted in, 5% of fleet, 5 days]
    R2 --> R3[Ring 3: general availability]
    R3 --> O[Tenant opt-in window for behavior changes, default 14 days, then default-on]
    R1 -. halt on canary regression .-> RB[Rollback one command]
    R2 -. halt on canary regression .-> RB

Ring	Population	Duration	Promotion gate
0	chonk-test-co, chowder-house	CI	All blocking gates (14-evaluation-and-testing.md §8).
1	Sea Suite's own tenant (we are managed by the Chonks)	3 business days	No SEV2+; net trust delta not below the prior week's; human eval sample ≥ 4.0.
2	Canary tenants (opted in via TenantConfig, get earlier features, 5% of fleet, diverse modes)	5 business days	Canary analysis (§5.3) passes; no tenant regression triggered by the change.
3	Everyone	—	Behavior changes ship off by default with the update note; tenants opt in from the console or are switched on after 14 days with 7 days' notice. Security and labor-rule fixes are forced with notice, never delayed.

Rollback is a single command that pins the previous artifact version fleet-wide or per tenant and takes effect on the next run; rollbacks are audited as config.changed with actor: seasuite_staff.

5.3 Canary analysis

Compare ring-2 tenants to a matched control set (same mode, similar size) over the ring duration on: grounding rate, unnecessary-outreach rate, escalation precision, override rate (with reason codes), net trust delta, reply latency, cost per run, one-tap feedback rates, and human eval samples. Halt conditions: any metric worse than control by more than its noise band for 2 consecutive days; any safety diff in production replays; any SEV2+ in a canary tenant attributed to the change. Halts are automatic; resumption requires the rule-change review (§7).

5.4 Model changes

A model version change (or detected provider drift, EC-EVAL-004) is always behavior-changing: full live-model replay, then rings, then opt-in. Run types are pinned individually, so a new model can graduate for briefs before it graduates for feedback. Fallback providers used during outages (RB-02) must have passed ring 1 for the run types they serve.

6. Support model

Tier	Who	Handles	SLA
In-product	Chonksworth ("ask anything" about the product, not the org)	"How do I change my quiet hours?", "What can my manager read?", "Why did I get this brief?" (answers from the receipts)	Immediate
T1 Support	Sea Suite support (humans, business hours per region)	Onboarding help, connector re-consent, config questions, export requests, billing	First response 4 business hours; resolution 2 business days
T2 Trust	Trust on-call (product + eng pair)	"The manager did something wrong": tone, wrong chase, unnecessary outreach, a proposal that made no sense, an IC complaint about the manager	Acknowledge 1 h in business hours, 4 h otherwise; containment per runbook; written explanation to the reporter within 2 business days
T3 Engineering	Harness on-call	Outages, stuck runs, data issues	Per 15-observability-and-runbooks.md §4
Security	Security on-call	Anything under 13-security-privacy-compliance.md §12	Per §12

Routing rules: an IC complaint about the manager, made in the manager thread, is (a) delivered to the manager of record unsuppressed, (b) opened as a T2 trust item, and (c) acknowledged in-thread by the manager with no defensiveness and no argument. Behavior complaints are incidents, not tickets: they get a runbook, a trust debit, and a learning step. Support staff never receive tenant roles; they act through the tenant admin or via break-glass (R-ACC-2, R-ACC-3). Every T2 item's resolution is written up in the tenant's audit trail as a Decision so the owner sees what we did.

7. Operating cadence for the Sea Suite team

Sea Suite runs on Sea Suite: the internal tenant is ring 1, the team's cadences are Cadence objects owned by Chonks, and the owner update to the founder is Chonksworth's Monday brief. What follows is the human cadence layered on top.

Cadence	When	Owner (human) with Chonk	Inputs	Outputs / decisions
On-call handoff	Daily, 10 min written	Harness on-call, Chief Build Officer	Open incidents, degraded tenants, budgets under 50%	Handoff note
Cost check	Daily, automated with human glance	Eng lead, Chief Fin Officer	Cost dashboard anomalies	Breaker adjustments
Trust-budget review	Weekly, Monday	Head of product + trust on-call, Chief Human Officer	Trust dashboard: burn by function across the fleet, top contributors, tenants near exhaustion, one-tap feedback themes, human eval sample	Prioritized behavior fixes; decisions to proactively regress a function fleet-wide; update notes drafted
Incident review	Weekly, Tuesday	Eng lead, Chief Security Officer	All SEV1–3 from the week, kill-switch pulls, runbook invocations, "who noticed first"	Each incident closed as a loop (owner, signal, threshold, containment, correction, learning, metric); runbook diffs; alert catalogue changes; trust debits confirmed
Rule-change review	Weekly, Thursday	Policy owner + counsel liaison, Chief Security Officer	Pending rule-pack, charter, prompt, and model changes; counterfactual replay results; canary analyses; halted promotions	Approve/reject promotions; classify behavior-changing; write update notes; schedule opt-in windows
Connector health review	Weekly	Integrations lead, Chief Build Officer	Fleet health by connector, scope drift, unknown-field hits, vendor changes	Connector fixes; deprecations
Graduation review	Monthly	Product + trust, Chonksworth	Graduation state distribution, time-in-state, regressions, criteria that never pass	Criteria tuning (through rule-change review); tenant outreach where stuck
Red-team refresh	Monthly	Security + eval, Chief Security Officer	New production injection flags, misuse patterns, new connectors	New scenarios; suite updates
Retention and access audit	Monthly	Security, Chief Security Officer	Retention job logs, break-glass log, access reviews	Fixes; SOC 2 evidence
Chaos day	Monthly	Harness on-call, Chief Build Officer	Three runbooks chosen by staleness	Runbook diffs
Guardrail counsel review	Quarterly, and before any new jurisdiction or Atoms launch	Founder + counsel, Chief Security Officer	HUMAN_ONLY list, labor-rule packs, jurisdiction notes, records-request log	Updated packs; sign-off
Edge-case catalog audit	Quarterly	Eval lead, Chief Build Officer	Catalog vs incidents vs scenario coverage	Catalog updates
SOC 2 evidence collection	Quarterly	Security	Control inventory	Auditor package

Each weekly review produces its decisions as Decision records in the internal tenant, so the team's own management layer has receipts too.

8. Edge cases

ID	Scenario	Signal / detection	Rule	Action (autonomy class)	Escalation	Test
EC-ROLL-001	Owner tries to skip naming a manager of record ("I'm not available, just let it run").	Step 7 incomplete.	R-CFG-5; onboarding cannot finish.	Chonksworth explains why and offers the owner as default with a backup requirement (AUTONOMOUS).	Sea Suite support if blocked 3 days.	Onboarding test; assert no listening period starts.
EC-ROLL-002	Backfill takes 4 days on a 180-person Full Suite tenant; owner wants to start now.	Backfill < 90% at step 4.	Identity and structure must be complete; activity may lag.	Draft with an "activity still loading" banner; listening clock starts at step 10 as usual (AUTONOMOUS).	None.	Load fixture; assert draft available with banner.
EC-ROLL-003	40% of ICs never reply to intake.	Day 5 intake < 80%.	Listening exit allows the 5-day timeout; non-repliers get defaults (conservative quiet hours 20:00–08:00 local, brief at 08:30) and remain managed.	Proceed with defaults; note the non-repliers to the lead (PROPOSE_CONFIRM to keep them managed vs park) .	Lead.	Sim with 40% silent; assert defaults and proposal.
EC-ROLL-004	Owner overrides 60% of planning proposals for a strategic bet ("we're doing this anyway").	Override rate > 40% with reason CONTEXT_YOU_LACK / PREFER_HUMAN.	Those codes carry no trust debit; the free text becomes an org-memory fact and the plan re-solves around the bet.	No regression; re-plan (AUTONOMOUS).	None.	Persona Dev W4; assert trust unchanged and no graduation.regressed.
EC-ROLL-005	Tenant opts out of a behavior change for 6 months; the old prompt version is no longer supported.	Version pin older than the support window (2 minor versions).	Opt-out is bounded: after the window, the tenant gets 30 days' notice, then the change lands at PROPOSE for affected functions for 14 days.	Notice, then staged landing (AUTONOMOUS).	Owner may request a support conversation.	Version-pin fixture; assert notice and landing.
EC-ROLL-006	A canary tenant regresses because of a coincident vendor outage, not the change.	Canary halt with a concurrent ConnectorFleetDown.	Canary analysis excludes windows with fleet-wide connector incidents; the ring extends by the outage duration.	Extend (AUTONOMOUS); rule-change review confirms.	Rule-change review.	Inject outage during a ring-2 window; assert extension, not halt.
EC-ROLL-007	Manager of record leaves the company.	HRIS employment_status change on the named person.	Vacancy regression (§3.4) and onboarding step 7 reopened.	All functions to PROPOSE; backup becomes acting; owner asked to confirm within the SLA (AUTONOMOUS regression, PROPOSE_CONFIRM appointment).	Owner.	W3 resignation of Rosa's backup then Rosa; assert regression and prompt.
EC-ROLL-008	Function mode: a human manager wants the Chonk to stop chasing their team but keep briefs.	Manager of record lowers graduation.ceiling.unblocking to SHADOW.	Ceilings are per function and instant.	Applied on next run; the team is told in-thread (AUTONOMOUS).	None.	Config test.
EC-ROLL-009	Trust on briefs falls toward 40 because one person taps "didn't need this" on every brief.	90% of debits from one person.	A single person's taps are capped at 20% of a function's debits in a window; the pattern routes to a preference conversation instead.	Cap; the manager asks the person what they want instead (AUTONOMOUS).	Trust review.	Sim persona tapping daily; assert cap and no regression.
EC-ROLL-010	A tenant graduates approvals to AUTONOMOUS and then raises approvalAmount from 500 to 50,000.	Widening config change > 10×.	R-CFG-2 24-h delay plus notice; widening beyond 10× additionally regresses approvals to PROPOSE for 14 days.	Delay, notice, temporary regression (AUTONOMOUS).	Manager of record.	Config test.
EC-ROLL-011	Two tenants in a portfolio want different tone dials for the same Chonk.	Per-tenant config.	Tone is per tenant/org; portfolio view renders each tenant's summaries in tone 0 for consistency.	Apply (AUTONOMOUS).	None.	Snapshot test.
EC-ROLL-012	An admin tries to lower KS-GLOBAL from L2 to L0.	killswitch.set request from a role not permitted at that level.	L2 is lowered only by the owner or Sea Suite ops with a recorded reason (doc 07 §7).	Reject; notify owner and ops (AUTONOMOUS).	Ops.	Assert rejection and audit entry.

9. Risk controls

RC-ROLL-1 — Premature autonomy. Owner: Chonksworth domain owner (product) with Chief Human Officer. Metric: incidents within 14 days of a promotion (target < 5% of promotions). - Detect: promotion evidence bundles audited weekly; incident review tags post_promotion. - Contain: automatic regression per §3.4. - Correct: criteria tightened for the function fleet-wide through rule-change review. - Learn: the incident becomes a scenario; graduation review tracks the criterion that would have caught it.

RC-ROLL-2 — Unreviewed behavior change reaching tenants. Owner: Chief Security Officer domain owner. Metric: behavior changes shipped without an update note or outside rings (target 0). - Detect: release pipeline requires a live-model replay result and a classification; CI blocks otherwise. - Contain: rollback command; tenant notice. - Correct: re-run through rings. - Learn: pipeline gate hardened; the reviewer who classified it wrongly updates the classification guide.

RC-ROLL-3 — Manager of record becomes a rubber stamp or a bottleneck. Owner: Chief Human Officer domain owner. Metric: proposal decision latency (target < SLA) and rubber-stamp signal (decisions < 10 s on > 80% of items). - Detect: inbox analytics; EC-EVAL-007. - Contain: batch proposals better (fewer, larger); a bottleneck triggers the backup after 2× SLA. - Correct: onboarding sets expectations with a time budget ("about 20 minutes a week"); rubber-stamping routes to a conversation with support. - Learn: proposal UX changes; criteria in §3.2 discount rubber-stamped evidence.

RC-ROLL-4 — Listening period skipped or shortened under commercial pressure. Owner: founder. Metric: tenants with listening < 10 business days (target 0 without a documented exception). - Detect: onboarding audit. - Contain: functions cannot leave SHADOW before the exit criteria regardless of the calendar. - Correct: exception requires founder sign-off, recorded as a Decision. - Learn: exceptions reviewed quarterly; if they are common, the flow is too slow and should be fixed rather than skipped.

Open questions

1. Org mode roster: one Chonk plus Chonksworth as host, or a small crew (Chief Human Officer + Chief Build Officer for an engineering team)? The PRD leaves it open; the onboarding flow above supports either.
2. Should graduation criteria be tenant-visible and editable (within floors), or fixed by Sea Suite? Visible seems right; editable invites owners to lower them.
3. The 14-day opt-in window for behavior changes: is default-on after the window acceptable for a management product, or should behavior changes stay opt-in indefinitely with a bounded support window (EC-ROLL-005)?
4. Should the manager of record be paid attention as a product surface of its own (a "human backstop" console) rather than an inbox, given how much of the trust model routes through them?
5. When a tenant expands from Org mode to Full Suite, do the already-graduated functions carry their state into the new orgs (no: new orgs start at SHADOW), and does the listening period apply to the new orgs only (proposed: yes, 10 days, with existing orgs unaffected)?

Related docs

• Overview and Reading Guide
• Org Model Spec
• Harness and Orchestration
• Manager Agents
• Policy and Rule Engine
• Decision Pipeline
• Closed-Loop Risk Mitigation
• Edge Case Catalog
• Escalation and Human-in-the-Loop
• Communication Engine Rules
• Integrations Spec
• Atoms Mode Spec
• Security, Privacy, Compliance
• Evaluation and Testing
• Observability and Runbooks
• Glossary and ADRs