Write an ETF rule card before asking for a backtest
You do not need to write code to specify a rule, but you must decide what it means. S04 makes those choices visible; S05 calculates only after the rule and data conditions are satisfied.
Start from an actual sentence
Our synthetic user says: “Keep ETF_A and ETF_B at 60/40, restore weights each month-end, and compare with holding equal weights.” Neither identifier is a real fund. This sentence leaves signal timing, execution, costs and the calendar unresolved.
| Rule field | Proposed teaching choice | Must be confirmed |
|---|---|---|
| Assets/weights | ETF_A 0.6; ETF_B 0.4 | Identity and scope |
| Signal | After month-end valuation close | Calendar definition |
| Execution | Next valuation close | New weights earn later returns |
| Friction | 10 basis points per side, assumed | Cost model, not broker quote |
| Cash | Zero return; no borrowing | No leverage/shorting |
| Benchmark | Equal-weight buy and hold | Same start and initial friction |
The Investor.gov ETF overview explains the investment vehicle; the choices above are our teaching model, not official ETF trading rules.
Produce a readable draft first
The current 0.1.0 S04 package requires Python 3.12 for its bundled specification tool, just as S01/S02/S05 require it for their fixed tasks. The teaching tool uses only the standard library and no network; no market feed is needed to prepare a draft. If the runtime is missing, stop tool execution and prepare the documented isolated environment separately. Producing a specification with this tool does not authorize or run a backtest.
Ask S04: “Turn my sentence into a strategy card. Show undecided fields and the data requirements. Do not run a backtest or mark confirmed on my behalf.”
Read the card as a sequence: information available after close, next valuation execution, later return exposure. If the card grants the same close’s return to a signal formed after that close, the rule is inconsistent. Define a full calendar rather than using the last input row as month-end.
S04 should provide a human card, structured rule, data requirements and a confirmation record. The user can review prose rather than edit JSON. Confirmation records the actual accepted text, time and rule digest; changing the rule returns it to pending confirmation.
A useful refusal
“Buy when it feels strong” is not an executable momentum definition. The first calculation family permits fixed-weight monthly rebalancing or a specified simple momentum rule, not arbitrary generated trading logic. Unsupported ideas can still receive a useful specification and explicit limitation.
Acceptance and next step
Check weights total one, assets are fixed, costs and benchmark are visible, and execution is unambiguous. Then collect total-return indices, currency and calendar in a manifest. No market feed is needed to finish the draft. A clear unresolved item is better than an impressive result based on an unapproved assumption.
FAQ
Can I confirm a rule without price data?
Yes. Specification can be completed independently; calculation still needs valid data.
Can the model choose my missing costs?
It can propose an explicit assumption for review, not silently treat it as accepted.