The Autopilot overview reports three numbers next to each other at the top of the page. At the time of writing mine read PROFILES 11, ENABLED 10, MODE LIVE. Eleven configurations exist, ten of them are currently permitted to act, and the engine is not in paper. Read as an operations metric that is unremarkable. Read as a governance metric it is a question with ten separate answers, because the thing worth knowing is not how many profiles are enabled but which named person authorised each one, against what evidence, and whether that record still exists somewhere you could produce it.
Most firms already have this discipline for models. They have it for limits. They very often do not have it for the toggle that makes a model capable of sending an order, because the toggle looks like an operational convenience rather than a change. It is a change. It is arguably the only change that matters, since everything upstream of it is research and everything downstream of it is client money.
Activation is a change event, not a preference
Write the definition down before you write the process, because the definition decides how much the process has to cover. The version I would defend in a review is this: an activation is any action that makes a configuration capable of sending an order against live capital, or that materially changes what such a configuration is permitted to do.
That definition catches more events than the obvious one. Enabling a profile that was previously disabled is an activation. Resuming a profile that was paused for cause is an activation. Importing a configuration from outside the environment and enabling it is an activation. Repointing an existing profile at a different signal source is an activation, even though nobody touched an on switch, because the thing that was approved is not the thing that is now running. Raising a size parameter past a materiality threshold is an activation. Renaming a profile is not.
The reason to be this pedantic is that every one of those paths ends in the same place, which is an order hitting a venue with your firm's name on it, and only one of those paths tends to have a control on it.
What has to be closed before the switch is even offered
Pre-conditions work when they are binary and someone else can verify them without talking to the author. Vague ones ("adequately tested") produce arguments. These are the ones I would require, phrased so that the answer is yes or no.
- A written specification of the profile: which signal source it follows, which instruments, which venue and account, base size, and an explicit statement of what it will not trade. The profiles in my own list are named for exactly this, along the lines of Follow: NDX MTE 1day and Follow: XAG/USD MTE 4h, and a name that says the source and the timeframe is the minimum honest label.
- Evidence from a non-live run. The engine badges itself PAPER + LIVE and the overview counts paper profiles separately, which at capture showed 0 paper. A profile with no paper history has no evidence behind it, only intention.
- A stored backtest artefact, not a remembered one. The Backtest tab exists so that a run can be produced. The requirement is that the parameters, window and output are retained and referenced by the approval record, so a year from now the question "what did we look at" has an answer.
- Guardrail values recorded as numbers. The module offers risk guards, trailing stops and partial take-profits. "Guards configured" is not a control. "Maximum position notional 40,000 USD, trailing stop 3 percent, no more than four concurrent positions" is a control, because a second person can open the profile and compare.
- Named owner, named supervisor, named approver, all three different where headcount allows, and at minimum the approver distinct from the author.
- A written stop condition. The circumstances under which this profile gets switched off, decided while nobody is losing money, because that decision is much worse when taken during a drawdown.
What the second signature is actually checking
Dual control fails in practice when the second person is asked to re-approve the idea. They will not, because they did not do the work, and what you get is a signature that means nothing. Scope the second signature to verification instead, and it becomes cheap enough to do properly every time.
The approver has four jobs. First, open the profile and confirm that what is configured matches the specification document field by field, including the venue and the account, because a correct strategy pointed at the wrong account is the expensive version of this mistake. Second, confirm the guardrail values equal the documented numbers rather than approximately resembling them. Third, confirm the evidence referenced in the record actually exists and covers the configuration being approved, not an earlier variant of it. Fourth, and this is the one people skip, personally exercise the halt path.
That last check matters because the Autopilot action row carries several controls that sound similar and are not: PAUSE ALL, RESUME ALL, and EMERGENCY KILL SWITCH sit next to each other. The approver should know, from having done it rather than from having read about it, what each of those does to a position that is already open in this specific setup. An approval given by someone who has never used the stop is an approval of the entry only.
The record that has to outlive the person who made the decision
The module describes itself as keeping a full audit trail, and the History and Analytics tabs are where the trading record lives. Keep the distinction clear in your own head: that trail is about orders. The trail about authority is yours to maintain, and it should not live inside the tool it governs, because a system cannot be the sole evidence of its own change control.
The minimum fields are short. Profile identifier and configuration version. What changed, as a diff against the previously approved version. Author. Approver. Timestamp in UTC. The environment it moved from and to. Links to the evidence artefacts. And a review date, because an approval that never expires becomes a permanent entitlement attached to a strategy nobody has looked at since.
Set the review date deliberately short for anything new. Ninety days on first activation is defensible and cheap. If the profile is still worth running, re-approving it takes ten minutes and gives you a second data point about who owns it.
Where activation authority quietly leaks
Every firm I have seen build this control builds it around the enable action, and every leak I have seen goes around the side.
The bulk actions are the first gap. RESUME ALL restores whatever was paused, and if one of those profiles was paused for cause, a bulk resume has just reversed a risk decision without anyone deciding to. The fix is procedural rather than technical: record a reason with every pause, and require that anything paused for cause is resumed individually by the person who owns it.
Import is the second. There is an IMPORT action on the overview, which means configurations can arrive from outside the environment. Any path that can produce a live-capable profile without passing through your approval gate needs to be either restricted to named individuals or wired so that anything imported lands disabled by default.
Cloning is the third, and it is the subtlest, because a clone inherits the shape of an approved profile without inheriting the approval. It also inherits the reviewer's confidence, which is worse. Treat a clone as a new profile with a new record, however small the delta.
The fourth is parameter drift. Nobody doubles a size limit in one move. They raise it twenty five percent, twice, over six weeks, and each step is individually unremarkable. Set a materiality threshold in advance and apply it mechanically: any change to size, instrument universe, signal source, venue or a guardrail value re-triggers approval, and the diff is measured against the last approved version rather than against yesterday.