Reference
Audit trail and versioning
What the system records for every decision, how each record is version-stamped, and how a trade from months ago is reconstructed exactly as it was decided.
Last reviewed: 25 August 2026
Why this exists
The usual complaint about automated trading is that it is a black box: money moves and nobody can say why. That complaint gets sharper, not softer, when a language model is involved.
So every decision this system makes is written down with the reason attached, and with enough version information to reconstruct the conditions later. Not a log you grep in an emergency — a record you can read.
What is recorded
| Record | Captures |
|---|---|
| Risk decision | The proposal, the verdict, and the specific rule that produced it — including for rejections. |
| Order event | What was dispatched, what the broker did with it, and any broker error code returned. |
| Position event | Every management action over the life of the trade: break-even, ratchet steps, partial close, emergency exit. |
| Approval | Where a human approved or rejected a proposal, and that it was a human decision. |
Version stamping is the part that matters
A record saying “rejected: daily loss limit” is not much use in six months if the daily loss limit has been changed twice since. So each record carries the versions in force when it was written:
- The software version of the component that made the decision
- The git revision that software was built from
- The risk policy version being enforced
- The position policy version being applied
That is what turns a log line into something reproducible. Given the same recorded inputs and the same stamped policy version, the deterministic C++ engine produces the same decision — which is a property a prompt-based system cannot offer.
Where to read it
The console exposes this as trade history and a decision log rather than as raw tables. Every rejection shows the rule behind it, which is the view worth checking regularly: it tells you whether the limits you configured are the limits you meant to configure.
Rejections are the interesting records
Demo and live are kept apart
Demo, paper, simulation and backtest activity are recorded separately from live trading and are never mixed into live figures or billed. A performance fee is calculated only from completed positions on live accounts — see Billing.
What we do not claim
An audit trail proves what the system decided and why. It does not prove the decisions were good ones, and it is not a track record. We do not publish a performance history because we do not have a verified live one to publish — the FAQ says more about why we would rather show you nothing than show you a backtest dressed as a forecast.