The compiled terminal keeps broker access and execution supervision close to the person operating it
The first distributable Trade build raised a product question before it raised a design question: where should the operating boundary live?
We chose the user’s machine. Trade ships as a compiled local terminal because execution belongs close to the person responsible for it. That choice shapes onboarding, status, stopping, and the way we describe the software.
Local is a boundary, not a safety claim
A local application gives the operator a place they can point to. They launch it. They can see whether it is connected and ready. They can stop it without searching for a distant process they cannot inspect.
That boundary is useful, though it does not make execution harmless, private by default, or immune to failure. A local terminal still depends on external market and broker systems. The machine can sleep. A connection can lose context. Configuration can be wrong. A supervised workflow begins by making those conditions legible.
This is why the public launcher does more than open a terminal window. It walks through current policy acceptance and setup, then hands control to a self-contained application. The handoff should feel deliberate. A person should understand when they are moving from reading about Trade to operating something that can carry real consequences.
Research has to cross a gate
The market views, pattern work, replay environment, and terminal share the same range language. Shared language does not give every research result permission to become an action.
An idea begins as a question. Replay runs that idea through recorded market history as if each moment were arriving live, shaped around the constraints of our model. Review asks where the historical and live-shaped readings disagree. Demo use puts the workflow beside current conditions without treating a promising report as proof.
Each stage can reject the idea. That is a feature. Research that only travels forward accumulates confidence faster than understanding.
We avoid turning this gate into a score that implies certainty. Historical behavior can reveal a broken assumption and still say nothing guaranteed about the next event. The operator remains responsible for deciding whether the system should run.
Status is part of the interaction
Execution demos tend to focus on the moment an order appears. Our harder design work sits around that moment.
Can the operator tell what the terminal believes its state to be? Does a loss of context look different from ordinary waiting? Is the stop control obvious before it is needed? If the application resumes after interruption, does it make that recovery visible? These are product questions, not background details.
The terminal uses plain text and a restrained hierarchy because status should be readable at a glance. The visual language comes from the same graphite surfaces, green activity, and measured spacing as the rest of the interface, but the terminal stays compact enough to operate from a local shell. Decoration has very little work to do there.
What the current release asks of the operator
Trade remains experimental. Supported configurations may submit, modify, and close broker-connected orders when live execution is enabled. The terminal requires current risk acceptance and active supervision. Demo use comes first.
Those conditions belong near Trade, not at the end of a long promise. Local operation gives us a clear place to build trust: one visible application, one responsible operator, and controls that state what the software is doing before anyone asks it to act.