UC_4.15.4: Scenario C — Defense Protocol (Level 9+) (LIVE)

Document References

1. Overview

2. Trigger

Middleware detects: Net_P&L <= −Market_Loss_When_Stopped (Hard Stop Loss threshold, Table A/B per-level lookup — same trigger event as UC_4.15.2 §2) via the LEVEL_STOP_BREACH WebSocket event, AND the Defense Gate resolves to the Defense branch:

IF Resignation == True: SKIP Defense Gate (goes to UC_4.15.2 liquidation path directly).
IF Current_Level >= 9 AND Defense_Used == False:
    → Trigger Flow 4 Trigger B (Defense Handoff). HALT Flow 7.
    → Dashboard renders Defense Protocol Activated modal (§10.1) immediately — CTA "Acknowledge"
    → After Acknowledge → Shadow Mode (48h lock)
ELSE (Current_Level < 9 OR Defense_Used == True, or resigned):
    → Terminate. Proceed to Liquidation. [UC_4.15.2]
    → Dashboard renders Risk Parameter Breached / Trading Revoked modal (owned by UC_4.15.2) — CTA "Start Associate Track"

(Source: Flow 7 Defense Gate, Zapier Integration V7.pdf)

3. Pre-conditions

• Trader's account is Active_DMA, Level 9 or above (Forex or Futures, LIVE).
• Current_Level >= 9.
• Defense_Used == False for the trader's current recharge cycle.
• Trader has not resigned.

4. Basic Flow

Source: Flow 4 Trigger B — Drawdown Defense Path (Stop_Loss_Hit + Eligible)

Pre-entry: Trader's Net_P&L drops to or below −Market_Loss_When_Stopped (Net_P&L = Realized P&L + Unrealized P&L, monitored continuously via execution-gateway ACCOUNT_METRICS stream). Middleware pushes LEVEL_STOP_BREACH. Flow 7 Defense Gate evaluates Current_Level >= 9 AND Defense_Used == False → hands off to Flow 4 Trigger B and halts Flow 7's termination path (Ref: §2 Trigger, BR_4.15.4.1).

Catch Hook: Accepts data from both Flow 7 or Flow 19.

Double Dip Gate:

• Check: IF Defense_Used == True → Terminate (Trigger Flow 7 Termination). [Ref: BR_4.15.4.1.]

• ELSE (Defense_Used == False) → proceed with the following actions:

  1. Set Defense_Used = True AND Status = 'SUSPENDED_DEFENSE' in SQL Database.
  2. Set Defense_Trigger_Date = Today. [For Principal Accrual Tracking → used by Flow 21 to calculate recharge for Level 18+. Ref: BR_4.15.4.7.]
  3. Reset Promotions_Since_Defense = 0. [For Standard Accrual → used by Flow 4 Trigger A to calculate recharge for Level 9-17. Ref: BR_4.15.4.7.]
  4. Call Middleware Hub Endpoint POST /system/set-account-state with user_id, state="Locked", context="Defense". The Node.js middleware executes the corresponding API call to the execution server to enforce the freeze at the exchange/broker level. The Defense lock does not call DeleteUser — the sub-account remains fully intact and is simply re-enabled at T+48h with the Table F parameters.
     • Immutable Ledger: Node.js middleware initializes Ethers.js wallet and executes contract.recordMetric(). [Ref: BR_4.15.4.2.]
  5. Defense Calculation: New_Limit = Floor(Original_Limit × Defense_Notional_Multiplier, 100). [Full worked examples — Level 9 Forex and Level 9 Futures with normalization — in BR_4.15.4.3.]
  6. Send Drawdown_Defense_Activated_Initial Email. [Suppressed if incoming Reason Code == STAGNATION — Flow 19 already sent its own email. Ref: BR_4.15.4.4.]

Wait: Delay 48 Hours (Cooling-Off). [Neither the Auth0 login nor the trading account is deleted. The POST /system/set-account-state call suspends trading at the execution broker; the SQL database retains the full performance ledger and trading history.]

At T+48h — all sub-actions execute together:

7. Update Status = 'Active_DMA' in SQL Database.
8. Re-enable Account with new reduced parameters from Table F. Reset stagnation_deadline = Today + 60 Days 🆕[CR-64] (PIP timer — applies unconditionally for all Defense re-activations, regardless of trigger source. Ref: BR_4.15.4.8.).
9. Send Drawdown_Defense_Ready Email.
10. Pod Check: IF Is_Pod_Leader == True:
    • Set Pod_Status = Suspended in SQL Database.
    • Trigger Flow 15 (Re-Assignment). [Flow 15 disperses mentees to new mentors automatically. Ref: BR_4.15.4.6.]
