State Machine Entry DebuggerState Machine Entry Debugger - CoffeeKiller
State Machine Entry Debugger - CoffeeKiller is a development and diagnostic indicator designed to make a strategy's long-entry process visible on the chart.
Many strategies do not enter immediately when one condition becomes true. Instead, they move through a sequence of internal states. That sequence may include detecting a setup area, validating filters, waiting for confirmation, checking execution permission, and finally producing an entry signal.
These internal stages are normally invisible. A developer may see only the final strategy order and assume the entry was delayed without knowing which part of the logic caused the delay.
This indicator turns that hidden process into a visible chart timeline.
Important
This is not a standalone trading system.
The included EMA, ATR, pullback, and breakout conditions are placeholders used only to demonstrate how the debugger operates. They are not intended as production trading signals.
The current example is designed for long-entry debugging only. It does not contain a separate short-side state machine.
Entry Sequence
The debugger tracks the following sequence:
Touch -> ARM -> Trigger -> Entry Signal -> Reset
Touch
Price reaches or interacts with the defined setup area.
ARM
The setup passes its required filters and becomes eligible to wait for a trigger.
Trigger
The strategy's confirmation condition becomes true.
Entry Signal
All setup, filter, trigger, and final permission requirements have passed.
Reset
The example state machine returns to its idle state and waits for another setup.
Why This Tool Exists
A strategy may appear to enter late for several different reasons:
A setup filter remained false.
The trigger occurred several bars after the initial touch.
The setup expired before confirmation.
Entry permission blocked execution.
The state machine required each stage to begin on a separate bar.
The strategy waited for the candle to close.
The debugger and strategy used different realtime calculation behavior.
The strategy created an order on one bar but filled it on the next.
Reset or cancellation logic removed the setup.
Without a debugger, these situations may all appear to be the same problem: a late entry.
This script separates those possibilities.
Confirmed-Bar State Transitions
The state machine advances only when the candle is confirmed:
barstate.isconfirmed
This means a state transition is committed only after the candle closes.
This behavior is intended to match strategies that evaluate their entry logic at bar close.
Without confirmed-bar gating, a condition may temporarily become true while the realtime candle is forming. Touch, ARM, Trigger, or Entry labels could then appear, disappear, or move before the candle closes.
That can make an indicator appear to react earlier than the strategy it is supposed to diagnose.
By waiting for candle confirmation, the debugger provides a more consistent comparison with bar-close strategy logic.
A strategy that intentionally calculates intrabar requires a debugger configured to reproduce its execution behavior.
Relevant strategy settings and behaviors may include:
calc_on_every_tick
calc_on_order_fills
process_orders_on_close
Wick-based versus close-based confirmation
Higher-timeframe data behavior
Session filters
Time filters
The debugger and the strategy must use equivalent assumptions before their results can be compared accurately.
Entry Signal Versus Strategy Fill
The green Entry Signal marker identifies the bar where the state machine determines that all entry requirements have passed.
It does not necessarily represent the strategy broker emulator's actual fill bar or fill price.
Under the normal strategy execution model, an order created after a bar closes is generally filled at the next available tick. For a bar-close strategy, that commonly means the open of the next bar.
The chart may therefore show:
Debugger Entry Signal on the current bar
Strategy fill on the next bar
That one-bar difference is not automatically a bug.
A strategy using the following setting may instead process an order at the close of the signal bar:
process_orders_on_close=true
When comparing the debugger with a strategy, determine whether you are comparing:
The signal bar
The order-creation bar
The broker-emulator fill bar
The recorded fill price
These events are related, but they are not always identical.
One Transition Per Bar
The example state machine intentionally allows only one transition per confirmed bar.
A completed sequence may therefore appear as:
Bar 1: Touch
Bar 2: ARM
Bar 3: Trigger
Bar 4: Entry Signal
This occurs because the transition logic uses an if / else if structure.
Even when several conditions are already true, the state machine cannot move through multiple stages during the same bar. It must begin the bar in the required prior state before it can advance.
This behavior is useful for exposing structural delays.
For example, the market may satisfy the setup filters and breakout condition on the same candle, but the state machine may still require separate bars for Touch, ARM, Trigger, and Entry Signal.
In that situation, the apparent delay is caused by the state-machine architecture rather than by the market conditions.
This design is intentional for debugging purposes.
A strategy that permits multiple transitions on the same bar requires a different transition structure.
What the Debugger Displays
The script can display event labels for:
Touch
ARM
Trigger
Entry Signal
Touch expiration
ARM expiration
State reset
It can also display blocked-condition labels for:
Trend filter
Quality filter
Extension filter
Trigger condition
Entry permission
A blocked label identifies the first condition preventing the current state from advancing on a confirmed bar.
A blocked condition does not automatically mean the strategy is malfunctioning.
For example, while an armed setup is waiting for confirmation, the trigger condition should normally remain false. A Waiting Trigger label may simply indicate that the state machine is operating as designed.
Timeline Measurements
The debugger measures the number of confirmed bars between the major state transitions:
Touch to ARM
ARM to Trigger
Trigger to Entry Signal
Touch to Entry Signal
These measurements help distinguish between:
Filter delay
Trigger delay
Permission delay
State-sequencing delay
Timeout behavior
The debugger also tracks:
Bars since Touch
Bars since ARM
Bars since Trigger
State Background
Optional chart-background colors show the current internal state:
Blue: Touched
Orange: Armed
Purple: Triggered
Green: Entry Signal reached
No background: Idle
The green state represents the debugger's logical Entry Signal state. It should not automatically be interpreted as the strategy's broker-emulator fill.
Debug Table
The on-chart table shows the latest state and condition information, including:
Current state
Last event
Last blocking condition
Touch condition
Trend filter
Quality filter
Extension filter
Trigger condition
Entry permission
Bars since Touch
Bars since ARM
Bars since Trigger
ATR extension distance
Confirmed-bar status
Realtime-bar status
Current bar index
Conditions are displayed as PASS or FAIL.
A FAIL value means only that the condition is currently false. Whether that is expected depends on the current state.
The table displays condition values for the latest chart bar. On a forming realtime candle, those values may continue to change, but the state machine will not advance until the candle closes.
Data Window Values
The indicator also sends its internal values to the PulseWire Data Window.
This allows developers to inspect individual historical bars and compare the debugger with the original strategy.
Available values include:
State number
Touch condition
Trend filter
Quality filter
Extension filter
Trigger condition
Entry permission
ATR extension distance
Bars since Touch
Bars since ARM
Bars since Trigger
Same-bar transition checks
Confirmed-bar status
Realtime-bar status
Boolean values appear as:
1 = true
0 = false
Placeholder Logic
The included conditions exist only so the indicator can compile and demonstrate its operation.
The main placeholder variables are:
touchCondition
trendFilter
qualityFilter
extensionFilter
triggerCondition
entryPermission
Replace these variables with the exact conditions from the strategy being diagnosed.
For an accurate comparison, developers should also reproduce the strategy's:
Price sources
Wick or close confirmation rules
Session restrictions
Time restrictions
Higher-timeframe requests
Position-state restrictions
Pyramiding behavior
Cooldown rules
Cancellation logic
Rearm logic
Order-processing settings
Suggested Implementation Process
Start with a duplicate of the strategy you want to diagnose.
Assign the condition that begins the setup to:
touchCondition
Assign the setup-validation requirements to:
trendFilter
qualityFilter
extensionFilter
Assign the actual confirmation event to:
triggerCondition
Assign final execution restrictions to:
entryPermission
Then compare the debugger's Touch, ARM, Trigger, and Entry Signal markers with the strategy's signal condition, order creation, order marker, and broker-emulator fill.
Do not assume that the debugger's Entry Signal and the strategy's fill marker should always appear on the same bar.
Recommended Debugging Method
First reproduce the strategy's existing behavior exactly.
Do not begin by removing filters or forcing earlier entries.
Once the debugger and strategy agree, change one part of the logic at a time.
This helps determine whether an entry delay comes from:
The market setup
A filter
The trigger
Entry permission
A timeout
State sequencing
Bar-close confirmation
Intrabar calculation
Order-fill timing
Reset or cancellation behavior
The goal is not simply to make the strategy enter earlier.
The goal is to understand why it entered when it did.
Current Design Limitations
This version uses long-side placeholder logic.
It does not contain an independent short-side state machine.
Although the placeholder conditions can be replaced with bearish conditions, a complete two-direction debugger should normally use independent long and short state machines. This prevents one direction's setup from overwriting or blocking the other direction's state.
The example resets immediately after reaching the Entry Signal state.
A production strategy should replace that behavior with its actual:
Position-entry handling
Exit handling
Setup cancellation
Rearm rules
Cooldown period
Opposite-signal behavior
The debugger intentionally permits only one transition per confirmed bar.
Because this script is an indicator rather than a strategy, it does not simulate:
Strategy orders
Position sizing
Pyramiding
Commissions
Slippage
Broker-emulator fills
Labels may become crowded across long historical ranges. The recent-bars setting can be used to reduce chart clutter.
Final Purpose
State Machine Entry Debugger converts an invisible decision process into a visible chart timeline.
Instead of seeing only the final strategy entry, developers can inspect:
Where the setup began
When it became armed
Which condition delayed it
When the trigger occurred
When the logical entry signal became valid
Whether the setup expired or reset
Whether the apparent delay came from state logic or order-fill timing
This makes complex state-machine behavior easier to test, explain, and improve.
Disclaimer
This indicator is intended solely for educational, informational, diagnostic, and software-development purposes.
It is not a trading system and should not be interpreted as a recommendation to buy or sell any financial instrument.
The included conditions are placeholders and are not presented as a profitable or complete trading methodology.
Trading involves substantial risk of loss. Historical behavior, simulated performance, and strategy results do not guarantee future performance.
Always perform your own analysis, thoroughly test all strategy logic, account for realistic execution conditions, and consult a qualified financial professional when appropriate before risking real capital.
Indicator
