What Automated Software on a Chart Is Allowed to Do

Running and permitted are two different states

A program attached to a chart can be fully loaded and completely unable to trade. It reads incoming prices, updates its own state, reaches its own conclusions, and then has every order it tries to send refused before that order leaves the machine. Nothing about the chart looks wrong while this is happening.

The gap between running and permitted is the most useful thing to understand about automation on a retail platform, because most of the stories that begin with a strategy having done nothing overnight live inside it. The program was not broken and the market was not quiet. It was simply not allowed to act.

Permission is a chain, not a switch

Whether attached software may send an order is usually decided by more than one setting. There is a terminal-wide switch, a per-program setting, and on some accounts a broker-side permission as well. An order goes through only when every one of them allows it, which makes permission a chain: one closed link stops everything, and all of them produce the same outward appearance.

So saying that automated trading has been switched on is an incomplete statement — it names one link. Establishing that a program can act means establishing that each of them says yes at the same moment, and the account-level one is not visible from the terminal at all. It is a fact about the account, answered by the broker rather than by the software.

The refusal is silent exactly where you are looking

When permission is missing, the order is refused by the terminal before it reaches the server, so it never becomes anything the account can show you. There is no rejected order in the history, because there was no order. The chart carries on drawing, the program carries on running, and the only record of what happened is in the platform’s own log.

That is why permission is worth treating as a state to be checked rather than a setting to be configured once. It can be changed by an update, by a restart, by opening a saved layout, or by a change on the account, and none of those announce themselves. The log is the only surface on which the difference between deciding not to act and not being allowed to act is visible at all.

A program that runs once and a program that stays

Platforms generally distinguish two kinds of attached program, and the distinction is lifetime rather than language. Both are written the same way and both talk to the terminal through the same interface. One is invoked, does its work against the state of the account as it is at that moment, and stops. The other stays loaded and is invoked again on every incoming price.

Almost every practical consequence follows from that. A run-once program suits a job defined by the present moment — closing everything, placing a prepared set of orders, writing the contents of a chart out to a file — because it does not need to know what happens next. It also cannot manage what it placed, since by then it is no longer there. Anything that has to respond to later prices has to be the kind that stays, and choosing the wrong one produces a program that works perfectly and then does nothing further, which reads as a failure and is not one.

Its silence is not a report

Attached software acts on the prices the terminal delivers to it. While the connection is down no prices arrive, so nothing is computed and nothing is sent — and from the outside that is indistinguishable from a program that received everything and concluded that there was nothing to do.

The two are different in every way that matters and identical on screen. Separating them means going to the record: what the log says the program was doing, and whether the account shows anything on the other side of it. Neither the chart nor the program’s own display on the chart can settle it, because both are drawn from whatever the terminal has, which is exactly the thing in question.

A label on an order is not an identifier

Most platforms let an order carry a short piece of free text: a comment sent with the order, which travels to the server and generally appears against the resulting position and in account statements. It is genuinely useful for that — reading a statement afterwards and being able to see which rule or which program placed something.

What it is not is a field software can rely on. The text is short and longer text is truncated. Brokers and servers may append to it or replace it. And a position closed by a stop or by an automatic process often carries a comment written by the server rather than the one it was opened with, so the label on the way out is not necessarily the label that went in. Anything that has to be read back reliably belongs in a field intended for identification, with the comment left as what it is — a note for a person reading a statement later.

What a description of an automated run leaves out

Any claim about what a program did over a period is a claim about a particular build of a terminal, a particular server, a particular set of permissions and a particular chart, and it is only as reproducible as those are. A description that omits them has not said enough for anyone to check it, including the person who wrote it.

One thing can be checked without any of that, which is internal consistency. The platform’s log and the account statement are written by different systems and record the same events from different sides. Where they agree, something happened the way it was described. Where they disagree, or where the log holds refusals the statement has no trace of, the answer is in the gap between them. That comparison is unglamorous, and it is the only part of the picture that does not depend on trusting the description.