11. Render the "Drawdown Defense Active: Account Restricted" modal (§10.2) on the trader's next system entry (any screen, not scoped to Dashboard) — CTA "Acknowledge"; re-displays on every login, reload, or navigation until acknowledged. [Ref: BR_4.15.4.9.]

Trader resumes trading under the reduced Table F parameters, inside the 60-day PIP window (Ref: BR_4.15.4.8).

12. PIP Outcome — two cases:
    • Case A (PIP Success): Hitting the 6% Profit Target triggers Capital Reinstatement: the system calls POST /financial/reset-ledger to archive PIP P&L (PIP earnings do not carry over), restores full Notional/PT/SL to the trader's current level, and resets stagnation_deadline = Today + 90 Days. No level promotion occurs. Dashboard immediately renders the "Capital Allocation Restored" modal (§10.3) — CTA "Acknowledge"; re-displays on every login, reload, or navigation until acknowledged. (Ref: BR_4.15.4.7, BR_4.15.4.8, BR_4.15.4.9.)
    • Case B (PIP Failure): Either (i) a Stop Loss hit under the reduced Table F parameters, Defense_Used == True → Flow 7 terminates immediately, time remaining on the PIP timer is irrelevant (Ref: BR_4.15.4.1, BR_4.15.4.8), or (ii) Days_Remaining <= 0 AND Current_Profit < 6% PT → Flow 19 detects, no second grace → Flow 7 terminates (Reason Code: STAGNATION) (Ref: BR_4.15.4.8). Both routes to UC_4.15.2.

5. Post-conditions

• Defense_Used = True, Status = 'Active_DMA' (after the 48h unlock), account running under Table F reduced parameters until the trader hits the 6% Profit Target (Capital Reinstatement → restores to full level parameters, no level-up) and the Defense perk recharges separately (Ref: BR_4.15.4.8).
• Defense_Trigger_Date is set to today.
• Immutable Ledger has a permanent, non-repudiable record of the Defense event.
• Dashboard is in Shadow Mode (Frosted Glass, read-only) during the 48h lock; Notification bell, PnL Gauge, and Days Remaining counter continue operating normally throughout the lock. Newsquawk audio defaults to Off and stays locked Off for the duration of the lock. (Ref: UC_4.1.1 §2)

Business Rules

BR_4.15.4.1: Defense Eligibility Gate and Double Dip Guard

Defense Protocol applies only to accounts where Current_Level >= 9 AND Defense_Used == False. The eligibility check happens twice: once in Flow 7 (Defense Gate, on the LEVEL_STOP_BREACH event) and once again inside Flow 4 Trigger B itself. If a trader has already consumed their Defense for the current recharge cycle (Defense_Used == True), any subsequent Stop Loss hit routes to termination — UC_4.15.2, not this UC. Resignation always bypasses the Defense Gate entirely and proceeds straight to liquidation, regardless of Level or Defense_Used.

BR_4.15.4.2: Immutable Ledger Logging

IF state == 'Locked' AND context == 'Defense', the Node.js middleware must natively initialize the Ethers.js wallet and execute contract.recordMetric() (metric_category="Risk Management Protocol", metric_value="Drawdown Defense Deployed (Seat Protected)", receipt_hash=[Internal Event ID]). This call is triggered by the same set-account-state invocation described in §4 Basic Flow Action 4. This produces a permanent, non-repudiable on-chain record of the Defense event.

BR_4.15.4.3: Defense Calculation — Reduced Parameters (Table F)

On activation, the system computes:

New_Limit = Floor(Original_Limit × Defense_Notional_Multiplier, 100)

Table F (Defense_Configuration_Matrix) is a flat, single-row lookup for the entire Level 9-24 range.

Note: Table F values are maintained in Zapier and may be updated by the client at any time. Values shown below reflect the configuration at document creation date and may not be current at read time.

At T+48h re-activation, the trader's notional is reduced to 25% of the original allocation, and the profit target / stop loss for the reduced account are recomputed at 6% / 5% respectively of the new (reduced) notional.

Important — Floor rounds DOWN to the nearest multiple of 100, not to the nearest hundred. E.g. Floor(13,945, 100) = 13,900, not 14,000.

Worked example — Level 9 Forex:

• Original Notional = $750,000
• New Notional = Floor(750,000 × 0.25, 100) = $187,500
• New Profit Target = 187,500 × 0.06 = $11,250
• New Stop Loss = 187,500 × 0.05 = $9,375

