UC_4.15.2: Hard Breach — Level Stop (LIVE)

Architecture note: LIVE Hard Breach shares the same Atomic Kill Switch mechanism, Frosted Glass display rule, and dynamic Discount_Code_Duration_Days window as SIM Hard Breach — UC_4.10.2. Three confirmed divergences are written out in full for LIVE:

1. Trigger — LIVE uses Market_Loss_When_Stopped (Table A/B per-level lookup), not SIM's flat 7.5% × Notional.
2. Recovery path — LIVE has no "Reset" option, only "Re-Buy" — every LIVE failure requires purchasing a brand-new evaluation.

Flow 7 vs. Flow 7B — do not conflate (v2 correction): Flow 7 (Financial Reporting / Recycling Logic) is the master termination pipeline this UC owns end-to-end — Defense Gate → Refund Check → Ledger Close → Liquidation → Balance Check → Retention Gate (→ Flow 9) → Post-Termination Access Control → Digital Eviction → GL Posting → Notification → Feedback Survey Gate. Flow 7B (Retention & Retargeting) is a separate, independently-triggered Zapier flow — it fires off the Status state-change itself (not a call from inside Flow 7), runs a 1-hour cool-down + purchase check, then routes to Path A (SIM) or Path B (Live/Funded — in scope for this UC) to email a Klaviyo retention offer.

---

Document References

---

1. Overview

2. Trigger

Middleware detects: Net_P&L <= −Market_Loss_When_Stopped

Formula:

Market_Loss_When_Stopped is looked up directly from Table A (Forex) or Table B (Futures) by the trader's Current_Level

Worked example (LIVE Level 1, Forex, $25,000 notional tier): Market_Loss_When_Stopped = $1,250 (Table A) → Hard Breach fires when Net_P&L <= −$1,250.

• Net_P&L = Realized P&L + Unrealized P&L
• Detection runs continuously via the execution-gateway ACCOUNT_METRICS stream (Rithmic/MT5/TraderEvolution) — identical monitoring architecture to SIM
• Once triggered, the decision is final — no recalculation or rollback even if post-flatten slippage changes P&L

3. Pre-conditions

• Trader has an active LIVE account (Status = Active_DMA)
• Middleware maintains a persistent connection to the execution gateway
• Net_P&L is tracked in real-time via ACCOUNT_METRICS stream

4. Post-conditions

Immediate (T+0):

• All open positions flattened via execution gateway
• All working orders cancelled
• Frontend renders Failure Modal with "Frosted Glass" full-dashboard blur
• DB updated with current Equity, Balance, Closed_Trades
• DB Status updated to 'Terminated', failure_timestamp = NOW()
• Trading sub-account is locked (Read-Only) — NOT immediately deleted.
• Dashboard screen: permanently frosted (blurred, non-interactive). Data rendered underneath the frost is the static snapshot captured at the exact moment of the hard breach (equity, balance, closed trades, charts as they stood at failure_timestamp) — NOT live data, NOT reset to a blank state
• • Notification bell is NOT frozen: notifications continue to arrive, unaffected by the Hard Breach/Frosted Glass state.
• All other screens (Account, Settings, etc.): render normally, no blur, no restrictions.
• Trader can purchase Re-Buy at discounted price during this window — see UC_4.15.3.

After archive_date (Failsafe fires):

• Historical ledger data purged from the active dashboard view → archived to user_account_history (SQL database retains the full performance ledger; only the active UI view is purged).
• Broker-specific Failsafe actions: see BR_4.15.2.7.
• At this point the dashboard resets to a blank D=0 state.
• Re-Buy pricing after window expiry depends on is_founder: IF is_founder == TRUE → locked_rebuy_price; IF is_founder == FALSE → Full Challenge Price (Table J).

Re-Buy Exception: if the trader purchases Re-Buy before the window expires, the backend's atomic reset immediately wipes the failed state and resets the dashboard to D=0 for the new challenge.

Dashboard access:

