Target Architecture

RAPID is the shared execution layer for self-directed investors: an open runtime on the member's own machine that turns the member's own rules into the member's own orders. Engines signal, RAPID composes and asks, the member approves, the broker executes.

The law came first. Seven research rounds since July, a counsel opinion in June, and the integrations built and run along the way produced this design. Each constraint is a legal finding turned into a boundary, a default or a missing feature.

This page is the design. What remains after it is in the Legal Position. Read them together.

The invariants: the engine only signals. RAPID composes from the member's local policy. The member decides. Guards can stop anything. Only the member's authorization can send. The ledger never lies. Everything else may change.

Every other auto-trading service tells the member: "we promise not to misuse our access." This one is built so that the access simply doesn't exist. Here's that argument, in five claims:

1. The access doesn't exist. Structurally. The trade credential lives only in the runtime, on the member's own machine. The hosted engine never holds a trade key and has no path to the broker at all. Compromise an engine and there is still no credential to expose and no way to manufacture execution authority. This is also the shape the SEC staff cleared in 2005: locally installed, user-programmed software that sent the user's own orders to the user's own broker (CommandTRADE / GlobalTec). Open source makes the runtime auditable and buildable by anyone, and that is why we chose it. It is not the legal reason the boundary holds. No securities authority gives weight to the licence; what matters is who holds the key.
2. The design targets what the research actually weighs. Four things, every time: is the advice personal, is it timed to the market, who holds decision authority, and does the member's own mind step in before the trade. And two facts P7 (5 Sep 2026) showed carry the weight: the member wrote the trigger criteria himself, and the member asked to be told. Signal-only output on its own buys nothing. Authorship and request do. RAPID builds all of it in: the member enters his own portfolio and order policy, engines send signals rather than orders, RAPID composes the order locally, and the member approves each one. One thing does not help, and the design does not lean on it: where the software runs. Local composition changes nothing by itself (Taucher v. Born). Who wrote the values does. Labels, participant caps and disclaimers don't stand in for those facts.
3. The brain can never create the order, or the authority to send it. (Brain is the engine. Hands are the RAPID runtime.) The engine sends only which rule fired, for which instrument, which side, and when. No quantity, no order type, no price, no time-in-force, no account. RAPID composes those from the member's own local policy. In per-order mode, the member's swipe in the RAPID-owned panel is the authorization. A future standing mode needs its own separate local grant. The engine can never create or enlarge either.
4. Execution stays inside the member's own terms. Once RAPID has a definite order from the member's policy, a definite security, a definite quantity, good for the day, the runtime may work it only within the price and time latitude the member granted. FINRA calls that latitude investment discretion but exempts it from the recordkeeping rule as long as it stays inside those limits. The envelope is never widened. Pre-trade risk control stays with the member's regulated broker. And in all marketing, onboarding and Product Terms: the member is a customer of his own broker, not of the Company. The Company has no customer relationship to any trade. That is condition 1 of the 1996 Schwab letter, the one primary-source cure the research found for the solicitation problem.
5. The record proves what was authorized. It doesn't change what the runtime is. The local journal links source, policy version, composed order, the exact terms shown, the member's authorization, adapter and broker response in one append-only chain. That answers what was authorized and by whom. It is evidence, not a legal transformation. The broker's statement is the final truth about execution. The journal stores derived values and the member's own terms only, never vendor prices or price sequences.

Every layer below exists to keep one of these five enforced by the machine, not by policy. The architecture is the current legal position, in running form.

RAPID (Rule-Authorized Proposal & Instruction Dispatcher) is the shared execution stack. Independently built engines connect as signal sources through one execution boundary that the member controls, on the member's own machine. The broker stays the member's. So does the authority to trade.

Terminology, used consistently below: engine = signal source · RAPID runtime = execution boundary · broker adapter = execution integration · broker = execution venue and account authority. (Brain and hands appear only in Why, as metaphor.)

A quick read of your codebase (the July version) is encouraging. The distance from your engine to this target looks shorter than the pages above suggest. We see:

• •a decision/placement boundary that already exists – useful because the target keeps signal generation in the engine while moving order construction into RAPID
• •a preview→place two-step that looks like a natural insertion point for the RAPID-owned approval panel
• •decision outputs returned as (bool, reason) – a useful primitive for signal + rule attribution
• •a deliberate soak interval between decision and action – a timing primitive worth keeping
• •bookkeeping (in-memory records, position-average gains) for which the shared journal and ledger would provide a natural destination
• •tuned thresholds that can inform the onboarding fields the member enters himself – never an imported or pre-filled preset

Produce a factual component map of this trading engine. Facts only – no judgments, no design advice. Deliver the result as one self-contained HTML document. Cover:
1. MODULE OVERVIEW – each file/module, one line on what it does (cite function names).
2. DATA FLOW – inputs (broker API? files?), outputs (orders? emails? logs?), and the order of a typical run.
3. DECISION POINTS – exactly where a BUY/SELL decision is made; which thresholds are hard-coded vs configurable.
4. BROKER COUPLING – which API and which calls (order placement, status, cash); retry and error handling around them.
5. BOOKKEEPING – how lots, markers and gains are recorded; definitions implicit in the code.
6. DEPENDENCIES & RUNTIME – language, libraries, startup, assumptions (account, subscriptions, machine).
7. SEAM CANDIDATES (observation only) – existing boundaries between "signal" and "execute".
Cite file + function for every claim. Mark assumptions [ASSUMED]. Keep code excerpts minimal.