UC_4.16.2: Career & HR Widget (LIVE)

---

Document References

---

1. Overview

Tiles covered by this UC (client design frame, 2026-08-26):

2. Trigger

• The trader activates the Career tab in the persistent sidebar (Ref: UC_4.1.2 §2), and the Career tab mounts.
• The trader returns to an already-mounted Career tab after the dashboard reconnects its WebSocket, or re-activates the browser tab — both re-run the same fetch (Ref: BR_4.16.2.14).

3. Pre-conditions

• The trader is authenticated and the account type is LIVE. A SIM trader has no Career tab at all — Career & HR data only exists once the trader is contracted, and a SIM/Evaluation trader has no Rippling and no Dots record (Ref: [HR-DEF-01], BR_4.16.2.1).
• The trader has an employment record the backend can resolve: either a Rippling worker record (created by Flow 6 Path A on the US W-2 path, or at Level 1 for the ICA), or an active Dots contractor payout profile with a retainer row in SQL (Flow 6 Path B, International). Which one exists determines the whole rendering of this tab (Ref: BR_4.16.2.3).
• GET /current-level-detail and GET /hr-integration are reachable for the logged-in user_id. Neither is a precondition for the other — each tile degrades independently (Ref: BR_4.16.2.13).

4. Post-conditions

• The Career tab shows the trader's employment record as it stood at the moment of the fetch. No server state has changed — this tab issues no write of any kind (Ref: BR_4.16.2.12).
• If the trader activated [Manage Payouts] or [View in Rippling], a new browser tab has been opened at the vendor and the Dashboard tab is untouched and still authenticated (Ref: BR_4.16.2.11).

5. Basic Flow — Career tab load (W-2 employee)

1. The trader activates the Career tab. The tab mounts with every tile in its skeleton/loading state (Ref: BR_4.16.2.13).
2. The frontend issues GET /current-level-detail with the authenticated user_id. The response supplies Level, Title and payout_portal_url for this tab (the remaining fields of that payload feed other widgets and are ignored here). Ref: BR_4.16.2.4, BR_4.16.2.9.
3. In parallel, the frontend issues GET /hr-integration with the same user_id. Ref: BR_4.16.2.2.
4. Server-side, GET /hr-integration reads compensation_track from the Users table, resolves the trader as W-2, and queries the Rippling API for the real-time HR values. It returns {vacation_days, next_pay_date, base_salary_annualized, benefits_estimate, compensation_track}. Ref: BR_4.16.2.2.
5. The frontend resolves the employment status from the returned discriminator and renders the badge W-2 Employee. Ref: BR_4.16.2.3.
6. The three-across header row renders: Current level = Lvl [Level] with [Title] beneath (Ref: BR_4.16.2.4) · Base salary = base_salary_annualized formatted per Ref: CR-11 with the caption Annualized (Ref: BR_4.16.2.5) · Benefits = benefits_estimate with the caption Health, dental, vision (annualized) (Ref: BR_4.16.2.6).
7. The left column renders Vacation days = vacation_days with the allowance caption derived from the level's DTO_Days band, and Next pay date = next_pay_date formatted per Ref: CR-08 with the caption Bi-weekly direct deposit. Ref: BR_4.16.2.7, BR_4.16.2.8.
8. [Manage Payouts] is not rendered — the trader is a W-2 employee, and Rippling already carries their pay. Ref: BR_4.16.2.9.
9. [View in Rippling ↗] renders and, on activation, opens the Rippling employee portal in a new browser tab; if there is no live Rippling session in that browser, Rippling presents its own login page and lands the trader on the employee homepage afterwards. The Dashboard tab keeps its session. Ref: BR_4.16.2.10, BR_4.16.2.11.
10. The Latest certificate panel to the right mounts independently — Ref: UC_4.16.1 §6.

6. Alternative Flow — Career tab load (contractor)

Applies when the trader is not a W-2 employee: Levels 1–5 (Global) and Level 6+ International Contractors. Steps 1–3 and 10 are identical to §5; only the differences are listed.

