What the author really built (decoded)
“Entropy Bias = standard deviations of PPS”
That is almost certainly a rolling dispersion / volatility‐normalized price series
****think
z-score of a smoothed price stream
So:
Entropy Bias ≈ how stretched price is relative to its recent distribution
This is not information theory entropy.
It is statistical dispersion dressed up with a marketing name.
“Price Recursion”
That usually means a recursive filter. In ThinkScript terms:
x = f(price) + decay * x[1]
Same family as:
- VIP Weighted Alpha recursion
- Ehlers filters
- adaptive smoothing
So this is just:
memory + decay
“Price Heartbeat”
This is the most obvious one. That is almost always a short-term directional pulse
In practice this is usually:
- very short ROC
- short EMA slope
- or candle impulse
So,
Heartbeat ≈ fast directional bias
Now the key part of the author’s comment, "SET LONG / SET SHORT are
set-ups, not new entries"
and "OPEN LONG / OPEN SHORT are “machine logic” using Heartbeat bias"
This is extremely important. They are explicitly saying:
SET signals = location / stretch / preparation
OPEN signals = timing / trigger
That is actually a 2-layer system:
setup → trigger
Why it feels broken when you try to use SET as entries. They told you directly "Seems not to work when SL or SS are used as signs to open initial trade position."
Because those are
not directional confirmation.
They are “price is statistically stretched and preparing”
That is the same class of signal as:
- our Gann σ zones
- our pullbackLong / pullbackShort
- our TMO deep pullback states
Now the important comparison to what I and others are building
My current architecture is:
Environment → Readiness → Execution
Let’s map their language into ours:
Their “Entropy Bias + Price Recursion” maps to: our
stretch / readiness layer
Their “Price Heartbeat OPEN signals” maps to: our
execution trigger layer
So conceptually
this is not crazy. But…
Here is the big difference (and why I would not adopt it). Their entire stack is built only on price transforms
There is:
- no structure
- no auction context
- no environment gating
- no HTF bias
So their pipeline is,
price stretch → price pulse → trade
Our pipeline is:
environment → structure → readiness → execution
That is much safer.
Now the most important practical point for you
Look again at what they said: "OPEN LONG and OPEN SHORT bubbles are Machine Logic"
That is exactly what you already saw:
- lots of repeated OPEN SHORT
- lots of re-affirmation bubbles
This is typical of fast pulse engines. They fire whenever the pulse condition is true again. That is why your chart is covered with them.
Does this add anything you don’t already have? No.
You already have:
stretch / readiness
- Gann σ zones
- WA ROC + slope
- TMO exhaustion
pulse / execution
- TMO cross / slope / turn
- micro structure / reclaim logic
And ours are:
- controllable
- interpretable
- and layered behind environment filters
The one part that
is philosophically aligned with you is this sentence, SET LONG and SET SHORT are set-up signals for trades, not a signal to open a brand new position.
This is exactly how you treat:
- pullback zones
- execution permissions
- readiness flags
So the
idea is fine. The implementation is just:
- rebranded
- compressed into a single black box
- and not environment-aware.
Blunt answer to your real question "Is this a fundamentally different or better engine than what you now use?" No. It is simply a z-score stretch + recursive smoothing + fast slope trigger
We have already built a cleaner version of this:
- without marketing names
- without hidden machine logic
- and integrated into your proper gating stack.
Final take (straight up)
The author’s comments confirm, "
This is a 2-stage setup/trigger engine." But....
You already implemented the same idea in a safer and more professional way:
- SET ≈ your pullback / stretch zones
- OPEN ≈ your TMO / structure trigger
with
environment script and HTF structure added on top. So there is no real edge here for you — only branding.
