UC_4.10.2: Hard Breach — Level Stop

---

Document References

---

1. Overview

2. Trigger

This UC owns the Failed state, not just the breach that causes it. Two events write status = 'Failed' on a SIM account, and everything downstream of that write is shared:

Entry point	failure_reason	Owned by
Hard Breach —Net_P&L <= −Absolute_Stop_Loss	Drawdown	This UC
Voluntary resignation —POST /resign	VOLUNTARY_RESIGNATION	UC_4.11.2 — the middleware sequence and the Resignation Complete modal only; everything after the status write is this document (Ref: CR-65)

The pipeline below (Flow 2 → Flow 7B Path A), §4 Post-conditions, BR_4.10.2.2, BR_4.10.2.3 and BR_4.10.2.7 therefore apply unchanged to a resigned trader. The only divergences are the entry point (BR_4.10.2.4's SIM gate does not apply — a resignation is user-initiated), the failure_reason value, and which modal renders over the frost (selected by state_reason).

Middleware detects: Net_P&L <= −Absolute_Stop_Loss

Formula:

Absolute_Stop_Loss = Notional × SIM_stop_percent (Zapier Table C, default 7.5% — same variable defined in UC_4.10.1 §2 Trigger, Ref: [CHR-49])

• Net_P&L = Realized P&L + Unrealized P&L (same definition as UC_4.10.1)
• Notional = Notional for the respective Associate Track (Level 1, 2 or 5) from Zapier
• SIM_stop_percent = 7.5% (default, Zapier Table C, Ops-editable — Ref: UC_4.10.1 §BR_4.10.1.6), flat rate applied regardless of level tier

Worked example (SIM Level 1, $25,000 notional): Absolute_Stop_Loss = $25,000 × 0.075 = $1,875 → Hard Breach fires when Net_P&L <= −$1,875.

• Detection runs continuously — as fills arrive and P&L updates in real-time, the middleware recalculates and checks against the threshold
• Open positions are continuously monitored in real-time (Mark-to-Market) as market prices fluctuate
• 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 SIM account (Status = Active_SIM)
• Middleware maintains a persistent connection to the execution gateway
• Equity is being tracked in real-time via WebSocket streams

4. Post-conditions

Immediate (T+0):

• All open positions flattened via execution gateway
• All working orders cancelled
• Trading sub-account locked (Read-Only state)
• LEVEL_STOP_BREACH WebSocket event fired to frontend
• Frontend renders Failure Modal with "Frosted Glass" full-dashboard blur
• DB updated with current Equity, Balance, Closed_Trades
• Net_P&L <= −Absolute_Stop_Loss → POST /fail-challenge with { user_id, Reason: "Drawdown" }
• DB Status updated to 'Failed', failure_timestamp = NOW()
• This DB Status change is what fires the CHALLENGE_FAILED state-change webhook → invokes Flow 2 → Flow 7B Path A (SIM retention email) — full sequence documented once, at Basic Flow Steps 7-8

From T+0 to archive_date (broker-specific — see BR_4.10.2.7) [CHR-59]:

• Reset Modal: Displayed immediately at T+0 (Hard Breach). The modal shown does not change based on archive_date — it is always the Reset Modal. Only the price inside the modal differs (see UC_4.10.3 BR_4.10.3.1).
• Trading sub-account: Locked (Read-Only). NOT deleted.
• Dashboard screen only: permanently frosted (blurred, non-interactive except for the Failure Modal/purchase CTAs). The dashboard data rendered underneath the frost is a static data captured at the exact moment of the hard breach (equity, balance, closed trades, charts as they stood at failure_timestamp) — it is NOT live data and is NOT reset to any starting/blank state.
  • PnL Gauge specifically: frozen in the "Breached (Account Disabled)" state — needle locked, no further ACCOUNT_METRICS updates (Ref: BR_4.8.1.5).
  • Notification bell and Days Remaining counter (Persistent Header), by contrast, are NOT frozen: both keep running normally — notifications continue to arrive and the countdown keeps ticking, unaffected by the Hard Breach/Frosted Glass state (Ref: UC_4.1.1 §2 Screen Description, Source: BA/client direct instruction, 2026-08-17)).