Worked example — Level 9 Futures (capital-based, requires normalization to Forex-equivalent notional first):

Futures accounts are listed by capital allocation, not Notional, so Target/Stop must be normalized to their Forex equivalent first:

Normalization_Multiplier = Max_Forex_Notional / Futures_Capital

• Original Futures Capital = $56,250; Forex-equivalent Original Notional = $750,000
• Normalization Multiplier = 750,000 / 56,250 = 13.3333
• Notional Equivalent = 56,250 × 13.3333 = $750,000 (confirms the multiplier round-trips correctly)
• New Notional Base = Floor(750,000 × 0.25, 100) = $187,500
• New Futures Capital = Floor(56,250 × 0.25, 100) = $14,000
• New Profit Target = 187,500 × 0.06 = $11,250
• New Stop Loss = 187,500 × 0.05 = $9,375

(Both examples use the Level 9 row of Table A/Table B; the Profit Target/Stop Loss dollar amounts are computed off the normalized Forex-equivalent notional in both cases, so Forex and Futures traders at the same level face equivalent post-Defense risk parameters.)

BR_4.15.4.4: Stagnation Email Collision Suppression Gate

Flow 4 Trigger B's Catch Hook accepts the Defense Handoff from either Flow 7 (real-time Stop-Out) or Flow 19 (Stagnation Monitor). Its Notify step natively sends Drawdown_Defense_Activated_Initial regardless of caller. When the handoff comes from Flow 19 rather than a real-time Stop-Out (LEVEL_STOP_BREACH), Flow 19 has already sent its own Stagnation_Defense_Activated email before handing off — sending Drawdown_Defense_Activated_Initial on top of it produces two conflicting emails for the same event.

Gate: IF incoming Reason Code (or source flag) == STAGNATION: SKIP Send Drawdown_Defense_Activated_Initial Email.

This suppression applies only to the Stagnation-originated branch. A real Stop-Out (Reason Code other than STAGNATION, e.g. DRAWDOWN) still sends Drawdown_Defense_Activated_Initial normally. All other steps of Flow 4 Trigger B (lock, ledger logging, Defense Calculation) execute identically regardless of Reason Code; only this one email is conditionally suppressed.

BR_4.15.4.5: Shadow Mode Display — Frosted Glass (Defense-Specific Behavior)

During the 48-hour lock, the Dashboard renders the "Risk Parameter Breached / Defense Protocol Activated" modal (§10.1) and, after acknowledgement, enters Shadow Mode (read-only) with a Frosted Glass visual overlay. Defense Protocol does not apply the archive_date / D=0 lifecycle rules — the account is not archived; the lock is strictly time-bound to 48 hours, after which the account is automatically re-activated. Underlying dashboard data (equity, balance, closed trades, charts) is rendered as a static snapshot captured at the moment of the Stop Loss hit — NOT live, and NOT reset to a blank state.

Defense-specific component behavior during the 48h lock (Source: UC_4.1.1 §2):

• Notification bell — continues receiving notifications and remains fully interactive. Not frozen.
• PnL Gauge — shows the "Drawdown Defense Enabled" state with a live countdown label. Display state owned by UC_4.8.1 §BR_4.8.1.1/BR_4.8.1.4.
• Days Remaining counter — continues counting down normally throughout the lock.
• Newsquawk audio — defaults to Off and stays locked Off for the duration of the 48h lock. Returns to user-togglable after re-activation.
• Desk Manager (Gekko) — continues operating and is never blocked during the lock. Ref: UC_4.8.3 §BR_4.8.3.4.
• Main navigation (sidebar) — never blocked during the lock.

Modal re-display: The Defense Protocol Activated modal re-displays on every Dashboard entry (login, page reload, sidebar tab switch) throughout the entire 48h lock — it does not disappear after the first "Acknowledge" click in subsequent sessions.

BR_4.15.4.6: Pod Leader Cascade

[If Is_Pod_Leader == True] activating Defense Protocol sets Pod_Status = Suspended in the SQL Database and triggers Flow 15 (Pod Re-Assignment) so the pod is not left without active leadership during the trader's 48-hour lock. Flow 15 disperses the pod's mentees to a new mentor — mentees are reassigned to an active Pod Leader for the duration of the lock, and the process runs on the same schedule regardless of whether the lock resolves in 48 hours (Defense) or is permanent (Termination).

The detailed flow will be updated in Stage 6.

BR_4.15.4.7: Defense Recharge — Dual Trigger Source (Flow 4 Trigger A / Flow 21)

