How to version and roll back a stock thesis
To version a stock thesis in Quantery, save each meaningful rule change as a new version, then activate the version you want scans and backtests to use. To roll back, activate an older version from the thesis's version list. The later work stays in the registry, so rollback doesn't erase it.
That separation matters because a thesis has two lives: the draft you're editing and the active rules the engine runs. Treat activation as a research decision. You can prepare a change, check that it validates, and leave the current rules active until you're ready to test the revision.
What does a thesis version preserve?
A thesis version is an immutable snapshot of the thesis spec at the moment it was saved. It includes the universe definition, parameters, features, criteria, gate, verdict bands, and backtest settings written into that spec. Once the version exists, later edits don't alter it.
Quantery also gives the version a content hash, a short fingerprint of the saved spec. If you save identical content again, the fingerprint matches and the registry doesn't create another version. That keeps an accidental double-save from filling the history with copies.
The active marker is separate from the saved version. A thesis can have several preserved versions while only one is active. Scans and new backtests use the active version. Moving the marker to an older version changes what the next run uses, but it doesn't rewrite a completed run.
This is why versioning belongs in the research method, not just the app's plumbing. A backtest result without its exact rules is a chart you can't interrogate. A result tied to a saved version gives you the question that produced it.
Save a baseline before changing a rule
Start from a thesis whose current behavior you understand. If it's new to you, run it unchanged and audit one stock screen result before editing. Confirm the gate, inspect a matched criterion, and trace a calculated feature to its inputs. You need a baseline you can describe in plain language.
Now state the proposed change before touching the builder. Keep the sentence narrow:
Raise the quality threshold because the current band admits companies whose cash return is too weak for this thesis.
The sentence does useful work. It names the rule, gives a reason, and makes the next run interpretable. “Improve the thesis” gives you nothing to compare later.
Make the edit in the visual builder or YAML view. Both are views of the same thesis text, so switching views doesn't create a version. Watch the validation result while you work. A valid spec means the schema and expressions compile. It doesn't mean the economic claim is sensible, and it doesn't mean the rule will produce useful results.
If you want the change preserved while the current thesis keeps running, choose Save as new version. Quantery writes the thesis and imports a new immutable version without moving the active marker. This is the safe holding area for a draft that compiles but hasn't earned a run yet.
Don't use the version number as a quality score. A later version is later. It may be better, worse, or just different. Put the reason for the change in your research log, because the registry preserves the spec and timestamp, while your reasoning still belongs to you.
When should you activate the new version?
Activate when you can say what the next run is meant to test. If the edit is ready now, Save & activate preserves it and makes it the version used by new scans and backtests. If you saved it earlier, use the version list to activate it when the test is ready.
Before activation, record four things:
- The rule or parameter that changed
- The business claim behind the change
- The run settings you'll hold fixed
- The result that would count against the change
This isn't ceremony. Suppose you tighten a profitability band and also change the universe, benchmark, and rebalance cadence. A different result can't tell you which edit mattered. Preserve the surrounding setup and let the version carry one meaningful rules change at a time.
The same discipline applies when the edit looks cosmetic. Reordering criterion rules can change the score because the first matching rule wins. Changing a null guard can bring companies into the evaluable set or push them out. Renaming a label may leave the arithmetic untouched, but read the diff before assuming that was all you changed.
Run a current scan first when the edit affects membership or scoring. Inspect a few changed rows. Then run the historical test if the current behavior matches the claim. Quantery's backtest workflow records the active thesis version with the report. Every backtest result is hypothetical and excludes costs, so version precision improves the experiment without turning it into a forecast.
How do you roll back a stock thesis?
Open the thesis and find its version list. The active entry is marked. Choose activate beside the older version you want to restore. Quantery moves the active marker to that stored spec. Your next scan or backtest will use those older rules.
Rollback is useful when a revision fails for a clear reason. Perhaps a tighter gate leaves the thesis unable to express the broad claim you started with. Perhaps a new feature depends on coverage that isn't available through enough of the test window. Perhaps the result changes only because a supposedly minor edit altered the eligible universe.
Don't erase the failed version. You can't learn much from a research process that keeps only its winners. The preserved version tells you exactly what failed, and the note beside your run should say why you stepped back.
Rollback moves a pointer and leaves history intact. The later version remains available and can be activated again. You can also open the older rules, make a more focused edit, and save that content as another new version. The sequence may branch in your notebook even though the registry's version numbers keep moving forward.
One detail prevents confusion: activating an older version doesn't make its version number “latest.” It makes that version active. The newest saved version and the active version can be different, which is useful once you stop treating every save as an automatic promotion.
What happens to earlier scans and backtests?
Completed runs retain their recorded thesis identity. Quantery stores the thesis version with scans and backtests, so activating another version doesn't relabel an old result. When you open an explanation from a recorded scan, the app tries to evaluate against the exact stored version that produced it.
Keep the run's recorded values separate from a live calculation. New filings, refreshed prices, or backfilled data can make today's evaluation differ from the saved observation. Comparing two screen runs explains that boundary: the diff can locate a changed feature or membership result, while today's filing trace doesn't become proof of what an older calculation used.
Scan history has a practical wrinkle. Rerunning the same thesis on the same UTC date replaces that date's earlier stored scan results. If you need separate rows for a run comparison, plan around that behavior instead of assuming every click creates another permanent row. Backtest reports are stored as their own completed runs, but you should still name the tested version in your notes.
Versioning also doesn't freeze the local data lake. It preserves rules. Reproducing a result depends on the run record and the data retained for that workflow. If a live value moves later, don't blame the spec until you've separated rule drift from data drift.
Archive a thesis without deleting its record
A thesis can reach the end of its useful life. Maybe its proxy never matched the claim. Maybe a cleaner thesis replaced it. Use Archive thesis to remove its active status while keeping every version in the registry.
Archiving is better than deleting the record because old scans and backtests still need an identity. The archived versions remain available, and activating one revives the thesis. That gives abandoned ideas a proper shelf instead of letting them clutter current work or vanish from the evidence.
Be stricter with archives than with weak runs. A poor result may still belong under an active thesis while you test why it failed. Archive when you no longer want new work to use any version by default.
A version history should read like an experiment log
A useful sequence is easy to summarize: baseline rules, one stated revision, a controlled run, and a decision to keep or roll back. Repeat from there. If you can't explain what changed between adjacent versions, the edits are too broad.
This is the practical benefit of Quantery's version model. The templates aren't sealed strategies, and your first draft isn't sacred. Change the rules, but preserve the question each run answered. Activate revisions deliberately. Roll back without shame. The rules stay yours because their history stays inspectable.
Research tooling, not investment advice. Nothing here is a recommendation to buy, sell, or hold any security. Screens, scores, and backtests are informational only; backtested results are hypothetical, exclude costs such as commissions and slippage, and do not guarantee future results. Verify against primary filings and make your own decisions.
Want to try this on your own rules? Quantery is free for 14 days: the full app, no card required.
← All articles