Change one strategy rule without changing the whole strategy

You want to loosen an entry threshold, not redesign your strategy. “Change RSI below 30 to below 35” looks like a small request. It stops being small if the result also changes the indicator period, doubles the order size, or turns an ordinary comparison into a crossing rule.

Treat an AI refinement as a proposed edit. Write down the one change you want, identify the behavior that must stay fixed, and compare the proposal with the saved baseline before applying it. A more polished description is not evidence that the executable rules stayed the same.

This walkthrough concerns a narrow rule change, not a search for a profitable RSI threshold. Neither 30 nor 35 is a recommendation. No performance comparison is claimed.

Make the unchanged parts explicit

The baseline for this demonstration is deliberately simple: SPY, daily RSI with a period of 14, a one-share long entry while flat when RSI is below 30, and a full-position exit when RSI is above 70. The specification requests completed regular-session daily candles, no short entries, no additions to an existing position, and no protective stop or profit target.

That omission of stops is a teaching constraint for the edit audit, not a suggested risk policy. The purpose is to make an accidental new rule easy to spot. Signal timing and market-order fill timing are separate: a signal on a completed daily candle does not establish a fill at that candle’s closing price.

Keep this short checklist beside the proposal. It defines the scope more clearly than “make the entry less strict.” The latter leaves room for a different indicator, a new filter, or a different interpretation of strictness.

If your starting description still contains vague terms, first use the plain-English strategy specification checklist. Refinement review is easier once the baseline has precise entries, exits, sizing, and timing.

Save a baseline you can compare

Open the strategy and inspect its actual rules, rather than relying only on the prompt that created them. Confirm the instrument selection and each condition and action. In a larger strategy, inspect supporting rules and custom variables too: the visible entry rule may depend on state established elsewhere.

Save the baseline before asking for the change. This gives you a known version to return to and a clear distinction between the saved strategy and a later draft. A saved strategy can still require validation before it is allowed to run; saving is not proof that its behavior matches your intent.

The baseline contained four rules: an entry, an exit, and two supporting rules. One tracks the daily clock; the other clears the exit-retry state once the position is flat. That state lets the exit rules keep trying to close a remaining long position without duplicating a pending sell order. Preserve these rules even though the requested threshold change sits in the entry.

The saved entry expression was RSI({length:14,interval:'D'})[1] < 30. Here [1] is the retained history reference for the prior, completed daily value. Changing that reference or the daily interval could change when the entry qualifies, even if the threshold still reads 35.

Record the complete baseline, including conditions below the visible part of the editor. A screenshot containing only “RSI below 30” misses the timing, pending-order checks, quantity, and exit that the review must protect.

Ask for the change and its boundaries

Use Refine strategy to make a bounded request. A shortened request template:

Change only the entry RSI threshold from 30 to 35. Keep daily RSI period 14, SPY, one-share long market entries while flat, the exit above 70, and all other conditions and actions unchanged. Do not add short entries, pyramiding, stops, targets, or new filters.

The recorded request was more specific: it also named the existing [1] history reference, pending-order guard, DAY duration, session and daily-clock guards, exit-retry state, and rule identities. Adapt the template to your baseline so “all other conditions” has a concrete checklist behind it.

Keep the original comparison too: “below 35” and “crosses below 35” describe different events.

Compare the proposal, including what did not change

A refinement proposal contains a before-and-after definition for review. Inspect both the changed rule and its surrounding configuration. The useful question is not just “Did 35 appear?” It is “Did anything else change that would alter an order or the data used to decide it?”

This is a semantic checklist, not a requirement that every display label stay identical. A renamed rule can leave behavior unchanged. Conversely, a tiny expression change can alter timing or quantity. Follow references into other rules if the proposal changes a shared variable or helper condition.

In this proposal, the entry threshold was the only executable-rule change. But the comparison also exposed a documentation problem: three explanatory notes disappeared, while the written description still said 30.

The following is an author summary of the complete retained definition comparison, not another product view. The proposal and the final saved version had the same outcome:

Separate three review decisions:

• Trading behavior: if an unexpected change alters the data, timing, orders, or safeguards, choose Discard changes and name the mismatch in the next request.
• Explanatory notes: a deletion may leave execution unchanged while making the strategy harder to understand later; keep the useful explanation in your strategy documentation or reject the deletion.
• Written specification: reconcile stale wording with the approved rules before treating the strategy as ready for its next test.

This demonstration applied and saved the proposal with those documentation issues still present. It did not restore the notes or correct the description. That is a limit of the example, not a finished specification to copy: the executable edit matched the request, but documentation still needed attention.

If you encounter Suggested Strategy Edits, keep that text workflow separate. Applying a suggested passage changes the written description; it does not update executable rules. Check the description and rules together after either kind of edit.

Apply to draft, then save deliberately

Apply to draft accepts the reviewed proposal into the editable workspace. Save records the selected version as the saved strategy. These are separate decisions; an accepted draft is not automatically the version you intended to use in a backtest.

After applying, inspect the resulting rules again and save the intended revision. If the draft changed while the proposal was open, the review asks you to discard the stale proposal and request a new one.

After Apply to draft, the saved version was still the baseline. After Save, the saved entry used 35; the three notes were absent and the original description remained. Saving persisted the reviewed result, including its unresolved documentation.

A correct edit still needs a fair test

Changing a threshold can alter which trades occur, how long positions stay open, and whether later entries are possible. A verified single-rule edit does not tell you that the revised strategy is better. It only makes the next comparison interpretable.

If you test the two versions, hold the instrument, historical window, starting capital, order sizing, fees, slippage, session settings, and execution settings constant. Retain both outcomes, including an empty or losing result. Check at least one changed decision in the trade/chart history before attributing a performance difference to the threshold.

For the next edit, start smaller than “improve this strategy”: choose one rule, save its baseline, and write the exact behavior that must remain unchanged. Then open the AI strategy builder guidance and review the proposed rules before saving your next version.