WEBVTT

00:00:01.300 --> 00:00:04.925
Now put the pieces together. At a high level, an automated strategy

00:00:04.925 --> 00:00:08.550
watches information, evaluates its conditions, checks whether an action is allowed, and

00:00:08.550 --> 00:00:12.175
may submit a request. After that, the response and any resulting position

00:00:12.175 --> 00:00:15.800
or transaction need to be inspected. This sequence is the useful public

00:00:15.800 --> 00:00:19.425
explanation. You do not need a creator's private formulas or exact thresholds

00:00:19.425 --> 00:00:23.050
to understand the difference between a possible action and a completed one.

00:00:23.550 --> 00:00:27.298
Watching is the information stage. Evaluating is the decision stage. The strategy

00:00:27.298 --> 00:00:31.045
considers the information according to its defined behavior. It may decide to

00:00:31.045 --> 00:00:34.793
wait. It may identify something worth acting on. The conditions can change

00:00:34.793 --> 00:00:38.541
before anything is completed. This is why seeing a promising market, or

00:00:38.541 --> 00:00:42.288
seeing an item in a candidate view, does not mean that the

00:00:42.288 --> 00:00:43.850
account has already bought it.

00:00:44.350 --> 00:00:48.125
Next come the relevant checks. These can involve strategy availability, enabled state,

00:00:48.125 --> 00:00:51.901
the account and mode, funds or allocation, connection capability, and the current

00:00:51.901 --> 00:00:55.676
trading controls. Think of them as questions that must be answered, not

00:00:55.676 --> 00:00:59.452
as a countdown toward an inevitable purchase. A strategy can have a

00:00:59.452 --> 00:01:03.227
reason to act while the account does not currently have the capacity

00:01:03.227 --> 00:01:04.800
or permission for that action.

00:01:05.300 --> 00:01:09.195
A request is the instruction sent for processing. In Paper, the activity

00:01:09.195 --> 00:01:13.091
is handled in the practice context. In Live, the authorized exchange route

00:01:13.091 --> 00:01:16.986
is involved. Keep those contexts separate when reading results. The important point

00:01:16.986 --> 00:01:20.882
in either case is that requesting and completing are different events. A

00:01:20.882 --> 00:01:24.777
loading indicator, a changed button, or a brief notification does not replace

00:01:24.777 --> 00:01:26.400
checking what was actually recorded.

00:01:26.900 --> 00:01:30.500
A fill is an executed amount of an order. The amount, price,

00:01:30.500 --> 00:01:34.100
fees, and timing may differ from what you expected while looking at

00:01:34.100 --> 00:01:37.700
a quote. Some outcomes may be incomplete or unsuccessful. Look at the

00:01:37.700 --> 00:01:41.300
fields and status that the app actually provides. Do not describe a

00:01:41.300 --> 00:01:44.900
submission as a completed purchase until the available result supports that description.

00:01:44.900 --> 00:01:47.900
When information is incomplete, keep that uncertainty in your explanation.

00:01:48.400 --> 00:01:52.112
Here is a fictional example. A strategy identifies a market, but no

00:01:52.112 --> 00:01:55.824
position appears immediately. You inspect the correct account and mode, then look

00:01:55.824 --> 00:01:59.536
for the relevant result in Transactions and Portfolio. If the result is

00:01:59.536 --> 00:02:03.248
still uncertain, investigate before placing another order by hand. Repeating an action

00:02:03.248 --> 00:02:06.960
simply because you have not seen its outcome can create a second

00:02:06.960 --> 00:02:09.125
exposure rather than clarify the first one.

00:02:09.625 --> 00:02:13.988
Once you find a recorded result, connect it to the strategy, account,

00:02:13.988 --> 00:02:18.351
market, and time involved. A similar-looking transaction from yesterday is not confirmation

00:02:18.351 --> 00:02:22.714
of today's request. A position owned by another strategy is not confirmation

00:02:22.714 --> 00:02:27.078
either. Those identifying details let you follow the actual sequence instead of

00:02:27.078 --> 00:02:30.350
constructing a story from unrelated numbers on different screens.

00:02:30.850 --> 00:02:34.635
For your checkpoint, describe the sequence in five plain steps: observe, evaluate,

00:02:34.635 --> 00:02:38.419
check, request, and verify. Then identify where waiting could occur. It can

00:02:38.419 --> 00:02:42.204
happen before a request, and uncertainty can remain after a request. Understanding

00:02:42.204 --> 00:02:45.988
that sequence makes automation easier to supervise because you can ask which

00:02:45.988 --> 00:02:49.773
step you are looking at instead of asking only why the robot

00:02:49.773 --> 00:02:51.350
has not bought something yet.