Strategy testing and trading software · Germanycontact@stratcorealpha.com · DE
Free Strategy Rule Check
Engineering notes

Engineering note · Repair acceptance

Scope a Trading Bot Repair Without Changing the Strategy

“Fix the EA” is too broad to accept. A useful repair brief names one failed behavior, the existing behavior that must remain and the changes excluded from the delivery. That boundary protects the buyer from a working patch that quietly becomes a different strategy.

  1. 01Identify the failed case
  2. 02Freeze the baseline
  3. 03Protect an unaffected case
  4. 04Exclude a new feature
Proposed repair acceptance checks. No customer repair, trading result or completed test is claimed here.

Restoring a rule is different from choosing a new one

A missing entry might violate a written rule. It might also reflect a session filter whose intended behavior was never agreed. The first is a defect against a baseline. The second is a rule decision. Keep unresolved decisions visible rather than letting a developer choose the most convenient chart outcome.

Write the current source revision, platform version, inputs and shortest reproduction. Add one expected decision with a timestamp and the observed decision. If authorized source is missing, the task is not a normal source repair; a separate rebuild needs its own specification.

Use three columns: fix, preserve and exclude

Fix describes the one difference the patch must make. Preserve names the rules it must not change, such as bar timing, position sizing, valid no-trade filters and existing exits. Exclude names tempting additions such as a new indicator, dashboard or parameter search.

For example, a repair may restore one permitted closed-bar entry while preserving a blocked out-of-session entry. Adding a new intrabar mode is excluded. Those are hypothetical acceptance decisions, not measured results from a delivered EA.

Keep exclusions observable. “No strategy changes” is hard to review if the handoff contains only a compiled file. Retain the original and changed source, a concise change list, the inputs and the test evidence for the agreed cases.

Acceptance needs a negative control

The original failed case checks that the intended difference exists. An unaffected case checks that protected behavior still exists. An excluded-feature case checks that the delivery did not expand beyond the agreed task. Record actual outcomes for each case instead of calling the whole EA fixed after one screenshot.

Passing those cases proves only the named software boundary in the tested environment. It does not certify every broker, every market condition or future trading performance. Keep a newly found unrelated defect separate from the accepted repair and quote another scope only when needed.

Three acceptance checks

Proposed tests, not executed customer results. Record actual outcomes separately.

Original failure

Input: Repeat the frozen incident with the original inputs and the reviewed patch.

Expected: The named behavior changes to the agreed decision, with a retained trace and source revision.

Protected behavior

Input: Repeat an unaffected no-trade case covered by an existing gate.

Expected: The gate still prevents a request and records the same reason.

Excluded feature

Input: Inspect an explicitly excluded mode or feature and the source change list.

Expected: The patch does not add or enable it. A requested new rule remains a separate decision.

Sources and related guides

Start with your own rules

Use the free Rule Check to write the expected behavior and one protected no-trade case. It is a requirements check, not a claim that the EA works.

Define your repair boundary →

Trading risk disclosure

Futures and forex trading contains substantial risk and is not for every investor. An investor could potentially lose all or more than the initial investment. Risk capital is money that can be lost without jeopardizing one's financial security or lifestyle. Only risk capital should be used for trading, and only those with sufficient risk capital should consider trading. Past performance is not necessarily indicative of future results.

Hypothetical performance disclosure

Hypothetical performance results have many inherent limitations. No representation is being made that any account will or is likely to achieve profits or losses similar to those shown. There are frequently sharp differences between hypothetical performance results and the actual results subsequently achieved by any particular trading program. Hypothetical results are generally prepared with the benefit of hindsight, do not involve financial risk, and cannot completely account for the impact of financial risk in actual trading. Market conditions, the ability to withstand losses, and adherence to a trading program can all materially affect actual results.

NinjaTrader trademark disclosure

NinjaTrader® is a registered trademark of NinjaTrader Group, LLC. No NinjaTrader company has any affiliation with the owner, developer, or provider of the products or services described herein, or any interest, ownership or otherwise, in any such product or service, or endorses, recommends or approves any such product or service.

Testimonials, when shown, may not represent the experience of other clients and are not a guarantee of future performance or success. Virtual-currency trading carries additional risks. See the CFTC customer advisories. Read the full financial risk disclaimer.