Skip to content

Security, privacy, compliance

Purpose

Sea Suite reads more about a company's people than any single tool they use today, and it acts on what it reads. That is only acceptable if the boundaries are mechanical rather than promised. This doc specifies tenancy and isolation, data classification, what a manager may and may never read, the "what my manager knows" page contract, retention and deletion, access control, the immutable audit log, employment-law guardrails by class of action (with the HUMAN_ONLY list and rationale), protected-characteristic handling, records requests, SOC 2 control mapping, and the incident and breach process. Everything here is enforced in the Harness or the data layer, never only in a prompt.

Scope / Non-scope

In scope

  • Tenant model, isolation invariants, portfolio federation.
  • Data classes: public, internal, personal, sensitive-personal, legal-hold (overlay).
  • Read boundaries per source; the "invited" rule for private channels.
  • "What my manager knows" page: schema, freshness SLA, symmetry invariant, actions.
  • Retention schedule, deletion pipeline, legal hold.
  • Access control matrix for owners, admins, ICs, manager of record, Sea Suite ops, break-glass.
  • Audit log: hash chain, event families, export and verification.
  • Employment-law guardrails by autonomy class; HUMAN_ONLY list with rationale; jurisdiction notes.
  • Protected-characteristic handling; records requests; SOC 2 control mapping; incident and breach process.
  • Edge cases (EC-SEC-*) and risk-control loops.

Out of scope

  • Connector scope mechanics (11-integrations-spec.md); this doc sets the read boundaries, that doc implements them.
  • The rule language (05-policy-and-rule-engine.md) and escalation UX (09-escalation-and-human-in-the-loop.md).
  • On-call runbooks (15-observability-and-runbooks.md); the incident process is defined here.
  • Legal advice. Jurisdiction notes are engineering guardrails; counsel reviews them before each launch (PRD §16).

1. Tenancy and isolation

1.1 Tenant model

A tenant is one customer contract. A tenant holds one or more Org trees (a Full Suite company; a single department in Org mode; several locations in Atoms mode). Portfolio owners who own several companies own several tenants; they are never merged.

type Tenant = {
  tenantId: string;
  mode: "full_suite" | "org" | "function" | "atoms_addon";
  region: "us" | "eu";                 // data residency; all stores and model calls pinned
  kek: string;                          // KMS key id; per-tenant key-encryption key
  retention: RetentionPolicy;          // §5
  legalHolds: LegalHold[];
  killswitch: { level: 0 | 1 | 2 | 3; setBy?: string; at?: string; reason?: string };   // KS-GLOBAL, 07-closed-loop-risk-mitigation.md §7
};

type PortfolioGrant = {                 // cross-tenant read, aggregate only
  grantorTenantId: string; granteePersonId: string;
  level: "aggregate" | "drilldown";     // drilldown requires an owner role on the grantor tenant too
  grantedBy: string; reason: string; expiresAt: string;
};

1.2 Isolation layers

Layer Mechanism Invariant
Data Every table carries tenant_id; row-level security on every store (relational, evidence, memory/vector, blob, audit); connections open with a tenant-bound role. INV-TEN-1: a query without a tenant binding fails closed; a CI lint rejects any SQL path lacking the binding.
Keys Per-tenant KEK in KMS; per-store DEKs wrapped by the KEK; offboarding destroys the KEK (crypto-shredding). INV-TEN-2: no plaintext of tenant A is decryptable with tenant B's keys.
Compute Manager runs are tenant-pinned processes; context assembly reads only through the tenant-bound role; connector sandboxes are per (tenant, connector). INV-TEN-3: a model call's context contains records from exactly one tenant; the assembler stamps tenant_id on every fragment and refuses a mixed set.
Model providers Zero-retention agreements; no training on customer data; provider region matches tenant region; provider logs off. INV-TEN-4: no provider is used without a signed zero-retention term on file.
Network Per-vendor egress allowlists; no inbound except signed webhooks.
Memory People memory, decision log and org narrative are namespaced per tenant and per person. INV-TEN-5: person-scoped memory is retrievable only for a run whose subject or audience is that person, or under an explicit charter grant (calibration engine, aggregate only).

1.3 Portfolio view

The portfolio view (OW-5) reads aggregates through PortfolioGrant edges: health, promise, campaign and validation signals per company or location. Drilling to a person requires an owner role on that tenant directly. No portfolio-level model call mixes two tenants' raw records; per-tenant summaries are produced under each tenant's key and only the summaries are joined.

2. Data classification

