UC_4.14.2: Pod Mentorship Module (LIVE)

---

Document References

---

1. Overview

Design states covered by this UC (client design pack, 2026-08-26):

The SIM counterpart of this card — a permanently locked empty state with a disabled [Join a POD] — is owned by UC_4.9.2 and is not one of the four states above (Ref: BR_4.14.2.1).

2. Trigger

• The trader navigates to the Community page via the Community tab in the persistent sidebar (Ref: UC_4.1.2 §2 Screen Description) → the My POD card mounts and issues its single GET /community/my-pod request (Ref: BR_4.14.2.10).
• The trader activates the card's call-to-action — [Enter My POD], [Join a POD] or [Link Discord to Unlock], whichever the current state renders (Ref: BR_4.14.2.3, BR_4.14.2.4, BR_4.14.2.9).

There is no third trigger. No server push, no polling interval and no cross-widget event re-renders this card. A pod assignment completed by the backend one second after mount is not reflected until the next mount (Ref: BR_4.14.2.10).

3. Pre-conditions

• The user is authenticated and is on the Community page.
• The account is a LIVE account at Level 1 or above. A SIM / Evaluation account never reaches this UC — the card is owned by UC_4.9.2 for the whole time the account is SIM (Ref: BR_4.14.2.1).
• To render any state: GET /community/my-pod has returned successfully. There is no client-side default state — a failed request has its own treatment and never falls back to the empty state (Ref: BR_4.14.2.10).
• To act on the unassigned-state CTA: discord_user_id is populated on the user record. If it is null the control is rewritten rather than disabled (Ref: BR_4.14.2.3).
• The card's rendering is independent of the broadcast session. It renders identically whether is_live is true or false, and a session transition does not re-render it (Ref: BR_4.14.2.10).

4. Post-conditions

• The card is rendered in exactly one of the four states listed in §1, and occupies its full slot in the Community page grid in every one of them (Ref: BR_4.14.2.1).
• No state of this card writes anything. The card issues exactly one GET; it never posts, patches or deletes. Pod membership is created, changed and removed entirely by the backend flows in BR_4.14.2.13.
• Activating [Join a POD] hands the trader to an external form. The Dashboard learns nothing about the submission and shows no confirmation — the state change surfaces on the next mount (Ref: BR_4.14.2.4, BR_4.14.2.10).
• Activating [Enter My POD] opens Discord in a new tab. The Dashboard session is untouched (Ref: BR_4.14.2.9).

5. Basic Flow — Matched (trader is in a pod)

1. The Community page renders. The My POD card mounts in its grid slot.
2. The frontend calls GET /community/my-pod with the authenticated user_id. This is the card's only request (Ref: BR_4.14.2.2, BR_4.14.2.10).
3. The payload identifies the account as assigned to a pod, and carries leader_name, leader_level, discord_channel_url and the members[] array (Ref: BR_4.14.2.2).
4. The card renders the Pod Leader tile: the leader's avatar, their display name, and beneath it the leader's title and level taken from the 24-level career path — Table A for Futures, Table B for Forex — not from the Discord role map (Ref: BR_4.14.2.8). The avatar is the leader's own profile_photo_url from Settings → Profile & Preferences, falling back to their initials (Ref: BR_4.14.2.15).
5. The card renders the POD members list. Every member of the pod is listed with their avatar, name, title and level, and a status indicator driven by that member's status value. Each avatar is resolved per displayed member on the same rule as the leader's (Ref: BR_4.14.2.15). The list is identical for a Pod Leader and for a Pod Member — there is no privacy masking and no management layout (Ref: BR_4.14.2.6, BR_4.14.2.7).
6. A member currently held by the Zombie Protocol renders with the inactive indicator and the Inactive label beside their name (Ref: BR_4.14.2.7).
7. The card renders the [Enter My POD] control.
8. The trader activates [Enter My POD]. The browser opens discord_channel_url in a new tab. The destination is the pod's private Discord category — one text channel and one voice channel, permissioned to that pod only (Ref: BR_4.14.2.9).
9. The card holds this appearance for the rest of the page view. Nothing on the card is interactive besides that one control — member rows are not clickable, and no counter, capacity bar or SLA countdown is rendered anywhere on it (Ref: BR_4.14.2.10, BR_4.14.2.11, BR_4.14.2.12).

