Why Your Turn Marker Missed (and the Live Analysis Didn't)
FractalCycles ships two ways to project a detected cycle forward: a fixed projection that freezes its read the moment it's run, and a dynamic projection that re-estimates as new price data arrives. A subscriber's recent experience is the clearest illustration we've seen of why that distinction matters.
His routine was simple: run a cycle analysis on FractalCycles, note the projected turning point, then head over to his broker's platform and place a marker on the chart so he wouldn't forget the date. When the day arrived, he'd try to execute around it.
Here's what he noticed. The marker he'd carefully placed kept missing. Not by a lot, a session or two, sometimes a bit more, but often enough that the entry felt more like a guess than a plan. Meanwhile, if he went back into the platform and simply re-ran the analysis closer to the date, the live projection had already moved to where the market actually turned.
Same cycle. Same underlying setup. Two different outcomes: one was frozen the moment he wrote it down, and the other kept working. That gap is a communication problem on our end more than a platform problem, so this is us closing it.
Two engines, two very different jobs
FractalCycles ships with both a static (fixed) projection and a dynamic (live) one, and that's by design: they answer different questions.
A fixed projection takes a snapshot: here's what the detected cycles say right now, extrapolated forward. It's a structural extrapolation, not a prediction, and it's genuinely useful for framing (where you might be in a larger rhythm, what the historical cadence has looked like, what a chart-ready reference point looks like for a report or a post). It does not update. It's not supposed to.
A dynamic (live) projection re-estimates using whatever data exists at that moment. As new sessions print, the composite wave gets re-estimated and the projected turn shifts to reflect what the market has actually done since the last run.
The subscriber's marker was a fixed projection he'd manually carried off-platform. His broker's chart had no way to hear about the sessions that came in afterward. The live engine did. For the deeper methodology behind both engines, see why static and dynamic cycle analysis both matter.
What that actually looks like
Picture the same setup, checked on three different days:
Day 1, Day 5, Day 9: the live projection tightens toward the actual turn while the fixed marker holds still.
On Day 1, the live engine's best estimate puts the turn a couple of sessions later than it eventually lands. By Day 5, with a few more sessions of price data feeding the model, the estimate has already tightened. By Day 9, it's essentially sitting on top of where the market actually turns.
The fixed marker, set on Day 1 and never touched again, sits exactly where it was placed the whole time, including on Day 9, when it's now visibly off from both the live projection and the actual turn.
Nobody's engine was "wrong" here. The fixed marker did exactly what a fixed marker does: it held still. The live engine did exactly what it's built to do: it kept listening.
Why the turn date moves, and why the cycle length isn't as fixed as it sounds
This is the part that trips people up, so it's worth explaining plainly: there are two separate reasons a projected turn date can shift between runs, and the more intuitive one is usually the bigger driver.
The first, and the one people underestimate, is that real cycles don't repeat at a fixed length every single time. A validated cycle has a nominal period, a typical length it tends to run, but that nominal length carries a tolerance band around it, not a hard constant. This is the same principle J.M. Hurst built into his own cyclic framework: a "nominal" cycle length is a useful anchor, not a promise that every repetition lands on exactly that number. A cycle that has behaved like a familiar length across many past instances can still run a few sessions longer or shorter this time around, and when a live re-run captures that, the model isn't correcting a mistake, it's picking up something genuinely different about how this particular repetition is playing out.
The second reason is the one that's easier to explain, and the one we originally led with: a composite projection is built from several statistically validated cycles, each with its own detected period, amplitude, and phase. Even when a cycle's length hasn't moved at all, the phase, exactly where in that cycle you currently sit, sharpens as more price data arrives. A few more sessions can nudge the phase estimate enough to move the projected peak or trough by several sessions on its own.
In practice both effects stack together. A little bit of genuine wavelength drift, plus a phase estimate that keeps getting more precise, is why the gap between a stale marker and a fresh re-run can be larger than people expect.
Isolating one of the two causes: even when the period holds steady, a sharper phase estimate alone can move the projected turn by a few sessions.
That diagram isolates just the phase effect so it's easy to see on its own. In practice, the cycle's actual length is also free to run a little long or short on any given pass, which is often the larger and more visible part of what the subscriber saw. Neither effect means the cycle "changed" in some alarming way. It means a live re-run picks up real information, about the cycle's current length, about where you sit inside it, or both, that a frozen snapshot never gets the chance to.
So when is a saved screenshot actually fine to use?
This matters for anyone screenshotting an analysis to reference later, or sharing one of our posts, and the honest answer is: sometimes it's fine, and sometimes it's the exact thing that gets someone into a bad trade.
Context versus timing: the same screenshot can be safe for one purpose and risky for the other.
The short version: a screenshot travels well when you're using it for context and the underlying cycle length hasn't changed since. It travels badly when you're using it to time an entry or exit, because the one thing a still image cannot do is hear about the sessions that happened after it was taken.
If in doubt, the fix costs you thirty seconds: re-run the analysis before you act on it.
See a projection update in real time
Run a live cycle analysis on any symbol, then re-run it as new sessions print to watch the projection refine.
Run a free analysis NowThe practical takeaway
None of this makes the fixed engine less useful. It's the right tool when you want a stable reference point, a clean visual for a report, or a historical frame that isn't supposed to move. And none of it makes the dynamic engine infallible: live projections still carry the same statistical caveats as any cycle work. Validated cycles can still fail, regimes can still shift, and this is a structural read of price behavior, not a prediction.
What it does mean is simple: if you're marking a level to actually act on, mark it as close to execution as you reasonably can, using the live engine, and treat anything older than a handful of sessions as due for a re-run, not as gospel.
The subscriber who flagged this wasn't doing anything wrong. He was doing what any careful analyst does: writing the plan down so he wouldn't second-guess himself in the moment. The fix isn't a new habit; it's re-running that same plan a little closer to game time, and letting the engine that's built to adapt actually do its job.
A fixed projection is a snapshot; a dynamic projection keeps re-estimating as new data arrives. The gap between them shows up as a shifted turn date, because real cycles run a little long or short from one pass to the next and because more data sharpens the phase estimate on top of that. Mark levels you plan to act on with the live engine, close to execution, and treat older screenshots as context rather than a timing signal.
Frequently asked questions
What's the difference between a fixed and a dynamic cycle projection?
A fixed (static) projection freezes its read on the detected cycles at the moment it's run and extrapolates forward without updating. A dynamic (live) projection re-estimates every time it's run, incorporating whatever price data exists at that moment to refine the projected turn.
Why does a projected turn date shift between two runs of the same analysis?
Two reasons, and the more intuitive one is usually the bigger driver: real cycles don't repeat at a fixed length every time. A validated cycle has a nominal period with a tolerance band around it, so this pass through the cycle can genuinely run a bit longer or shorter than the last one. The second, subtler reason is that phase (where you currently sit inside the cycle) sharpens as more price data arrives, which can move the projected turn by a few sessions even when the cycle's length hasn't shifted at all.
Is it safe to use a saved cycle analysis screenshot to time a trade?
A saved screenshot is fine for general context if the cycle length still matches a fresh run. It's not reliable for timing an entry or exit, because a still image can't reflect any price sessions that occurred after it was captured. Re-running the live analysis first is the safer habit.
When should I use the fixed projection instead of the dynamic one?
The fixed projection is the right tool for a stable reference point: a historical comparison, a chart for a report, or a snapshot that isn't meant to update. Use the dynamic projection when timing matters, such as near a projected turn you plan to act on.
This article describes how FractalCycles' fixed and dynamic projection tools work and does not constitute financial, investment, or trading advice. Cycle analysis identifies statistically validated patterns in historical data; it does not guarantee future results. Always confirm your own analysis and risk parameters before acting on any projection.
Get the Monthly Market Cycle State Report
Free market cycle data for 20+ instruments. Dominant periods, regime shifts, and phase transitions delivered every month.
No spam. Unsubscribe anytime.