Update stock trading rules in separate simulation branches
New trading records can suggest a different explanation of an investor’s decisions. Updating the explanation should create a new research branch, because changing an existing rule retroactively also changes the experiment already under observation. Freeze the old rule, its initial state and the observations it has received before deciding how to study the revision.
This guide registers a manually supplied second version and compares independent synthetic stock accounts. No model is called or actual journal imported. Version registration, persistent observation accounts and scheduled updates are external extensions; the example does not establish that CoTrading or a reference shadow replay already provides them as a long-running service.
Decide whether there is a reason to revise
Record which new executions arrived, the journal cutoff and the proposed interpretation change. A corrected export, a newly closed position and a genuinely different candidate rule are different update reasons. Correcting an input may require a documented repair branch; adding another winner does not automatically authorize replacing the active candidate. Keep the existing observation policy visible before making that choice.
The two fixture rules are hand supplied. Version v1 enters when a previously observed value exceeds 100 and exits below 100. Version v2 enters above 105 and exits below 102. The observed values are explicit prior-session inputs, separate from current synthetic execution prices. Neither version is described as learned by AI, and the example does not evaluate how either threshold was selected.
Five profitable source rounds, if used as an extraction eligibility gate, remain a statement about selected input. A new version can fit newly appended winners without improving prospective behavior. Preserve the reason for every revision and the unsuccessful alternatives so the number of attempted explanations does not disappear when a version label changes.
Seal rule bytes and account state separately
Store the rule’s version, thresholds and extraction cutoff together. The Python hashlib documentation provides SHA-256 for identifying exact serialized inputs. A digest detects a changed representation; it does not authenticate a reviewer, establish data quality or prove that the rule was frozen before an untrusted timestamp. Keep supporting records appropriate to the real research process.
The example writes v1 into a temporary directory, registers v2 with exclusive file creation, and confirms that the original v1 bytes remain unchanged. A second attempt to create the v2 file fails. These operations exercise the illustrated registration policy locally. They are not a concurrent version registry, distributed lock or permanent archival system, and the temporary directory is removed when the example exits.
Use a stable serialization convention before comparing digests. The Python JSON documentation describes sorted keys and compact separators; the helper also disables nonfinite number serialization. Formatting differences can change bytes even when a human thinks two cards mean the same thing. Preserve both semantic fields and their canonical representation rather than treating every digest difference as an economically meaningful revision.
Give the continuing branch its actual known state
At the start of the future fixture, v1’s continuing account has 900 USD cash and one share. That holding is an input snapshot, not a purchase invented at the first new observation. The new v2 account starts independently with 1,000 USD cash and zero shares. Their histories and starting exposures differ, so their final values cannot directly isolate the effect of the rule revision.
The future observations are numbered four through seven. Their previously known decision inputs are 101, 107, 99 and 110, while current fill prices are 102, 108, 100 and 111. The fixture assumes immediate fills at those separate supplied prices with no fees. It does not claim that observing a current close permits trading retroactively at that same close.
For each event the replay calculates cash plus shares at the current fill price before and after any trade. The two values must match under the zero-fee assumption, and cash cannot go negative. This transition check catches funding errors even when the final marked value looks plausible. Price changes between events affect valuation, while purchases and sales move value between cash and shares.
Read the independent account paths
Continuing v1 holds its original share at observations four and five. At six, the observed value 99 triggers a sale at 100, raising cash from 900 to 1,000. At seven it buys one share at 111, leaving 889 cash and one share. Marking that share at the final synthetic price 112 gives ending value 1,001.
Fresh v2 stays flat at observation four. At five, observed 107 exceeds its entry threshold and it buys at 108, leaving 892 cash. It sells at observation six for 100, leaving 992, then buys at seven for 111, leaving 881. The same terminal mark produces 993. The program retains these event rows instead of showing only two ending balances.
The eight-unit difference between these continuing and fresh branches combines rule behavior with their different initial states. It is not a clean estimate of the benefit of retaining v1. Label the branch start, cash, shares, currency, cost convention and terminal mark alongside every comparison, because a version name by itself does not identify the capital path being compared.
Add a common-start comparison without rewriting v1
Create a separate comparison branch for v1 with 1,000 cash and no shares at the same observation-four boundary as v2. This fresh v1 buys at 102 when it sees 101, sells at 100 when it sees 99, and buys again at 111. Its terminal value is 999, compared with fresh v2’s 993. The continuing v1 result remains 1,001 in its original branch.
This common-start contrast controls the stated initial capital and holdings, but remains a tiny synthetic illustration. It does not settle which threshold generalizes, estimate a reliable long-run advantage or justify selecting a version from these observed outcomes. If the comparison influences a revision, reserve a new untouched observation interval rather than repeatedly calling this one independent.
Do not transfer virtual profits or holdings between branches. A purchase by v2 does not close v1’s position, and a later real-account sale does not automatically edit either account. If an intentional state transfer is part of a different experiment, record it as a new branch with explicit opening assets and flows; do not disguise the transfer as an ordinary rule update.
Refuse pre-cutoff replay and silent replacement
Version v2 has cutoff three. Passing an observation at or before that cutoff raises an error, because this example’s observation handoff only accepts subsequent events. The guard does not prove that the threshold was independently selected; it prevents this narrow replay function from treating pre-freeze rows as new prospective observations. Keep extraction records and observation records separate.
Exclusive creation protects the first local v2 registration from accidental overwrite. A correction should receive a new identifier and a reason linking it to the old artifact. The old account can continue, pause or be archived according to a declared policy, but those actions must not recalculate its historical signals under the new thresholds. Preserve unknown or missing events rather than manufacturing an uninterrupted history.
Before accepting a handoff, compare the account-opening rows rather than only the rule cards. An unknown opening cash amount blocks a funded comparison; market value is not spendable cash. Check the last mark independently of the trade prices and disclose the zero-fee simplification. If actual fees, share units or a blocked execution are later introduced, rerun both common-start branches under the same changed convention and register that experiment separately.
Run and retain the branch evidence
Download the complete example, save R640.py and run python R640.py using Python 3.12 or later. Only standard-library modules and synthetic inputs are used. Assertions check ending values 1,001, 993 and 999, distinct first-event behavior, unchanged v1 bytes, exclusive v2 registration, pre-cutoff rejection and cash/share conservation at every transition.
For a real research handoff, retain the frozen cards, account snapshots, event rows, cutoffs, comparison convention and current observation status. Update the candidate only through another explicit registration decision. The useful outcome is an honest record of which rule and state produced each path, even when the answer is that the revision has not yet received enough independent observation.
FAQ
Must every journal update create a new active rule?
No. Record the new input and decide whether a revision is warranted. An eligible or plausible candidate can remain unapproved.
Which comparison isolates the initial-state difference?
The separate common-start branches use equal opening cash and shares. They do not replace the continuing account’s history or prove long-run superiority.