the interval between doing it and protecting it

Opening a position and attaching its protection were two separate requests. The gap between them was real, of seconds order, and entirely unmeasured: nothing in the system described it, so nothing bounded it. When the question was finally asked directly — how long is a fill unguarded — the honest answer was that nobody knew.

The repair was not to make the gap smaller. It was to remove the gap as a category: both fields now travel inside the single request that opens the trade, so the protection exists at the instant the fill does, in one round trip. That is a design change rather than an optimisation, and it is only true on the path that supports it.

The counterparty, it turned out, silently discards those inline fields on one of its two order paths. So the code verifies rather than assumes. After every stop-bearing open, the live position record is read back and checked. If the attach landed, the path was atomic. If it did not, the protection is applied immediately and the measured interval is written into that trade's record. If that also fails, the fill is closed rather than held.

The second rule is the one that matters. An unprotected position is not a smaller version of a protected one; it is a different object, and the system refuses to keep one.

What it proves: the window was closed by construction, and where construction could not close it, the exposure is measured and the failure is undone instead of logged.