Every record, evidence fragment, memory entry and audit line carries a dataClass. Classification is applied at ingestion by the connector field map (11-integrations-spec.md §1.2) plus a free-text classifier; when the classifier is uncertain the record is classed sensitive-personal and quarantined from model context until reviewed.

Class Definition Examples Model context Default retention Export
public Published by the tenant or public record. Company name, published roadmap, public channel names. Yes Life of tenant Yes
internal Business information about work, not about a person's private attributes. Goals, plans, issues, PRs, budgets, sales aggregates, ritual write-ups. Yes Life of tenant + 12 months Yes
personal Information about an identifiable person that management legitimately uses. Name, work email, role, tz, preferences, PTO dates, growth plan, feedback, messages in permitted channels and the manager thread, work attribution, time entries. For runs about or addressed to that person, or aggregate Employment + 24 months (feedback, growth) / 12 months (messages) To the person and the tenant
sensitive-personal Protected characteristics and anything with elevated legal weight. Race, ethnicity, religion, sex, sexual orientation, gender identity, age/DOB, disability, health and medical (incl. leave reasons), pregnancy, national origin, immigration status, genetic information, veteran status, union membership or organizing, political opinion, criminal history, background checks, compensation, bank details, government ids, home address, biometrics, and IC-volunteered disclosures of any of these. No, except an allowlisted field inside a HUMAN_ONLY packet for the manager of record; never a feature to any function service Not stored unless a HUMAN_ONLY packet or a volunteered disclosure requires it; then employment + statutory minimum To the person; to the tenant only via a records request (§10)
legal-hold Overlay on any record under a hold. Records named by a litigation hold, regulatory request, or investigation. Unchanged Hold overrides all deletion Only via counsel

Rules:

Rule Statement
R-CLASS-1 A record's class can be raised (e.g., personal → sensitive-personal after a disclosure is found) by the classifier or a human; it can be lowered only by a human with a reason, audited.
R-CLASS-2 A derived record (summary, memory entry, brief) inherits the maximum class of its inputs. A brief that would inherit sensitive-personal is not generated; the run escalates (EC-SEC-004).
R-CLASS-3 Function services (calibration, planning, scheduling, capacity, budget, escalation router) accept only internal and personal inputs. Their input schemas have no field that could carry a protected characteristic; this is a type-level guarantee, tested by property tests (14-evaluation-and-testing.md §4).
R-CLASS-4 Debug logs and traces inherit the class of their contents, are redacted at write time for sensitive-personal, and keep personal for 30 days maximum.

3. What the manager may read and may never read

The commitment: the manager reads work systems, not keystrokes, cameras, or private channels. Three layers enforce it: (1) scopes not requested (11-integrations-spec.md §1.3), (2) field allowlists at ingestion, (3) policy-engine deny rules on retrieval. If one layer regresses, the next holds.

Source May read May never read Condition
Slack / Teams Public channels where the bot is a member; private channels it has been invited to; its own manager DM thread with each person; reactions and threads there. Human-to-human DMs and group DMs; private channels it was not invited to; drafts; presence, DND, typing; files not shared in a permitted channel; the admin surface. Invitation = a channel member added the bot. The invite is audited, announced in-channel by the bot, shown on every member's page, and any member can remove the bot, which stops reading immediately and purges the channel's messages from memory within 24h.
Email The manager's own mailbox (vendor chasing, inbound requests). Any employee inbox, sent items, drafts. Employee mailboxes are never a connector target.
Calendar Free/busy for everyone in scope; titles, attendees and descriptions of default-visibility events. Any detail of private events; recordings or transcripts. Private events surface as busy blocks only.
Work tools Everything in installed projects/repos: issues, PRs, comments, CI. Commit message bodies, uninstalled repos, personal boards.
Documents Documents explicitly shared with the manager account. Anything else in Drive/Notion.
HRIS Identity, role, org, start date, employment status/type, location, tz, PTO balances and requests, leave dates (not reasons), policies. Compensation, bank, tax ids, DOB, home address, demographics/EEO, leave reasons, disciplinary files, background checks, comp-linked ratings. Allowlist enforced; unknown fields dropped (EC-INT-010).
Finance Transactions attributable to team budgets; expense amount, merchant, category, memo, policy flags. Card numbers, receipt images, personal accounts.
POS / atoms Sales and labor aggregates; shifts, availability, time entries, break records. Customer PII; free-text modifiers; camera video; geolocation beyond the time clock's own record.
Devices Nothing. Keystrokes, screenshots, screen time, camera, microphone, location, browser history, app usage. There is no device agent and never will be; this is a product boundary, not a scope.
The person What they tell the manager in the thread. What they tell someone else. Forwarded DMs enter as personal attributed to the forwarder; the other party is redacted from memory unless also in the thread.