• Dashboard login never expires. Trader can return at any time.

5. Basic Flow

Detect breach: middleware continuously monitors Net_P&L from the execution-gateway stream (ACCOUNT_METRICS) and checks Net_P&L <= −Market_Loss_When_Stopped as fills arrive and P&L updates → Breach confirmed, then trigger Flow 7 as below:

Flow 7 (Financial Reporting / Recycling Logic) — full pipeline

Step 1 — Defense Gate:

• IF Resignation == True → SKIP Defense Gate, proceed directly to Liquidation (Step 4 Atomic Kill Switch). This path is entered via Flow 20 — see §8 Business Rules / Stagnation & Alternate Entry Points for the full description.

• Eligibility check: IF Current_Level >= 9 AND Defense_Used == False → eligible for Defense. Otherwise → ineligible, proceed to termination.

  • If eligible → trigger Flow 4B webhook (Defense Handoff), HALT Flow 7 — check details for defense case in UC_4.15.4 (Scenario C: Defense Protocol).
  • If ineligible (Current_Level < 9 OR Defense_Used == True) OR resigned → continue through Flow 7 (termination path).

• Atomic Kill Switch:

  1. Lock: Disable order entry via Broker API
  2. Flatten: Send Market Close for ALL open positions
  3. Cancel: Cancel all working orders (pending orders)
  4. DB Update: Status = 'Terminated', failure_timestamp = NOW()
  5. Lock sub-account (Read-Only): the middleware locks the trading sub-account (Read-Only) at T+0.
  6. Fire event: Middleware pushes LEVEL_STOP_BREACH to the frontend AND to Zapier — payload (Note: Sotatek can modify if needed):

  Field	Type	Description
  event_type	string	"LEVEL_STOP_BREACH"
  user_id	string	Trader's user ID
  net_pnl	float	Current Net P&L at breach (negative float)
  market_loss_when_stopped	float	Account's per-level stop threshold (negative float, from Table A/B)
  amount_over_stop_loss	float	Amount by which Net P&L exceeded the stop loss

  [CHR-69] Amount_over_stop_loss = |Net_PnL at hard breach| − Market_Loss_When_Stopped

  • |Net_PnL at hard breach|: absolute Net P&L (Realized + Unrealized) at the moment LEVEL_STOP_BREACH fires.
  • Market_Loss_When_Stopped: per-level Hard Stop Loss threshold (Table A/B).
  • Amount_over_stop_loss: excess loss beyond the stop threshold (gap/slippage). Used in Flow 9 Severance deduction — see BR_4.15.2.5.

  POST /fail-challenge (called with { user_id, Reason: "Drawdown" }) only returns HTTP 200 when the account is CONFIRMED FLAT (Open_Positions == 0). The decision is final once triggered (BR_4.15.2.4).

• Frontend renders Failure Modal (immediate UI reaction to the WebSocket event, running in parallel with the rest of Flow 7 below):

  • "Frosted Glass" blur applied to the Dashboard screen only — same display rule as SIM, see BR_4.10.2.2. Other screens render normally.

  • There are 5 Failure Modal variants, chosen by Current_Level, Defense_Used, and Severance_Pay. See BR_4.15.2.6 for the full breakdown and wireframe references:

    #	Level band	Has Defense?	Severance?	Modal shown
    1	1-8	No	No	Standard failure modal (no severance notice)
    2	1-8	No	Yes	"Risk Parameter Breached" + Severance payout notice
    3	9-24,Defense_Used == FALSE	Yes	—	"Drawdown Defense Activated" notice (Defense runs — checkUC_4.15.4)
    4	9-24,Defense_Used == TRUE	No (already used)	No	Standard failure modal — no severance, defense exhausted
    5	9-24,Defense_Used == TRUE	No (already used)	Yes	Failure-with-Severance notice — defense exhausted

    Wireframe assets for the base Hard Breach modal are listed at §9 Wireframe / UI.