This UC sets Defense_Trigger_Date and resets Promotions_Since_Defense = 0 on activation, but does not own the recharge mechanism itself — the full recharge flow is owned by UC_8.4.2. Recharge (Defense_Used reset back to False) is evaluated by two independent, level-gated flows:

Important distinction: Recharging the Defense perk (Defense_Used → False) is not the same as Capital Reinstatement. Capital Reinstatement (hitting the 6% PT on the reduced account) restores the trader's notional to 100% of their current level — this is a separate event documented in BR_4.15.4.8. The perk recharge below only concerns when the trader is eligible to use Defense again in the future.

Recharge gating rule:

• Level 9-17: recharge via Promotions_Since_Defense >= 2 (Flow 4 Trigger A — on each Promotion event, counted after Capital Reinstatement).
• Level 18+: recharge via Months_Since_Trigger >= 4 (Flow 21 — monthly scheduled job). [CR-63]
• These two paths are mutually exclusive by level bracket — they never fire simultaneously for the same trader.
• Defense_Used is a boolean; a trader holds at most one "defense bullet" at a time. Recharge simply resets it to False — it does not grant additional uses or stack.

Flow 4 Trigger A — Recharge Check (Standard Accrual, Level 9-17):

This check runs as one sub-step inside Flow 4's Promotion Path (Trigger A, Profit_Target_Hit). The surrounding Promotion Path mechanics are owned by the Promotion/Level-Up UC — not duplicated here.

Recharge Check (Standard Accrual):
  IF Level is between 9 and 17 AND Defense_Used == True:
    Increment: Promotions_Since_Defense = Promotions_Since_Defense + 1 in SQL Database.
    IF Promotions_Since_Defense >= 2:
      Set Defense_Used = False.
      Reset Promotions_Since_Defense = 0.
      Notify: Send Defense_Protocol_Recharged Email.

(Source: Zapier Integration V7.pdf, Flow 4 Trigger A — Recharge Check sub-step)

Flow 21 — Principal Partner Accrual (Level 18+): [CHR-63]

Flow 21: Principal Partner Accrual

  Trigger: Scheduled Job (Monthly, 1st of Month).
  Query: SQL Database Query: Find all Traders where Level >= 18 AND Defense_Used == True.
  Logic Loop (Per Trader):
    Calculate: Months_Since_Trigger = (Today - Defense_Trigger_Date) in Months.
    Recharge Check:
      IF Months_Since_Trigger >= 4 AND Status != 'SUSPENDED_DEFENSE':
        Set: Defense_Used = False.
        Update: Last_Defense_Recharge_Date = Today.
        Notify: Send Defense_Protocol_Recharged Email.

Both flows send the same Defense_Protocol_Recharged email (AWS SES operational notification — not a Klaviyo marketing sequence). Defense_Trigger_Date and Last_Defense_Recharge_Date are tracked as two fully independent fields.

BR_4.15.4.8: Defense PIP — Timer, Failure Paths, and Capital Reinstatement [CR-64]

PIP Timer (set at T+48h Re-Activate — §4 Basic Flow Step 8):

The system must always reset stagnation_deadline = Today + 60 Days unconditionally for all Flow 4B re-activations, regardless of Reason Code (DRAWDOWN or STAGNATION). This is the PIP (Performance Improvement Plan) timer — the 60-day evaluation window for the trader to prove they deserve their seat back.

PIP failure paths:

• Time expiry: Days_Remaining <= 0 AND Current_Profit < 6% PT → Flow 19 detects → Defense_Used == True → no second grace → Flow 7 (Termination, Reason Code: STAGNATION).
• Stop Loss hit during PIP: Under reduced Table F parameters (5% SL on reduced notional), if Net_PnL <= −Market_Loss_When_Stopped → LEVEL_STOP_BREACH → Flow 7 Defense Gate → Defense_Used == True (Double Dip Guard, BR_4.15.4.1) → terminate immediately. Time remaining on the PIP timer is irrelevant.

PIP success — Capital Reinstatement:

Capital Reinstatement and Defense Perk Recharge are two independent mechanics:

When Net_PnL reaches the 6% Table F Profit Target (computed off the reduced notional), the following sequence fires:

1. Ledger Reset: Call POST /financial/reset-ledger.
   • Syncs final closed P&L from execution gateway.
   • Archives PIP performance into historical_pnl.
   • Resets ledgers.virtual_equity to $0.
   • Rationale: Profit earned during the PIP offsets what the trader already cost the firm — it does not carry over as a head start on the next promotion. Fresh start at $0 toward the full 100% Profit Target of their current level.