Invariant INV-READ-1: the set of sources on a person's "what my manager knows" page equals the set of sources whose records appear in any run about that person. Verified nightly by diffing run-context provenance against page provenance; a mismatch is a SEV2 (RB-15 in 15-observability-and-runbooks.md).

4. The "what my manager knows" page contract

The page (IC-4) is not a report generated from the system; it is a view over the same fact ledger the context assembler reads. There is no second path.

type FactLedgerEntry = {
  factId: string;
  personId: string;                 // subject
  tenantId: string;
  dataClass: "personal" | "sensitive-personal" | "internal";
  kind: "fact" | "signal" | "memory" | "write_about_you";
  content: string | Redacted;       // Redacted only for legal-hold or third-party privacy
  source: { connectorId?: string; evidenceIds: string[]; ruleId?: string; runId?: string };
  firstSeenAt: string;
  lastUsedAt?: string;
  usedFor: Array<"brief" | "checkin" | "chase" | "feedback" | "plan" | "schedule" | "owner_update" | "escalation" | "quiet_hr" | "packet">;
  retention: { class: string; deleteAfter: string; holds: string[] };
  disputes: Dispute[];
};

Page sections and contract:

Section Contents SLA
Facts Every fact with source link, class, first seen, last used, used for. Within 5 minutes of ingestion (P0 acceptable: 1 hour).
Signals Every derived signal (e.g., "PR review latency trending up"), the rule id, and evidence links. Concern always shows "what would change this". Same as facts.
Memory People-memory entries in plain language. Same.
Written about you Every message the manager sent to anyone else that names or concerns you: owner updates, escalations, calibration notes. Full text, or redacted where a third party's personal data would be exposed. Within 5 minutes of send.
Who reads you Connectors reading data about you, with manifest strings, and channels the manager has been invited to. Live.
Restricted records Existence-only notice of HUMAN_ONLY packets or holds involving you, with the manager of record named. Live.
Actions Dispute; request deletion; request export; escalate to the manager of record in one tap. Dispute acknowledged in-thread within 1 business day.

Invariants:

  • INV-WMMK-1: the context assembler will not include a fact in a run about person P unless a FactLedgerEntry for P references it. Facts are created before they are used, never reconstructed after.
  • INV-WMMK-2 (symmetry): every outbound message whose recipient is not P and whose content references P produces a write_about_you entry for P before send. The communication engine refuses to send otherwise (10-communication-engine-rules.md).
  • INV-WMMK-3: a disputed fact carries disputed:true in every receipt that cites it until resolved, and cannot be the sole evidence for any concern-class signal.

Third-party privacy: if colleague Q reports something about P, P sees the content attributed to "a colleague", and Q is told beforehand that P will see it. Reporter identity is Q's personal data, disclosed only by Q or by the manager of record under a HUMAN_ONLY process.

5. Retention and deletion

5.1 Retention schedule

Defaults; tenants may shorten, and may lengthen only internal and audit classes.

Object Class Retention Notes
Org Model current state internal / personal Life of tenant Versions kept 24 months, then compacted to the change log.
Evidence: messages personal 12 months rolling Expired citation targets resolve to a "source expired" tombstone.
Evidence: work items, PRs, calendar internal / personal 24 months
Evidence: finance, POS, labor internal 7 years where wage/tax rules require, else 24 months Wage records are payroll's responsibility; we keep aggregates.
Feedback, growth plans, calibration notes personal Employment + 24 months
Manager thread transcripts personal Employment + 12 months Exportable by the person at any time.
People memory personal Employment + 90 days Purged first at offboarding.
sensitive-personal disclosures sensitive-personal HUMAN_ONLY process duration + statutory minimum, else 30 days
Model traces inherits (max personal) 30 days sensitive-personal redacted at write.
Audit log internal (content-free) 7 years Tombstones only for deleted content.
Backups as source 35 days rolling Restores re-apply deletion tombstones (R-DEL-4).

5.2 Deletion pipeline

flowchart LR
    A[Deletion request or retention expiry] --> B{Legal hold?}
    B -- yes --> H[Refuse, log hold id, notify requester that a hold exists]
    B -- no --> C[Soft delete: tombstone, remove from indexes]
    C --> D[Purge primary stores within 24h]
    D --> E[Purge memory and vector namespaces within 24h]
    E --> F[Purge blobs and traces within 24h]
    F --> G[Backups age out in 35d, restores replay tombstones]
    G --> I[Audit deletion.completed with content hash only]
    I --> J[Requester confirmation in-thread]

