Why DXY Can Never Block a Trigger

The MODEL-1 indicator dashboard has a DXY row. It shows whether the dollar index is building a mirrored setup in the opposite direction — since both EURUSD and GBPUSD price the dollar as the quote currency, a short wants DXY rising at the same time, a long wants it falling. It's a simple correlation check: when two markets say the same thing from opposite sides, the signal stands on firmer ground. This week I found out, the hard way, how easily a check like that turns into something I never meant it to be — a veto.

Context that took more authority than it should have

The indicator settings have a toggle called "Require DXY confluence" — off by default in the code, but switched on in the layout saved on the chart. It was checked only at the moment of fill, and it required a fully confirmed mirrored model on the dollar index, not just the directional "rising ↑" or "falling ↓" arrow shown one row above it.

In practice, that looked like this: the euro completed a valid retest of the Model-1 level, Confirmation was green, the rest of the checklist looked complete — and the indicator still sat on "limit @ M-1" instead of flipping to TRIGGERED. The dollar index had the right direction at that moment; it just hadn't formally closed its own mirrored model yet. A signal that was valid under every other rule was waiting on confirmation from something that was never supposed to have the power to stop it.

The fix: DXY back to an informational row

The decision was easy once I saw what was happening: DXY is allowed to describe context, never to block it. I turned "Require DXY confluence" off, the history recalculated, and the same trade flipped back to TRIGGERED retroactively. Verified on the EURUSD short from 27 July — without the fix, the indicator would still be showing an unmet setup that, in reality, had gone through exactly by the rules.

One more detail surfaced along the way, worth mentioning on its own. DXY can flip over time — a candle can close on one side even though it briefly touched the other intrabar. A screenshot taken after the trade was already managed could show a different state of the dollar index than the one that was true at entry, making it look like I'd ignored context that actually supported the trade at the time. The dashboard now keeps a separate DXY @entry row that locks in the moment of entry and never changes afterward, while the main row keeps living in real time. Without that distinction, a retrospective look at a trade could read as dishonest without actually being dishonest.

Where context stops

The Strategy page says this directly: the extra context checks aren't a filter that forbids a trade — they only flag it, and the decision stays with me. DXY belongs in the same category as relative strength or the D1 bias line, which greys out to "not relevant" when direction alone no longer adds anything. They describe the quality of a setup. They don't decide whether the setup exists.

That boundary is fixed in the settings now, but not entirely finished in the code — the open question is whether to cut DXY out of the trigger condition in code entirely, so TRIGGERED never depends on a single toggle, even if someone (say, me) switches it back on by accident later. For now the fix is knowing where the toggle is and what it's set to, which is reliable right up until the day I forget. It isn't a finished solution, it's a fix that produced another open question — which is what building your own tool looks like when the mistakes don't get swept under the rug, they get written down here instead.