Why does policy keep research code away from any system that can send a live order? This note explains the separation, using a notebook study of SPY as the public example, and says where the site's own legal and privacy pages fit.
Authority is the difference
Research code computes, draws, and proposes. An order system can cause a message to be sent toward a venue. Policy treats those as different authorities. The first may be wrong at low cost, which is how questions get answered. The second may be wrong at the cost of an instruction leaving the building, which is why its changes are slower and its permissions are smaller. A policy that merely asks people to be careful, while letting one environment hold both authorities, has written a wish. The wish will be tested by the most convenient shortcut.
The written rule is that research code does not receive credentials that can send an order, and an order path does not import a scratch file because the scratch file looked finished. A crossing is a reviewed release of a named version, or it is an incident. There is no third category called temporary. Temporary is how an unreviewed path becomes the path everyone is afraid to turn off.
Research code may compute and propose. It may not hold the authority to send a live order. That authority, if it exists, lives in a separate system and crosses only by a reviewed release.
A study that cannot click send
A notebook that studies SPY can load history, rank days, and produce a chart. Policy is satisfied with that activity only while the notebook cannot submit an order in SPY or in anything else. The public example is intentionally ordinary. If the rule only feels necessary for exotic strategies, it will be waived for ordinary ones, and ordinary ones are where habits form. The SPY notebook is a success when it is insightful and still incapable of sending anything.
The order system, on the other side of the wall, may eventually call a reviewed function that began as research. Policy cares that the function was copied into a version, tested, and accepted, and that the notebook was not given the production configuration in exchange. Peer review is part of the crossing. A model that fails its tests is removed from eligibility. Removal must be real, which means the live path was never pointed at the researcher's home directory. The SPY example does not suggest that such a function should be promoted. It shows the only shape a promotion is allowed to have if it ever happens.
Personal data has no role on either side of this particular wall. A study of a public fund does not need a person's identity, and an order path does not become safer because a name is attached to a ticket in a research file. Questions about how this website handles personal information belong to /privacy-policies. Questions about what the public site is committing to belong to /legal. Neither page is amended by a notebook.
The policy in one paragraph
Research code proposes. Live systems, if they act, act through a separate authority with a separate review. A public example such as a SPY study is not a workaround. The convenience of running both on one screen is not a counterargument. A firm that blurs the line will eventually send an experiment, or will be unable to prove that it did not.
This note is an educational page about that line. It is not an operating manual for sending orders, and it is not a description of any order that has been sent. Readers who want the site's terms should use /legal and /privacy-policies rather than inferring them from an engineering preference.
This piece does not claim that any research study becomes an order, that a SPY notebook is a strategy, or that the firm is describing a live system in detail. A convenient shared screen is not an exception, and a chart that looks finished is not one either. The wall is boring on purpose, because the interesting exceptions are how unreviewed code would acquire the ability to act. Governing pages for this site are /legal and /privacy-policies.