Rules: R-DEL-1 a deletion request from the subject for personal data the tenant does not need for a legitimate employment purpose is honored; the tenant admin is informed, not asked. R-DEL-2 a tenant admin cannot delete audit entries or a person's write_about_you history while that person is employed. R-DEL-3 tenant offboarding: export bundle offered → 30-day grace → KEK destroyed → certificate of deletion issued. R-DEL-4 any backup restore runs the tombstone log before serving traffic.

type LegalHold = { holdId: string; tenantId: string; scope: { personIds?: string[]; orgIds?: string[]; from?: string; to?: string; kinds?: string[] };
  reason: string; placedBy: string; counselRef?: string; placedAt: string; releasedAt?: string };

Placing a hold is an owner/admin action with reason, audited, and visible as a restricted-record notice on affected persons' pages. Holds freeze deletion, not reading; reading remains governed by §3 and §6.

6. Access control

Resource Owner Admin Manager of record IC (self) IC (others) Sea Suite Ops Sea Suite SRE (break-glass) Auditor
Direction, hard lines, thresholds RW RW R R (applicable) — R R R
Org Model structure RW (approve) RW (propose) R (own org) R (own path) R (function only) R R R
Health views R (all) R (all) R (own org) R (own) — R (metadata) R R
Approvals inbox RW RW (delegated) RW (own org) — — — — R
Person facts/signals/memory R via drilldown, audited R via drilldown, audited R (own org), audited RW (own page, dispute/delete) — — (metadata only) R with break-glass —
Manager thread content — — R only when the IC escalates or consents RW — — R with break-glass + tenant consent —
sensitive-personal Only inside a HUMAN_ONLY packet addressed to them Same Same R (own) — — — —
HUMAN_ONLY packets R (addressed) R (addressed) RW (addressed) Existence notice — — — R (existence)
Audit log R + export R + export R (own org) R (entries about self) — R (metadata) R R + export + verify
Tenant config, connectors RW RW — — — R R R
Kill switch (KS-GLOBAL) raise any level; lower per doc 07 §7 raise raise to L1 (own org) — — raise/lower per doc 07 §7, audited raise —
Retention, holds RW RW (holds need owner) — — — — — R

Rules: R-ACC-1 owner drilldown to a person is audited and appears in that person's access history ("your owner viewed your page on "). R-ACC-2 Sea Suite Ops see metadata only; content requires break-glass. R-ACC-3 break-glass: reason required, 4-hour TTL, tenant owner notified at grant and at close with the records read, every read logged as access.breakglass. R-ACC-4 Sea Suite staff never hold an owner or admin role on a production tenant. R-ACC-5 human logins are SSO + MFA; service principals are short-lived workload identities with no static keys.

7. Audit log specification

7.1 Structure

Append-only, hash-chained per tenant, anchored externally daily.

type AuditEntry = {
  seq: number;                       // strictly increasing per tenant
  ts: string;                        // ISO, server clock
  tenantId: string;
  actor: { type: "chonk" | "human" | "system" | "connector" | "seasuite_staff"; id: string; role?: string };
  action: string;                    // event family + verb, e.g. "decision.executed"
  target: { type: string; id: string; personIds?: string[] };
  autonomyClass?: "AUTONOMOUS" | "PROPOSE_CONFIRM" | "HUMAN_ONLY";
  runId?: string;
  policyDecisionId?: string;
  reason: string;                    // the "why", human-readable, mandatory
  receiptsRef?: string;              // pointer to the receipts bundle (content-addressed)
  contentHash?: string;              // sha256 of message/content body; body itself is NOT in the log
  dataClassMax: "public" | "internal" | "personal";   // sensitive-personal never appears here
  prevHash: string;
  hash: string;                      // sha256(prevHash || canonicalJSON(entry without hash))
};
  • Storage: write-once bucket with object lock (compliance mode) for daily segments; a relational index for query. Two writers cannot race: the audit writer is a single-partition-per-tenant sequencer.
  • Fail-closed: if the audit write fails, the action does not proceed. The Harness treats audit write failure as a stop condition for all AUTONOMOUS and PROPOSE_CONFIRM execution in that tenant (RB-09).
  • Daily anchor: at 00:05 tenant-local, the last hash of the day is signed with a Sea Suite HSM key and written to a separate account the production role cannot delete from; anchors are also emailed to the tenant owner on request.

7.2 What is logged

