01 · overview · non-technical

What is rx, and what are the 4 doors?

rx stands for prescription. The system watches your life across four domains, notices when something is drifting away from your stated goal, and writes you a single concrete recommendation backed by evidence — and a counter-argument. One at a time. Sourced. Ranked.

The metaphor

Imagine your life as a house with four doors, each leading into a different room. Each room has its own books, its own instruments, and its own log. They share nothing structurally — what happens in one room does not bleed into another.

door 1
Zeus
fitness
Workouts, recovery, body composition. Reality flows in from a phone app called verocity.
door 2
Athena
nutrition
Macros, meals, supplementation. The room is built but the lights are still off — scaffolded, not yet generating recs.
door 3
Lakshmi
finance
Watchlist, hypotheses, trades, drift alerts. Powered by TradingV, a private FastAPI app on the operator's laptop — an internal tool, not the TradingView charting product (whose webhook alerts are one of its data sources).
door 4
Ganesh
learning
Sprints, inbox, teach-back. Recommendations live entirely in markdown files. No database, ever.

What does an rx look like?

Every recommendation is a markdown file. The frontmatter is machine-readable (id, drift score, signals, confidence, status). The body is human-readable. Always exactly one driving signal. Always at least one counter-thesis (the strongest case against taking the recommendation). Always 3–5 source citations from the knowledge vault.

rx-fin-2026-05-18-00.md --- id: 8f3a-... drift_score: 0.68 confidence: 72 signals_fired: [stale_opp] status: open --- TL;DR Trim NVDA below 5% cap. Counter-thesis Earnings in 9d; risk = whiplash. It exists in two places: 1. on disk as markdown human reads + edits in editor 2. as a row in the rec store app reads + writes via UI a reconciler keeps them in sync disposition (acted / dismissed / snoozed) flows from store → markdown runs at the start of the next rx call ("Phase W reconciler")
Same artifact, two representations — the reconciler keeps them honest.

Why split storage like this?

The split was made deliberately. It is the load-bearing decision of the whole architecture, locked into the decisions log as D-045 (storage routing) and D-047 (Lovable scope).

The locked rules

Hover a row to see its mapping highlight.

DoorWhere the rec livesWho shows it to you
Zeus fitness Supabase cloud, shared with phone Lovable verocity app
Athena nutrition Supabase cloud (zombie — no consumer) none D-047 removed it
Lakshmi finance TradingV postgres laptop-only, no cloud TradingV FastAPI panel
Ganesh learning markdown file system only none editor reads the file
The "no cross-write" rule. Finance recs never touch Supabase. Fitness recs never touch the TradingV postgres. Each door's data stays in its own backend. This is what makes the whole system simple to reason about — there is no privileged central store that could become a single point of contamination. Enforcement: for finance this is a runtime guarantee — a database CHECK (domain = 'finance') constraint plus a service-layer guard reject anything else, and owner_user_id is stamped by the server, never trusted from the request. The broader cross-door discipline holds by construction (each command carries credentials only for its own backend) and by code review; there is no single lint/CI check spanning all four doors.

Three things every rx contains

The drift score

A 0–1 number summarising how far reality has drifted from the goal. It is a weighted average of per-signal sub-scores. The math is copied verbatim from a SQL view or local helper — Claude does not do the arithmetic.

The driving signal

Exactly one of the contributing sub-scores has the highest weighted value. That signal is named, and the recommendation addresses it specifically — not the entire drift surface.

The counter-thesis

The strongest argument against acting on this rec, plus the conditions under which the counter-thesis wins. Mandatory by decision D-008. If a rec doesn't have one, it is malformed.

How the knowledge vault enters the picture

Drift signals tell you that something is off. They don't tell you what to do about it. For that, every rx command consults a personal knowledge vault — a folder of curated reading: books, newsletters, video transcripts, SEC filings, smart-money snapshots.

The vault is partitioned by domain (finance / fitness / nutrition / learning). Four small server processes (one per domain) hold an embedding index of the vault and answer ranked-evidence queries. The technical layer is fully explained on the Deep tech page.

One system, two speeds

A deliberate split runs through the whole architecture, along a cost seam. The everyday app is built to be cheap and always-on: it does fast retrieval, checks each citation, tracks outcomes — all deterministic, no language model in the loop. The expensive thinking — deep multi-hop retrieval, weighing contradictory sources, hunting an external counter-argument — is opt-in: it runs only when the operator asks for it, in a separate session, and writes its findings back for the app to show. That's how the system stays affordable while still being able to go deep on demand (see the cost seam on Pipeline).

One cross-door note: the fitness app's interface lives in its own separate codebase (the verocity repo), while finance is served by the TradingV app and learning is just markdown. Same recommendation contract, three different surfaces.

Lifecycle in one sentence

The data flows in continuously (markets, screenshots, workouts, video transcripts). When you invoke /rx-<door>, a single artifact is composed, dispositioned by you in the UI surface (or by editing the markdown), and the next invocation reconciles your disposition back into the file. The system grades its own action-rate in a rolling window — below 30% is a warning, below 15% it flags itself as failing.

← prev
Home