Sonar Sciences
Start free
Start freeSign in
Research/From research to publishing

How does a strategy get from research to a published stream?

Through a sequence of gates, each of which can refuse it. A strategy that survives validation becomes a versioned record: an exact, numbered statement of what the strategy claims to do and how it is evaluated. Publishing means committing to that record, not posting a screenshot. Every later change is a new version with its own history, so a reader can always see what was claimed, when, and what has changed since.

This pillar explains each stage in that order: what a versioned recommendation stream is and is not, how review works before anything carries a person's name, and how payouts, identity checks and the ledger operate when money is involved. The compliance detail is the substance here, not the fine print. A published stream is a set of records a stranger can audit, and that property is what separates publishing from promotion. Read the versioned-streams article first; the rest of the pillar assumes its vocabulary. If you are here to understand how money moves, read the ledger article last, because it only makes sense once the versioning and review stages are clear.

The gates between a validated strategy and a published stream: versioning, review, identity, ledger.

Suggested reading order

1How to archive a retired strategyArchiving a retired strategy means preserving a fixed final implementation, the final evaluation outputs, and a clear retirement rationale. Sonar’s cited materials support this as a research discipline because versioned research artifacts, overfitting audits, and deflated Sharpe ratio analysis all depend on retaining the exact evidence behind a strategy decision.4 min2How to document a trading strategyA trading strategy becomes testable and reproducible when its specification fully defines the universe, rules, position sizing, transaction costs, and all assumptions. Sonar’s research workflow and audit materials support this principle by emphasizing formalized research, backtest auditing, and corrected evaluation metrics such as the deflated Sharpe ratio.4 min3How to keep a strategy research logA complete strategy research log records every tested variant, including failures, because the number and structure of trials are necessary to interpret the final result. Full trial histories support Sonar's overfitting audit workflow and the use of the deflated Sharpe ratio, both of which depend on knowing how much multiple testing occurred. Recording all variants improves auditability, validation, and research decisions by preserving the full search process rather than only the chosen outcome.5 min4How to make a backtest reproducibleA backtest is reproducible when every result-determining input is fixed and recorded, including pinning the data snapshot, fixing the code version, logging all parameters, and recording random seeds for any stochastic step.4 min5How to prove when a result was producedAuditable, reproducible research records are important, and provenance matters. Cryptographic hashes and commit identifiers help bind a result to an exact artifact and code state, and later rehashing can reveal tampering.4 min6How to report a backtest honestlySonar’s cited materials support honest backtest reporting as a disclosure problem: publish the number of trials, sample period, and modeling assumptions such as costs, and do not hide the selection process behind a single favorable result. Sonar’s Backtest Overfitting Audit and glossary on the deflated Sharpe ratio specifically support disclosing trial count because multiple testing can inflate a raw Sharpe ratio. Sonar’s research-to-publishing guidance supports documenting sample windows and assumptions for transparency and reproducibility.4 min7How to run an independent strategy reviewAn independent review starts from complete reproducibility inputs: code, data specification, parameters and documentation. The reviewer replicates the backtest, checks data integrity, and runs statistical sanity tests before forming any opinion.5 min8How to separate research code from execution codeThe workflow separates notebook‑based research from a later publishing step, creating a strong boundary between exploration and downstream implementation. This supports the engineering pattern of keeping research and execution in separate code paths linked by a formal specification, and emphasizes validation and overfitting controls before promotion.4 min9How to version a datasetSonar’s cited materials support the reproducibility logic behind dataset versioning: freeze the data used in a research run as a snapshot, verify it with a checksum, record all updates in a change log, and link those records to the backtest or publication. That creates an audit trail that can identify which data produced a result.4 min10What belongs in a performance disclosureA performance disclosure should state the assumptions behind the result, the cost treatment, the sample limits, and whether the result is hypothetical. Sonar Sciences’ guidance says this information should be placed adjacent to the relevant chart, table, or metric so the reader can interpret the figure with its limits and conditions in view.4 min11What counts as investment adviceSonar treats published output as educational research, not trade instruction. Its research-to-publishing rules prohibit specific trade recommendations and permit method descriptions, tests, and analytical frameworks instead. The overfitting audit and Deflated Sharpe Ratio materials show a process centered on research validation rather than actionable trade calls. SEC/FCA regulatory definitions are not referenced in the current material, so that broader legal claim cannot be established here.3 min12Why a track record needs an audit trailA track record is verifiable only when it includes an audit trail. The cited Sonar sources support three parts of that standard: traceable research-to-publication workflow, independent backtest overfitting audit outputs, and metrics like the deflated Sharpe ratio that depend on transparency about multiple testing and selection. The sources support the need for timestamps, version lineage, and third-party records at the principle level, though they do not provide detailed public specifications for logging schemas or version-control implementation.4 min13Why every public claim needs a sourceSonar’s publishing materials require public claims to be tied to sources so conclusions remain traceable to evidence. Without a documented source, a public claim cannot be reliably checked later and cannot be systematically retired when underlying evidence changes. A claim register solves this by recording each claim together with its supporting source, making both verification and maintenance mechanical.4 min14Why financial promotion rules matter to quantsFinancial promotion rules matter to quants because public statements about strategies, signals, and trading activity can operate as regulated inducements even when they are framed as technical research. The practical response is to treat public investment-related communication as compliance-sensitive content that requires controlled drafting, review, and approval before publication...3 min15Why identity checks exist in financeFinancial identity checks exist to verify customers, connect accounts and transactions to real people or entities, and preserve enough context to detect concealment. They are used to obstruct crimes that depend on hidden identity or hidden ownership, including money laundering, terrorist financing, fraud, and tax evasion. Transaction-related checks occur when money movement raises uncertainty about who is acting, whose funds are involved, or whether the activity matches the stated purpose of the relationship.3 min16Why pre-registering a test keeps you honestPre registering pass criteria means deciding the success rules before a backtest runs. It reduces bias by limiting the ability to change metrics or thresholds after results are visible, which helps contain post hoc selection and overfitting.3 min17Why public track records skew positivePublic track records are positively skewed because publication is a filtered subset of research, continued visibility depends on meeting publishing criteria, and multiple testing can inflate the metrics of the survivors. The backtest‑overfitting audit and deflated Sharpe ratio are tools to address these selection problems.4 min18Why publication needs a review gateA mandatory review gate means a qualified second reader must check research before publication. It helps because authors are structurally prone to miss errors created by familiarity with their own method, code, and conclusions. Sonar's publication framework and audit materials support the value of this control point, especially for catching overfitting and misinterpreted performance metrics.3 min19Why reproducibility matters in trading researchReproducibility matters in trading research because it preserves the full path from data and code to conclusion, making claims auditable rather than anecdotal. Sonar’s sources support the argument that weakly documented backtest workflows create room for hidden selection and overfitting, and that tools such as overfitting audits and the deflated Sharpe ratio are designed to address those risks.4 min20Why screenshots are not a track recordScreenshots are not reliable track records because they are images of selected information rather than verifiable records. They do not securely link results to a specific identity, cannot prove completeness of the trade history, do not provide trustworthy timing, and can hide selection bias. They also cannot support metrics such as the deflated Sharpe ratio, which require the full return series and multiple testing context.3 min21Why strategy changes need version historyStrategy edits break the continuity of a backtest record, so presenting all results as one uninterrupted history is misleading. Traceable research stages, auditability of iterative testing, and metrics like the deflated Sharpe ratio are designed for multiple-testing contexts. The defensible conclusion is process-based: version history is essential to preserve provenance and prevent revised strategies from inheriting performance records that belonged to earlier versions.5 min
Tool · free, no signupBacktest Overfitting AuditEight questions about your sample, your process, and your cost model. Answer them and you get a written verdict you can keep.

Terms used in this pillar