• All other screens (Account, Settings, etc.): render completely normally, exactly as business-as-usual — no blur, no restrictions, nothing logged out, nothing deleted. Only the Dashboard screen carries the frosted/permanent-failure treatment during this window.
• GET /get-failure-state returns: is_breached: true, archive_date: <broker-specific per [BR_4.10.2.7](#BR_4.10.2.7)> [CHR-59]
• Trader can purchase Reset at discounted price → see UC_4.10.3

After archive_date fires [CHR-59]:

• Trade history cleared from active dashboard view → archived to user_account_history
• Broker-specific provisioning:
  • Rithmic: Revoke Market Data entitlements. Change failed sub-account status to "unassigned". Provision brand-new sub-account. Assign to existing User ID. Re-enable User ID.
  • MT5 and TraderEvolution: Hard-delete the locked sub-account. Provision brand-new sub-account.
• Dashboard screen: data underneath the frost resets to T=0 state (same as a fresh account) — no longer the breach snapshot. Frosted Glass remains permanent (does not disappear). The Reset Modal continues to be displayed — same modal as before archive_date fired. If the trader has not reset/rebought yet, the modal remains present and functional after archive_date.
  • Level Progression widget exception: the Associate Track / SIM evaluation package card is shown in a locked state (lock icon overlay) — this differs from a normal Day 0 dashboard, where the same card is unlocked.
• All other screens carrying trader data (Account, Settings, Journal, etc.) — not just the Dashboard — also reset to T=0 state.
• Account screen (triggered from the sidebar) now shows 3 tabs: "Profile & Preferences", "Billing", and "Account Actions" (Billing tab remains accessible after archive) → Wireframe: Account (hard breach + account has been reseted (window expired)).png
• Trader can purchase Reset at full Challenge Price → see UC_4.10.3

Dashboard access:

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

5. Basic Flow

Note on Flow 2 architecture: Zapier Flow 2 no longer triggers on a Trade_Closed webhook, and its failure check no longer includes Daily_Loss < Limit (Daily Loss is a soft pause, never a hard failure — see UC_4.10.1). The Node.js middleware performs continuous real-time equity monitoring and makes the failure decision itself — Zapier is invoked only afterward, as an event router off the middleware's CHALLENGE_FAILED state-change webhook.

Step 1 — SIM Gate (pre-check, prevents race conditions): Before evaluating any breach condition, the middleware verifies Status == 'Active_SIM'. IF Status is anything else (e.g., 'Promoting' during a Flow 3 race condition) → skip; no further action this cycle.

Step 2 — Detect breach: Middleware continuously monitors Net_P&L in real-time from the execution-gateway stream (ACCOUNT_METRICS) and checks Net_P&L <= −Absolute_Stop_Loss as fills arrive and P&L updates.

Step 3 — Check Failure → Atomic Kill Switch (4 sequential sub-steps):

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 = 'Failed', failure_timestamp = NOW()

The endpoint POST /fail-challenge only returns HTTP 200 when account is CONFIRMED FLAT (Open_Positions == 0). The decision is final once triggered — no recalculation or rollback even if post-flatten slippage changes the P&L.

Step 4 — Update DB (Sotatek can change the payload if needed): Write current Equity, Balance, Closed_Trades to Users table. Call POST /fail-challenge with { user_id, Reason: "Drawdown" }.

Step 5 — Fire WebSocket event (Sotatek can change the payload if needed): Middleware emits LEVEL_STOP_BREACH to the frontend:

Note — the resignation path does not emit LEVEL_STOP_BREACH. There is no breach event to push: the frontend already holds the HTTP 200 from POST /resign and re-fetches state directly. Steps 5–6 are Hard-Breach-only; a resigned trader reaches the same Frosted Glass state through the GET /failure-state refresh instead — Ref: UC_4.11.2 §BR_4.11.2.15.

Step 6 — Frontend renders Failure Modal:

• "Frosted Glass" blur applied to the Dashboard screen only → Wireframe: Dashboard - Day 0 + Hard breach.png.
• Other screens (Account, Settings, etc.) render normally — no blur outside the Dashboard.
• Full display rule and re-summon behaviour → BR_4.10.2.2.

Step 7 — State-change webhook → Flow 2 "Challenge Monitor" (router only): Middleware's DB Update in Step 3 fires the CHALLENGE_FAILED state-change webhook → invokes Flow 2. Flow 2 now routes SIM-status failures to Flow 7B Path A.

A voluntary resignation joins the flow exactly here. POST /resign performs its own equivalent of Steps 3–4 (lock → flatten → cancel → status = 'Failed' with failure_reason = 'VOLUNTARY_RESIGNATION') and then fires the same CHALLENGE_FAILED webhook. Steps 7–8 below run identically for it — same cool-down, same purchase check, same pricing route, same Klaviyo Challenge_Failed emission. Ref: UC_4.11.2 §BR_4.11.2.9, CR-65.

Step 8 — Flow 7B Path A (SIM failure retention):

1. Trigger: Account Status changes to Failed (Any Level) — DB webhook
2. Action 1 — Cool-Down: Delay 1 Hour (gives user time to click Dashboard "Reset" CTA before marketing email fires)
3. Action 2 — Purchase Check: After 1 hour, check whether the trader has already reset the account themselves — IF the last purchase date (Last_Purchase_Date) is later than the failure time (Failure_Timestamp), it means they already bought a Reset during the cool-down window, so STOP the retention flow (no email sent).
4. Action 3 — Path Router: Check User_Level → routes to Path A (SIM)
5. Action 4 — Pricing route [CHR-59]:
   • IF is_founder == TRUE AND within failure_timestamp + Discount_Code_Duration_Days → retrieve locked_reset_price (Table J)
   • IF is_founder == TRUE AND after failure_timestamp + Discount_Code_Duration_Days → retrieve locked_rebuy_price (Table J) — the locked reset privilege expires after the window; pricing falls back to the Live Re-Buy locked price
   • IF is_founder == FALSE AND within failure_timestamp + Discount_Code_Duration_Days → retrieve Reset Fee (Table J) by Current_Level + Asset_Class
   • IF is_founder == FALSE AND after failure_timestamp + Discount_Code_Duration_Days → retrieve Full Challenge Price (Table J)
6. Action 5 — Reason Code Gate (Ref: UC_4.10.4 §BR_4.10.4.2): IF incoming Reason Code == STAGNATION (i.e. this Failed status originated from Flow 19's Stagnation path, not a real-time Hard Breach) → do NOT emit the Challenge_Failed payload in Action 6 below. ELSE → proceed to Action 6.
7. Action 6: Emit Challenge_Failed payload to Klaviyo API with user_name and Pricing_Logic_Amount
8. Out of system scope: Klaviyo monitors conversion lifecycle natively. IF no new transaction within failure_timestamp + Discount_Code_Duration_Days → Klaviyo executes 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 a Founding Mentor-specific overlay, re-shown until acknowledged, on any of these 3 cases: (a) reloading while already on the Dashboard, (b) navigating to the Dashboard from the header menu/another tab, or (c) logging in and landing on the Dashboard → Wireframe: Hard breach for founding mentor.png
  • Overlay content:
    • Header: "Risk Threshold Breached"
    • Body: "Your account has triggered a Level Stop Loss and all positions have been liquidated. As a Founding Mentor, while your trading account is closed, your Pod Leadership and Discord roles are protected and remain active. Your trading account is eligible for reduced pricing to restart."
    • Button: "I Acknowledge"
  • After acknowledgement: The Founding Mentor overlay is dismissed. Since this overlay already stands in for the Hard Breach Popup as the entry-point popup, clicking "I Acknowledge" does not then show the Hard Breach Popup as a separate intermediate step — it routes straight into pricing + modal, the same way the Account Actions "Reset" button bypasses the Hard Breach Popup (BR_4.10.2.2). The two steps are:
    1. System calls POST /calculate-cart (Quaderno tax calculation) → price is locked.
    2. Reset Modal or Start New Track Modal opens directly (4-variant matrix per UC_4.10.3 §9.2) — further branching depends on Discount_Code_Duration_Days window and customer_vault_id.
  • The mentor's trading account is closed and locked in read-only status exactly like a standard user. They cannot trade immediately. The overlay's "eligible for reduced pricing to restart" line refers to the standard within-window discounted Reset Fee (vs. the Full Challenge Price after expiry) that applies to every trader during Discount_Code_Duration_Days.
  • From then on: every subsequent Dashboard reload or click on "Reset" shows the Hard Breach Popup directly — the Founding Mentor overlay does not reappear for this breach event, since it has already been acknowledged.
  • Capital Protection (runs immediately, no bypass): All positions flattened via execution gateway. All working orders cancelled.
  • Administrative Termination: Discord roles are NOT revoked. Pod assignments remain intact.

7. Exceptional Flow

• [Founding Mentor closes tab without acknowledging]

  • The Founding Mentor overlay is displayed on their next login.
  • Dashboard remains locked in Frosted Glass state.
  • After acknowledgement, transitions to standard Reset or Start new track Modal.

8. Business Rules

BR_4.10.2.2: Frosted Glass — Permanent Until Reset

• The Hard Breach modal and Frosted Glass display permanently anytime the user is on the Dashboard. Other screens (Account, Settings, etc.) render normally, without blur.
• Hard Breach Popup (the Dashboard-only popup, §10.1 of UC_4.10.3) is (re-)summoned on any of these 3 cases: (a) reload while already on the Dashboard, (b) navigate to the Dashboard from the header menu or another tab, (c) login and land on the Dashboard.
• Account Actions screen "Reset" button is a separate, direct entry point — clicking it does NOT summon the Hard Breach Popup. It bypasses the popup entirely and goes straight to pricing calculation + the Reset modal. See UC_4.10.3 §2 Trigger and §5.3 for the full flow.
• In Frosted Glass mode: all interactive controls on the Dashboard are disabled; data displays and charts appear desaturated and blurred.
• Navigation isolation — the trader is never trapped. The following stay fully interactive behind/around the overlay, in every Failed state: the sidebar navigation, the sidebar user chip and its dropdown (including Logout), and every Settings / Account tab (Profile & Preferences, Billing, Account Actions). Only the Dashboard's own widgets are frozen. Shared by every SIM Failed path, resignation included — Ref: UC_4.11.2.
• Modal selection is driven by state_reason. GET /failure-state returns state_reason: "BREACH" | "RESIGNATION"; "BREACH" renders the Hard Breach Popup / Reset Modal specified here, "RESIGNATION" renders the Resignation Complete modal owned by UC_4.11.2 §9.4. The Frosted Glass treatment underneath is identical in both cases — Ref: CR-65.
• The Reset Modal is the only modal shown for a SIM Hard Breach. It is displayed immediately upon Hard Breach and remains the same modal before and after archive_date. The archive_date does not change which modal is displayed — only the price inside the modal differs by Discount_Code_Duration_Days window (see UC_4.10.3 BR_4.10.3.1).

BR_4.10.2.3: Discount_Code_Duration_Days — Dynamic Configuration

• The reset window duration is NOT hardcoded. It is read dynamically from Zapier Table C as Discount_Code_Duration_Days.
• Default value: 10 days. Operations can change this at any time without code deployment.
• This variable is one input to the archive_date calculation — but archive_date is broker-specific (see BR_4.10.2.7) [CHR-59]. For MT5/TE: archive_date = failure_date + Discount_Code_Duration_Days. For Rithmic: archive_date = Min(23:00 UTC last day of failure month, failure_date + Discount_Code_Duration_Days).
• Scope of this variable: Discount_Code_Duration_Days determines the price shown in the Reset Modal (Reset Fee vs. Full Challenge Price — see UC_4.10.3 BR_4.10.3.1). It does not control which modal appears or when the modal appears. The Reset Modal is always displayed immediately on Hard Breach, regardless of whether this window has elapsed.

BR_4.10.2.4: Hard Breach → SIM Gate (Pre-Check)

• Before evaluating any breach condition, the middleware verifies Status == 'Active_SIM' (Basic Flow Step 1).
• If Status is anything else (e.g., 'Promoting' during a Flow 3 race condition), the middleware skips the breach check entirely for that cycle.
• This prevents accidentally failing an account that is mid-promotion.
• Scope: this pre-check guards the automated breach evaluation only. It does not apply to a voluntary resignation, which is user-initiated and validated by its own endpoint — Ref: UC_4.11.2 §BR_4.11.2.7.

BR_4.10.2.5: is_founder vs Role_Flag — Distinct Fields

• is_founder (Boolean): Set at Flow 1 Step 4 by comparing the price charged against the Founder Price for the user's tier (Table J). Ref: [CHR-53], UC_2.8.2 §2 Step 4. Used for grandfathered pricing (locked_reset_price, locked_rebuy_price).
• Role_Flag = 'Founding Mentor' (String): Set via Flow 1.5 when Pod Leader signs Rippling agreement. Used for Founding Mentor Defense Bypass (protection from automated suspension).
• Flow 7B Path A uses is_founder Boolean for pricing, NOT Role_Flag. Being a Founding Mentor does not by itself grant reduced pricing.

---

BR_4.10.2.7: Broker-Specific Archive Date, Failsafe, and Reset Provisioning Mechanics [CHR-59]

archive_date — Broker-Specific Calculation:

---

Pre-Archive Gate — Data Integrity Sync

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

• user_account_history (PostgreSQL) — active query layer
• 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 disable/revoke/unassign or MT5/TE hard-delete.
• Case A (Reset before Failsafe): archive runs before any broker-side cleanup as part of Reset provisioning.
• Case B (Reset after Failsafe): archive was already completed when Failsafe ran — no repeat required.

Execution order is strict: (1) Sync PostgreSQL + S3 Glacier → (2) Provision new sub-account → (3) Delete/unassign old sub-account (broker-specific).

---

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

---

Reset Provisioning — Broker-Specific (New Sub-Account Always)

POST /purchase-challenge-reset always provisions a new sub-account. Provisioning steps differ depending on whether the trader resets before or after the Failsafe has fired.

Case A — Reset BEFORE Failsafe (within archive_date):

Failed sub-account still exists (locked). Failsafe has not fired — User ID remains enabled and Market Data entitlement may still be active. Pre-Archive Gate runs first, then Reset provisioning cleans up the old account.

Case B — Reset AFTER Failsafe (after archive_date):

Failsafe has already run: User ID disabled, Market Data revoked, sub-account unassigned (MT5/TE: hard-deleted). Archive already completed at Failsafe time. Reset provisions the new account and restores access.

In all cases: wipe failed state from DB, clear trade_history, reset virtual balance to tier's starting capital.

For Early Reset (input Status = 'Active_SIM', Ref: UC_4.10.3 CHR-40): no failed state to wipe (no-op); trade_history clear and virtual balance reset still apply. Case A always applies (Active_SIM means no Failsafe has fired).

BR_4.10.2.8: Market Data Handling — Rithmic Reset (SIM) [CHR-60]

Applies to Rithmic traders purchasing a Reset on the SIM track. Because the exchange charges a flat fee per User ID per calendar month, the backend action depends on two conditions: (a) whether the reset occurs in the same calendar month as the failure, and (b) whether the Failsafe has already revoked the entitlement.

BR_4.10.2.6: Immediate Triggering — No Rollback

• As soon as Net_P&L crosses the Level Stop threshold (−Absolute_Stop_Loss), the Atomic Kill Switch is initiated immediately.
• The system WILL NOT recalculate or roll back the Status, even if post-execution slippage causes the final realized P&L to fall back above the threshold.
• Once the flow is initiated, the decision is final (the Status is 'Failed' until a Reset purchase changes it).

9. Wireframe / UI

Wireframe references (Hard Breach state itself only — Reset / Start New Track modal wireframes and the post-expiry Account screen live in UC_4.10.3 §9):

---

Changelog