Why is a research notebook a different system from any path that can send an order? This note draws the boundary, using a study of SPY written in a notebook as the public example, and lists what is not allowed to cross by accident.
Two machines with two jobs
A notebook is a place to read data, draw a picture, and try a rule that will probably be thrown away. It is good at that job because it is flexible, personal, and easy to change without a release. An order path is a place that can cause a message to leave toward a venue. It is a bad place to explore, because a change there is a change to something that can act. Treating them as one environment means an experiment inherits the power to act, or a live path inherits the habits of a scratch file. Both inheritances are failures of design.
The boundary is technical, not ceremonial. The notebook should not possess credentials that can send an order. The order path should not import a scratch module because a chart looked promising. Code crosses only through a review that says what moved, what tests ran, and what remains research. A shared folder and a verbal approval are not that review. If the only thing separating the two systems is a person's intention, they are one system with two moods.
A notebook is an exploratory system with no authority to send an order. An order path is a reviewed system that can act. Code does not cross from one to the other except as a versioned, tested artifact.
A SPY study that stays a study
Imagine a notebook that loads a history of SPY and computes a rule about the day's range. The notebook can be insightful, wrong, or unfinished. None of those states is an order. The moment the same code can see a live session and also possesses a way to submit a message, the notebook has stopped being a notebook. The SPY study does not need that power in order to be completed. Giving it the power does not make the study more serious. It makes the boundary fictional.
What may cross is an artifact that has been made boring on purpose: a versioned function with tests, a documented input, and no path to a venue. A reviewer can read it. A replay can run it. The order system, if it ever calls that function, calls the reviewed version, not whatever is currently open on someone's screen. The notebook may continue to diverge after the copy. That divergence is healthy. It means exploration did not drag the reviewed version along with it.
The accidental crossings are mundane. A developer points a research tool at a production configuration. A notebook kernel is started on a host that also runs a live process and shares its environment. A file named final is imported because the real release was inconvenient. Each of those is a design bug even if no message is sent. The SPY example is deliberately dull, a liquid fund and a simple rule, so the drama of the market cannot excuse a missing wall. The wall is owed to the dull studies as much as to the exciting ones.
The order system stays the smaller door
The system that can send an order should be the smaller one. Fewer changes, explicit review, logs that can be replayed, and checks that sit outside any model and can say no. Research can be wide. The door out of research is narrow on purpose. A failing idea is removed from consideration. It is not left half-wired because the notebook still has the import. Removal has to be possible, which means the wiring was never direct.
A notebook and an order are different systems because their failures have different costs and their changes have different tempos. A study of SPY may inform a later, separate decision. It does not get to skip the decision by living on the wrong host. The boundary is the whole point of having two of them.
This piece does not claim that a notebook result should become an order, that research and production share a machine, or that a study of SPY is ready for anything beyond the notebook. It keeps the two systems from being one system under two names.