Step 2 — Refund Check (Market Data): IF Next_Month_Data_Paid == True (pre-paid market-data subscription within the last 3 days) → call POST /issue-refund with { user_id, type: "MARKET_DATA" }. Middleware looks up the original Gateway_Source and issues the refund via the matching API.

Note — Non-refundable gateway exception: If Gateway_Source is Dusupay, Crypto (tbd), or any other APM that rejects automated reversal, the middleware must instantly catch the failure (or bypass the API attempt entirely for known-incompatible gateways) without blocking the rest of Flow 7. The system must instead:

1. Log the transaction exception to the financial ledger database.
2. Auto-generate a high-priority Freshdesk ticket for the Operations team. The ticket payload must contain:
   • user_id — the trader's User ID
   • transaction_id — the original Transaction ID
   • gateway_source — the Gateway Source
   • refund_amount — the exact refund amount

Same pattern as the irreversible refund branch in UC_2.8.2 §2.

Step 3 — Ledger Close: Call POST /financial/reset-ledger with { deactivate: true } to set ledgers.virtual_equity = 0. virtual_equity is the primary internal balance tracker on the Ledgers table — initialized at Live Onboarding (Flow 3H), updated with new capital on promotion (Flow 4), and reset to 0 here on failure.

Step 4 — Liquidation: Flatten positions (second pass — a confirming safety re-check on top of the real-time Kill Switch already executed in Step 1's Otherwise branch above, in case any position opened in the gap between breach detection and Flow 7 pickup).

Step 5 — Balance Check (Flash Crash Protection): IF Balance < 0 → trigger a Critical Alert routed to the #ops-general Slack channel (ID: C0BR8LRC5MK — Production) / #test-ops-general (ID: C0BR6UXRR8D — Test) AND log to the Bad_Debt_Log SQL table for tax write-off. Bad_Debt_Log should contain user_id, fcm_subaccount_id, date, and negative_balance_amount. (Ref: CR-15.2)

Step 6 — Retention Gate → Severance Protocol:

• IF Severance_Pay > 0 (looked up from Table A/B by Current_Level) → Execute Flow 9.
• IF Severance_Pay == 0 (or NULL) → Skip Flow 9.
• Full Flow 9 payout logic (Authorized_Amount deduction math, Path A/B/C routing by contractor status) — see BR_4.15.2.5.

Step 7 — Post-Termination Access Control: Call POST /system/set-account-state with { user_id, state: "Terminated" }.

• Trading sub-account is NOT hard-deleted at this step. The sub-account remains in a locked (Read-Only) state from T+0. Trading is permanently blocked, but the account record and performance ledger are fully intact in the SQL database.

• Dashboard login remains active — the trader can still log in at any time to view their frozen dashboard and to access the Re-Buy CTA. No login expiry is applied.

• Sub-account deletion is deferred — hard-delete only occurs under one of two conditions:

  • archive_date Failsafe fires (cron job) — broker-specific cleanup runs (see BR_4.15.2.7).
  • Trader purchases Re-Buy before archive_date → atomic reset cleans up the locked sub-account as part of Re-Buy provisioning (see UC_4.15.3 and BR_4.15.2.7 Case A).

Step 8 — Community (Digital Eviction): Call POST /discord/revoke-all-roles with { user_id }. The Node.js Discord Bot removes "Pod Member", "Pod Leader", and all Title Roles using the trader's stored discord_user_id. (Not run for the Founding Mentor path — see §6 Alternative Flow, which explicitly keeps Pod Leadership/Discord roles intact.)

Step 9 — GL Posting: Log P&L to QuickBooks Online. Payload should include user_id, termination date, and final realized P&L to close out the ledger.

Step 10 — Feedback Survey Gate: Query the Users table for pod_leader_id. IF pod_leader_id IS NOT NULL (trader was in a pod) → embed a Typeform exit-evaluation survey link directly inside the Live_Account_Closed email (Step 11) and update last_survey_date = Today.

The form is natively hosted by Typeform (no build required); Typeform handles the webhook payload on submission.

Step 11 — Notification: Send the Live_Account_Closed email with the Typeform link. Suppression gate: IF this Flow 7 run was triggered by Flow 19 (Stagnation Monitor, Reason Code == STAGNATION) → SKIP this email (silent skip — Flow 19 already sent its own Stagnation_Termination email; sending both would collide). See suppression logic in UC_4.15.4 BR_4.15.4.4.

---

Flow 7B (Retention & Retargeting) — separate flow, Path B only

Flow 7B is a separate database-webhook listener — it is NOT a sequential step of Flow 7. It fires on two distinct triggers, both of which write Status = 'Terminated' into the database:

• Trigger A — Hard Breach: Account Status changes to 'Terminated' via Step 1's Atomic Kill Switch (real-time breach detection or Stagnation Monitor).
• Trigger B — Voluntary Resignation: Trader clicks the "Resign Account" button → RESIGNATION_EXECUTED webhook fires → Flow 7 runs with Reason = VOLUNTARY_RESIGNATION → Status = 'Terminated' is written. Flow 7B fires on the same state change.

In both cases Flow 7B runs independently alongside the rest of Flow 7's pipeline:

1. Trigger: Account Status changes to Terminated.
2. Action 1 — Cool-Down: Delay 1 Hour (gives the trader time to click the Dashboard Re-Buy CTA before the marketing email fires).
3. Action 2 — Purchase Check: IF Last_Purchase_Date > Failure_Timestamp (trader already re-bought during the cool-down window) → STOP, no email sent.
4. Action 3 — Path Router: checks is_professional == TRUE:

• IF is_founder == TRUE → locked_rebuy_price
• IF is_founder == FALSE AND within failure_timestamp + Discount_Code_Duration_Days → Challenge_Price × (1 − Retry_Discount) (Table A/B Retry_Discount, base price from Table J by Current_Level at time of failure)
• IF is_founder == FALSE AND expired → Full Challenge Price (Table J)

6. Action: Emit Retention_Offer_Discount payload to the Klaviyo API with user_name, current_level, and the targeted Discounted_Price value.
7. Action 4 — Follow-Up Marketing (out of system scope): Klaviyo monitors the conversion lifecycle natively. IF no new transaction within failure_timestamp + Discount_Code_Duration_Days (Table C) → Klaviyo executes the Coupon_Expiring_Soon follow-up broadcast.

6. Alternative Flow

• [Founding Mentor Hard Breach]

  • If Role_Flag = 'Founding Mentor' and the overlay has NOT yet been acknowledged for this breach event, the Failure Modal is replaced by the Founding Mentor-specific overlay — identical re-summon rule to SIM, see UC_4.10.2 §6 — Wireframe: Hard breach for founding mentor.png (shared wireframe with SIM, no separate LIVE asset).

  • After acknowledgement: routes straight into pricing + modal, same as SIM. The only difference is the modal itself:

    1. System calls POST /calculate-cart (Quaderno tax calculation) → price is locked at locked_rebuy_price (Founders always use locked_rebuy_price, never locked_reset_price, which is SIM-only).
    2. Re-Buy Modal opens directly

  • Capital Protection (runs immediately, no bypass): identical to SIM — all positions flattened, all working orders cancelled.

  • Administrative Termination: identical to SIM — Discord roles are NOT revoked, Pod assignments remain intact.

7. Exceptional Flow

Identical to SIM — see UC_4.10.2 §7 Exceptional Flow.

8. Business Rules

BR_4.15.2.2: Frosted Glass — Permanent Until Re-Buy

Identical to SIM — see BR_4.10.2.2, substituting "Re-Buy" for SIM's "Reset".

BR_4.15.2.3: Discount_Code_Duration_Days — Dynamic Configuration

Identical to SIM — see BR_4.10.2.3.

BR_4.15.2.4: Immediate Triggering — No Rollback

Identical to SIM — see BR_4.10.2.6.

BR_4.15.2.5: Severance Protocol (Flow 9) — Eligibility and Payout

• Eligibility: Severance_Pay > 0 for the trader's Current_Level (Table A/B lookup) → If not, HALT.

• Deduction math: Authorized_Amount = Severance_Pay − (Amount_Over_Stop_Loss if > $100) — slippage under $100 is forgiven; slippage over $100 is deducted in full.

  [CHR-69] Amount_over_stop_loss = |Net_PnL at hard breach| − Market_Loss_When_Stopped

  • Eg:
    • Severance pay = 225 and Amount_Over_Stop_Loss = 125 → Authorized_amount = 225 - 125 = 100
    • Severance pay = 225 and Amount_Over_Stop_Loss = 25 → Authorized_amount = 225

• Reason override:

  • IF Reason == TERMINATION_FOR_CAUSE (fraud, malicious activity, chargeback dispute — manually flagged by Operations, not automatically detected) → Severance = $0.
  • IF Reason == LAYOFF/NO_CAUSE or VOLUNTARY_RESIGNATION → pay full Severance_Pay (no Stop-Loss deduction). Note: Reason = VOLUNTARY_RESIGNATION: trigger when user clicks the "resign account" button.
  • Ordinary breach: Hit hard breach, Reason == DRAWDOWN → Calculate Authorized_amount normally.

• Authorization: Payout is initiated when a Marketing User clicks the "Authorize" button inside the Zapier Interface (linked via an ActiveCampaign Task). The Node.js middleware simply exposes the Process Severance Payout endpoint — Zapier holds state and waits for the human to authorize. The human interaction occurs completely outside of the Node.js middleware. On-click, Zapier:

  1. Creates an ActiveCampaign task with the authorized amount and script template.
     1. Script template: This is simply a text prompt for the marketing team to use during the phone call. Do not need to code the content. Just ensure the payload field exists so marketing can map their copy in Zapier.
  2. Queries billing_country and current_level to determine the payout path.
  3. Sends payout_amount via the corresponding API.

  Path routing by contractor status at time of failure:

  Path	Condition	API
  Path A — US Contractor (Levels 1-5)	billing_country = 'US' AND current_level 1-5	Dots API
  Path B — International (All Levels)	billing_country != 'US' (all levels)	Dots API
  Path C — US W-2 (Level 6+)	billing_country = 'US' AND current_level >= 6	Rippling Off-Cycle Payroll API

  Note: Severance is paid regardless of whether the trader chooses to execute a Re-Buy.

• Every payout is logged and must be visible on the trader's Billing screen.

BR_4.15.2.6: Failure Modal Variant by Level Band

Wireframe source: References/Wireframe/Stage 2.2/Failure and recovery/

Severance availability is independent of level band — a trader at any level within 1-8 may or may not have severance depending on the Table A/B lookup. The level band determines which wireframe variant and modal copy to use.

Level 9-24 has three termination modals (Variants 3, 4, 5):

• Variant 3 (Defense_Used == FALSE): "Drawdown Defense Activated" — account enters Defense Protocol (UC_4.15.4); Flow 7 termination pipeline is halted. This modal is shown, but the account is NOT terminated.
• Variant 4 (Defense_Used == TRUE, Severance_Pay == 0): Failure modal, no severance — account is terminated through Flow 7 normally. Header: "Risk Parameter Breached" / sub-title: "Trading Revoked"; body text specific to Level 9-24 drawdown breach. No severance notice box. Screen description: UC_4.15.3 §10.3.
• Variant 5 (Defense_Used == TRUE, Severance_Pay > 0): Failure-with-Severance — account is terminated through Flow 7 normally, severance payout notice displayed.

BR_4.15.2.7: Broker-Specific Failsafe and Re-Buy Provisioning (LIVE) [CHR-61] [CHR-62]

archive_date — Broker-Specific Calculation:

Broker routing:

Example (Rithmic): Trader fails on 25 Aug. M2 = 4 Sep (25 Aug + 10 days). M1 = 31 Aug 23:00 UTC. → archive_date = 31 Aug 23:00 UTC (M1 fires first).

---

Rithmic — Server Architecture & ID Rules

Rithmic runs two distinct server environments:

• Paper Trading Server — SIM accounts
• Live Trading Server — Live accounts (Ironbeam controlled)

These are separate gateways. A Re-Buy (Live → SIM rollback) must provision the new sub-account on the Paper Trading Gateway — the Live sub-account and Live server are never reused.

ID Mapping: Rithmic assigns two independent gateway-level User IDs per trader:

Both IDs must be explicitly mapped to the master PostgreSQL user_id (UUID) at all times. The two IDs are fully independent — enabling or disabling one has no effect on the other.

Live Onboarding state change: When a trader's SIM account is promoted to Live, the system disables the Rithmic SIM User ID and unassigns the SIM sub-account. Any rollback to SIM (Re-Buy) must therefore explicitly re-enable the Rithmic SIM User ID before the new SIM sub-account can be provisioned.

---

Pre-Archive Gate — Data Integrity Sync

Before executing any broker-side cleanup (unassign / delete), the system must verify that all final trade data and P&L snapshots for the failed LIVE account are successfully written to:

• user_account_history (PostgreSQL)
• AWS S3 Glacier — immutable system of record for all trade logs and compliance data, operating independently of the execution platforms

No cleanup action may proceed until both writes are confirmed. This gate applies at two trigger points:

• Failsafe (archive_date fires): archive runs before Rithmic unassign or MT5/TE hard-delete.
• Case A (Re-Buy before Failsafe): archive runs before any broker-side cleanup as part of Re-Buy provisioning.

---

Failsafe — actions when archive_date fires (after Pre-Archive Gate passes)

---

Case A — Re-Buy purchased BEFORE Failsafe (within archive_date)

Locked LIVE sub-account still exists. Pre-Archive Gate runs first, then Re-Buy provisioning executes the full Live-to-SIM rollback.

---

Case B — Re-Buy purchased AFTER Failsafe (after archive_date)

Failsafe has already run: Rithmic Live User ID disabled, Market Data revoked, LIVE sub-account unassigned (MT5/TE: hard-deleted). Archive already completed at Failsafe time. Re-Buy only needs to restore SIM access and provision the new account.

BR_4.15.2.8: Market Data Re-Select Screen (Rithmic Futures Re-Buy only) [CHR-62]

• Applicable only to Rithmic Futures traders purchasing Re-Buy.
• After Re-Buy payment succeeds, the frontend presents a Market Data re-select screen that persists (non-dismissible) until the trader clicks "Complete". The screen re-displays on every page reload or re-login until selection is submitted — the trader cannot access the dashboard before completing this step.
• This screen is required because the old Live Pro data entitlements were revoked at failure time (Case A) or by Failsafe (Case B), and the new SIM sub-account starts with no active entitlements. The trader must select their SIM Non-Pro data package before they can access the dashboard.
• Forex brokers (MT5, TraderEvolution) do not present this screen — there is no per-user market data subscription for Forex.

SIM feed reuse example:

A trader purchases a SIM challenge on 2 Aug and selects 3 exchanges (CME Level 2, CBOT, NYMEX). On 3 Aug they go Live, fail the Hard Breach on the same day, and immediately purchase a Re-Buy.

• At Re-Buy: their SIM entitlements are still active on the Paper Trading gateway for the current billing period.
• The Market Data re-select screen is shown. If the trader selects the same 3 exchanges (exact match) → backend detects active entitlements and reuses them without charging again.
• If the trader drops to 2 exchanges (downgrade) → backend reuses the 2 active ones, no purchase.
• If the trader adds COMEX as a 4th exchange (upgrade) → backend provisions the 4th exchange at $18

Wireframe / UI: Hard Breach modals and the Market Data re-select screen are documented in UC_4.15.3 §9–§10.

Changelog