1. Server-side, GET /hr-integration reads compensation_track and does not find a W-2 trader. For a Level 6+ contractor it queries the SQL Database for the retainer amount instead of calling Rippling; the retainer is the Base_Income_Flex rate written by Flow 6 Path B. Ref: BR_4.16.2.2, BR_4.16.2.5.
2. The badge renders as the contractor variant rather than W-2 Employee. Ref: BR_4.16.2.3.
3. Benefits has no W-2 benefits package behind it and renders its empty state rather than a figure. Ref: BR_4.16.2.6.
4. Vacation days — an international contractor takes an unpaid hiatus with no day limit (Flow 13 Path B), not a paid DTO balance, and DTO_Days for Levels 1–5 is 0 in both Table A and Table B. The tile renders its non-W-2 state. Ref: BR_4.16.2.7.
5. Next pay date carries the contractor cadence caption — the monthly retainer paid through Dots (Flow 36) — not Bi-weekly direct deposit. Ref: BR_4.16.2.8.
6. [Manage Payouts] is rendered and, on activation, opens the Dots login page in a new browser tab, using the payout_portal_url returned at step 2 of §5. Ref: BR_4.16.2.9, BR_4.16.2.11.

7. Exceptional Flow

• GET /hr-integration fails or times out → the four HR tiles (Base salary, Benefits, Vacation days, Next pay date) enter their error state and Ref: TE-SYS-01 is shown once for the tab. Current level, the two buttons and the Latest certificate panel are unaffected — they do not depend on this call. Ref: BR_4.16.2.13.
• GET /current-level-detail fails or times out → Current level enters its error state and [Manage Payouts] is not rendered, because its destination URL is unknown; the four HR tiles are unaffected. Ref: BR_4.16.2.13.
• Rippling is unreachable from the backend while the endpoint itself answers → the endpoint returns the affected fields as null rather than failing the whole call, and each affected tile renders its empty state individually. A null is an empty state, never a zero — rendering 0 vacation days when the balance is merely unknown is a defect. Ref: BR_4.16.2.13.
• The trader has no employment record yet — LIVE and contracted, but the Rippling worker or the SQL retainer row has not been provisioned (Flow 6 still mid-flight, or a Level 1–5 trader who has no salaried record at all) → every affected tile renders its empty state; the tab itself still mounts and the certificate panel and [View in Rippling] still work. Ref: BR_4.16.2.13.
• payout_portal_url is absent or empty for a non-W-2 trader → [Manage Payouts] is not rendered. It is never rendered pointing at nothing, and never rendered disabled. Ref: BR_4.16.2.9.
• The browser blocks the new tab (pop-up blocker) on either button → the Dashboard state is unchanged and no error is raised by the application; recovery is the browser's own pop-up prompt. Ref: BR_4.16.2.11.

8. Business Rules

BR_4.16.2.1: LIVE Only — and This UC Owns the HR Tiles Only

• The Career tab exists only for a LIVE trader. Career & HR data comes into being when the trader is contracted; a SIM/Evaluation trader has no Rippling record and no Dots payout profile, so the tab is not reachable for them at all (Ref: [HR-DEF-01]).
• Within the tab, this UC specifies the Employment status badge, the Current level, Base salary, Benefits, Vacation days and Next pay date tiles, and the [Manage Payouts] and [View in Rippling] buttons.
• Not owned here: the Latest certificate panel, its motion, its share targets, the Redacted version toggle, [View], [Download] and [Replay] → Ref: UC_4.16.1. The payout calculation, schedule, approval, profit-split and execution behind [Manage Payouts] → STAGE 5: PAYOUT & WITHDRAWAL. The red Resign & Close Account button → UC_4.17.2. The promotion mechanics that change Level and Base salary → STAGE 6: CAREER PATH & PROFESSIONALIZATION (Flow 4, Flow 6, Flow 8).

BR_4.16.2.2: Read-Only Mirror — Two Endpoints, One Load, No Polling

The tab is fed by exactly two backend reads, both issued once when the tab mounts:

• The two calls are independent and parallel. Neither blocks the other, and a failure in one degrades only its own tiles (Ref: BR_4.16.2.13).
• GET /current-level-detail is the same call the dashboard already makes on load for the header and the Bento Grid. The Career tab reuses that response and does not issue a second identical request.
• The frontend performs no calculation on any returned value — no accrual, no proration, no annualisation, no balance arithmetic. It formats and displays exactly what the backend returns (Ref: [HR-DEF-01]).
• The frontend never calls Rippling or Dots directly, and never reads a Zapier Table. Both are server-side integrations behind GET /hr-integration; the browser holds no vendor credential.

BR_4.16.2.3: Employment Status Resolution

The Employment status badge is resolved from the trader's compensation arrangement, not from their level alone:

