Check whether candidate stock trading rules can be executed
A candidate explanation of profitable stock trades is not yet an executable strategy. Phrases such as strong momentum, good management or a confident entry do not tell an evaluator which input to read, when that input became available, or what action follows. Turn the candidate into a reviewable rule card before allowing any simulated execution.
This guide reviews a manually supplied candidate using a fixed one-stock USD basket. No model is called and no real journal is analyzed. The example validates a narrow rule vocabulary and replays observable decisions with next-session fills. It is an external research method, not evidence that CoTrading has extracted, approved or deployed an AI strategy.
Separate the proposed explanation from its evidence
Preserve the original candidate wording and the journal cutoff that motivated it. If an actual model produced the proposal, save its model identity, prompt, response and source references separately; do not substitute the cleaned rule for that response. Here the proposal is written by hand, so the record says human_candidate=True and model_calls=0. That distinction is part of the experiment’s provenance.
A threshold of five profitable completed rounds can be an input condition for a reference extraction workflow. It provides no assurance that the candidate explains losses, unselected opportunities or future observations. Record the winner selection explicitly and carry it into the later test plan. A plausible description of the chosen winners can coexist with a rule that fails everywhere else.
The joint SEC, NASAA and FINRA AI alert advises checking underlying information rather than relying solely on AI output. Our practical response is a field-level evidence map. The alert does not validate this particular rule or any profitability claim, and an approval signature below only confirms the specified interpretation.
Build a rule card with observable conditions
The supplied card contains a version, lookback, entry condition, exit condition, execution policy, quantity, currency, basket and reviewer identity. The supported entry is close_gt_previous_mean; the exit is close_lt_previous_mean. The lookback is two earlier closes. The current close is compared with their arithmetic mean, and equality produces no change. These choices are explicit fixture rules rather than inferred facts about the trader’s intentions.
Every field needs an input origin. Prices come from the synthetic close vector, the basket is the supplied list A, and the reviewer is a nonempty fixture identity. Real deployment would additionally require a verified security master, market calendar, price-adjustment policy and data availability timestamps. Do not label those external dependencies confirmed merely because the local card has all required keys.
The parser rejects missing and unknown keys. It also rejects a blank reviewer, a Boolean lookback, unsupported quantity or currency, and any condition outside its small vocabulary. Accepting arbitrary natural language here would move unresolved interpretation into the execution stage. Keep rejected wording on the review card and request evidence or a new explicit interpretation before assigning another version.
Keep decision time separate from fill time
A decision formed from session t’s close can first request this example’s fill at session t+1’s open. It cannot trade at the close that helped produce the decision. The fixture has equal-length close and open arrays and records both indices on every event. This makes the time relationship inspectable instead of hiding it behind a single trade date.
The first two closes are history only. At index two, the previous mean is 101 from 100 and 102; the current close is 105, so the flat rule requests a buy. The synthetic fill is index three’s open, 104. While holding, index three closes at 99 against the previous mean 103.5, requesting a sale at index four’s open, 100.
The two generated events are therefore buy(decision=2, fill=3, price=104) and sell(decision=3, fill=4, price=100). They illustrate executable timing, not favorable performance. The example has no fee model or capital ledger; use a separate funded account replay before interpreting an executable signal as an affordable completed transaction.
Make unknown information an explicit review result
The candidate buy_when_confident is rejected because the evaluator has no observable confidence input or threshold. The alternative tomorrow_close_up is rejected because it names a future outcome rather than a supported decision-time feature. These failures concern the rule specification, even when every price in the fixture is available to the offline test program.
Missing history is a different mechanism. Replace the close at index one with None. Both decisions requiring that observation become unknown, and the sample generates no events. It does not interpolate the missing close, skip to a shorter window or invent a signal across the gap. A later supported history window can be evaluated under the same frozen rule, but it cannot repair earlier unknown decisions retrospectively.
The replay also rejects nonfinite or nonpositive supplied prices. Validity checks precede comparisons, preventing NaN from quietly turning a condition false. A missing next open leaves the decision unresolved in this small example; it does not create a fill. Real systems need an additional pending-order lifecycle, which this executable-review demonstration deliberately does not implement.
For the review ledger, use one row per clause with its original wording, accepted operator, required observations, availability boundary and reviewer decision. A clause about a company’s quality needs a dated source and a measurable mapping; it cannot inherit confirmation from a price-only export. A failed mapping blocks approval instead of becoming an ignored footnote. Keep signal-state behavior explicit too: this candidate buys only while flat and sells only while holding. Identical comparisons can therefore produce different actions from different initial positions, another reason to include the starting state in the observation handoff.
Run and inspect the independent example
Download the complete example, save R639.py and run python R639.py with Python 3.12 or later. It uses only the standard library and synthetic arrays. Assertions verify the two event indices and prices, rejection of vague and future conditions, missing-history behavior, invalid approval fields and nonfinite market input. No credentials, network service or model is required.
The Python JSON documentation explains why parsing a structured object is not equivalent to enforcing a schema: default decoding can accept repeated names and special nonfinite numbers. This example receives a Python dictionary and explicitly validates its contract. A real JSON importer must additionally decide how to reject duplicate keys and malformed or oversized input before constructing that dictionary.
The printed approval scope is USD:A. It does not mean every USD security, every exchange session or every account configuration is supported. Record the exact card alongside the output and keep the evidence references that justified each condition. If a reviewer changes the lookback or interpretation, regenerate the card and rerun the example as a new candidate rather than silently editing the approved record.
Review discrepancies without repairing the historical story
If the executable candidate disagrees with the original journal, preserve the disagreement. A recorded purchase may have depended on information absent from the export, a discretionary decision or a different execution convention. Do not tune the lookback until every selected winner matches and then describe the match as independent confirmation. Add the discrepancy to the card, identify the missing evidence, and distinguish a hypothesis about trader behavior from an accepted mechanical definition. Rejection can be the correct deliverable when the available records cannot determine an executable condition.
Hand off an executable candidate to observation
The completed deliverable is a rule card, an unresolved-field list and a human-confirmed version. Require every mandatory field to have either an accepted definition or a blocking unknown status. Optional commentary can remain descriptive, but it must not influence execution through an undocumented discretionary branch. Store rejected candidates as well as the accepted one so the search history remains visible.
Next, freeze a future observation window and collect all planned opportunities within the verified basket, including losses, no-signal rows and missing data. Keep virtual funds and positions separate from real holdings. Executability is one prerequisite for that study; it does not establish economic usefulness, guarantee five new winners, or authorize broker replication. Any scheduler, rule extractor or long-running product integration remains unverified here.
FAQ
Did this example use AI to extract the rule?
No. A human supplies the candidate. The program checks a small explicit vocabulary and timing contract, and records zero model calls.
Does human approval prove a profitable strategy?
No. Approval confirms a reviewable interpretation. Independent future observations and a funded cost-aware ledger are still needed.