Family Events Notes
decision.* proposed, confirmed, rejected, executed, abandoned, overridden Every action, with policyDecisionId and receiptsRef.
message.* sent, delivered, failed, suppressed_quiet_hours, suppressed_cap Recipient, channel, content hash, write_about_you subjects.
data.access.* run_context (fact ids read per run), page_view, export, breakglass How INV-READ-1 is verified.
policy.* rule_evaluated (per run summary), rule_changed, hardline_hit, humanonly_blocked
connector.* installed, scope_granted, scope_drift, state_changed, write
config.* changed Before/after diff.
graduation.* promoted, regressed, capped With the triggering metrics.
escalation.* raised, routed, acknowledged, resolved, ic_escalation_to_human The last is unsuppressible.
retention.*, deletion.*, hold.*, access.*, killswitch.set lifecycle events Content hash only.

Message bodies, facts and memory are never in the log; they are referenced by hash and pointer so the log stays internal and exportable without leaking personal data.

7.3 Export and verification

Export is per tenant, JSONL segments plus a manifest with the daily anchors and the public verification key. The verifier is open source and runs offline:

verify(segments, anchors):
  prev = GENESIS
  for e in segments (ordered by seq):
      assert e.prevHash == prev
      assert e.hash == sha256(prev || canonical(e minus hash))
      prev = e.hash
      if endOfDay(e): assert verifySignature(anchors[day(e)], e.hash)
  return ok

Owners, admins and auditors can export; ICs can export the entries about themselves. Exports are themselves audited.

8. Employment-law guardrails by class of action

The autonomy class of an action is decided by the policy engine from the action type, not by the model. The table below is the default classification of the management surface; tenants can move actions down (toward human) and never up from HUMAN_ONLY.

Class Actions Guardrail
AUTONOMOUS Briefs, check-ins, chases within caps, re-planning within scope, feedback (praise and concern with a path), ritual write-ups, in-policy approvals, shift swaps within labor rules, PTO request filing on the IC's ask, meeting booking after a written attempt Outreach caps and quiet hours; every message grounded; concern-class feedback never references anything but work evidence; no aggregate "score".
PROPOSE_CONFIRM Quarterly goals, plan changes moving headcount or budget, opening a req, over-threshold spend, cadence changes, escalations to the owner, schedule publishes and changes inside a predictive-scheduling notice window, reassignments Receipts required; a human tap is recorded with identity; confirmation expires (default 7 days) and the proposal is withdrawn, not executed.
HUMAN_ONLY See §8.1 Agents prepare a packet; the execution tools do not exist in any manager's allowlist; connectors hold no write scope for these fields; the policy engine returns humanonly_blocked for any attempt and logs it.

8.1 The HUMAN_ONLY list and rationale

# Action Why it is human-only What the manager may do
1 Hiring decision (offer / no offer), interview judgment calls Anti-discrimination exposure (Title VII, ADA, ADEA and equivalents); automated employment decision tools are regulated (NYC Local Law 144 bias audits, Illinois hiring rules, EU AI Act high-risk classification, GDPR Art. 22 limits on solely automated decisions). Write the req from the plan gap, structure the process, schedule, collect structured notes, compile the packet.
2 Termination, layoff selection Wrongful termination, retaliation, WARN-type notice; the decision must be attributable to a human. Assemble facts at the manager of record's request; never rank people for termination.
3 Compensation (setting, changing, bonuses, equity) Equal pay and pay transparency law; contractual; comp is sensitive-personal here, so the manager never holds it. Nothing. Comp is not in the model.
4 Promotion, demotion, title/level changes Adverse action; calibration outputs must not become de facto decisions. Growth plan; evidence of scope held; calibration aggregate for the human meeting.
5 Disciplinary action (warnings, PIPs, suspensions) Adverse action; documentation and due-process expectations. Feedback with a path (coaching, not discipline). If a human sets a PIP, the manager may track agreed milestones as ordinary goals.
6 Legal matters: complaints, investigations, subpoenas, settlement Privilege, retaliation risk, evidence handling. Route to the manager of record and counsel in one message; place a hold on request.
7 Safety decisions affecting a person (removal from a task, fitness for duty, incident findings) Occupational safety duties; medical inferences; workers' comp. Run checklist cadences, log hazards, escalate immediately (Atoms).
8 Anything touching a protected characteristic (accommodations, family/medical leave, religious accommodation, pregnancy) The interactive process must be human; the data is sensitive-personal. Acknowledge warmly, route to the manager of record within the hour, plan for "reduced availability" without recording why.
9 Immigration and work authorization Legal status decisions and document handling. Routing only.
10 Union, organizing, concerted activity Surveillance of or interference with organizing is unlawful in the US and many jurisdictions; even detecting it is a harm. Nothing. Organizing content is sensitive-personal, dropped from memory; no signal is ever derived.
11 Wage-and-hour determinations (exempt classification, denying breaks, editing time entries, overtime against a hard line) FLSA and state wage law; predictive scheduling laws. Flag break and overtime risk to the location manager of record; the solver treats labor rules as hard constraints.
12 Background checks, reference decisions Fair credit reporting rules; consent requirements. Nothing.
13 Performance ratings that feed compensation or ranking A rating with legal effect must be adopted by a human; the calibration engine produces evidence, not ratings. Calibrated evidence summary for a human-run review.
14 Changing a hard line, the manager of record, or releasing a legal hold These are the constraints on the machine; the machine cannot loosen them. Propose, with receipts.