6. Alternative Flows

6.1 — Unassigned, Discord account linked

Applies when the payload reports the account as not assigned to a pod and discord_user_id is populated. This is the state of a trader who has just completed live onboarding and has not yet submitted the matching form.

1. Steps 1–2 of §5 run unchanged.
2. The payload carries join_form_url and no leader data (Ref: BR_4.14.2.2).
3. The card renders the empty state: the title You're not in a POD and the supporting line Join a POD to trade with a team, get feedback, and track performance together.
4. The card renders [Join a POD] as the primary control, enabled.
5. The trader activates it. The browser opens join_form_url in a new tab — an external Typeform or ActiveCampaign form, not an in-app screen and not a modal (Ref: BR_4.14.2.4).
6. The trader completes the form outside the Dashboard. The backend matching waterfall runs asynchronously (Ref: BR_4.14.2.13).
7. The card does not change. It shows no confirmation, no spinner and no "submitted" state, because the Dashboard is never told the form was submitted. On the next mount of the Community page the card renders either the matched state of §5 or the pending state of §6.3, depending on what the payload then reports (Ref: BR_4.14.2.10).

6.2 — Unassigned, Discord account not linked

Applies when the payload reports the account as not assigned to a pod and discord_user_id is null. Submitting the matching form in this condition would produce a match the trader cannot use, because a pod lives entirely inside a private Discord channel the bot can only grant to a linked account.

1. Steps 1–3 of §6.1 run unchanged. The title and the supporting line are identical — no new screen and no alternative copy is built for this case (Ref: BR_4.14.2.3).
2. The call-to-action is rewritten, not disabled: the label becomes Link Discord to Unlock, it carries a 🔒 icon, and it renders as a secondary / muted control (Ref: BR_4.14.2.3).
3. The trader activates it. No modal opens and no navigation occurs. Instead, in the same page view, the Link your Discord account first block inside The PIT card is given a short highlight / pulse treatment to draw attention to it, and the toast Ref: TS-POD-01 is displayed (Ref: BR_4.14.2.3).
4. On a mobile viewport, where The PIT card is stacked below this card, the same activation additionally performs a smooth auto-scroll of the viewport down to The PIT card, and the highlight runs on arrival (Ref: BR_4.14.2.3).
5. The instruction block the trader is being pointed at — the heading, the three numbered steps, the token value and [Copy], and [Open Discord] — is owned by BR_4.5.2.7. This card renders no instructions, no token and no Discord link of its own.
6. The trader completes /link [token] in #verify inside Discord. The bot writes discord_user_id to the user record (Ref: BR_4.5.2.6).
7. The control reverts to the primary [Join a POD] of §6.1 on the next page load or Community-page mount. The card does not poll discord_user_id and does not subscribe to a linking event, so the change is not live within the current view (Ref: BR_4.14.2.3, BR_4.14.2.10).

6.3 — Pending Mentor Allocation

Applies whenever the trader is between pods. Two distinct causes share one screen, and the card gives the trader no way to tell them apart (Ref: BR_4.14.2.5):

1. Steps 1–2 of §5 run unchanged.
2. The payload reports the account as pending assignment.
3. A Pending status chip renders beside the My POD card header.
4. The card body renders the title Pending Mentor Allocation and the supporting line You are in the queue for the next available mentor. We will assign you to a POD as soon as a spot opens up.
5. The member list is not rendered at all — not empty, not collapsed, not zero-state. A trader with no Pod Leader is in no pod, so there are no peers to show (Ref: BR_4.14.2.5).
6. No information about the outgoing leader is rendered in any form — no name, no level, no avatar, no former mentor line, and no status label such as Terminated, Suspended or Under Review (Ref: BR_4.14.2.5).
7. No call-to-action is rendered. The trader is already in the automated queue; there is nothing to submit and no queue position to display (Ref: BR_4.14.2.5).
8. The card leaves this state on the next mount after the backend completes the assignment, transitioning directly to the matched state of §5 (Ref: BR_4.14.2.10).