2. Restore full level parameters: Update Notional, Profit Target, and Stop Loss to the 100% values of their current level (Table A/B row — same level as when Defense was triggered). No level promotion occurs.
3. Stagnation deadline reset: stagnation_deadline = Today + 90 Days. The 60-day PIP timer governed the Defense evaluation phase only. Once reinstated, the trader is a standard Live trader — standard 90-day stagnation rule applies immediately.
4. Defense_Used remains True — the perk is still consumed and will only recharge via BR_4.15.4.7.
5. The Promotion counter (Promotions_Since_Defense) starts counting from this point — the next genuine level-up increments the counter toward the 2-promotion recharge threshold (Level 9-17).
6. Frontend Notification: Dashboard renders the "Capital Allocation Restored" modal (§10.3) immediately, announcing reinstatement to the trader's standard (100%) risk parameters. Display/re-display rule: BR_4.15.4.9.

Example: Trader at Level 12 triggers Defense. Account reduced to 25% notional (5% SL, 6% PT). Trader hits 6% PT within 60 days → (1) ledger reset to $0, (2) restored to Level 12 full parameters, (3) stagnation_deadline = Today + 90 Days, (4) "Capital Allocation Restored" modal shown. Still Level 12, Defense_Used still True. Then promotes to Level 13 (Promotions_Since_Defense = 1). Then promotes to Level 14 (Promotions_Since_Defense = 2) → Defense perk recharged, Defense_Used = False.

BR_4.15.4.9: Post-Defense Modals — Display and Acknowledge Rule

Two follow-up modals fire after the initial Defense Protocol Activated modal (BR_4.15.4.5), at two different points of §4 Basic Flow:

• Drawdown Defense Active: Account Restricted modal — fires at §4 Basic Flow Step 11, on the trader's next system entry after the account re-activates at T+48h with the reduced Table F parameters (§4 Basic Flow Steps 7-8). Screen/copy detail: §10.2.
• Capital Allocation Restored modal — fires at §4 Basic Flow Step 12 Case A (Capital Reinstatement — PIP success). Screen/copy detail: §10.3.

Shared rule (both modals):

• Acknowledge requirement: the trader must click "Acknowledge" exactly once to dismiss the modal.
• Re-display rule: until acknowledged, the modal re-renders on every login, page reload (F5), and navigation to any screen. After the single "Acknowledge" click, the modal is dismissed permanently for that event and does not reappear in later sessions.

Wireframe / UI

9. Wireframe / UI

9.1 Modal Variants — Overview

This UC owns three modal states: the Defense Activated modal (entry into the 48h cooling-off), the Drawdown Defense Active: Account Restricted modal (exit from the 48h lock, start of the PIP window), and the Capital Allocation Restored modal (exit, on successful Capital Reinstatement). The second-breach (failure) path — Stop Loss hit during PIP, or PIP time expiry — routes to UC_4.15.2 and its own modal — not documented here.

9.2 Flow — Defense Activated Path

LEVEL_STOP_BREACH event → Flow 7 Defense Gate
    → Current_Level >= 9 AND Defense_Used == False
        → Flow 4 Trigger B (Defense Handoff)
            → [Defense Protocol Activated modal — §10.1] (re-displays on every Dashboard entry during 48h lock)
                → User clicks "Acknowledge"
                    → Shadow Mode (Frosted Glass, read-only, 48h)
                        → T+48h: account re-activated (Table F reduced parameters)
                            → [Drawdown Defense Active: Account Restricted modal — §10.2] (re-displays on every login/reload/navigation until acknowledged)
                                → User clicks "Acknowledge"
                                    → Normal DMA trading resumes (reduced parameters, PIP window running — BR_4.15.4.8)
                                        → Trader hits 6% Table F PT within 60 days → Capital Reinstatement (BR_4.15.4.8)
                                            → [Capital Allocation Restored modal — §10.3] (re-displays on every login/reload/navigation until acknowledged)
                                                → User clicks "Acknowledge" → modal dismissed permanently, standard 100% parameters active
                        (PIP Failure — Stop Loss hit or time expiry, per §4 Step 12 Case B → routes to UC_4.15.2, not this UC)

10. Screen Description and Business Rules

10.1 Defense Protocol Activated Modal (Level 9-24, Current_Level >= 9 AND Defense_Used == False)

10.2 Drawdown Defense Active: Account Restricted Modal (T+48h Re-Activation)

10.3 Capital Allocation Restored Modal (Capital Reinstatement — PIP success, Ref: BR_4.15.4.9)

Changelog