RX5Acceptance Tests
The proposed AT01–AT19 acceptance pack defines required outcomes before release. These are test specifications; no executions, passing results or certified builds are claimed.
Proposed specification · Implementation and test evidence pending
19 Defined Scenarios · Evidence Pending
The supplied review dated 9 September 2026 defines this test pack. A scenario becomes a demonstrated result only when its exact fixture, build, environment and expected-versus-actual output are reviewed.
Swipe horizontally to view all columns.
| Status | Meaning |
|---|---|
| Planned / evidence pending | The scenario is specified; there is no reviewed execution result. |
| Blocked | A named prerequisite, fixture, permission or implementation is missing. Record the owner and resolution. |
| Failed | Observed behavior differs from the required result. Retain the failure and remediation before rerunning. |
| Passed for stated scope | A reviewer accepts dated evidence for exact versions, inputs, limits and environment. This does not certify unrelated configurations. |
AT01–AT04 · Isolation and Resource Limits
Exercise hostile runtime and compiler inputs while measuring their effect on other tenants and the order engine.
Swipe horizontally to view all columns.
| Scenario | Required pass result | Evidence to retain |
|---|---|---|
| AT01 · Cross-tenant accessPlanned · Evidence pending | A bot cannot read another account's market entitlements, logs, secrets, orders, filesystem or memory. | Tenant-pair fixtures and denied-access logs across host APIs, process and storage boundaries. |
| AT02 · Infinite loop and allocation floodPlanned · Evidence pending | CPU or memory quota halts the offending instance while other broker workloads remain within their agreed service budgets. | Limit configuration, termination event and measurements for unaffected workloads. |
| AT03 · Host API exhaustionPlanned · Evidence pending | Slow requests, oversized logs and leaked resource handles hit independent quotas without blocking the order engine. | Host-call deadlines, quota traces, resource cleanup and order-engine measurements. |
| AT04 · Build-time attackPlanned · Evidence pending | Build scripts and procedural macros cannot reach host credentials, external networks or sibling builds. A timeout terminates the worker. | Isolated build fixtures, denied-network/credential traces and timeout cleanup. |
AT05–AT08 · Recovery, Client State and Risk
Prove how intent, orders and positions behave across acknowledgement gaps, disconnections, stop requests and missing data.
Swipe horizontally to view all columns.
| Scenario | Required pass result | Evidence to retain |
|---|---|---|
| AT05 · Restart during acknowledgement gapPlanned · Evidence pending | Execution reports are reconciled before a retry; one user intent never produces duplicate live exposure. | Durable request IDs, restart trace, provider reports and reconciled orders/ledger. |
| AT06 · Mobile disconnectionPlanned · Evidence pending | An eligible broker-hosted bot continues under server risk controls. Reconnection reflects authoritative state and never falsely reports that the bot stopped. | Disconnect/reconnect timeline, runtime heartbeat and matching client/server state. |
| AT07 · Stop and kill switchPlanned · Evidence pending | Each documented stop mode gives its specified order/position outcome. No new intent passes after server-side stop confirmation. | Stop receipts and before/after orders and positions for every stop scope. |
| AT08 · Stale or missing quotesPlanned · Evidence pending | New orders are blocked or follow an explicitly approved fallback. The event and user warning are retained. | Stale/gap fixtures, risk decisions, approved fallback and warning record. |
AT09–AT14 · Migration and Reproducibility
Bind every compatibility conclusion to authorized source, exact language/toolchain versions, licensed fixtures and declared numerical tolerances.
Swipe horizontally to view all columns.
| Scenario | Required pass result | Evidence to retain |
|---|---|---|
| AT09 · Compiler subsetPlanned · Evidence pending | Unsupported constructs produce blocking diagnostics tied to source lines, without silent substitution of different behavior. | Versioned supported-subset matrix and expected/actual diagnostic fixtures. |
| AT10 · Source-rights gatePlanned · Evidence pending | Binary inputs, missing licensed dependencies and protected-source retrieval are rejected. Accepted source retains origin and licence records. | Accepted/rejected input fixtures, dependency rights and provenance records. |
| AT11 · Differential semanticsPlanned · Evidence pending | Fixture signals, orders and state match the declared tolerances on identical data/settings. Deviations stay visible and prevent unsupported equivalence claims. | Original/generated traces, declared tolerances and reviewer decisions. |
| AT12 · Pine timing edge casesPlanned · Evidence pending | Fixtures cover bar-close and intrabar behavior, rollback, var/varip, higher timeframes, missing values, sessions and lookahead. | Versioned fixtures showing supported behavior or explicit blocking diagnostics. |
| AT13 · MQL order edge casesPlanned · Evidence pending | Fixtures cover tick coalescing, partial fills, transaction reordering, hedging/netting and missing includes. | Event and position traces with include-resolution and unsupported-feature diagnostics. |
| AT14 · Backtest reproductionPlanned · Evidence pending | Fixed input hashes, runtime version and seed reproduce the order sequence and P&L within a documented numerical tolerance. | Two independently repeated run bundles, hashes and machine-readable comparison. |
AT15–AT19 · Entitlements, Policy and Claims
Validate the complete activation, payment and publication workflow with approved commercial and jurisdiction-specific rules.
Swipe horizontally to view all columns.
| Scenario | Required pass result | Evidence to retain |
|---|---|---|
| AT15 · Marketplace revocationPlanned · Evidence pending | A revoked package cannot newly activate. Existing deployments follow the disclosed incident policy and notify affected traders. | Revocation record, activation rejection, notices and open-position handling trace. |
| AT16 · Billing and eligibilityPlanned · Evidence pending | The correct broker price and renewal terms are shown. Duplicate webhooks never duplicate billing, and ineligible rewards are blocked. | Offer/consent version, webhook replay and eligibility fixtures. |
| AT17 · Store purchase restorationPlanned · Evidence pending | Eligible entitlements restore across devices; refund and revocation events reconcile. Regional flows match the approved payment/entitlement matrix. | Approved regional matrix and purchase, restore, refund and revocation traces. |
| AT18 · Jurisdiction policyPlanned · Evidence pending | Restricted UK/EU retail CFD test cases cannot receive prohibited campaigns through UI, API, introducing-broker or manual-credit routes. | Approved jurisdiction/client/product fixtures and denials through every grant path. |
| AT19 · Claims auditPlanned · Evidence pending | Every published integration, live feature, app-store badge, performance number and comparison has dated evidence and an accountable owner. | Claim-to-evidence inventory with exact scope, version, reviewer and approval date. |
Campaign and Jurisdiction Controls
AT18 requires approved jurisdiction policy fixtures. These campaign controls come from the supplied review and do not determine legal eligibility.
Swipe horizontally to view all columns.
| Control | Requirement |
|---|---|
| Bonus ledger | Separate bonus-credit ledger from cash and client money; show withdrawability and expiry. |
| Dual approval | Two-person policy approval and immutable campaign version. |
| Eligibility checks | Date/residence/entity/product/group eligibility and sanctions/age checks where applicable. |
| Vested balances | No retroactive reduction of vested balances or unclear turnover conditions. |
| All grant routes | Policy engine covers direct and IB campaigns, coupons, manual credits and API grants. |
| Hosting rewards | Free-hosting rewards reviewed separately; do not assume information/research-tool exclusion applies to automated execution. |
Keep a Reviewable Result for Every Run
Preserve failed and blocked runs as well as passes. A changed compiler, SDK, runtime, adapter, entitlement rule or risk configuration must trigger the relevant regression cases.
Swipe horizontally to view all columns.
| Field | Required detail |
|---|---|
| Identity and scope | Test ID, unique run ID, scenario revision, date, accountable engineer/reviewer and applicable broker/entity/account class. |
| Build and environment | Source/package hashes, compiler/SDK/runtime/adapter versions, OS/hardware, dependency lock and broker/risk configuration. |
| Inputs and expected output | Licensed fixture identity and hashes, event sequence, seed, settings, numerical tolerance, agreed service budgets and expected transitions. |
| Observed output | Logs, order/position/ledger state, quota/risk decisions, timings and machine-readable differences, with secrets and unrelated tenant information removed. |
| Decision and follow-up | Actual status, reviewer sign-off, evidence location, exclusions, outstanding defects and the conditions requiring a rerun. |