@adaptic/maestro 1.0.0

package/docs/superpowers/specs/2026-04-05-information-barrier-design.md

@@ -0,0 +1,678 @@
+# Information Barrier & Disclosure Control System
+
+**Date:** 2026-04-05
+**Status:** Approved design — pending implementation
+**Triggered by:** Incident where confidential JVA/Seed SAFE review content from a Mehran + Nima meeting was included in a Slack message to Shayan Kargarian (counterparty on JVA, interested party on Seed SAFE)
+**Scope:** All outbound communications, all recipients, all channels
+
+---
+
+## Problem Statement
+
+Sophie operates with full context — meetings, conversations, legal discussions, financial details, board deliberations — all in a single shared memory pool. When composing outbound messages, there is no mechanism to prevent information from one context bleeding into communications with recipients who should not have access to it.
+
+The existing pre-send validation pipeline catches factual errors (relationship claims, AI disclosure, in-person scheduling) but does not assess **whether the recipient should see the information being shared**.
+
+This is the equivalent of an institutional Chinese wall / information barrier failure. In a regulated firm, this would be a compliance breach.
+
+## Design Principles
+
+1. **Universal application** — Every outbound message, every recipient, every channel. Internal and external. No exceptions.
+2. **Dynamic assessment** — No static ring/matrix lookup. Sophie assesses disclosure appropriateness at send-time using recipient profiles, information provenance, and contextual judgment.
+3. **Defense in depth** — Two layers: pre-draft guidance (shapes what Sophie considers) + post-draft assessment (catches what slips through).
+4. **Severity-based response** — Sophie distinguishes between critical leaks (block and escalate) and minor oversharing (strip and log). She uses judgment, not a single response for all cases.
+5. **Audit everything** — Every assessment logged, whether the message passed, was stripped, or was blocked.
+6. **Fail-closed on high severity** — If assessment confidence is low on a potentially critical disclosure, default to block and escalate rather than allow.
+
+---
+
+## Architecture Overview
+
+```
+[Sophie composes message]
+        |
+        v
+[Pre-Draft Boundary Guidance]  ← Layer 1 (soft)
+  - Loads recipient profile + information_boundaries
+  - Surfaces active conflicts, excluded domains
+  - Warns about recent sensitive context the recipient shouldn't see
+  - Shapes Sophie's drafting — prevents leaks at the source
+        |
+        v
+[Sophie drafts message]
+        |
+        v
+[Post-Draft Disclosure Assessment]  ← Layer 2 (hard)
+  - Extracts substantive references from draft
+  - Traces provenance for each reference
+  - Assesses against recipient boundaries
+  - Classifies severity per reference
+  - Action: PASS / STRIP / BLOCK
+        |
+        v
+[Existing Validation Rules]  ← Rules 1-5 still apply
+  - Relationship claims, title accuracy, AI disclosure,
+    in-person scheduling, unverified commitments
+        |
+        v
+[Dispatch or Hold]
+        |
+        v
+[Audit Log]
+```
+
+---
+
+## Component 1: Information Provenance (Ingestion Layer)
+
+### Purpose
+
+Every time Sophie ingests information — meeting notes, conversations, documents, emails, queue items — provenance metadata is recorded. This is the foundation the disclosure assessment draws on to determine where Sophie learned something and who was involved.
+
+### Provenance Record Structure
+
+Stored as metadata alongside the information in interactions, queue items, and memory:
+
+```yaml
+provenance:
+  source_type: meeting | conversation | document | email | internal_analysis
+  source_id: "meeting-2026-04-04-jva-review"
+  participants: [mehran-granfar, nima-masroori]
+  originator: nima-masroori
+  context_domain: adaptic-internal-legal
+  matter: "jva-review-adaptic-group-investments"
+  sensitivity_signals:
+    - legal_privilege
+    - negotiation_position
+    - financial_terms
+    - personal_data
+    - regulatory_strategy
+    - board_deliberation
+  timestamp: "2026-04-04T05:00:00Z"
+  classification_confidence: high | medium | low
+```
+
+### Field Definitions
+
+| Field | Description |
+|-------|-------------|
+| `source_type` | How Sophie received this information |
+| `source_id` | Unique identifier for the source event, traceable in logs |
+| `participants` | People who were present or party to the source (slug format) |
+| `originator` | The person who provided or originated the information |
+| `context_domain` | Broad domain category (see Domain Taxonomy below) |
+| `matter` | Specific matter identifier — links to queue items, meeting IDs, project names |
+| `sensitivity_signals` | Machine-detectable markers indicating the nature of the information |
+| `timestamp` | When the information was ingested |
+| `classification_confidence` | How confident the automated tagging is. Low confidence triggers conservative treatment |
+
+### Sensitivity Signals
+
+| Signal | Description | Examples |
+|--------|-------------|----------|
+| `legal_privilege` | Legal advice, attorney-client communications, GC strategy | Nima's advice on JVA terms, litigation strategy |
+| `negotiation_position` | Positional information on active negotiations | Adaptic's target price on an acquisition, JVA term preferences |
+| `financial_terms` | Pricing, valuations, cap table, runway, compensation | Seed SAFE terms, employee offer amounts, fundraising targets |
+| `personal_data` | Individual compensation, health, performance reviews | Candidate screening scores, salary details |
+| `regulatory_strategy` | Internal approach to regulators, gap assessments | DFSA remediation strategy, how to position on compliance gaps |
+| `board_deliberation` | Board-level discussions, resolutions in draft, governance decisions | Draft board resolutions, director appointment deliberations |
+| `competitive_intelligence` | M&A pipeline, competitive positioning, market strategy | Project Aether targets, competitive analysis |
+| `internal_operations` | Internal process, tooling, workflow details | Sophie's own infrastructure, internal team dynamics |
+
+### Ingestion Points
+
+Provenance is tagged at these integration points:
+
+| Ingestion Point | Script / Workflow | What Gets Tagged |
+|-----------------|-------------------|------------------|
+| Meeting action capture | `workflows/daily/meeting-action-capture.yaml` | Meeting notes with participants, agenda items, extracted actions |
+| Inbox processor | `scripts/daemon/dispatcher.mjs` | Inbound emails and Slack messages with sender, topic, detected sensitivity |
+| Post-interaction indexer | `scripts/post-interaction-indexer.py` | Conversation summaries with participants and context |
+| Queue item creation | Any workflow that writes to `state/queues/` | Action items with originating context and matter |
+| Document ingestion | Manual or workflow-triggered | Documents with author, matter, privilege markers |
+
+### Storage
+
+Provenance metadata is stored:
+
+1. **Inline with interactions** — `memory/interactions/{service}/{channel}/{date}.jsonl` entries include a `provenance` field
+2. **Inline with queue items** — Queue items in `state/queues/*.yaml` include provenance on creation
+3. **Provenance index** — `memory/provenance/index.jsonl` is a searchable index of all provenance records, enabling fast lookup by matter, participant, or source_id
+
+### Provenance Index Schema
+
+Each line in `memory/provenance/index.jsonl`:
+
+```json
+{
+  "source_id": "meeting-2026-04-04-jva-review",
+  "source_type": "meeting",
+  "participants": ["mehran-granfar", "nima-masroori"],
+  "originator": "nima-masroori",
+  "context_domain": "adaptic-internal-legal",
+  "matter": "jva-review-adaptic-group-investments",
+  "sensitivity_signals": ["legal_privilege", "negotiation_position"],
+  "timestamp": "2026-04-04T05:00:00Z",
+  "classification_confidence": "high",
+  "interaction_ref": "memory/interactions/slack/ceo-office/2026-04-04.jsonl:42"
+}
+```
+
+The `interaction_ref` field points back to the full content, enabling provenance tracing without duplicating message bodies in the index.
+
+---
+
+## Component 2: Recipient Boundary Profiles (RBAC Layer)
+
+### Purpose
+
+Every user profile in `memory/profiles/users/` is enhanced with information boundary attributes. These are not static permission lists — they are the inputs Sophie uses for dynamic disclosure assessment. They describe the person's legitimate scope of interest, explicit exclusions, active conflicts, and matter involvement.
+
+### New Profile Fields
+
+Added under an `information_boundaries` key in each user profile:
+
+```yaml
+information_boundaries:
+  domains_of_interest:
+    - ftlab-operations
+    - ftlab-commercial
+  
+  excluded_domains:
+    - adaptic-internal-legal
+    - adaptic-financial
+    - adaptic-hr
+    - regulatory-strategy
+    - rollup-strategy
+  
+  party_to_matters:
+    - ftlab-jva
+    - ftlab-operations
+  
+  conflicts:
+    - matter: jva-review-adaptic-group-investments
+      nature: "Counterparty — Adaptic's JV negotiation position is adverse to Shayan's interests"
+    - matter: seed-safe-review
+      nature: "Investor — terms under review affect his investment"
+  
+  information_shared_with:
+    - mehran-granfar
+    - sophie
+```
+
+### Field Definitions
+
+| Field | Description | Usage |
+|-------|-------------|-------|
+| `domains_of_interest` | Domains where this person has legitimate need-to-know | Strong positive signal — information in these domains is generally safe to share |
+| `excluded_domains` | Domains explicitly out of scope for this person | Strong negative signal — references to these domains should be assessed carefully |
+| `party_to_matters` | Specific matters this person is directly involved in | Person can see operational facts about these matters, but NOT the other side's strategy if they are a counterparty |
+| `conflicts` | Active conflicts of interest with matter identifier and nature description | Sharpest signal — any information touching a conflicted matter requires extreme caution |
+| `information_shared_with` | Who can receive information that originated from or about this person | Reverse-direction protection — controls sharing OF information about this person, not just TO them |
+
+### Key Design Rules
+
+1. **Sophie always has full access.** She needs complete context to operate. Boundaries govern what she shares outward, not what she knows.
+2. **Mehran (CEO) has full access.** No information is withheld from the CEO in outbound communications.
+3. **`domains_of_interest` and `excluded_domains` are guidance, not hard rules.** Sophie uses them as strong signals during assessment but can reason about edge cases where a reference is genuinely necessary.
+4. **`conflicts` is the sharpest signal.** If a conflict exists, Sophie should be extremely cautious about any information touching that matter. The `nature` field explains why, enabling Sophie to judge severity.
+5. **Every person gets a profile** — internal and external. Hootan doesn't need to see HR screening notes for candidates he's not involved with. Nima doesn't need engineering sprint details. The system is universal.
+6. **Profiles evolve.** As relationships change, matters open and close, conflicts arise and resolve — profiles are updated. The post-interaction indexer and evening wrap workflows maintain freshness.
+
+### Domain Taxonomy
+
+Used in `context_domain` (provenance) and `domains_of_interest` / `excluded_domains` (profiles):
+
+| Domain | Description |
+|--------|-------------|
+| `adaptic-internal-legal` | Adaptic's own legal strategy, GC advice, privilege-protected |
+| `adaptic-financial` | Cap table, runway, fundraising, financial planning |
+| `adaptic-hr` | Hiring, compensation, performance, org structure decisions |
+| `adaptic-operations` | Internal ops, processes, tooling |
+| `regulatory-strategy` | Approach to regulators, gap assessments, remediation |
+| `rollup-strategy` | Project Aether M&A targets, deal terms, pipeline |
+| `board-governance` | Board materials, resolutions, governance |
+| `ftlab-operations` | FTLab JV operational matters (shared domain) |
+| `ftlab-commercial` | FTLab commercial / revenue matters (shared domain) |
+| `ftlab-internal` | Adaptic-side-only FTLab matters (negotiation position, internal JV strategy) |
+| `investor-relations` | Investor communications, fundraising pipeline |
+| `competitive-intelligence` | Market positioning, competitor analysis |
+| `engineering` | Technical development, platform, repos |
+| `product` | Product strategy, roadmap, features |
+| `public` | Published information, press, website — no restrictions |
+
+### Example Profiles
+
+**Shayan Kargarian (JV Partner / Investor):**
+```yaml
+information_boundaries:
+  domains_of_interest: [ftlab-operations, ftlab-commercial]
+  excluded_domains: [adaptic-internal-legal, adaptic-financial, adaptic-hr, regulatory-strategy, rollup-strategy, board-governance, ftlab-internal]
+  party_to_matters: [ftlab-jva, ftlab-operations]
+  conflicts:
+    - matter: jva-review-adaptic-group-investments
+      nature: "Counterparty — Adaptic's JV negotiation position is adverse"
+    - matter: seed-safe-review
+      nature: "Investor — terms under review affect his investment"
+  information_shared_with: [mehran-granfar, sophie]
+```
+
+**Hootan Yazhari (CFO / CIO / SEO):**
+```yaml
+information_boundaries:
+  domains_of_interest: [adaptic-financial, regulatory-strategy, adaptic-operations, engineering, board-governance, investor-relations]
+  excluded_domains: []
+  party_to_matters: [dfsa-submission, adaptic-financial-strategy]
+  conflicts: []
+  information_shared_with: [mehran-granfar, nima-masroori, bronwyn-leong, sophie]
+```
+
+**Nima Masroori (General Counsel):**
+```yaml
+information_boundaries:
+  domains_of_interest: [adaptic-internal-legal, regulatory-strategy, board-governance, rollup-strategy]
+  excluded_domains: [engineering, product]
+  party_to_matters: [jva-review-adaptic-group-investments, seed-safe-review, dfsa-submission, gc-appointment]
+  conflicts: []
+  information_shared_with: [mehran-granfar, sophie]
+```
+
+---
+
+## Component 3: Pre-Draft Boundary Guidance (First Defence — Soft Layer)
+
+### Purpose
+
+Extend the existing `pre_draft_lookup.py` to return disclosure boundary guidance alongside the current recipient context. This shapes Sophie's drafting by making her aware of what she should NOT reference before she composes a single word.
+
+### Current Interface
+
+```python
+pre_draft_lookup(recipient, message_type="email", channel=None, topic=None)
+# Returns: { profile, recent_interactions, standing_instructions, critical_facts }
+```
+
+### Enhanced Interface
+
+```python
+pre_draft_lookup(recipient, message_type="email", channel=None, topic=None)
+# Returns: { profile, recent_interactions, standing_instructions, critical_facts, disclosure_boundaries }
+```
+
+### The `disclosure_boundaries` Block
+
+Generated dynamically at lookup time by cross-referencing:
+- The recipient's `information_boundaries` profile
+- Sophie's recent activity (interactions, queue items, meetings) that touch the recipient's conflicts or excluded domains
+- Active provenance records that involve the recipient as a counterparty or non-participant
+
+```yaml
+disclosure_boundaries:
+  recipient_clearance_summary: >
+    Shayan Kargarian is a JV partner (FTLab) and Adaptic investor.
+    He has legitimate interest in FTLab operational and commercial matters.
+    He is a counterparty on JVA terms and an interested party on Seed SAFE terms.
+    Do NOT reference: Adaptic internal legal strategy, financial position,
+    regulatory approach, M&A pipeline, HR matters, or board deliberations.
+    Do NOT share Adaptic's negotiation position on any matter where he is counterparty.
+
+  active_conflicts:
+    - matter: jva-review-adaptic-group-investments
+      warning: "Counterparty — do not reference Adaptic's position, Nima's advice, or internal JVA review discussions"
+    - matter: seed-safe-review
+      warning: "Interested party — do not reference internal term negotiations or legal strategy"
+
+  recent_sensitive_context:
+    - source: "meeting-2026-04-04-jva-review (Mehran + Nima)"
+      warning: "JVA review meeting — Shayan was not present, content is adverse to his position"
+    - source: "queue item as-20260404-027 (GC appointment)"
+      warning: "Internal corporate governance — no relevance to Shayan"
+
+  excluded_domains_active:
+    - adaptic-internal-legal
+    - adaptic-financial
+    - adaptic-hr
+    - regulatory-strategy
+    - rollup-strategy
+```
+
+### Generation Logic
+
+The `disclosure_boundaries` block is generated by a new function `generate_disclosure_boundaries(recipient_slug)`:
+
+1. **Load recipient profile** — Read `information_boundaries` from `memory/profiles/users/{slug}.yaml`
+2. **Scan recent activity** — Check Sophie's recent interactions (last 48 hours) and active queue items for provenance records that:
+   - Touch the recipient's `conflicts` (by matter ID)
+   - Fall in the recipient's `excluded_domains`
+   - Have participants that don't include the recipient
+3. **Generate clearance summary** — Natural language summary of who this person is, what they can see, and what they cannot see
+4. **Surface active conflicts** — List each conflict with a specific warning
+5. **Surface recent sensitive context** — List recent provenance records that the recipient should not see, with source and warning
+6. **List active excluded domains** — Quick reference of domain exclusions
+
+### Fail-Open Behaviour
+
+Consistent with the existing pre-draft lookup design:
+- If the recipient has no profile → return `disclosure_boundaries: null` with a warning log
+- If provenance index is unavailable → return partial boundaries from profile only
+- If the function errors → log and return `None` — never block a send at this layer
+- The post-draft assessment (Layer 2) is the hard gate
+
+---
+
+## Component 4: Post-Draft Disclosure Assessment (Second Defence — Hard Gate)
+
+### Purpose
+
+After Sophie composes a message and before it is sent, the disclosure assessor analyses the draft against provenance metadata and recipient boundaries. This is a new validation rule (Rule 6) added to the existing `config/validation-rules.yaml` pipeline.
+
+### Assessment Process
+
+For each outbound message:
+
+**Step 1 — Extract substantive references:**
+Identify references in the draft to: meetings, decisions, legal matters, financial details, named individuals in context, specific topics, queue items, documents, or action items. Ignore generic pleasantries, scheduling logistics, and publicly known facts.
+
+**Step 2 — Trace provenance:**
+For each substantive reference, look up the provenance record:
+- What source did this come from?
+- Who were the participants?
+- What matter does it relate to?
+- What sensitivity signals are tagged?
+
+**Step 3 — Assess against recipient boundaries:**
+For each reference, run the assessment criteria:
+
+```
+ASSESSMENT CRITERIA (evaluated in order of severity)
+
+1. PRIVILEGE CHECK — Is this information legally privileged?
+   - Legal advice from counsel → never share outside privilege circle
+   - Board deliberations in draft → never share outside board + officers
+   - Financial terms under negotiation → never share with counterparties
+   → FAIL = Critical severity
+
+2. CONFLICT CHECK — Does the recipient have a conflict on this matter?
+   - Active conflict flagged in profile → no strategy, no positioning,
+     no legal advice, no negotiation context for this matter
+   - Operational facts about the matter MAY be acceptable if the recipient
+     is a party (e.g., "the JVA signing is scheduled for next week" is OK;
+     "we're pushing for better terms on Schedule 3" is not)
+   → FAIL = Critical or High severity depending on content
+
+3. PARTICIPANT CHECK — Was the recipient present when this was discussed?
+   - If yes → generally safe to reference
+   - If no → proceed to domain and necessity checks
+   → FAIL alone = Medium severity (not present, but no conflict)
+
+4. DOMAIN CHECK — Does this reference fall in the recipient's excluded domains?
+   - If yes → should not be referenced unless there is a clear, specific
+     reason it's necessary for the purpose of this message
+   → FAIL = High severity if combined with other fails; Medium if isolated
+
+5. NECESSITY CHECK — Is this reference necessary for the message's purpose?
+   - If the message is about FTLab ops and Sophie tangentially mentions
+     the DFSA submission → unnecessary, strip it
+   - If the message is a direct response to a question the recipient asked
+     about a topic → may be necessary even if borderline
+   → FAIL = Medium or Low severity
+```
+
+**Step 4 — Classify severity and determine action:**
+
+| Severity | Trigger Conditions | Action |
+|----------|--------------------|--------|
+| **Critical** | Privilege check FAIL, or conflict check FAIL with strategy/positioning/legal content | **BLOCK** — Message held. Mehran notified immediately via Slack DM with: the draft (not sent), the specific concern, Sophie's recommendation |
+| **High** | Conflict check FAIL with operational content, or domain check FAIL combined with participant check FAIL | **BLOCK** — Message held. Sophie flags to Mehran with the concern and a recommendation on how to proceed |
+| **Medium** | Participant check FAIL in non-conflicted domain, or necessity check FAIL (tangential oversharing) | **STRIP** — Remove the specific reference from the message. Send cleaned version. Log what was removed and why |
+| **Low** | Borderline reference tangentially related to recipient's legitimate interests | **WARN** — Log the concern in audit trail. Send the message. Flag in weekly digest for Mehran's review |
+
+### Severity Judgment — Strip vs. Block
+
+Sophie uses judgment, not a rigid lookup. The guiding principle:
+
+- **Block when the damage is irreversible or severe.** Once privileged legal strategy reaches a counterparty, it cannot be unsaid. Once a negotiation position is revealed, leverage is lost. These require human review.
+- **Strip when the issue is oversharing, not a breach.** Mentioning a meeting the recipient wasn't in, referencing an unrelated internal project — these are indiscretions, not crises. Remove and log.
+
+When assessment confidence is low (e.g., ambiguous whether content is privileged, unclear if recipient has a conflict), **default to the more conservative action** — block rather than strip, strip rather than pass.
+
+### Integration with Existing Validation Pipeline
+
+The disclosure assessment runs as Rule 6 in the validation pipeline, after the existing five rules:
+
+```yaml
+# In config/validation-rules.yaml
+
+disclosure_assessment:
+  enabled: true
+  severity: dynamic  # determined per-reference by assessment logic
+  description: >
+    Assess whether substantive references in the draft are appropriate
+    to share with the recipient, based on information provenance,
+    recipient boundary profiles, and contextual judgment.
+  
+  assessment_criteria:
+    - privilege_check
+    - conflict_check
+    - participant_check
+    - domain_check
+    - necessity_check
+  
+  data_sources:
+    user_profiles: memory/profiles/users/
+    provenance_index: memory/provenance/index.jsonl
+    active_queues: state/queues/
+    recent_interactions: memory/interactions/
+  
+  actions:
+    critical: block_and_escalate
+    high: block_and_flag
+    medium: strip_and_send
+    low: warn_and_send
+  
+  # When assessment confidence is low, escalate severity by one level
+  low_confidence_escalation: true
+  
+  # Maximum assessment time before fail-open (ms)
+  timeout_ms: 3000
+  
+  # Fail behaviour on timeout
+  timeout_action: block_and_flag  # fail-closed for this rule
+```
+
+### Timeout and Failure Behaviour
+
+Unlike the pre-draft layer (fail-open), the post-draft assessment is **fail-closed on timeout for high-sensitivity recipients**:
+
+| Recipient Classification | Timeout Action |
+|--------------------------|----------------|
+| `partner`, `investor`, `board-member`, `regulator`, `acquisition-target`, `advisor` | **Block and flag** — too risky to send without assessment |
+| `internal-ceo`, `internal-executive`, `internal-team` | **Warn and send** — internal recipients are lower risk |
+| `unknown` | **Block** — always block unknown recipients |
+
+---
+
+## Component 5: Audit Trail & Transparency
+
+### Purpose
+
+Every disclosure assessment is logged — passes, strips, and blocks — creating a reviewable record of Sophie's information-sharing judgment. This enables calibration, compliance review, and incident investigation.
+
+### Log Structure
+
+Appended to `logs/audit/{date}-disclosure-assessments.jsonl`:
+
+```json
+{
+  "timestamp": "2026-04-04T12:51:30Z",
+  "message_id": "msg-20260404-slack-shayan-003",
+  "channel": "slack",
+  "recipient": "shayan-kargarian",
+  "recipient_classification": "partner",
+  
+  "references_assessed": [
+    {
+      "reference_summary": "JVA governance terms adjustment",
+      "provenance_source_id": "meeting-2026-04-04-jva-review",
+      "provenance_participants": ["mehran-granfar", "nima-masroori"],
+      "provenance_sensitivity": ["legal_privilege", "negotiation_position"],
+      "checks": {
+        "privilege": { "result": "FAIL", "detail": "GC legal strategy" },
+        "conflict": { "result": "FAIL", "detail": "Counterparty on jva-review" },
+        "participant": { "result": "FAIL", "detail": "Recipient not present" },
+        "domain": { "result": "FAIL", "detail": "adaptic-internal-legal excluded" },
+        "necessity": { "result": "FAIL", "detail": "Not necessary for message purpose" }
+      },
+      "severity": "critical",
+      "action": "blocked",
+      "reasoning": "Negotiation position on JVA terms shared with counterparty who was not present in review meeting. Content includes privileged legal strategy from GC."
+    }
+  ],
+  
+  "outcome": "blocked",
+  "escalated_to": "mehran-granfar",
+  "draft_hash": "sha256:abc123...",
+  "cleaned_hash": null,
+  "assessment_duration_ms": 450,
+  "assessment_confidence": "high"
+}
+```
+
+### Audit Outcomes
+
+| Outcome | Description | Visibility |
+|---------|-------------|------------|
+| `passed` | All references assessed clean. Message sent. | Logged silently. Available in audit search. |
+| `stripped` | Medium-severity references removed. Cleaned message sent. | Logged with detail of what was removed. Surfaced in weekly digest. |
+| `blocked` | High/critical severity. Message held. | Mehran notified immediately via Slack DM. Full detail in audit log. |
+
+### Mehran's Visibility
+
+- **Blocks** → Immediate Slack DM notification with: what was caught, why, the draft, and Sophie's recommendation
+- **Strips** → Weekly digest summarising what was removed from messages and why — so Mehran can review Sophie's judgment without being interrupted for every minor edit
+- **Passes** → Searchable in audit log on request ("show me all disclosure assessments for Shayan this week")
+
+### Calibration Loop
+
+When Mehran overrides a block ("that was fine to share") or flags a miss ("you should have caught that"), Sophie:
+
+1. Logs the override/feedback in the audit trail
+2. Updates her assessment criteria notes in `memory/precedents/disclosure-calibration.yaml`
+3. Adjusts future assessments based on accumulated precedent
+
+This is a learning system. Over time, Sophie's judgment improves as she accumulates calibration data from Mehran's feedback.
+
+---
+
+## Component 6: Scope of Application
+
+### Channels
+
+This system applies to every outbound communication channel:
+
+| Channel | Integration Point | Assessment Applies |
+|---------|-------------------|--------------------|
+| Slack (DMs, channels, threads) | `scripts/daemon/responder.mjs`, `slack-send.sh` | Yes — all messages |
+| Email (Sophie's voice) | `send-email.sh` | Yes — all messages |
+| Email (Mehran's voice) | `send-email-as-mehran.py` | Yes — all messages |
+| WhatsApp | `send-whatsapp.sh` | Yes — all messages |
+| SMS | `send-sms.sh` | Yes — all messages |
+| Voice briefing scripts | Voice AI pipeline | Yes — all generated scripts |
+| Documents shared externally | PDF generation, Google Docs uploads | Yes — content reviewed before sharing |
+| Calendar invites with agenda content | Google Calendar integration | Yes — agenda text assessed |
+
+### Recipients
+
+Every person Sophie communicates with, whether internal or external:
+
+- **Internal executives** (Hootan, Bronwyn, Nima) — bounded by their role scope
+- **Internal team** — bounded by their function and involvement
+- **JV partners** (Shayan) — bounded by JV scope, excluded from internal Adaptic matters
+- **Investors** — bounded to investor-relevant information only
+- **Board members** — full governance access, excluded from operational minutiae
+- **Regulators** — only formal, approved content
+- **Advisors** — bounded by their advisory scope
+- **Candidates** — hiring-relevant information only
+- **Vendors** — engagement-relevant information only
+- **External parties** — most restrictive by default
+
+### Group Communications (Channels, CC, Multi-Recipient)
+
+When a message is sent to multiple recipients — a Slack channel, a CC'd email, or a group thread — the disclosure assessment evaluates against **every recipient** present. The most restrictive boundary wins.
+
+**Process:**
+
+1. **Enumerate all recipients** — For Slack channels, resolve current membership. For emails, include all To/CC/BCC. For threads, include all participants.
+2. **Run assessment per recipient** — Each substantive reference is assessed against every recipient's profile independently.
+3. **Apply highest severity** — If a reference is `passed` for Nima but `critical` for Shayan, the overall severity is `critical`.
+4. **Action based on highest severity** — If any recipient triggers a block, the entire message is blocked. If any triggers a strip, the reference is stripped for all recipients (since all see the same message).
+
+**Example:** Sophie posts in a Slack channel where both Nima and Shayan are members. She references the JVA review meeting. Nima was a participant (PASS), but Shayan has an active conflict (CRITICAL). The message is blocked because Shayan is in the channel.
+
+**Channel profiles** in `memory/profiles/channels/` should include a `members` field that is kept current. The disclosure assessment uses this to enumerate recipients for channel-level messages.
+
+**Sophie should prefer DMs over channels** when the content is sensitive enough that channel membership could cause a disclosure issue. The pre-draft boundary guidance should flag this: "Consider sending this as a DM to [specific person] rather than posting in [channel] — [person X] in this channel has boundary conflicts with this content."
+
+### New Recipients Without Profiles
+
+When Sophie encounters a recipient with no profile in `memory/profiles/users/`:
+
+1. **Default to most restrictive boundaries** — treat as external with no domains of interest and all domains excluded
+2. **Log a warning** — flag that a message is being sent to an un-profiled recipient
+3. **Create a stub profile** — auto-generate a minimal profile with `information_boundaries` set to maximum restriction, flagged for Mehran to review and populate
+4. **Block if high-sensitivity content detected** — any substantive reference triggers a block for un-profiled recipients
+
+---
+
+## Implementation Priorities
+
+### Phase 1: Foundation (Immediate)
+1. Add `information_boundaries` to all existing user profiles
+2. Create the provenance record schema and index
+3. Implement `generate_disclosure_boundaries()` in pre-draft lookup
+4. Add disclosure assessment as Rule 6 in validation pipeline
+
+### Phase 2: Ingestion Integration
+5. Update meeting action capture to tag provenance
+6. Update inbox processor to tag provenance on inbound messages
+7. Update post-interaction indexer to tag provenance
+8. Update queue item creation to include provenance
+
+### Phase 3: Audit & Calibration
+9. Implement disclosure assessment audit logging
+10. Implement block notification to Mehran (Slack DM)
+11. Implement weekly strip digest
+12. Create calibration precedent store
+
+### Phase 4: Coverage Completion
+13. Integrate assessment into all send scripts (Slack, email, WhatsApp, SMS)
+14. Integrate into voice AI briefing pipeline
+15. Integrate into document sharing workflow
+16. Integrate into calendar invite content
+
+---
+
+## Testing Strategy
+
+### Unit Tests
+- Provenance tagging: verify correct metadata extraction from meeting notes, emails, conversations
+- Boundary generation: verify `generate_disclosure_boundaries()` correctly surfaces conflicts, excluded domains, recent sensitive context
+- Assessment logic: verify each check (privilege, conflict, participant, domain, necessity) produces correct severity for known scenarios
+- Action routing: verify critical → block, high → block, medium → strip, low → warn
+
+### Integration Tests
+- End-to-end: compose a message with sensitive content → verify it is blocked before sending
+- End-to-end: compose a clean message → verify it passes without delay
+- Strip test: compose a message with one sensitive reference and one clean reference → verify sensitive part is stripped, clean part is sent
+- Timeout: simulate slow provenance lookup → verify fail-closed behaviour for external recipients
+
+### Scenario Tests (based on real incidents)
+- **The Shayan incident:** Draft a message to Shayan referencing JVA review meeting with Nima → must be BLOCKED at critical severity
+- **Legitimate FTLab ops:** Draft a message to Shayan about FTLab operational matter he's party to → must PASS
+- **Hootan HR overshare:** Draft a message to Hootan referencing candidate screening scores for a role he's not hiring for → must be STRIPPED
+- **Nima engineering detail:** Draft a message to Nima about engineering sprint progress → must be STRIPPED (unnecessary, excluded domain)
+- **Unknown recipient:** Draft a message to an un-profiled external contact with any substantive reference → must be BLOCKED
+
+### Calibration Tests
+- Override a block → verify precedent is recorded and future similar assessments adjust
+- Flag a miss → verify assessment criteria update and future similar content is caught