Status: Accepted
Date: 2026-04-22
Deciders: user (PR #189 comments, 2026-04-22), software-architect
Scope: MBT investor-profile model; resolves MBT §14 open questions 1–3
Related docs: docs/architecture/mbt-investor-profiles.md, docs/architecture/mbt-paper-trading-engine.md
MBT (the Raxx-native paper-trading engine, specified in PR #189) left three open questions in §14 that block implementation sub-cards:
The direct answer would be: pick a number (e.g., $100k), pick a fill mode (e.g., mid-price), pick a rate model (e.g., fed-funds). Three config knobs.
On 2026-04-22, the user reviewed the PR and explicitly rejected the "pick a default" framing. Instead: build a profile-driven experience that infers sensible defaults from the user's stated goals, and teaches rather than configures. The user described three distinct user archetypes ($10k / $50k / $100k), tied fill behavior to what "feels right" for the user's purpose, and framed margin interest as a teaching moment rather than a setting.
This ADR records that decision.
MBT defaults for starting cash, fill aggressiveness, and interest-rate narrative tone are determined by the user's investor profile, not by a single global or per-user config value.
Three starter profiles ship in v1:
| Profile | Starting cash | Fill aggressiveness | Narrative tone |
|---|---|---|---|
| Trial | $10,000 | Conservative | Teaching-heavy |
| Income Builder | $50,000 | Mid | Balanced |
| Diversifier | $100,000 | Aggressive | Assume-familiarity |
Profile is inferred via a 3–5 question onboarding flow. All defaults are user-overridable after onboarding. Users can re-run onboarding from Settings at any time.
The profile system ships behind FLAG_MBT_INVESTOR_PROFILES. Existing users (when flag activates) receive Diversifier ($100k) as a migration default — preserving continuity with the prior $100k Alpaca-paper balance — with a prompt to review.
Positive: - Eliminates the "configure a number" UX problem for users who don't know what starting cash means. - Provides a natural hook for the educational overlay (narrative tone per profile). - Scales: adding a fourth profile or adjusting defaults is a data change, not a schema change. - Profile data doubles as product telemetry: distribution of profile types informs which features matter most.
Negative / tradeoffs:
- Adds an onboarding flow that must be designed, copy-written, and tested before the profile system is useful. Engineering placeholder copy reduces this to a non-blocker for v1 GA, but a copy-polish card must follow.
- Profile names are currently placeholders. Final naming requires a product-manager or marketing-strategist decision before implementation copy is locked.
- Profile data is PII-lite (financial goals, risk tolerance). Adds a new table to the GDPR DSR scope.
- The educational overlay adds ~40 narrative templates to the narrative service. These are maintained as code strings in v1; externalization is a v2 task.
Regulatory: - Profile adjusts defaults; it never recommends securities, strategies, or positions. The §202(a)(11) (Investment Advisers Act) line is maintained. Any future feature that introduces profile-based strategy recommendations MUST NOT ship without securities-attorney sign-off.
Pick $100k, mid-fill, balanced tone for every user. Simple. No onboarding flow required.
Rejected because: it ignores the user's explicit directive on PR #189. More importantly, it produces a bad experience for beginners ($100k is meaningless to a Trial user) and misses the educational value the user wants to deliver. The complexity cost of a profile system is justified by the retention and comprehension benefits.
No onboarding inference; let users manually configure starting cash, fill mode, narrative preference from Settings.
Rejected because: it front-loads configuration on users who don't know what the knobs mean. The user's comment explicitly describes "hiding" the fill complexity and "guiding" users through it. A raw config panel is the opposite of that intent. Profile-driven with override-capability satisfies both the guided and the expert use case.
Infer profile from trading behavior over time rather than asking upfront.
Rejected for v1 because: it requires behavioral history before inference can happen (cold-start problem), it raises advisory-posture questions faster than an explicit user-stated preference does, and it is architecturally complex for a v1 feature. Deferred consideration for v2 if profile accuracy proves insufficient.
Refs: PR #189 user comments (2026-04-22). See mbt-investor-profiles.md for full design.