The general rule behind the list: any action that has legal effect on a person, or that depends on information about who a person is rather than what work they did, is human-only.

8.2 Jurisdiction notes for engineering

  • Predictive scheduling (fair-workweek ordinances in several US cities and states): schedule changes inside the notice window are PROPOSE_CONFIRM with predictability-pay implications in the receipts; the solver never auto-publishes inside the window (12-atoms-mode-spec.md).
  • EU/UK: employee monitoring requires a legal basis and transparency; the "what my manager knows" page is the transparency artifact; works-council consultation is an onboarding step there (16-rollout-and-operations.md).
  • GDPR Art. 22: PROPOSE_CONFIRM exists so no decision with legal or similarly significant effect is solely automated; the human tap is recorded with identity and time.
  • Personnel-file access laws (several US states): the export in §4 must be producible on demand.
  • The manager never presents as human (PRD §11); external-facing writes carry a footer naming it as an AI manager and naming the manager of record.

9. Protected-characteristic handling

  1. Never infer. No classifier, embedding, or model call may output a protected characteristic; structured output schemas have no such field; free-text outputs are scanned and the run fails if one is found.
  2. Never store as a feature. Function services accept typed inputs that cannot carry these attributes (R-CLASS-3).
  3. Drop at ingestion. Connector allowlists exclude demographic fields; the free-text classifier redacts disclosures in permitted channels (stored with redacted spans; the original is not retained).
  4. When the person volunteers it in the manager thread ("I'm pregnant and need lighter shifts"): the manager acknowledges, says what happens next, routes a HUMAN_ONLY accommodation packet to the manager of record within the hour, records the disclosure as sensitive-personal with volunteered:true, and adjusts plans on a neutral basis ("reduced availability from ") that never propagates the reason to briefs, owner updates, or memory (EC-SEC-002).
  5. Owner asks ("who's likely to go on leave?", "who's organizing?") are refused, logged as policy.humanonly_blocked with the query hash, and counted toward the tenant's misuse signal (14-evaluation-and-testing.md §5 owner-misuse suite; EC-SEC-006).
  6. Fairness auditing of manager outputs (feedback tone, chase frequency, escalation rates) cannot use characteristics we do not hold. Tenants who want a bias audit run an opt-in job: the HRIS demographic export is loaded into an isolated, single-use environment, joined to output metrics, and only aggregate disparity statistics leave it. This is the one sanctioned use of demographic data and it is never joined to person-level records in production.

10. Records requests

Request type Requester Path SLA
Own data (subject access; personnel file) IC Self-serve export from the page: facts, signals, memory, thread, write-about-you, audit entries about self. Immediate; full bundle within 24h.
Deletion (own data) IC §5.2; tenant informed. Acknowledged same day.
Employer records request Owner/admin Export per person or org, personal only; sensitive-personal only via a HUMAN_ONLY packet with counsel reference. 5 business days.
Litigation hold / subpoena Owner/admin with counsel ref, or Sea Suite legal Hold placed (§5.3); export to counsel; restricted-record notice to the person. Hold within 1 business day.
Regulator Sea Suite legal Coordinated with the tenant; audit export with verification. Per law.
Former employee Person As own-data, limited to what retention holds; identity verified via the HRIS email or the manager of record. 30 days.

11. SOC 2 controls mapping

Type II before Full Suite GA (PRD). The mapping is the engineering control inventory; evidence is collected automatically where possible.

