cocottetech/@platform/codebase/@features/ai-copilot/docs/AE-provider-social-network.brief.md

AE — Provider Social Network (peer-to-peer)

Goal

CocotteAI today has exactly one inter-provider data plane: Brief N (coop safety-intel) + Brief Y referral links — both intentionally read-only / one-way. AE opens the peer plane to richer interactions: follow / colleague connections, ai-mediated peer DMs, group chats ("salons"), peer-discoverable directory, content collaboration, scope-claimed endorsements (positive complement to N's danger flags), and structured mentorship pairings. The collective lift: provider isolation stops being a ceiling on growth, and peer-to-peer trust + learning compounds the way it already does in offline operator communities.

The opacity, safety, and audit invariants that hold for client interactions all hold here too. Two providers still never see each other's prospects, drafts, journals, audit, analytics, or personas; AE adds a new peer-to-peer plane on top, with its own RLS rules.

Designer skim

• Headline UX: A provider opts in to discoverability per-coop, finds peers who endorse bookings-tryst listing optimization, requests a "colleague" connection, exchanges ai-mediated DMs in the AD-opaque way (each side in their own language), forms a 5-person salon for Berlin-area peers, gets paired with a mentor for 4 vigils of content-onlyfans PPV pricing, and decays back to incognito when they want to. None of this loosens the prospect/journal/audit RLS floor.
• Sections (11): AE1 peer discovery · AE2 connection model (follow / colleague) · AE3 peer DM · AE4 group chats / salons · AE5 peer-discoverable directory · AE6 content collaboration · AE7 endorsements · AE8 mentorship pairings · AE9 aggregated peer feed · AE10 abuse / moderation · AE11 privacy + opt-in posture.
• Foundation: every AE mechanic inherits from N (peer data discipline, hashing, moderation), Y (RLS isolation, discovery patterns), W (org-vs-personal scope), AD (multilingual opacity), K (PII gate on outbound), I (append-only audit), L (specialist mediation).
• Voice: this brief is working register. The product itself uses working by default in peer surfaces, plain for blocks/disputes/abuse, hearth for mentorship welcome + salon-arrival receipts.
• Blocking Qs: AE-Q1 connection-model shape, AE-Q2 default discoverability posture, AE-Q4 ai-mediation invariant, AE-Q5 endorsement-abuse defense, AE-Q6 cross-org peer-connection scope.

Constraints

• Per-provider RLS floor unchanged. Two providers connected on AE still cannot see each other's prospects, drafts, journals, audit, analytics, or personas. AE adds peer tables (§Schema follow-up); it does not relax existing RLS policies on the per-provider tables.
• AI mediation is the default. Every peer DM and every salon message passes through the sender's ai-copilot, which drafts/filters, and through the recipient's ai-copilot, which ingests + presents in the recipient's preferred language (per AD opacity). Raw-bytes peer-to-peer is out-of-scope at P0 (AE-Q4 leans P5+ at the earliest, with extreme caveats).
• K3 PII rules apply to peer outbound. K3c-1 (govt name), K3f-2 (hotel addresses), K3h (channel-vs-surface) all gate peer DMs and salon messages. A leak in a peer DM is no different from a leak to a client; the gate is locale-invariant per AD5.
• AD multilingual opacity applies to peer DMs. Sender writes in their language; recipient sees in theirs; no "translated from…" annotation ever. Audit triad (original / canonical-EN / recipient-view / delivered) holds (AD6).
• Append-only audit. Every peer interaction — connection request, DM, salon message, endorsement, mentorship event, block, report — is an agent_actions row. Erasure (brief V) redacts; never deletes.
• Voice §V6 banned-phrase list applies in both directions per AD4 (per-locale equivalents). The drafter rejects banned phrases on outbound; the ingest path flags them on inbound for the recipient's information without redacting (transparency on what the peer actually wrote).
• Org-scope discipline (brief W §W4). Peer connections at P0 are personal-only; org-attributed peer connections (e.g., "as Demimonde") are deferred to P5+ per AE-Q6.
• Coop boundary preserved. AE5 directory + AE9 feed both respect coop membership: peers outside any shared coop and outside the platform-wide directory opt-in cannot be discovered.
• No platform-action surface inside AE. AE doesn't post to external platforms; it's a closed peer plane inside the CocotteAI service. Surface adapters (@cocottetech/@platform/codebase/@features/{bookings,content}-*/adapter/) are untouched by AE.
• @model-boss is the mediation router (apricot GPU host). Drafting + ingest translation calls go through @model-boss /translate per AD. Never load translation models locally.

States to design

• Opt-in posture (AE11): incognito (default) · discoverable · open.
• Connection state (AE2): none · requested · connected · muted · blocked. Per-pair, bidirectional state machine.
• DM thread (AE3): empty · drafting · sent · read · degraded (AD <0.65 confidence fallback) · blocked-mid-thread.
• Salon lifecycle (AE4): proposal · awaiting-quorum · active · archived. Plus per-member states (member, mod, muted, removed).
• Endorsement (AE7): offered · accepted · public · withdrawn.
• Mentorship pairing (AE8): offered · accepted · active (rounds 1–4) · ended (mutual / unilateral).
• Abuse / report (AE10): report-filed · under-mod-review · sanctioned · dismissed.
• Aggregated feed (AE9): empty (no peers yet / opted out) · populated · degraded (insufficient anonymized data).

AE1 — Peer discovery

Three legitimate paths, mirroring Y1's discipline:

AE1a — Coop-mediated

• Inside any coop the provider belongs to (per N), the peer-roster sub-tab surfaces fellow members only if both have opted in to coop-mediated discovery (per AE11 posture).
• No global "everyone in this coop" list at incognito posture. Discoverable = coop-mediated visible; open = directory visible too.
• Tapping a peer-roster row opens peer-profile.screen.md (read-only until connection state advances).

AE1b — Referral introduction

• An existing connection introduces two peers (extension of Y1b referral patterns). The introducer drafts a one-line context; both peers consent before the connection state advances past requested.
• Introducer never sees the resulting DM thread or any post-connection data.

AE1c — Directory-discoverable (AE5)

• Opt-in only (open posture). The directory is searchable by surface_kind, language, region, and endorsement scope-claims (AE7). PII is filtered at composer time (no govt names, no precise location).

AE2 — Connection model

Two relationship kinds, both stored in peer_connections:

Kind	Shape	Use
follow	Asymmetric (A follows B; B doesn't auto-follow back). Public-ish: B can see who follows them.	Light "I want to learn from this peer" signal. No DM unlock. Feed-relevant.
colleague	Symmetric (A ↔ B). Requires acceptance.	Unlocks peer DM (AE3) + salon-invite eligibility (AE4) + endorsement-eligibility (AE7).

State machine: none → requested → (declined|connected) → (muted|blocked|disconnected).

A follow can be upgraded to a colleague request without dropping the follow. A block hard-overrides both: blocked peer cannot see the blocker's posture, profile, feed presence, or any AE surface.

AE3 — Peer DM (ai-mediated)

Thread between two colleague-state peers. Mediation:

1. Sender writes → sender's ai-copilot drafts → K3 PII gate + voice §V6 banned-phrase check + AD3 register-faithful re-authoring into recipient's preferred language.
2. Encrypted payload to platform — stored as peer_messages row with AD6 triad columns (original_text / canonical_text / recipient_view_text / delivered_text — but see AE-Q3 for storage shape choice).
3. Recipient's ai-copilot ingests → presents in recipient's language at the recipient's chat-home surface (peer-DM thread variant of chat-home.screen).
4. Audit triad recorded; turn_id links sender's outbound row to recipient's ingest row.

No raw-bytes mode at P0. Both peers consent at connection time to ai-mediation; the only "raw" affordance is a "view what the peer literally wrote in their language" expand on a recipient-side message — sender's voice in their own bytes, displayed verbatim alongside the recipient-view rendering. This is the only moment AE breaks AD opacity, and only on the recipient side, only inside peer-DM, only with both peers' consent at connection.

AE4 — Group chats / "salons"

Multi-peer rooms with stated topic + a moderator quorum (no single mod — rotates among members per a quorum threshold N).

Two flavors:

• Open salons — anyone in a shared coop can join (subject to AE10 ban list). Stated topic; persistent.
• Closed salons — invite-only. Smaller, often topic-specific (e.g. "Berlin Tryst peers", "Mandarin speakers", "PPV pricing study group").

Lifecycle: proposal → awaiting-quorum (need ≥ 3 founding members) → active → archived (manual or after 90d inactivity).

Each salon is ai-mediated per-message (same K3 + AD pipeline). Moderation actions (mute, remove, archive) require quorum agreement; appeals route to platform-admin (AE10).

AE5 — Peer-discoverable directory

Opt-in profile rows. Fields:

• handle (provider-chosen, unique platform-wide; never govt name per K3c-1)
• bio — short free-text; passes voice §V6 banned + K3 gate before publish
• surfaces_operated — list of surface_kind values (per O); claim-only (no verification at P0)
• languages — provider's preferred + working languages
• region — country / metro level only, never precise location per K3f-2
• discoverable_in — list of coop_ids + optional platform_wide=true

Searchable filters: surface_kind, language, region, endorsement scope-claim text-search. Result row tap → peer-profile.screen.md.

AE6 — Content collaboration

Three collaboration kinds stored in peer_collaborations:

• co_tour — multi-leg tour (per R6) crossing two peers' itineraries. Schedule overlap detection; per-leg ownership; both peers approve all-leg view; lightweight revenue split tracking (no money handling — that's brief Z).
• cross_promo — coordinated posts across peers' surfaces. Each peer's content-{surface} specialist drafts under that peer's persona; both peers approve. Audit records both turn_ids.
• shared_playbook — peer-authored templates (content plan, engagement script, blocklist snapshot) shared into the recipient's templates library with attribution (AE7 endorsement auto-offered on acceptance).

Collaborations never share prospect data, journals, or audit between peers.

AE7 — Endorsements

Scope-claimed positive reputation. Each endorsement:

• endorser_id, endorsee_id — both must be colleague-state
• scope_claim — free text ≤ 80 chars, named competency (e.g. "bookings-tryst listing optimization", "Mandarin-speaking subject handling", "tour pricing for Berlin")
• evidence (optional) — short note ≤ 200 chars
• accepted_at — endorsee must accept before public
• public — once accepted, surfaces on endorsee's directory profile

Endorsements are never aggregated to a global score. No "5-star Quinn." Reputation is scope-claimed and recency-decayed (per AE-Q5).

Endorsements never originate from ai-copilot. Only peers, by intentional action.

AE8 — Mentorship pairings

Structured: one peer offers mentor_pairing with a specific scope-claim and a 4-vigil cadence; another peer accepts.

Pairing lifecycle:

1. Offered — mentor opens a pairing with scope + 4-vigil window + capacity (default 1).
2. Accepted — mentee accepts; round 1 starts.
3. Active — 4 rounds, one per vigil. Mentor's specialist drafts can be shared on opt-in (sanitized — never includes prospects, journals, or audit).
4. 30-day check-in — automated nudge to both peers for explicit continue / end decision.
5. Ended — clean termination, optional mutual review.

The structure is intentionally codified at P0 (per AE-Q7) to enforce healthy boundaries; "free-form mentorship" is just colleague-state DM, which already exists.

AE9 — Aggregated peer feed

"What your peers are doing this week" — anonymized aggregations only.

Sample lines (working / hearth):

• "Your colleagues posted 4× more on Threads this week than last."
• "3 of your colleagues marked Berlin coop reports as low-confidence — worth a look."
• "A salon you're in published 2 shared playbooks."

Never:

• Specific prospect data.
• Per-peer breakdowns ("Sarah did X").
• Cross-provider prospect rows.

The aggregator runs as an extension of prospect-resolver (per L), with a dedicated peer-aggregator worker producing anonymized rollups daily.

AE10 — Abuse / moderation

Sanction surfaces, low to high:

• Block (per-peer, AE2) — hard-overrides all AE visibility between two peers.
• Mute (per-peer or per-salon, AE4) — suppress from feed/threads without alerting the muted peer.
• Report to coop moderators (per-coop) — quorum review for coop-bound infractions.
• Report to platform-admin — for cross-coop or platform-policy violations. Surfaces in the platform-admin queue (out-of-scope brief; signpost only).
• Sanctions — directory shadowban → coop removal → platform-wide suspension. Each level requires explicit decision + audit row.

Voice register for moderation is plain: no metaphor, no hearth-softening. "{Peer} reported you for {reason}. {Coop moderators / platform admin} reviewing. Your peer-DMs are paused for {N} days."

AE11 — Privacy + opt-in posture

Three postures, switchable any time from S settings:

• Incognito (default for all new accounts) — no peer-facing surface anywhere. No directory, no coop peer-roster, no salons, no endorsements visible. Existing peer-DMs persist in audit but stop surfacing in chat-home.
• Discoverable — coop-mediated discovery on (AE1a + AE1b). No platform-wide directory.
• Open — everything: coop discovery + directory + salons + endorsements + feed.

Switching to incognito does not delete past data; it stops surfacing. To delete, use brief V erasure flows.

Schema follow-up (sketch for migration 0006)

Authoritative migration filename: @platform/infrastructure/sql/migrations/0006_peer_social.sql.

-- peer_profiles — opt-in identity
CREATE TABLE peer_profiles (
  user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
  handle TEXT NOT NULL UNIQUE,
  bio TEXT NOT NULL DEFAULT '',
  surfaces_operated TEXT[] NOT NULL DEFAULT '{}',
  languages TEXT[] NOT NULL DEFAULT '{en}',
  region TEXT NULL,
  discoverable_in UUID[] NOT NULL DEFAULT '{}',  -- coop_ids
  platform_wide_discoverable BOOLEAN NOT NULL DEFAULT FALSE,
  posture TEXT NOT NULL DEFAULT 'incognito',     -- incognito|discoverable|open
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- peer_connections
CREATE TYPE peer_connection_kind AS ENUM ('follow', 'colleague');
CREATE TYPE peer_connection_state AS ENUM ('requested', 'connected', 'muted', 'blocked', 'declined', 'disconnected');
CREATE TABLE peer_connections (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_a UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  user_b UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  kind peer_connection_kind NOT NULL,
  state peer_connection_state NOT NULL,
  requested_by UUID NOT NULL REFERENCES users(id),
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (user_a, user_b, kind),
  CHECK (user_a < user_b)  -- canonical ordering to avoid (A,B) + (B,A) duplicates
);

-- peer_messages — ai-mediated peer DMs
CREATE TABLE peer_messages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  sender_id UUID NOT NULL REFERENCES users(id),
  recipient_id UUID NOT NULL REFERENCES users(id),
  agent_action_id UUID NOT NULL REFERENCES agent_actions(id),  -- canonical row per AE-Q3
  delivered_at TIMESTAMPTZ NULL,
  read_at TIMESTAMPTZ NULL,
  turn_id UUID NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- peer_groups — salons
CREATE TYPE peer_group_kind AS ENUM ('open', 'closed');
CREATE TABLE peer_groups (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  topic TEXT NOT NULL,
  kind peer_group_kind NOT NULL,
  coop_id UUID NULL,         -- nullable; closed salons may not be coop-bound
  quorum_count INTEGER NOT NULL DEFAULT 3,
  state TEXT NOT NULL DEFAULT 'proposal',  -- proposal|awaiting_quorum|active|archived
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  archived_at TIMESTAMPTZ NULL
);

CREATE TABLE peer_group_members (
  group_id UUID NOT NULL REFERENCES peer_groups(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  role TEXT NOT NULL DEFAULT 'member',  -- member|mod
  joined_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (group_id, user_id)
);

CREATE TABLE peer_group_messages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  group_id UUID NOT NULL REFERENCES peer_groups(id) ON DELETE CASCADE,
  sender_id UUID NOT NULL REFERENCES users(id),
  agent_action_id UUID NOT NULL REFERENCES agent_actions(id),
  turn_id UUID NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- peer_endorsements
CREATE TABLE peer_endorsements (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  endorser_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  endorsee_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  scope_claim TEXT NOT NULL,
  evidence TEXT NULL,
  accepted_at TIMESTAMPTZ NULL,
  withdrawn_at TIMESTAMPTZ NULL,
  public BOOLEAN NOT NULL DEFAULT FALSE,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  CHECK (endorser_id <> endorsee_id),
  CHECK (LENGTH(scope_claim) BETWEEN 1 AND 80)
);

-- peer_collaborations
CREATE TYPE peer_collab_kind AS ENUM ('co_tour', 'cross_promo', 'shared_playbook');
CREATE TABLE peer_collaborations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  kind peer_collab_kind NOT NULL,
  owner_id UUID NOT NULL REFERENCES users(id),
  peer_id UUID NOT NULL REFERENCES users(id),
  state TEXT NOT NULL DEFAULT 'proposed',
  payload_json JSONB NOT NULL DEFAULT '{}'::jsonb,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- peer_mentorships
CREATE TABLE peer_mentorships (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  mentor_id UUID NOT NULL REFERENCES users(id),
  mentee_id UUID NOT NULL REFERENCES users(id),
  scope_claim TEXT NOT NULL,
  state TEXT NOT NULL DEFAULT 'offered',  -- offered|accepted|active|ended
  round INTEGER NOT NULL DEFAULT 0,
  started_at TIMESTAMPTZ NULL,
  ended_at TIMESTAMPTZ NULL,
  review_json JSONB NULL,
  CHECK (mentor_id <> mentee_id)
);

-- RLS: every peer table requires current_user_uuid() to match at least one party.
-- See @platform/codebase/@features/platform-api/src/db/rls/peer_*.sql for policies.

RLS unchanged on per-provider tables (prospects, journals, agent_actions, personas, etc.).

In-the-wild copy

• (working, connection request received) "Sarah-K asked to be colleagues. They endorse bookings-tryst listing optimization."
• (hearth, salon welcome) "Welcome to Berlin Tryst peers. 7 in the room, last active 12 minutes ago."
• (plain, peer-block) "You blocked Mira. They won't see your profile, feed, or any AE surface."
• (plain, K3 leak in peer DM) "Held a draft back — contains restricted content. See audit for the row."
• (working, endorsement offered) "Q-Berlin endorses you for Mandarin-speaking subject handling. Accept to make it public on your profile?"
• (working, mentorship round 4 wrap) "Round 4 done. Mutual review available — both consent before either reads."
• (working, peer-DM AD <0.65 fallback) "I'm not confident I understood this. Want to write back yourself?"
• (working, aggregated feed) "Your colleagues posted 4× more on Threads this week than last."

Edge cases

• Peer DM containing govt name (K3c-1 leak) → outbound never delivered; counter-action row written; opaque framing per AD ("contains restricted content"); doesn't name language.
• Peer requests connection while you're in vacation mode (brief H §H1) → request queues to pending-approvals drawer; doesn't push-notify; surfaces on vacation exit.
• Mentor offboards mid-pairing (brief V erasure or AE10 sanction) → mentee gets plain-register cue: "Your mentor pairing ended. {Reason category}. Continue solo or request a new mentor."
• Coop boundary collapse — peer leaves a coop you both belonged to → coop-mediated discovery via that coop ends immediately; existing connections persist (they were coop-discovered, but they're not coop-dependent).
• Provider switches posture incognito mid-thread → past threads still readable to both peers (they had consent before); no new messages can be sent until posture changes; existing salons remain joined unless explicitly left.
• Endorsement-trading ring detected (per AE-Q5 heuristic) → moderator review; possible directory shadowban; per-peer cap re-enforced.
• Cross-org peer connection attempt (Quinn-as-Demimonde-admin requests colleague with peer) at P0 → blocked with plain-register cue ("Personal peer connections only. Org-attributed peer connections are coming."). Per AE-Q6 lean.
• Salon-message PII leak across recipients → message blocked before any recipient delivery; audit row written once with delivered_text=NULL per recipient.
• Peer in coop you both belong to has blocked you → coop-mediated discovery hides them from your peer-roster; coop intel reports are unaffected (you can still see their published coop reports — that's N's plane, not AE's).
• Reduced motion / VoiceOver on peer-DM thread → inherits chat-home accessibility patterns (X).
• Right-to-left provider in salon with LTR peers (per AD-Q4) → recipient-view rendering flips per locale; sender-view stays in sender's locale.

Related

• Brief N — sibling plane. N = read-only safety intel; AE = peer social. Both inter-provider, complementary.
• Brief Y — Y1 discovery patterns + Y7 RLS invariants AE inherits. AE replaces Y's "coops are the only inter-provider plane" out-of-scope line (see Y amendment).
• Brief W §W4 — scope discipline; AE6 personal-only at P0, org-attributed P5+.
• Brief AD — opacity + storage triad + register-faithful re-authoring applied to peer DMs and salon messages.
• Brief K §K3 — PII gate AE applies to peer outbound.
• Brief I — append-only spine; every AE action is an agent_actions row.
• Brief L — ai-copilot mediates; prospect-resolver powers AE9 aggregator extension.
• Brief M §M2a — degraded-mode behavior when @model-boss translation router is unreachable.
• Brief V — erasure flow extends to peer tables (redacts, never deletes).
• Brief X — peer-DM thread inherits chat-home accessibility patterns.
• Brief AC — distinct: AC is intra-org invite; AE is cross-provider social.
• Brief Z — peer-to-peer commerce (revenue split for co_tour, marketplace for shared_playbook) lives in Z, not here.

Out of scope

• Public unauthenticated discoverability — directory + profile are always gated to logged-in providers. No public peer pages.
• Cross-platform federation (ActivityPub, Matrix, etc.) — no inter-CocotteAI peer plane.
• Peer-to-peer commerce / money handling — refer to brief Z. AE6 co_tour tracks revenue-split intent but doesn't move money.
• Raw-bytes peer DM — explicitly P5+ at the earliest; current spec is always ai-mediated.
• Global peer reputation score — endorsements are scope-claimed; never aggregated to a global score.
• Cross-provider prospect linking — preserved from Y §Y7: each provider keeps own prospect row. AE does not unlock cross-provider prospect data.

Open questions

• AE-Q1 Connection model — follow-only (asymmetric, public-ish), colleague-only (symmetric, gated), or both? [blocking] (lean: both — different social muscles, different surfaces unlocked).
• AE-Q2 Discoverability default — incognito or discoverable? [blocking] (lean: incognito; opt-in to discoverable, opt-in separately to open).
• AE-Q3 Peer-message audit shape — shadow AD6 triad columns on peer_messages table, or write canonical row to agent_actions and keep peer_messages as IDs + delivery state? [engineering] (lean: latter; preserves I append-only spine as single source of truth).
• AE-Q4 ai-copilot mediation — always mediated, or can two consenting peers go raw-bytes? [blocking] (lean: always mediated at P0; raw is P5+ with extreme caveats; recipient-side verbatim-view is the only AD opacity break).
• AE-Q5 Endorsement abuse defense — per-coop endorsement cap + endorsement-recency decay + moderator review on reputation spike? [blocking] (lean: all three).
• AE-Q6 Cross-org peer connections — at P0, can a provider connect as Demimonde-org vs personally? [blocking] (lean: personal-only at P0; org-attributed peer connections P5+ per W).
• AE-Q7 Mentorship structure — codified rounds (current spec) or free-form? [exploratory] (lean: codified at P0 to enforce healthy boundaries; relax with usage if data supports).

Apricot-deferred verifications

Per [[feedback-apricot-unreachable]]: this brief is pure-doc authoring. When implementation begins, verify against apricot:

• @model-boss /translate round-trip for peer DM (AD opacity).
• PII-gate firing on peer DM containing govt name → blocked + counter-action row written to agent_actions.
• Endorsement-abuse heuristic — requires data volume; defer to P5+ for tuning.
• Aggregator anonymity floor — peer-aggregator worker must reject rollups below k=5 anonymity threshold before publishing to feed.