How do you write an AI crypto trading rule without ambiguity?

Why is “buy a strong crypto coin on a dip” not a complete strategy?

The sentence leaves the asset universe, strength benchmark, pullback reference and decision clock undefined. Strength could mean a rising USD price, a rising BTC ratio or a high turnover rank. A pullback could be distance from a past high or a return to an average; those produce different eligible opportunities.

Write measurable alternatives before choosing one. For example, “completed daily close above SMA200” is not the same as “EMA20 above EMA50 on 4h,” and “five percent below a 20-bar high” is not a touch of confirmed support. A future-confirmed swing low cannot be used before its confirmation time.

Separate the view from the permission to trade: a bullish hypothesis can persist while the entry trigger is absent or costs are too high. The user must approve which definition expresses the intended strategy; the model must not choose whichever produces the best historical result.

What belongs in an auditable AI trading rule contract?

A complete contract links an observable input to an authorized action and an explicit failure response. Record the product and venue, selected universe, interval, completed-bar and known-at times, eligibility, entry, order type, expiry, sizing, stops, targets, every other exit and version. Missing data is a state, not a zero.

The downloadable template is a generic review document, not a directly executable API payload. A hypothetical EMA9/21 BTC long example uses the next bar open, $500 maximum notional at 1×, a 2% stop, 4% target, opposite-cross exit and 48-hour cap. Those values illustrate a fully specified rule; the existing experiment of that rule lost money and should not be copied as a recommended strategy.

Freeze assumptions about simultaneous stop/target touches, gap handling and unfilled orders. If your data cannot reconstruct tick order, document the convention and the sensitivity you will need. A stop level is an intended risk reference, not a guaranteed execution price.

How do margin, leverage, notional and risk differ in the instruction?

Margin is committed collateral; notional is price exposure; initial estimated stop risk is the loss to the stop plus modeled costs. A hypothetical $500 margin at 20× creates $10,000 notional, so a 1% adverse price move is about $100 before fees—not $5.

State both the order cap and the portfolio cap. Several orders individually under $500 can still create correlated risk beyond the account budget. Define whether adding to a trade changes its total permitted margin and whether a reduce action frees risk only after the simulated or real fill.

A model can propose size within an approved range. The code must enforce the range and cannot accept a confident narrative as a waiver. Real futures liquidation needs venue-specific maintenance margin and price rules; a simple notional calculation does not supply them.

Verify: Leverage and liquidation risks

How do you detect when AI silently changes your strategy?

Compare the original request with the interpreted contract field by field. Label each difference as a user requirement, an explicit user-approved default or an unsupported clause. If a new exit, market or capital interpretation was not requested, ask for approval before a run.

A request with no maximum holding period should not become an approved four-hour strategy just because a parser needs a value. Similarly, “stop at loss of $100” is not a 2% stop until product, size and leverage make that mapping explicit. Store both texts and the approved contract so later results can be traced to the actual rule.

The historical EMA study documents an opposite-cross exit that originally appeared in code but not in the first prose protocol. Its correction is retained rather than hidden. That concrete mismatch is why an experiment should show all effective exits, not just a clean final description.

Verify: Published EMA experiment and its protocol correction

Which hand-worked cases must pass before a backtest?

Check at least one satisfying case, one rejected case and one missing-data case for each critical condition. For a crossing, compare prior and current completed values: being above an average on both bars is not a new cross. For execution, the order cannot fill before the signal became known.

Use a small test sheet before a long run: an unfinished bar must not signal; missing or stale data must block entry; a duplicate order ID must not create another trade; an unsupported clause must be returned for clarification. If stop and target share a candle, use the frozen tie rule rather than the profitable order.

These checks test contract interpretation and accounting, not strategy profitability. Passing them authorizes a historical examination of the approved rules; later untouched and prospective evidence still matter.

Will CoinNudge’s strategy test run this entire generic contract?

Not automatically. The current workbench supports BTC on one selected 5m, 15m, 1h, 4h or daily interval with EMA cross, RSI reversion, channel breakout, standard MACD cross or Bollinger reversion families. It uses code replay after interpretation review. A generic contract can contain more requirements than that schema supports.

The parser has explicit timeframe, family, direction, indicator parameters, stop/target, margin, leverage and maximum-hold fields, plus unsupported requirements. It does not imply support for multi-coin selection, arbitrary custom code, order-book queues or a complex dynamic ladder. A clarification is the correct outcome for a strategy outside that range.

Before testing, sign in, review the translated strategy and reported unsupported items, then confirm the actual coverage and gaps of the selected interval. Do not use a cleaner supported approximation unless you explicitly accept the changed question.

Verify: Inspect supported historical strategy testing · Backtest workflow and validation boundaries

How should you change a contract without rewriting the experiment?

Give each material change a new contract version, reason and comparison plan. Keep the old specification, data hash, output ledger and failure record. Changing an exit after seeing losses produces a new hypothesis, not a corrected winning version of the original result.

Predefine the comparison on the same eligible opportunities and costs, reserve later validation and disclose all attempted variations. For runtime models also retain identifier, prompt version, unavailable responses and inference costs. Current-model replay of old data is retrospective behavior, not proof that those decisions occurred then.

Use the template as a review step before the backtest owner page. The template chooses what should be tested; the backtest determines what this exact approved rule did under its assumptions.

Verify: Download the generic contract template · Evaluate the same opportunities with and without AI

Frequently asked questions

Sources and verification

• CoinNudge published BTC rule and correctionExisting dated study; not a new strategy.
• Generic review contractAuthored template, not an executable API promise.

Explore a bounded AI trading workflow.

Use the paper accounts to inspect recorded behavior; supported historical strategy tests require an account and interpretation review.