A trade idea is not a setup, and a setup is not an executed trade. Good sourcing keeps those stages separate. It gives every candidate a known origin, checks it against the same eligibility rules, records why it was rejected or executed, and preserves the candidates you did not trade.
Three practical routes cover most workflows: a predefined watchlist, a rules-based scanner, and an event/calendar feed. None is automatically superior. The right route depends on the instrument universe, strategy definition, available attention, data latency, and whether the pipeline can be audited after the fact.
Define Idea, Candidate, Setup, and Trade
Ambiguous stage names make sourcing impossible to diagnose. Use four explicit states:
- Idea: a hypothesis or area worth monitoring, with a source and timestamp.
- Candidate: an instrument/event returned by the declared sourcing rule.
- Qualified setup: a candidate that passes the frozen setup checklist.
- Executed trade: a qualified setup that also passes timing, correlation, liquidity, risk, and operational checks.
Write rejection reasons at the stage where they occur. “No setup” is different from “setup valid, but correlation blocked execution.” The setup-confluence guide can supply checklist fields, but the criteria must be defined before reviewing the candidates.
| Required field | Why it matters | Fail-safe state |
|---|---|---|
| Candidate ID and source | Prevents duplicate ideas and source confusion | Unattributed |
| Universe/query version | Shows what could have been selected | Not verified |
| Created and observed time | Separates timely ideas from late discovery | Time unknown |
| Qualification decision | Preserves pass, reject, and unresolved counts | Unreviewed |
| Execution decision | Separates opportunity quality from capacity constraints | Not executed—reason unknown |
| Outcome coverage | Allows later comparison of executed and shadow candidates | Outcome unavailable |
Mode 1: Predefined Watchlist
A watchlist limits the universe before the session. It works well when repeated familiarity with a manageable set matters more than broad discovery.
Build the list as a contract
Record the eligible instruments, liquidity or tradability requirements, strategy versions, review cadence, and removal rule. Do not add an instrument because it is moving today and still call the result a fixed-watchlist test. Put ad hoc names in a separate exploration list.
Daily workflow
- Load the frozen list and record coverage: reviewed, unavailable, or skipped.
- Create a candidate only when the predeclared trigger appears.
- Run the full setup and risk checklist.
- Record qualified-but-not-executed opportunities with the blocking reason.
- Review additions and removals on the declared schedule, not after one outcome.
Strength: stable coverage and instrument familiarity. Risk: opportunity blindness outside the list and survivorship when weak instruments are removed without preserving their history.
Mode 2: Rules-Based Scanner
A scanner searches a broader universe using saved conditions. Its output is a candidate feed, not a trade signal. The scanner can be technically correct while the strategy checklist rejects most rows.
Version the query
Store universe, data vendor, timeframe, field definitions, thresholds, run time, timezone, sort order, result cap, and query version. A changing universe or vendor adjustment can alter the feed even when your visible settings look unchanged.
Calibrate without chasing a target count
There is no universal healthy number of daily candidates or pass-rate band. Too many candidates means the review cannot meet its service level; too few may mean the strategy is quiet, the query is narrow, or the data is incomplete. Diagnose those alternatives instead of loosening a rule merely to make the list busy.
Test the scanner with recorded outputs before using it as the sole live source. Preserve false positives, empty runs, delayed data, and missed examples. Those records show whether the bottleneck is the query, data feed, reviewer capacity, or setup definition.
Strength: repeatable broad coverage. Risk: query drift, data dependencies, curve-fitting, and the temptation to treat a ranking score as execution permission.
Mode 3: Event and Calendar Sourcing
An event feed starts from a scheduled or observed catalyst, then asks whether a strategy-defined technical opportunity forms. The event is context; it does not predict direction.
Record the source, publication or scheduled time, affected instruments, embargo/revision state where relevant, and the earliest time the information was available to the trader. For scheduled events, define in advance whether the strategy permits pre-event positions, post-event entries, or no trade.
The economic-calendar guide covers event preparation and timing controls. Expect missing releases, revisions, latency, spread changes, slippage, halts, and rejected orders; the calendar cannot guarantee executable liquidity.
Strength: explicit catalyst context and a natural monitoring schedule. Risk: late discovery, narrative bias, unstable execution conditions, and hindsight about what the event “meant.”
Use Hybrid Sources Without Double-Counting
A multi-strategy workflow may need more than one source. Assign one primary source to each strategy and a deterministic deduplication key to every candidate. If a watchlist and scanner surface the same instrument and timestamp, retain both source hits but keep one candidate record with an attribution rule.
This keeps source comparison fair. Otherwise the same winning trade may be credited to two pipelines while rejected duplicates disappear from both denominators.
Measure the Complete Candidate Funnel
The core counts are raw candidates, reviewed candidates, qualified setups, executed trades, and shadow outcomes where available. Pair ratios with denominators and operational context.
| Metric | Calculation | What it can diagnose |
|---|---|---|
| Coverage | Reviewed ÷ eligible candidates | Whether the team or trader actually examined the feed |
| Qualification rate | Qualified ÷ reviewed | Query breadth or checklist selectivity |
| Execution rate | Executed ÷ qualified | Timing, risk, correlation, liquidity, or capacity constraints |
| Duplicate rate | Duplicate source hits ÷ source hits | Overlap between sourcing routes |
| Review time | Minutes ÷ reviewed candidates | Operational load, not idea quality |
| Outcome distribution | Executed and shadow outcomes by source/version | Whether an observed difference deserves a later test |
A low qualification rate is not automatically bad, and a high execution rate is not automatically good. Interpret the rate with coverage, capacity, strategy frequency, and outcome completeness. The profit-per-hour analysis can evaluate workflow cost, but time efficiency must not replace risk or evidence quality.
Hidden Deal-Breaker: Random Browsing Enters the Dataset Unlabeled
Browsing charts can generate useful hypotheses. The problem begins when an unplanned discovery is executed under the measured strategy without an exploration label. It changes the candidate universe after the trader has seen attractive price action, while uninteresting charts leave no record.
This creates selection bias: executed discoveries are visible, skipped possibilities are not, and the source cannot be reproduced. Confirmation and recency are plausible explanations, but the trade log alone cannot establish the trader’s motive.
Use a separate exploration source. Record the instrument, discovery time, reason it caught attention, setup version, and whether it would have appeared in a frozen watchlist/scanner/event feed. Exploration can later propose a new sourcing rule; it should not retroactively become evidence for the old one.
Choose by Constraints, Then Validate
| If the strategy needs… | Primary route to test | Evidence to monitor |
|---|---|---|
| Depth in a stable, limited universe | Predefined watchlist | Coverage, additions/removals, missed external candidates |
| Broad systematic discovery | Rules-based scanner | Query version, data latency, false positives, review capacity |
| Explicit catalyst timing | Event/calendar feed | Source timing, revisions, liquidity, eligible entry window |
| Several distinct strategies | One primary route per strategy | Deduplication and attribution across feeds |
| Research outside the current system | Separate exploration queue | Unbiased logging before promotion into a rule |
Run the chosen route long enough to collect complete funnels across varied conditions. Freeze changes, compare later periods, and retain the prior version. Do not declare a sourcing winner from one backfilled sample: historical review knows which candidates became interesting.
Make the Execution Handoff Explicit
A qualified setup can still be non-executable. Define correlation, position-size, liquidity, news, venue, and operational gates before the order. The execution protocol separates a sourcing success from an execution decision and preserves the reason a valid candidate was passed.
After execution, keep the Candidate ID on the trade. That join lets later analysis compare sources and versions without guessing from symbol or notes.
Where TSB Fits
TSB is our product. It can consolidate executed trades, preserve account/source identity, attach setup and review context, and compare scoped outcomes. TSB recognizes 331 import profiles and has processed 600K+ imported trades.
Those figures describe import coverage and product scale, not the quality of a sourcing method. A normal trade import does not contain every candidate you rejected or never executed. To measure the full funnel, maintain the candidate log and join its stable Candidate ID to executed trades. Without that denominator, TSB can analyze executed-trade evidence but cannot reconstruct unseen opportunities.
A lifetime-access route is available alongside the current plan rendered in the server-side provider card. Reconcile timestamps, fees, duplicates, account mapping, and source/version tags before comparing routes. If candidate coverage is unknown, say Not verified.
Methodology and Review Rules
- Denominator: retain rejected, unresolved, and qualified-but-not-executed candidates.
- Versioning: freeze universe, query, setup, and attribution rules before comparison.
- Costs: use reconciled net outcomes where available and disclose missing coverage.
- Bias control: keep exploration separate; do not backfill only memorable historical candidates.
- Uncertainty: no universal watchlist size, conversion ratio, or testing duration proves source quality.
- Outcome boundary: structured sourcing improves auditability and coverage control; it does not guarantee better trades or P&L.
See the TSB editorial evidence methodology for the claim classes and source standards used here.
Final Verdict: Build an Auditable Opportunity Pipeline
Watchlist, scanner, and event sourcing are useful because each can define a reproducible candidate universe. Their value is not a universal ranking. It is the ability to see what was eligible, what was reviewed, what qualified, what was executed, and why the rest stopped.
Choose the route that matches the strategy and operating constraints, label exploration separately, and preserve complete denominators. Then test changes on later candidates. A sourcing process that can be audited and rolled back is more valuable than a busy feed that only remembers the trades you took.