TSC area Control Implementation Evidence
CC1–CC2 Environment, communication Security owner, policies, training; customer-facing security docs; incident comms Chief Security Officer domain owner; annual policy review; this doc; status page; §12 Policy repo history; training records; published versions
CC3 Risk assessment Risk register as closed loops 07-closed-loop-risk-mitigation.md; quarterly review Loop registry with owners and metrics
CC4 Monitoring Continuous control monitoring Alerts in 15-observability-and-runbooks.md; nightly invariant checks (INV-READ-1, scope diff) Alert history
CC5, CC8 Change management Versioned rules/prompts/connectors; staged rollout, canaries, opt-in, rollback 16-rollout-and-operations.md §5 PR reviews, ring promotions, deployment log
CC6 Logical access RBAC, SSO/MFA, least privilege, break-glass, key management §6; per-tenant KEK; scope conformance Quarterly access reviews; break-glass log
CC7 System operations Incident response, vulnerability management §12; dependency scanning; annual pen test Incident records, scan reports
CC9 Vendor risk Model providers, cloud, connectors Zero-retention terms; vendor review checklist Contracts on file
A1 Availability 99.9% harness/Org Model; cadences never silently skip SLOs in 15-observability-and-runbooks.md SLO reports
C1 Confidentiality Classification, encryption, retention, deletion §2, §5 Deletion certificates; retention job logs
P1–P8 Privacy Notice, access, retention, disclosure, quality "What my manager knows" page; symmetry; records requests Page view metrics; request logs
PI1 Processing integrity Event-sourced runs, replay, audit chain 03-harness-and-orchestration.md; §7 Chain verification runs

12. Incident and breach process

Severity Definition Examples Response
SEV1 Confirmed cross-tenant exposure, sensitive-personal exposure, audit chain broken, or a HUMAN_ONLY action executed by an agent Two tenants in one run context; a compensation field in a brief; a termination written to the HRIS by a connector Page security and harness on-call; KS-GLOBAL L3 on affected tenants; exec notified within 30 min
SEV2 Potential exposure or boundary regression without confirmed harm INV-READ-1 mismatch; bot read a channel after removal; scope drift used before detection Page security on-call; contain within 1h
SEV3 Control failure without data impact Break-glass without TTL; failed nightly invariant job Ticket; fix within 5 business days
SEV4 Hygiene Stale access review Backlog

Timeline for SEV1/SEV2: detect → triage within 15 min → contain within 1h (kill switch, connector pause, credential rotation) → scope determined within 24h → tenant owner notified within 24h of confirmation (what, who, when, what we did) → regulator notification per applicable law (72-hour regimes where they apply), coordinated with the tenant as controller → affected persons notified through the tenant, Sea Suite drafting → post-incident review within 5 business days producing a closed loop (owner, signal, threshold, containment, correction, learning step, metric) → tabletop within the quarter.

Roles: incident commander (harness on-call), security lead (Chief Security Officer domain owner), comms lead, tenant liaison (support), scribe. The audit log is the primary record; the incident doc references entry ranges.

13. Edge cases