7. Exceptional Flow

• [If GET /community/my-pod fails with a network error, a timeout, or HTTP 5xx] — the card keeps its grid slot and renders the error treatment with Ref: TE-SYS-01. It must not fall back to the You're not in a POD empty state: telling a matched trader they have no pod would invite them to submit the matching form a second time and create a duplicate record for the matching engine (Ref: BR_4.14.2.10).
• [If the payload reports the account as assigned but discord_channel_url is null or empty] — this is the window between Flow 15B inserting a leader into Pod_Leader_Registry and POST /create-pod-channel returning, and it is also the permanent condition of an archived pod, where Archive Pod Channel clears channel_url in the registry. The card renders the leader and the member list normally and renders [Enter My POD] in a Disabled state; no error and no toast is shown (Ref: BR_4.14.2.9).
• [If the trader is the Pod Leader and the pod currently has no mentees] — the members[] array is empty. The leader tile renders, and the POD members list renders its own empty line. The card stays in the matched state; it does not fall back to You're not in a POD, because the trader is in a pod — their own (Ref: BR_4.14.2.6).
• [If a member's status carries a value the frontend does not recognise] — it is treated as not active: the inactive indicator and the Inactive label are rendered. Only the explicit active value produces the active indicator (Ref: BR_4.14.2.7).
• [If the trader's Pod Leader breaches their own trading account] — nothing on this card changes. For an ordinary leader the card only reacts once Flow 15A has actually re-matched the cohort, at which point the trader is already in the pending state of §6.3. For a Founding Mentor the eviction scripts are bypassed entirely, so no transition ever fires (Ref: BR_4.14.2.14).
• [If the trader reaches Level 7 while a mentee] — the Alumni Graduation Sequence removes them from the pod automatically. On the next mount the card renders the unassigned state of §6.1. No notification, no farewell state and no reference to the former pod is rendered (Ref: BR_4.14.2.13).
• [If the trader's Discord roles are revoked by Flow 7 §Digital Eviction] — discord_user_id is not deleted, so the card still evaluates the account as linked and still renders [Enter My POD]. Activating it opens a Discord URL the trader no longer has permission to view. The Dashboard has no visibility of Discord role state and builds no check for it (Ref: BR_4.5.2.8).
• [If the broadcast session starts or ends while the trader is on the page] — the card does not re-render and keeps its state. Only the video component re-renders (Ref: BR_4.5.1.8).

8. Business Rules

BR_4.14.2.1: Eligibility Is LIVE Level 1+, and the Card Is Never Hidden

Pod Mentorship is reserved for traders at Level 1 and above trading live capital. It is not available to SIM or Evaluation accounts in any form, including read-only viewing of pod information (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Definition A1, Adrian Stack).

• The card must not be hidden in any state. Removing the component breaks the Community page CSS grid. The card keeps its slot and its dimensions in all four states, including the pending state, which renders the least content of the four.
• The handover between the two UCs happens on the next mount of the Community page after the account leaves SIM. There is no real-time transition and no animation between the locked card and this one.

BR_4.14.2.2: One Endpoint, One Call — and How the Four States Are Derived

The card is fed entirely by GET /community/my-pod, taking user_id and returning a single payload that carries leader data, the member array and the routing URLs together (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Community Endpoints — Get Pod Data; RFQ_ Website and Dashboard Implementation V7.pdf §Community Page Implementation). One payload serves both the Pod Leader's view and a Pod Member's view — there is no second endpoint and no role-specific variant (Ref: BR_4.14.2.6).

Payload as specified by the source:

Fields the card needs that the specified payload does not carry:

Where the data actually comes from — this endpoint reads SQL, not Discord. The card looks like a Discord surface, so it is worth stating plainly: Get Pod Data queries the SQL database to find the assigned pod_leader_id (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Community Endpoints). Rendering this card triggers no Discord API call at all.

• Consequence. Discord identity governs what the trader sees inside the pod channel — nickname, Discord profile picture, roles. It does not feed this card, in either direction. The one place on the Community page where Discord identity is the source is the chat panel's author name (Ref: BR_4.9.1.6); the two must not be conflated.
• The frontend never queries Zapier Table E directly. Max_Capacity, Current_Count, Status and Pending_Carry_Balance are backend-side fields; the endpoint is the only contract the Dashboard knows (Ref: BR_4.14.2.11).
• pod_role is derived server-side, not sent as a flag. The backend evaluates it at runtime: pod_leader_id populated on the user record = MEMBER; the user's ID present in Pod_Leader_Registry = LEADER (Source: RFQ_ Stack Trading Prop Tech V7.pdf). The card does not need it, because both roles render the same layout.

State resolution — evaluated in this fixed order, first match wins:

• The Discord linking flag is not part of this ladder. It is a gate on the action, not on the state: it rewrites the CTA of the unassigned state and never changes which state is rendered (Ref: BR_4.14.2.3). Mixing the two would produce impossible combinations such as "assigned but rendered empty".

🔴 The frontend switches on pod_status alone, never on which fields are null — unassigned and pending both leave leader_name null and are otherwise indistinguishable. The field is not yet in the specified payload: §10 item 1, blocking for BE.

⚠️ The WBS row for this UC is bypassed. It names GET /pod/status and expects a waitlist_position and a carry balance; the RFQ and the client answers give GET /community/my-pod, no queue position (Ref: BR_4.14.2.5) and no carry balance (Ref: BR_4.14.2.6). This document is authoritative and BE builds to it. The WBS row is to be corrected to match; it is not a source for this card.

BR_4.14.2.3: The Discord Gate Rewrites the CTA — No New Screen, No Modal, No Dead Click

Pod mentorship happens inside a private Discord channel, so an account with no linked Discord identity cannot be routed into a pod. No new screen is built for this — the linking guidance is already rendered permanently in The PIT widget beside this card (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A16).

• Two constraints the design must hold: the trader never reaches a matching form whose result they cannot use, and no second Discord-linking surface is built anywhere.
• The remedy is owned elsewhere. The instruction block being highlighted — heading, three numbered steps, token value, [Copy], [Open Discord] — belongs to BR_4.5.2.7. This card states the blocker; it does not restate the remedy.
• The gate is evaluated on mount only. The card does not poll discord_user_id and does not subscribe to a linking event, so a trader who links mid-session must reload to unlock the control (Ref: BR_4.14.2.10).

🔴 Matched + unlinked is not ruled. The gate above covers the unassigned state only; whether it extends to [Enter My POD] is §10 item 2, blocking for BE.

BR_4.14.2.4: [Join a POD] Hands Off to an External Form — the Dashboard Never Sees the Submission

[Join a POD] routes the trader to the join_form_url returned by the endpoint. The destination is an external ActiveCampaign or Typeform page, not an in-app screen and not a modal (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A13, Adrian Stack).

• The URL is always taken from the payload. It is never hard-coded in the frontend, so Operations can change the form destination without a release.
• The link opens in a new tab (target="_blank", rel="noopener noreferrer"), so the trader keeps their Dashboard session — which matters here, because the state change they are waiting for only appears when they return to it.
• The form collects the input for the matching waterfall: Asset Class and Trading Style, the latter as a restricted list of Scalping, Day Trading, Swing Trading, Algorithmic Trading (Source: Zapier Integration V7.pdf §Flow 10 Step 2). Ref: §10 item 4.
• Sotatek does not build this form. It is owned by Stack Trading Operations inside the third-party tool (Ref: §11).
• No confirmation is rendered on return. The Dashboard receives no callback, so the card shows no Submitted, no spinner and no disabled CTA after the trader comes back. Whether the next mount lands on §5 or §6.3 depends on whether the waterfall found a seat (Ref: BR_4.14.2.10).

BR_4.14.2.5: Pending Mentor Allocation — One Screen for Two Causes, and the Old Leader Is Erased

Both routes into the between-pods condition — the post-submission wait and the Flow 15A re-match — render the same screen. They are never split into two designs (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A15).

• Why no member list. A trader with no Pod Leader is not in a pod, so there are no peers to display. Rendering the previous cohort would imply a pod that no longer exists.
• The outgoing leader must be invisible. Absolute: no name, no level, no avatar, no former mentor line, and no status label such as Terminated, Suspended or Under Review. The Dashboard is not a place where a mentor's dismissal is announced to their mentees.
• No queue position is displayed. The supporting line is a qualitative reassurance, not a counter. No waitlist_position field exists (Ref: BR_4.14.2.2).
• No estimated wait time is displayed. Flow 11 releases a seat only when one is vacated and then waits up to 48 hours for the next trader in the queue to confirm by email, so no bounded estimate exists to render.

BR_4.14.2.6: One Shared Layout for Leader and Member — No Privacy Masking, No Management Panel

The matched state renders identically whether the viewer is the Pod Leader or a Pod Member (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A9 and A10, Adrian Stack).

• The trader themselves appears in the members[] array. The card does not filter them out and does not style their own row differently.
• No financial data is rendered on this card, for either role. Pending_Carry_Balance is the Pod Leader's accrued mentorship carry, held in Table E and paid on the 1st of each month by Flow 17. It is not in the endpoint payload, it belongs to one person rather than to the pod, and the client explicitly ruled out any statistics surface here. It is therefore not rendered on this card — the WBS row that asks for it is bypassed (Ref: BR_4.14.2.2).

BR_4.14.2.7: The Member Status Indicator Is Account Status, Not Presence

Each member row carries a small status indicator. It is not an online/offline dot — the backend has no real-time presence engine and opens no WebSocket for this card. The indicator maps directly to the status string returned for that member in the members[] array (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A11, Adrian Stack).

• Where the inactive state comes from. Flow 12 (Zombie Protocol) runs daily at 02:00 Central, selects traders whose last trade is more than 30 days old, disables their market data, decrements the Pod Leader's Current_Count to free the seat, and sets the trader's pod status to Inactive_Hold. Such a member must be distinguishable in the list by the Inactive label beside their name.
• Binary rendering, deliberately. The frontend treats only the explicit active value as active and every other value — including one it has never seen — as inactive, so the card stays correct when the backend adds a value. The enum itself is §10 item 6.
• The indicator says nothing about mentorship progress. It is not a "Trading Plan submitted" flag and not an SLA state (Ref: BR_4.14.2.12).

⚠️ Two client answers exist for this field and the conflict is not formally closed: §10 item 3.

BR_4.14.2.8: Title and Level Come from the Career Path, Not from the Discord Role Map

The label under each name — Senior trader - Lvl 12, Associate - Lvl 3 — is the trader's real title and level on the 24-level career path, sourced from Table A (Futures) and Table B (Forex) (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / UI-UX A1, Adam and Adrian).

• It is explicitly not Table G. Table G (Discord_Role_Map) is a Discord permission grouping only, and its role titles must not be rendered here.
• The leader's label is built from leader_level; each member's label is built from that member's level. The mapping from level to title is the same one used by the Levels module, so a level that is renamed there is renamed here without a change to this card.
• Futures and Forex traders can sit in the same pod, and the two tracks have different title tables. The label is therefore resolved per person, from the track their account belongs to — never from the viewer's own track.

BR_4.14.2.9: [Enter My POD] Is an External Link into a Private Discord Category

[Enter My POD] opens discord_channel_url directly. It is not an in-app page and there is no in-Dashboard pod chat (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A13, Adam).

• The link opens in a new tab (target="_blank", rel="noopener noreferrer"), consistent with [Open Discord] on The PIT card beside it (Ref: BR_4.5.2.7). It never navigates the current tab away from the Dashboard.
• What it opens. A POD is not a bare voice channel: it is provisioned as a Discord Category named pod-[leader_name] containing exactly one private text channel and one private voice channel, permissioned to the members of that pod alone (Source: Discord Server Details.md §DYNAMIC PODS; Stage 2 - Dashboard & Fomula (Community).csv — The Pit / Business logic A9b, Adrian Stack, 2026-08-10). The same structure is recorded from the metrics side in BR_4.5.2.11.
• Provisioning is backend work, invisible to this card. POST /create-pod-channel instructs the bot to create the channels and set permissions and returns the URL; POST /archive-pod-channel strips access, renames the channel to archived-pod-[leader_name], and clears channel_url in the registry.
• Disabled when there is no URL. If the payload reports the account as assigned but discord_channel_url is null or empty — the provisioning window after Flow 15B, or an archived pod — the control renders Disabled and no error or toast is shown. The rest of the matched state renders normally.
• The Dashboard does not verify Discord permissions. It knows only the URL. Whether the trader currently holds the Pod Member role is Discord's business (Ref: BR_4.5.2.8).

⚠️ The RFQ and the WBS call this control Enter Pod Chat; the label divergence is §10 item 5.

BR_4.14.2.10: One Request per Mount — No Polling, No Push, No Optimistic State

The card is a snapshot, not a live feed. Everything it can show is decided by the single response it receives when it mounts.

• Why the empty-state fallback is forbidden. A matched trader shown You're not in a POD would reasonably click [Join a POD] and submit the matching form again, producing a duplicate entry for the waterfall and a second SLA record. A silent failure here is more expensive than a visible one.
• The consequence for QA. Every backend transition in BR_4.14.2.13 — being matched, being graduated at Level 7, losing a leader, a teammate going inactive — is expected to appear only after a page re-entry. Lag between the backend event and the card is not a defect.

BR_4.14.2.11: Capacity Is an Operations Setting, Never a UI Element

A standard pod is capped at 7 mentees + 1 Pod Leader = 8 people in one Discord Category. The cap is not a constant in code: it is Pod_Max_Capacity in Zapier Table C — Global_Variables, with a per-leader override in Max_Capacity on Table E — Pod_Leader_Registry (Source: Zapier Integration V7.pdf §3.2, §3.3; Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A1, Adrian Stack).

• Ops owns the numbers, not Engineering. Changing the maximum capacity, marking a mentor active or ineligible, and registering a new mentor are all performed by Stack Trading Operations through the Zapier Tables interface, so that global variables change without a code deployment (Ref: §11).
• A Founding Pod Leader may carry a different capacity, configured individually on their registry row. The card must therefore never assume 7, and must never derive anything from a hard-coded number.
• Nothing about capacity is rendered. No Full badge when a pod is at capacity (Source: same row, answer A6). No x/7 counter, no progress bar, no remaining-seats line. Max_Capacity and Current_Count are not in the endpoint payload, so the frontend holds no data to render them from (Ref: BR_4.14.2.2).
• Minimum leader level is likewise invisible. Min_Pod_Leader_Level = 7 (Table C) gates who may become a Pod Leader in Flow 15B. It has no rendering on this card.

BR_4.14.2.12: SLA Deadlines Are Server-Side and Email-Only — Nothing Counts Down Here

The mentorship programme enforces exactly two onboarding deadlines, and neither appears on this card in any form (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A4 and A7, Adrian Stack).

• Both are tracked server-side and communicated entirely by automated email: warning and breach notices are dispatched by Flow 10.2, which scans for approaching and breached deadlines and identifies whether the violator is the mentee or the mentor. SLA is never displayed on the UI.
• No countdown, no progress bar, no Plan pending label and no per-member SLA badge is built. The status indicator beside a member's name is account status and must not be repurposed to carry SLA meaning (Ref: BR_4.14.2.7).
• Beyond the two onboarding deadlines there is no meeting cadence to display. Session frequency after induction is arranged between mentor and mentee in Discord, and the mentor's engagement level is audited automatically by the backend (Flow 10.5, Gemini PASS/FAIL written to the registry). None of that surfaces on the Dashboard.

BR_4.14.2.13: Every State Change Is a Backend Event — the Card Only Reflects Them

The card writes nothing. Membership is created and destroyed by seven distinct backend paths, and this rule exists so that QA and BE can trace each rendered state back to the event that produced it.

• Flow 15 has two further branches with the same UI consequence. Trigger B is a BPS admin re-assignment (POST /admin-pod-reassignment, which syncs Discord roles and updates Current_Count on both the old and the new leader), and Trigger C marks a leader Permanently_Ineligible so the Flow 10 waterfall excludes them. Both land the affected trader in the pending state and then in a new pod, with no distinct rendering of their own.
• Pod_Reassigned_Notification is not Sotatek's to write. It is classified as a lifecycle marketing event: the backend pushes a webhook payload to Zapier, Zapier forwards it to Klaviyo, and Klaviyo owns the template and the send (Source: Stage 2 - Dashboard & Fomula (Community).csv — Pod Mentorship / Business logic A8).
• On a graduation, the mentor's card simply loses a row. The graduating trader disappears from members[] on the next mount. No notification, no Graduated label and no farewell state is rendered on either side. Three related questions remain unanswered by the client — see §10 item 8.
• Whether Flow 11 runs after the Flow 7 decrement is not yet confirmed. Event 6 explicitly chains into Flow 11; event 7 does not say. If it does not, a seat freed by a resignation is never automatically filled, and traders sit in the pending state of §6.3 longer than the design implies — see §10 item 9.

BR_4.14.2.14: Founding Mentor — a Leader's Breach Is Never Surfaced to Their Mentees

A Founding Mentor is an ordinary Pod Leader with one architectural exception: Role_Flag = 'Founding Mentor' acts as a shield that bypasses the automated digital-eviction scripts, so the system does not dissolve their pod if they breach a stop-loss on their own trading account (Source: QnA from clients — STAGE 2: Founding Mentor, FM-09).

What this means for the mentee's card:

• The mentor's trading account is locked by the normal breach treatment, but their Pod_Leader_Registry.Status is not moved to Terminated, so Flow 15A never fires. There is no event for this card to react to, and the mentee's card continues to render the matched state of §5 unchanged.
• No status of the Leader is rendered at all — not Under Review, not Breached, not Suspended, not an inactive indicator on the leader tile. The payload carries only leader_name and leader_level; there is no leader status field to render, by design.
• The same silence applies to a non-Founding leader during the window between their breach and Flow 15A completing. The card either still shows the old matched state, or has already moved to the pending state of §6.3, which is required to erase the outgoing leader entirely (Ref: BR_4.14.2.5). At no point is a leader's failure narrated to their mentees.
• The Inactive label of BR_4.14.2.7 applies to members, from the members[] array. It has no equivalent on the leader tile.

BR_4.14.2.15: Avatar Source — the Trader's Dashboard Profile Photo, Read Through Per Displayed User

Every avatar on this card — the Pod Leader tile and each member row — renders the profile_photo_url of the person being displayed, taken from that user's Users record. That column is written in exactly one place, Settings → Profile & Preferences, and BR_4.6.2.13 already names this card as one of its four consumer surfaces. This UC consumes that rule; it does not create a second avatar source.

• The fallback is resolved per person, not per card. A pod can therefore show a photo for the leader and initials for three members in the same list — for example Marcus Chen with no photo renders as MC. This is expected rendering, not a loading state.

• Name and level are not part of this rule. They come from leader_name / leader_level and members[].name / members[].level, and the title label is resolved from the career path (Ref: BR_4.14.2.8). This rule contributes the image only.

• The avatar is not a Discord asset. The Discord server nickname and Discord profile picture govern what the trader looks like inside the pod channel; they do not feed this card. Conversely, changing the Dashboard photo does not change anything on the Discord side.

• profile_photo_url must be resolved server-side, returned beside the leader fields and inside each members[] entry. The frontend cannot resolve it itself: members[] carries name, level and status and no user_id, so it holds names rather than identities. The field is not yet in the specified payload — §10 item 11.

9. Screen Description

Related behaviour owned elsewhere:

• The Link your Discord account first instruction block on The PIT card — heading, three numbered steps, token value, [Copy] and [Open Discord] — is owned by BR_4.5.2.7. This card states the blocker and points at that block; it never restates the remedy.
• The SIM variant of this card, with its permanently disabled [Join a POD], is owned by UC_4.9.2.
• When the trader navigates into the Community screen, the Newsquawk audio stream in the persistent header switches to Off automatically. Owned by BR_4.1.4.4.

10. Open Items Pending Client Confirmation

11. Build Ownership

Recorded because the pod system spans four parties and the card renders data that none of Sotatek's code writes.

---

Changelog