Shared under NDA. This document may be passed on only with the author's consent. And only under an NDA of equal scope.
RAPID is the shared execution layer for self-directed investors: an open runtime the member controls, that turns the member's own rules into the member's own orders. Engines say which of the member's rules was met. RAPID composes the order from the member's own policy, asks, and sends under the member's own key. The broker executes.
The law came first. Eight 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. P8 (7 September 2026) added the brokers' own contracts to the record, and they moved several things: the attribution question closed, a permission question opened, the price-and-time envelope changed shape, and standing execution turned out to be refused in the form we had drawn.
Version 2.1 (12 September) folded in what four adversarial reviews of the patent specification found. Five statements here promised more than the machine can deliver and are now stated at the level it can, and one real gap was closed: the order the broker receives is verified against the order the member approved.
Version 2.2 (13 September) corrects one of those changes after a second opinion. Version 2.1 required the engine to hold no connection to the Company at all while it ran. That was adopted on a technical argument, and when it was tested against the securities material it did not hold up: nothing in the authorities turns on whether a vendor's software checks in during operation. What the authorities look at is whether the vendor participates in the transaction. So the axis is no longer online against offline. It is product control against transaction control: the Company may decide whether the software runs at all, and may have no influence whatever on an individual order. R1.6 is rewritten on that axis, and the diagnostics the earlier version gave up are back.
Version 2.3 (3 October) brings L1 and R1.5 in line with Why #2: the engine never reads account or policy state. The sort-key example “longest under cost” in L1 is moved to the plan, and R1.5 no longer lists the policy hash among the engine’s inputs; it journals the engine’s own inputs (market-data source, rule version, universe list version), and the policy hash belongs to the plan journal. Per the EE ruling of 3 October.
This page is the design. What remains after it is in the Legal Position. Read them together.
The invariants: the engine only reports that a member's rule was met on an instrument; it never says buy or sell, and every decision-relevant input to it is the member's or a named external source's. RAPID composes from the member's local policy, including the direction. In per-order mode the member decides every order, and the architecture requires that he decides on a surface the engine cannot fake. In plan mode the member's own software executes the member's own plan on a machine only he controls. Nobody holds discretionary authority. No Company-controlled component can authorize or transmit an order, and no Company-originated data is an input to whether, when or how an order qualifies, is composed, is authorized or is sent. Guards can stop anything. What leaves for the broker is what the member approved. The ledger is append-only and tamper-evident. 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:
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. 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 · member-operated instance = a machine, local or rented, that the member alone controls. (Brain and hands appear only in Why, as metaphor.)
YILD engine · rule-met signals only, one among equals; hosted in per-order mode, local in plan mode
Brian’s engine · independently built – own repo, logic, data
Other compatible engine · same signal contract, independently owned
Authenticates sources · validates signals · maps the member’s rule to its meaning · composes the order from the member’s policy · takes the member’s instruction (per-order) or executes the member’s plan · dispatches via broker adapters · journals everything.
🔒 Trade-capable credentials live only here – local keychain / isolated vault, inaccessible to every source and to the Company.
Authenticates · validates (pre-trade risk) · executes and works the order within the member’s limits · answers back: ack, fill, status.
Registered identity · version · provenance – an unknown source stops here.
The signal is validated; RAPID looks up what the member said this rule means (buy or sell), and composes quantity, order type, price limits, time-in-force and account from the member’s own local policy.
Per-order: the complete order is shown on a surface the runtime renders in its own process; the member’s act is the instruction. Plan: the member’s adopted plan is the instruction; the runtime records which plan version authorized the order.
Capability and permission validation · broker-specific translation, including the broker’s own order types that carry the member’s limits – invoked only after the member’s instruction, using the member’s own credentials. The request that will leave is read back and compared to the approved order before it is sent; a difference outside the declared translation, or any difference that would broaden the order, stops it.
Ack, fill, status – reconciled against the journal; the broker’s statement is final truth.
Source → configuration → instruction → canonical order → outgoing request → adapter → broker response, as one append-only, provenance-linked, replay-safe chain.
An engine, hosted by its builder or running on the member’s own instance, evaluates the member’s rule logic and emits an authenticated rule-met signal only: { rule_id, rule_version, instrument, fired_at, source_id, source_signature }. It says which of the member’s rules was met, on what, and when. Never buy or sell, never how much, never how to place the order. Side, quantity, order type, price, price limits, time-in-force and account cannot cross this boundary, and a message carrying a field the contract does not know is rejected rather than ignored, so that no auxiliary channel can be opened by adding one. Engine-side settings cover universe filtering, trigger points, thresholds and trading windows, all of them the member’s. What a rule means (buy or sell), sizing, cash management and how an order is built belong to the member’s local RAPID policy. Engines never hold the member’s trade credentials and have no broker code path.
Who writes the rule. The engine is filter-based. It evaluates the member’s criteria and sorts by the member’s chosen key, a key that reads only market facts and the member’s own engine settings: closest to ex-date, yield high to low, whichever the member picked in Settings. Any ordering or lot selection that depends on the member’s account or policy (longest under cost, highest priority) belongs to the plan, not the engine; the engine’s signal is per instrument. Sort labels are neutral (“Yield: high to low”), never evaluative (“best”). The builder supplies mechanics only: evaluation, the scheduling machinery, delivery. The economic timing is the member’s: trading window, evaluation frequency, distance to ex-date, the instant a trigger counts as met. So is the universe. There is no model, no weighting, no score, no threshold, no inclusion rule and no default in the engine that the member did not set, and nothing the Company controls can decide which instrument qualifies, when it fires, or where it ranks. The list is shown in the member’s own sort order with nothing highlighted. This is what makes “the member wrote every rule” a fact rather than a slogan. It also matters the other way: a Commission release calls the adjusting and customizing of parameters discretion. On that reading every parameter we shipped pre-filled would be discretion we exercised, which is why the empty-field rule is load-bearing and not housekeeping.
Where the engine runs, and what the Company’s server may do. In per-order mode the engine may be hosted; the member’s act stands between every signal and every order. In plan mode the engine runs on the member’s own instance as licensed software. The question that then arises is what our servers are allowed to be while it runs, and the answer is drawn on one line: product control, never transaction control. We may decide whether the software continues to run at all, which is what every software vendor decides. We may not influence, permit, refuse, delay or observe an individual order.
That line is not the same as “no connection”. Version 2.1 of this page required the engine to hold no connection to us at all during a session. It was adopted on the argument that a live channel carries information through its timing and its selective failure even when its fields are narrow, which is true as a matter of channels. Tested against the securities material, it did not earn its cost: nothing in the authorities turns on whether a vendor’s software checks in during operation, and staff relief has been given to systems that sat far closer to the order than a licence call. Meanwhile the cost was real, and it fell on the member: no way for us to see that his instance had stopped, no diagnostics while something was going wrong, and support reduced to asking him to package a bundle. So the requirement is drawn on what the channel may reach, not on whether it exists.
Three things are therefore kept apart, and each is separately testable. Entitlement says whether the software may run; it is validated locally, refreshed on its own schedule outside the execution path, and has a grace period so that a failure to reach us never decides an order. Liveness goes outward only: the instance tells us it is alive and may send a diagnostic bundle with no credentials and no prices; nothing that comes back is read by the engine. Support is a state the member turns on deliberately, unavailable while an execution interval is running, and closed again before ordinary operation resumes. The claim this architecture makes is not that no packet flows. It is that no Company-originated data is an input to qualification, composition, authorization or execution. That can be shown; “there is no connection” cannot, and would not be true at the transport layer in any case.
The stronger variant remains available and is described in the patent: an entitlement signed before a session, validated locally, with no operator-directed traffic at all for its duration. It is the better answer against a compromised backend, and a member or a broker may require it. It is not a condition of the legal position, and the product does not pay for it by default.
side or an unknown field are rejectedThe member works in the engine’s own interface. The engine shows that a rule was met. Beside it, a RAPID-owned approval surface shows the complete order RAPID composed from the member’s local policy: security, side, quantity, order type, price limits, time-in-force and account. The member places the order with one tap or swipe on that surface. That act is the member’s own instruction for that order, and it creates the instruction record: the exact terms shown, member, account, source, scope, timestamp and nonce. Immutable once minted.
No discretionary authority exists, in either mode. Nobody is granted standing power over the member’s account: not the Company, not the engine, not the source, not the builder. In per-order mode each order is the member’s current instruction for a definite quantity of a specific security. In plan mode the member’s adopted plan is the instruction, and the software executing it is his own, on an instance only he controls. Six brokers’ contracts treat an order under the member’s credentials as the member’s own, and none conditions that on who composed it or whether a human reviewed it. A member who never grants an authorization does not create the fact that someone holds one.
One approval, one trusted path. No second confirmation, no extra popup. The surface sits beside the engine experience but is rendered by the runtime, in the runtime’s own process, never inside the engine’s page. The engine frames the workflow. It can never produce the member’s yes, and it must never be able to draw the surface the yes is given on.
Trusted surface, and why it exists. The surface earns nothing by being ours. No instrument or decision was located in which the identity of the party that rendered a screen decided whose act it was; attribution runs on actual authority and on credentials, and NASD NTM 98-66 expressly lets a third party build and operate the surface. What the attribution cases do ask is whether the party now asserting the act could have produced it itself (Banister, Garcia, Aerotek); where it could, attribution fails. A runtime that renders the surface, holds the credential and mints the record sits in the losing posture until it can show lock-out of all three. The showing rests on what is not provisioned rather than on a test that came back empty: the key that turns a swipe into an instruction is generated on the member’s machine after install, marked non-exportable, and never supplied by or escrowed with us; and no Company principal appears in the policy that permits a write to the journal. Those are facts about what exists, and they can be inspected. Threat model: the operating system and the signed RAPID runtime are trusted; the engine process is not; compromise of the operating system is out of scope. The minimum is R2.5. If it cannot be guaranteed on one machine, a secondary trusted channel (the member’s phone as remote to his instance) is the clean answer; still one swipe. Which mechanism is chosen is open. That one is required is not.
Per-order modedisabled → per-order instruction
Plan mode · separate trackdisabled → plan adopted → member-executed on member-operated instance
Every new source starts disabled. The member can switch on per-order live use right away, with one explicit, logged local act. No waiting period, no intermediate mode. Each order then takes a fresh swipe on the RAPID surface. Plan mode is a different legal architecture and stays a separate track: the member adopts a plan field by field, the plan is journaled as a versioned instruction, and the member’s own engine and runtime execute it on an instance he alone controls, at brokers whose terms permit it. It is not a standing authority granted to anyone, and the documents no longer describe one: the Commission has held that a customer’s approval of a general strategy is not time-and-price discretion, and located the definiteness requirement on the customer’s grant rather than on the resulting order (Pino). A built-in delay between a rule being met and submission is kept as a system requirement in plan mode so that no order leaves at machine speed; the delay carries no legal claim. No authority says an interval bears on who decided; the only delay federal securities law mandates exists to sever an informational link, not to locate a decision.
authenticated signal → signal validation → member local policy (incl. rule meaning) → order composition → member instruction (act or plan) → instruction record → broker adapter → last-mile check → broker response & reconciliation
The runtime builds the order from the member’s own local policy: what each rule means (buy or sell), sizing, cash reserve, order type, price limits, time-in-force, account, instrument, and frequency and risk limits. The member enters those fields during onboarding, one at a time. Fields start empty. No presets, no one-click imports. Each policy version is journaled as a new event. Reference material stays beside the screen, not on it: the product neither fills a field nor shows a published figure next to one (Keimer; SEC 2008 layout guidance). The onboarding session is recorded, and the consent is asked and answered inside the recording (RCW 9.73.030(3); State v. Fields). Market data is the member’s own: each member connects his own broker or data token. RAPID and the Company hold no data credential.
External lists come straight from the publisher. After one explicit enable act, the member’s runtime fetches a list such as an RMS Universe from the publisher’s own endpoint. The Company never mirrors, caches, relays or re-serves it. The engine gets the list from the member’s runtime as part of the member’s configuration. Never from Company servers.
Dispatch, and the last mile. After the member’s instruction, the Dispatcher sends it through the chosen broker adapter to the member’s own broker. Credentials stay per member and local. There is no Company-level trading credential, no netting or routing across members, no “fire all now”. No Company-controlled component can authorize or transmit an order, and nothing the Company operates is consulted on the way.
Between the approved order and the broker there is one more step, and it is the one the earlier version of this page skipped. Every adapter transforms: it normalizes the symbol, rounds the quantity to a lot size, rounds the price to a tick, translates our order type into the broker’s, maps the account, and lets the broker apply defaults to anything left unspecified. So the request that leaves is not literally the object the member approved. R3.11 closes that gap: the adapter builds the outgoing request in full, reads it back, and compares it to the approved order under a declared translation for each field. A difference the translation does not allow stops the order. So does any difference that would make the order bigger: more quantity, a looser price limit, a longer life, another account, or a field filled in that the member left empty. The order may be expressed differently. It may never be broadened.
What the runtime does not do afterwards. The order carries the member’s own price limits, and where the member wants it worked, the broker’s own order types do the working on the same act. The runtime does not re-peg (a cancel-and-replace is a new order without an instruction under E*TRADE §4.9) and does not run an end-of-day sweep (a cancel is an act too, and the brokers’ own day-order handling covers it). It acts on nothing by itself after dispatch. It is not, however, a system that cannot cancel: the member can stop an order at any time from the app or at his broker, and any such action is his own fresh instruction through the same path. Software that can never intervene is not safer; it is only less useful in the moment something goes wrong.
Two questions per broker, and only one is ours to answer. Attribution (whose order) is settled by the brokers’ own contracts. Permission (may this software connect at all) is each broker’s own gate, and no consent design reaches it: E*TRADE requires a vendor key and a review with unpublished criteria; Schwab requires written approval through its Developer Program; Interactive Brokers expects a third party offering automated trading to hold registration or to supply a legal opinion explaining why not; tastytrade requires prior written approval for software the member did not write; Fidelity prohibits it and has no retail API. A broker is supported only when that gate is read and met. And broker approval says nothing about legal status: Schwab’s Developer Program Agreement §3 and Fidelity’s Account Authority form both disclaim it, so no approval is ever recorded as comfort.
null means reject, not unlimited; missing state means FREEZE.The member’s local journal links source → signal → local policy version → composed order → instruction → outgoing request → adapter → broker response as one append-only, provenance-linked, replay-safe chain. Broker API events land as provisional; the broker’s statement is final and promotes them. History is never rewritten, “not even by the hand that wrote it”. Corrections are new events. Append-only, provenance-linked and replay-safe are the required properties. A local file can still be deleted, truncated, replaced or written by a modified runtime, so the journal proves nothing on its own until four more things are true: events are signed, the release that wrote them is identifiable, time is trusted, and each instruction is bound to the surface or plan version it came from. Those are requirements, listed below. How they are stored and signed is an implementation decision, left open on purpose.
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:
(bool, reason) – a useful primitive for rule attribution; the side is dropped from the message and looked up in the member’s policy insteadOur read is stale, so the honest starting point is a fresh map made by you. This prompt produces a factual inventory of the current engine: modules, flows, decision points, seams. Run it, rewrite it, or skip it. Whatever map comes out is the shared picture we plan the integration from.
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". 8. OUTBOUND CALLS – every call the engine makes to a server the builder operates, and whether any of them sits on the path of an order. Cite file + function for every claim. Mark assumptions [ASSUMED]. Keep code excerpts minimal.