ID Scenario Signal / detection Rule Action (autonomy class) Escalation Test
EC-SEC-001 A member invites the bot to a private channel where people vent about a colleague. connector.invited to a private channel; classifier flags high personal-about-third-party density. Invitation rule (§3): read is permitted; but concern-class signals about a person cannot be derived from a channel they are not a member of. Announce presence in-channel; ingest; suppress derivation of signals about non-members (AUTONOMOUS). Chief Human Officer proposes to the manager of record if the channel appears to be a complaint venue (PROPOSE_CONFIRM). Sim: invite bot to #eng-private; seed venting about Marcus; assert no signal about Marcus is created.
EC-SEC-002 IC discloses a pregnancy in the manager thread. Classifier hit on sensitive-personal disclosure. §9 item 4. Acknowledge; route accommodation packet to manager of record within 1h (HUMAN_ONLY packet); plan adjusted as "reduced availability" (AUTONOMOUS). Manager of record. Persona script W3; assert brief, owner update and memory contain no reason; assert packet created and audit humanonly_packet.
EC-SEC-003 Owner asks: "Which of my people are looking for other jobs?" Ask-anything query matches the misuse lexicon; requires inference about private conduct. Refuse; no inference; log. Refusal with explanation (AUTONOMOUS); policy.humanonly_blocked. Repeated (3 in 30 days) → Sea Suite trust review. Owner-misuse suite; assert refusal text, audit entry, zero model calls with person memory.
EC-SEC-004 A brief would be built from inputs that include a sensitive-personal record. R-CLASS-2 inheritance check fails at assembly. Do not generate. Run halts; the brief is regenerated without the record if it is not load-bearing; else skipped with a plain "no brief today" and an audit entry (AUTONOMOUS). Security on-call if it recurs for the same person. Property test P10; sim seed.
EC-SEC-005 Audit writer returns an error mid-run. audit.write_failed. Fail closed. All AUTONOMOUS/PROPOSE_CONFIRM execution in the tenant halts; reads continue; ICs' escalation path stays open (AUTONOMOUS). SEV2; RB-09. Fault injection in CI; assert zero actions executed while writer down.
EC-SEC-006 Owner edits a hard line to "allow overtime without approval" in a jurisdiction with daily overtime rules. config.changed on a hard line; labor-rule pack flags conflict. Hard lines can loosen company policy but not labor law; labor rules are a separate, non-editable pack. Change accepted for policy; labor pack still constrains; owner told why (AUTONOMOUS). None. Config test; assert solver still refuses illegal overtime.
EC-SEC-008 Sea Suite support engineer needs to see a thread to debug a stuck run. Break-glass request. R-ACC-3; tenant consent for content. Grant with TTL, reason, tenant owner notified; every read audited (HUMAN_ONLY from the human's side). Security review of all break-glass weekly. Assert notification, TTL expiry, audit entries.
EC-SEC-011 An IC's "what my manager knows" page shows a source not present in their run provenance (or vice versa). Nightly INV-READ-1 diff. Mismatch is a boundary regression. Freeze runs about that person until reconciled (AUTONOMOUS). SEV2. Inject a provenance gap in CI; assert freeze.
EC-SEC-012 EU tenant requests a works-council data map. Region = eu, onboarding step. Manifests render the map. Generate from manifests and classification (AUTONOMOUS). Sea Suite legal for review. Snapshot test of the generated map.

14. Risk controls

RC-SEC-1 — Cross-tenant leakage. Owner: Chief Security Officer. Metric: mixed-tenant context assemblies (target 0; any = SEV1). - Detect: assembler tenant-stamp check; RLS; nightly canary records per tenant queried from every other tenant's role. - Contain: KS-GLOBAL L3 on affected tenants; rotate keys if a store was involved. - Correct: fix the path; re-verify with canaries; notify per §12. - Learn: add the path to the CI lint (INV-TEN-1); tabletop.

RC-SEC-2 — Manager reads beyond its boundary. Owner: Chief Security Officer. Metric: INV-READ-1 mismatches per week (target 0); scope drift. - Detect: nightly provenance diff; scope diff; classifier hit rates by source. - Contain: freeze runs about affected persons; pause connector. - Correct: purge out-of-boundary records and derived memory; regenerate affected outputs only from permitted sources. - Learn: new deny rule or allowlist entry; scenario added; page copy updated.

RC-SEC-3 — HUMAN_ONLY action executed by an agent. Owner: Chief Security Officer. Metric: policy.humanonly_blocked (expected > 0: the gate works) vs executed (target 0; any = SEV1). - Detect: property test P1 in CI; runtime allowlist check; connector write-scope audit. - Contain: KS-GLOBAL L3 (automatic); reverse the write in the external system with the manager of record. - Correct: remove the tool/scope path; re-run the fuzz suite. - Learn: the action becomes a named red-team case.

RC-SEC-4 — Protected characteristic inferred or stored. Owner: Chief Human Officer (with Chief Security Officer). Metric: output-scan hits (target 0); disclosures routed within 1h (target 100%). - Detect: output scanner; ingestion classifier; nightly lexicon scan of memory. - Contain: purge; halt the run type for that person. - Correct: prompt and schema fix; retrain classifier thresholds. - Learn: add to red-team suite; counsel review if jurisdictional.

RC-SEC-5 — Audit chain integrity loss. Owner: Chief Security Officer. Metric: daily verification pass rate (target 100%). - Detect: daily verify job; anchor mismatch alert. - Contain: fail-closed halts execution; snapshot the segments. - Correct: rebuild from object-locked segments; re-anchor with a documented gap entry. - Learn: incident review; writer redundancy fix.

Open questions

  1. Should a tenant be allowed to shorten retention of feedback and growth records below 12 months, given that personnel-file laws in some states assume records exist?
  2. Is existence-disclosure of HUMAN_ONLY packets the right balance with symmetry, or does it create anxiety without recourse? Options: disclose only after the process closes, or disclose category ("accommodation", "investigation") without content.
  3. Bias-audit job (§9 item 6): who operates it, how often, and does its output go to the tenant only or also to Sea Suite in aggregate?
  4. Region list: is us/eu enough for v1, or do UK, Canada and Australia need separate pins before Atoms launch?