• ⚠️ compensation_track alone cannot resolve this badge. It separates Standard from Flex, but a US Track B trader and an International contractor both carry Flex while being a W-2 employee and a contractor respectively. A dedicated W-2 discriminator is required in the GET /hr-integration response — the same gap Current Level Detail already implies by saying "Evaluate the user's Level and W-2 status". Written here as an explicit field; the exact name and values are pending (Ref: §10 item 1, and the identical open point at UC_4.16.1 §10 item 8).
• The badge is the single switch for the rest of the tab: it drives the Benefits state (BR_4.16.2.6), the Vacation days state (BR_4.16.2.7), the Next pay date caption (BR_4.16.2.8) and the visibility of [Manage Payouts] (BR_4.16.2.9). It must therefore be resolved before those tiles render, and all five must agree — a W-2 Employee badge shown next to a visible [Manage Payouts] is a contradiction.

BR_4.16.2.4: Current Level Tile

• Renders Lvl [Level] as the primary value and [Title] as the sub-label, both taken verbatim from GET /current-level-detail.
• Title is the level's Level Title from Table A (Forex) or Table B (Futures), resolved server-side by the trader's asset class — Associate Trader (L1–5) · Trader (L6–9) · Senior Trader 1 (L10–13) · Senior Trader 2 (L14–17) · Principal Trader (L18–21) · Managing Principal Trader (L22–24). The frontend does not re-derive the title from the level number.
• This tile shows the level the trader currently holds. It is not a progress bar and carries no next-level target — that belongs to the Level Progression widget (Ref: UC_4.12.6) and the Bento Grid career map.
• The value changes only when a promotion completes (Flow 4, or Flow 3H for the first SIM → LIVE transition). This tab does not listen for LEVEL_PROMOTION; it will show the new level at the next load (Ref: BR_4.16.2.14).

BR_4.16.2.5: Base Salary Tile

• Renders base_salary_annualized from GET /hr-integration, formatted per Ref: CR-11 (thousands separator, max 2 decimals, full value on hover), with the static caption Annualized.
• The figure is annualised on the server, whatever the underlying contract shape. Table A/B carry Base_Income_Type = Hourly for the lower salaried levels and Annual from the mid levels upward; Flow 8 already defines the conversion (Hourly ⇒ Rate × ((Standard_Hours × 52) / 12) monthly). The frontend never converts an hourly rate. It displays the annualised number the endpoint returns.
• Which rate is behind the figure follows the track, and is resolved server-side: compensation_track == 'Standard' ⇒ Base_Income; compensation_track == 'Flex' ⇒ Base_Income_Flex; an International contractor always resolves to Base_Income_Flex.
• [If base_salary_annualized is null or the trader has no salaried record] (typically Levels 1–5, where Base_Income is $0) → the tile renders its empty state, not $0.00 (Ref: BR_4.16.2.13).
• The value changes only through Flow 8 (Pay Raise) or Flow 6 (Level 6 Transition). Nothing on this tab can alter it.

BR_4.16.2.6: Benefits Tile

• Renders benefits_estimate from GET /hr-integration, formatted per Ref: CR-11, with the caption Health, dental, vision (annualized).
• The value is an estimate of the employer-funded benefits package, owned by Rippling, produced by the benefits enrolment the trader completed in Flow 6 Path A, Track A (Full Benefits). The dashboard does not price, itemise or explain it, and offers no enrolment or change action — those live in Rippling, reached through [View in Rippling] (BR_4.16.2.10).
• [If the trader is on Track B (Flex Cash) or is a contractor] → there is no benefits package. The tile renders its empty state. Flow 6 makes benefits enrolment conditional on Track A only, so a Flex trader having a benefits_estimate figure is a data error, not a display case.
• [If benefits_estimate is null] → empty state, never $0.00 (Ref: BR_4.16.2.13).

BR_4.16.2.7: Vacation Days Tile — Read-Only, Rippling Owns It

• Renders vacation_days from GET /hr-integration as the primary integer value, with a caption naming the level's allowance.
• 🔴 No PTO write path exists anywhere in this product. Client-confirmed 2026-08-15 ([HR-DEF-01]), verbatim: "This is managed in Rippling, do not worry about it. You are just reading in the current value in this screen." Concretely: no PTO logging UI, no request form, no approval workflow, no accrual calculation, no balance arithmetic, and no PTO write endpoint. A trader who wants time off files it inside Rippling, reached via [View in Rippling].
• The allowance behind the caption is DTO_Days from Table A / Table B, banded by level. Resolved server-side; the frontend does not hold the band table:

• [If the trader is an International Contractor] → they have no paid DTO. Flow 13 Path B grants an unpaid hiatus with no day limit, which is not a balance and cannot be rendered as an integer. The tile renders its non-W-2 state rather than a number (Ref: §10 item 4).
• [If the trader is Level 1–5] → DTO_Days is 0. The tile renders its empty state.
• The displayed balance is the remaining balance as Rippling reports it (Flow 13 Path A checks Used_DTO against DTO_Days inside Rippling). Whether the endpoint returns remaining or entitled days is the single most consequential ambiguity on this tile (Ref: §10 item 3).

BR_4.16.2.8: Next Pay Date Tile

• Renders next_pay_date from GET /hr-integration — an ISO YYYY-MM-DD value on the wire (Ref: CR-08) — displayed in the short human form shown in the design frame (Mar 21), with a caption naming the pay cadence.
• The cadence caption follows the pay instrument, resolved from BR_4.16.2.3:

• The date is read, not computed. The frontend does not derive the next date from a cycle length, a last-paid date or a calendar rule; it renders the date the endpoint returns, and if the endpoint returns null the tile renders its empty state (Ref: BR_4.16.2.13).
• The tile is display-only — it is not a link to a payslip, a payout history or a ledger entry. Those belong to STAGE 5: PAYOUT & WITHDRAWAL.
• ⚠️ The design frame's caption Bi-weekly direct deposit is a fixed string in the mockup, while Flow 34's trigger admits both Bi-Weekly and Monthly payroll runs. Written here as driven by the actual cycle, not hardcoded (Ref: §10 item 5).

BR_4.16.2.9: [Manage Payouts] — Hidden for W-2, Dots for Everyone Else

• Visibility (client instruction, 2026-08-26): [If the trader is a W-2 Employee] → the button is not rendered at all — hidden, not disabled, not greyed. [If the trader is not a W-2 Employee] → the button renders.
• Destination: the Dots login page, opened in a new browser tab (Ref: BR_4.16.2.11). The URL is the payout_portal_url string carried in the GET /current-level-detail payload on dashboard load — "a standard target="_blank" redirect to open the static vendor URL in a new browser tab". It is a static vendor URL, not a per-trader deep link and not an SSO hand-off; Dots authenticates the trader itself.
• ⚠️ This supersedes the RFQ's Payout Routing for the US W-2 branch. RFQ_ Stack Trading Prop Tech V7.pdf specifies payout_portal_url = the Rippling employee portal URL when the trader is Level 6+ US W-2. Under the client's 2026-08-26 instruction the button never renders for a W-2 trader, so that branch is never consumed by this tab and Rippling is reached exclusively through [View in Rippling] (BR_4.16.2.10). The backend may keep populating the field for other consumers; this UC ignores it whenever the trader is W-2 (Ref: §10 item 6).
• [If the trader is not W-2 and payout_portal_url is absent, empty or null] → the button is not rendered. A payout button pointing at nothing is worse than no button.
• Scope: this BR governs whether the button appears and where it points, nothing more. Payout eligibility, the profit split, the payout schedule, minimum thresholds, approval and execution are owned by STAGE 5: PAYOUT & WITHDRAWAL.

BR_4.16.2.10: [View in Rippling] — Always Available, Opens the Rippling Portal

• The button renders on the Career tab and, on activation, opens Rippling in a new browser tab (Ref: BR_4.16.2.11).
• Destination: the Rippling login page. Rippling handles its own authentication and lands the trader on the employee homepage once logged in; if the browser already holds a live Rippling session, the trader arrives at the homepage directly. There is no SSO hand-off, no token in the URL and no deep link into a specific Rippling screen from our side.
• This is the only route by which a trader acts on anything shown on this tab — requesting time off, changing benefits elections, downloading a payslip, updating tax or bank details. All of it happens inside Rippling (Ref: [HR-DEF-01], BR_4.16.2.7).
• The URL is an environment configuration value, not a per-trader value from an endpoint. It therefore renders even when both endpoints of BR_4.16.2.2 fail.
• ⚠️ The client's instruction gave no visibility condition for this button, so it is written as always rendered on the Career tab. That leaves an international contractor — who has a Rippling record for their ICA but no Rippling payroll, PTO or benefits — with a button into a portal that shows them almost nothing (Ref: §10 item 7).

BR_4.16.2.11: Outbound Vendor Navigation Standard

Applies to both [Manage Payouts] and [View in Rippling]:

• Navigation is a standard target="_blank" new-tab open. The Dashboard tab is never replaced, never reloaded and never logged out; the trader returns to it with their session, their WebSocket state and their open positions untouched.
• The outbound link carries rel="noopener noreferrer" — the vendor tab must not obtain a handle on the Dashboard window.
• No credential, token, user_id or PII is ever appended to the vendor URL. Both destinations are static vendor URLs and both vendors authenticate the trader themselves.
• The application shows no interstitial, no confirmation modal and no toast for either navigation.
• [If the browser's pop-up blocker suppresses the new tab] → nothing happens in the Dashboard, no application error is raised, and recovery is entirely the browser's own pop-up prompt.

BR_4.16.2.12: No Write Path From This Tab

• The Career tab issues GET requests only. There is no POST, PUT, PATCH or DELETE behind any tile or control specified in this UC.
• Nothing on this tab is editable, and nothing on it is a form field. Every tile is a label; the only interactive elements are the two outbound buttons.
• The trader cannot log PTO, request time off, change their track, change their hours, change their benefits elections, trigger a payout or edit their pay details from here — every one of those is a Rippling or Dots action, or a Zapier flow that runs without dashboard involvement (Flow 6, Flow 8, Flow 13).
• Consequence for QC: no test on this tab should ever assert a state change on the server. A change observed after visiting this tab means a defect.

BR_4.16.2.13: Per-Tile Degradation — Loading, Empty, Error

Each tile resolves its own state independently. The tab never blocks as a whole and never renders a full-screen error:

• The blast radius of each failure is fixed: GET /hr-integration failing affects only Base salary, Benefits, Vacation days and Next pay date. GET /current-level-detail failing affects only Current level and [Manage Payouts]. Neither affects the Latest certificate panel, which has its own endpoint and its own error handling (Ref: UC_4.16.1 §7).
• [View in Rippling] renders in every state, including total endpoint failure — its URL is configuration, not data. This is deliberate: when the dashboard cannot show the trader their HR data, the escape hatch to the system that owns it must still work.
• There is no retry button and no auto-retry on this tab. Recovery is re-entering the tab (Ref: BR_4.16.2.14).
• ⚠️ The exact copy for the empty and error states of each tile is not specified by any client source and is written here as a state, not as a string (Ref: §10 item 8).

BR_4.16.2.14: Refresh Cadence and Staleness

• The two reads of BR_4.16.2.2 fire on tab mount. There is no polling interval, no WebSocket subscription and no push event for HR data — none of these values changes on a trading timescale. vacation_days moves when Rippling approves a request, next_pay_date on a payroll run, base_salary_annualized on a promotion.
• The data is therefore a snapshot as at the last load, and is refreshed by: re-entering the Career tab from another tab, reloading the Dashboard, or a WebSocket reconnect that re-runs the dashboard load (Ref: CR-14).
• A trader who is promoted while sitting on the Career tab keeps seeing the old level and the old salary until they leave and return. This UC does not listen for LEVEL_PROMOTION — the promotion cinematic force-redirects the trader to the Command tab anyway (Ref: UC_4.16.1 §5 step 2), so the Career tab is re-mounted on the trader's own return.
• Whether the backend calls Rippling live on every request or serves a cached value, and the TTL if cached, is a backend decision that changes what "current" means on this screen and is not yet ruled (Ref: §10 item 2).

BR_4.16.2.15: Display Formatting Standards

• Monetary values (Base salary, Benefits) — Ref: CR-11: comma thousands separator, max 2 decimal places, full value in a tooltip on hover (Ref: CR-10). The design frame's abbreviated form ~$13K for Benefits is an approximation by design intent, and the tooltip must still carry the exact figure (Ref: §10 item 9).
• Dates (Next pay date) — transported as ISO YYYY-MM-DD per Ref: CR-08 and rendered in the short human form of the design frame.
• Integers (Vacation days) — rendered as a plain integer with no unit suffix on the primary value; the unit lives in the caption beneath.
• Overflow — every tile value and caption uses wrap text. No tile value is ever truncated with an ellipsis: a truncated salary or a truncated pay date is unreadable rather than merely compressed.

9. Screen Description

Career tab, LIVE trader. The Latest certificate panel occupying the right-hand region of the same screen is not described here — Ref: UC_4.16.1 §9.2. The persistent header (Days remaining, Squawk box, Daily loss limit, Close in, notifications) and the persistent sidebar are Ref: UC_4.1.1 and UC_4.1.2.

10. Open Items Pending Client / BE Confirmation

11. Build Ownership

---

Changelog