Indicator

ValidationUtilitiesValidationUtilities Library
🌸 Part of GoemonYae Trading System (GYTS) 🌸
🌸 --------- 1. INTRODUCTION --------- 🌸
💮 What Does This Library Contain?
ValidationUtilities is a centralised validation framework for Pine Script. It replaces scattered, ad-hoc input checks with a single, structured validation pass that catches every misconfiguration before a script begins operating.
The library spans the full validation workflow: framework lifecycle, configuration checks, position sizing guards, and signal completeness verification.
💮 Key Categories
The library contains:
Core Framework : the ValidationFramework UDT and its lifecycle methods (init, collect, report)
Standalone Utilities : bounded-buffer push and division-by-zero guard
Configuration Validation : range, ordering, exclusivity, lookback, source, and timeframe checks
Position Sizing & Risk : order size constraints, progressive risk alerts, allocation distribution, and Martingale safety
Signal & Timing : signal source completeness and cooldown gating
🌸 --------- 2. ADDED VALUE --------- 🌸
💮 Consistent, Readable Error Messages
Every error and warning follows the same Message format. Users see clear, categorised feedback instead of cryptic runtime error strings. A single validation pass surfaces all issues at once, so there is no need to fix one error only to hit the next on re-run.
💮 Single Import, Full Coverage
One import replaces dozens of inline validation blocks. Range checks, allocation constraints, timeframe guards, and position sizing validations are all available immediately.
💮 Errors and Warnings, Separated
Hard/soft boundary separation lets developers enforce critical constraints (errors halt execution via runtime.error() ) whilst still surfacing non-critical suggestions (warnings display as chart labels). The framework handles formatting, counting, and display.
💮 Proven in Production
ValidationUtilities underpins the validation layer of a strategy with an extensive configuration surface (12+ validated parameter groups). The methods have been refined against real misconfiguration scenarios including floating-point allocation sums, multiplier escalation, and unconnected data streams.
🌸 --------- 3. CORE FRAMEWORK --------- 🌸
💮 ValidationFramework (UDT)
The central data structure that collects validation results. It holds two string arrays, errors (critical, halt execution) and warnings (advisory, continue execution), alongside convenience flags has_errors and has_warnings .
Declare once with var , then call init() to reset state before each validation cycle:
var framework = vu.ValidationFramework.new()
framework.init()
💮 init()
Resets the framework: clears both arrays and resets flags to false . Call at the start of each validation cycle.
💮 add_error() and add_warning()
Building blocks for custom validation beyond the built-in methods. Both accept a category and message , formatting them as Message . Use add_error() for constraints that must halt execution and add_warning() for advisory messages.
framework.add_error("Position Sizing", "Order exceeds account equity.")
framework.add_warning("Risk", "Position represents 35% of equity — monitor carefully.")
💮 trigger_errors()
Fires runtime.error() with the first collected error and a count of any remaining. Always call after all validations have run so every misconfiguration is detected in a single pass.
💮 display_warnings()
Renders warnings as orange chart labels (below bar by default). Displays the first warning with a count of additional warnings, then clears state to prevent repetition. Accepts an optional yloc_arg for label placement.
↑ Runtime error dialog showing a categorised validation error with count of additional issues
↑ Warning labels displayed on the chart via display_warnings()
🌸 --------- 4. STANDALONE UTILITIES --------- 🌸
These functions are independent of the ValidationFramework and can be used anywhere.
💮 push_limited()
A FIFO bounded-buffer push: appends a value and evicts the oldest entry when the array exceeds a specified limit. Available for both float and int arrays.
vu.push_limited(price_buffer, close, 50) // Keeps the last 50 closes
💮 safe_denominator()
Returns math.max(value, floor) to guard against division by zero. Default floor is 1e-9 .
ratio = numerator / vu.safe_denominator(denominator)
🌸 --------- 5. CONFIGURATION VALIDATION --------- 🌸
These methods validate user-facing settings before a script begins operating. Each accepts the framework as self and a category string for error grouping. Refer to the source code for full parameter details.
💮 validate_range()
Checks that a value falls within hard bounds (error if violated) and optional soft bounds (warning if outside the optimal range). Supports a value_unit label for message clarity. Returns true if within hard bounds.
💮 validate_exclusive_selection()
Ensures exactly one boolean flag is active among a set of mutually exclusive options. Produces an error listing which options were found active, or that none were selected.
💮 validate_ascending_order()
Verifies that an array of values is in ascending order. Supports strict (default) or non-strict comparison. Skips na values.
💮 validate_minimum_lookback()
Checks that a lookback parameter meets a caller-derived minimum. Accepts an optional fix_hint for the error message. Returns true if met.
💮 validate_source_connected()
Detects when an input.source() has no external indicator connected (it silently defaults to close ). Uses a 2-bar close heuristic. Accepts an is_enabled flag to skip the check when the relevant feature is disabled. Returns true if the source appears connected.
💮 validate_higher_timeframe()
Validates that a user-selected timeframe is sufficiently higher than the chart timeframe. Returns the integer multiplier, useful for scaling lookback periods. Produces an error if below min_multiplier (default 1.0).
🌸 --------- 6. POSITION SIZING & RISK --------- 🌸
These methods guard against position sizing errors and excessive risk exposure. See the source code for parameter details and default thresholds.
💮 validate_order_size_constraints()
Checks a proposed order against account equity and position size limits. Errors if the order exceeds equity or a hard cap; warns if the position exceeds a configurable percentage of equity. Returns true if no errors were added.
💮 validate_multiplied_sizing_risk()
Progressive risk alerting for scripts that scale position sizes with multipliers (Martingale, Anti-Martingale, or any multiplicative sizing). Applies three escalating thresholds:
Warning (default 25%): elevated risk
Error (default 50%): high risk
Critical (default 75%): exceeds safe limits
Also warns when the multiplier itself exceeds a configurable threshold. Returns true if no errors were added.
💮 validate_martingale_settings()
Validates Martingale/Anti-Martingale parameter consistency: multiplier range, streak bounds, and maximum possible escalation. Warns when maximum escalation exceeds 100×.
💮 validate_allocations()
Validates percentage distributions (0–1 scale) for take-profit levels, portfolio weights, or any system that divides a whole into parts. Checks individual allocations and total against 1.0 with floating-point tolerance. Supports both mandatory full allocation and partial allocation.
🌸 --------- 7. SIGNAL & TIMING --------- 🌸
These methods verify signal completeness and enforce cooldown periods. See the source code for parameter details.
💮 validate_signal_configuration()
Completeness check for signal sources. Validates that an enabled signal has a connected primary data stream, a secondary stream (if required), at least one signal mapping, and activity in at least one market regime (when regime filtering is enabled).
💮 validate_timing_cooldown()
Gating check for entry timing. Verifies that enough bars have elapsed since the last relevant event and that a valid entry signal is present. Both conditions produce warnings rather than errors.
🌸 --------- 8. USAGE EXAMPLE --------- 🌸
A typical validation lifecycle: import, initialise, run validations, then trigger errors and display warnings.
import GoemonYae/ValidationUtilities/1 as vu
// Declare once, reset each bar
var framework = vu.ValidationFramework.new()
framework.init()
// Configuration validation
framework.validate_range("Config", "ATR Lookback", i_atr_lookback, 1, 500, 10, 50, "bars")
framework.validate_exclusive_selection("Distance", "TP Mode",
array.from(i_use_pct, i_use_atr, i_use_hl),
array.from("Percentage", "ATR", "High/Low"), "method")
// Allocation validation
framework.validate_allocations("TP Settings", "Take Profit",
array.from(i_tp1_alloc, i_tp2_alloc, i_tp3_alloc),
array.from("TP1", "TP2", "TP3"), true)
// Position sizing guard
framework.validate_order_size_constraints("Sizing",
order_size, close, strategy.equity, max_pos, 50.0)
// Report results
framework.trigger_errors() // Halts if any errors found
framework.display_warnings() // Shows warnings on chart
When all inputs are valid, trigger_errors() does nothing and execution continues; display_warnings() draws no labels. A correctly configured script simply runs with a clean chart.
🌸 --------- 9. PRACTICAL USAGE NOTES --------- 🌸
💮 Errors vs Warnings
Use add_error() for constraints that make the script unsafe or logically broken (missing data streams, impossible parameter combinations, equity-exceeding orders). Use add_warning() for suboptimal but non-dangerous configurations (values outside the recommended range, elevated risk percentages). Errors halt execution; warnings inform via chart labels.
💮 Single-Pass Collection
Always run all validations before calling trigger_errors() . The framework collects every error in a single pass so the user sees the total count of issues.
💮 Integration with Other GYTS Libraries
ValidationUtilities complements the GYTS library ecosystem:
FiltersToolkit : smoothing and signal processing
VolatilityToolkit : volatility estimation and regime detection
ColourUtilities : dynamic colour mapping
MathTransform : mathematical transformations and normalisation
Each library handles its own domain; ValidationUtilities handles the validation layer that sits above them.
💮 Limitations
A few constraints to keep in mind:
The validate_source_connected() heuristic (2-bar close comparison) can produce false positives if a source genuinely tracks price closely. It is a best-effort detection, not a guarantee.
Pine Script libraries cannot import other libraries. So ValidationUtilities is designed for indicators and strategies.
The framework validates configuration state, not runtime state. It catches misconfigurations at the input level; it does not monitor runtime behaviour.
Library

StO Price Action - Level ReactionShort-Summary
- Multi-timeframe reaction indicator for M5, M15, M30, H1, H4
- Monitors price interaction with higher timeframe levels (Daily, Weekly, H4)
- Detects whether price touches or breaks choosen levels
- Fully configurable colors, visibility and alerts per timeframe and level type
Full Description
Overview
- Tracks market reaction on significant levels across multiple timeframes
- Designed to identify intraday reactions to higher timeframe structure
- Supports both bullish and bearish reactions, with separate visual cues
- Alerts can be enabled to notify traders of touches or breaks
Core Logic
- Choice between detecting a touch or a break of the level
- Configurable reference level: Open, High or Low
- Lookback period can be set to target specific levels from previous candles
Timeframe Reactions
- Supported intraday reaction timeframes: M5, M15, M30, H1, H4, Daily, Weekly
- Each reaction type can be individually toggled for display
- Bullish and bearish reactions have separate color settings
- Alerts configurable per timeframe and reaction type
Alerting
- Alerts can be triggered for touches or breaks
- Supports separate alerts for each timeframe and each direction (bull/bear)
- Useful for real-time monitoring of key level interactions
Notes
- Intended as a market reaction tool not a standalone entry signal
- Helps traders confirm if price respects or violates higher timeframe levels Indicator

ICT Anchored Market Structures with Validation [LuxAlgo]The ICT Anchored Market Structures with Validation indicator is an advanced iteration of the original Pure-Price-Action-Structures tool, designed for price action traders.
It systematically tracks and validates key price action structures, distinguishing between true structural shifts/breaks and short-term sweeps to enhance trend and reversal analysis. The indicator automatically highlights structural points, confirms breakouts, identifies sweeps, and provides clear visual cues for short-term, intermediate-term, and long-term market structures.
A distinctive feature of this indicator is its exclusive reliance on price patterns. It does not depend on any user-defined input, ensuring that its analysis remains robust, objective, and uninfluenced by user bias, making it an effective tool for understanding market dynamics.
🔶 USAGE
Market structure is a cornerstone of price action analysis. This script automatically detects real-time market structures across short-term, intermediate-term, and long-term levels, simplifying trend analysis for traders. It assists in identifying both trend reversals and continuations with greater clarity.
Market structure shifts and breaks help traders identify changes in trend direction. A shift signals a potential reversal, often occurring when a swing high or low is breached, suggesting a transition in trend. A break, on the other hand, confirms the continuation of an established trend, reinforcing the current direction. Recognizing these shifts and breaks allows traders to anticipate price movement with greater accuracy.
It’s important to note that while a CHoCH may signal a potential trend reversal and a BoS suggests a continuation of the prevailing trend, neither guarantees a complete reversal or continuation. In some cases, CHoCH and BoS levels may act as liquidity zones or areas of consolidation rather than indicating a clear shift or continuation in market direction. The indicator’s validation component helps confirm whether the detected CHoCH and BoS are true breakouts or merely liquidity sweeps.
🔶 DETAILS
🔹 Market Structures
Market structures are derived from price action analysis, focusing on identifying key levels and patterns in the market. Swing point detection, a fundamental concept in ICT trading methodologies and teachings, plays a central role in this approach.
Swing points are automatically identified based exclusively on market movements, without requiring any user-defined input.
🔹 Utilizing Swing Points
Swing points are not identified in real-time as they form. Short-term swing points may appear with a delay of up to one bar, while the identification of intermediate and long-term swing points is entirely dependent on subsequent market movements. Importantly, this detection process is not influenced by any user-defined input, relying solely on pure price action. As a result, swing points are generally not intended for real-time trading scenarios.
Instead, traders often analyze historical swing points to understand market trends and identify potential entry and exit opportunities. By examining swing highs and lows, traders can:
Recognize Trends: Swing highs and lows provide insight into trend direction. Higher swing highs and higher swing lows signify an uptrend, while lower swing highs and lower swing lows indicate a downtrend.
Identify Support and Resistance Levels: Swing highs often act as resistance levels, referred to as Buyside Liquidity Levels in ICT terminology, while swing lows function as support levels, also known as Sellside Liquidity Levels. Traders can leverage these levels to plan their trade entries and exits.
Spot Reversal Patterns: Swing points can form key reversal patterns, such as double tops or bottoms, head and shoulders, and triangles. Recognizing these patterns can indicate potential trend reversals, enabling traders to adjust their strategies effectively.
Set Stop Loss and Take Profit Levels: In ICT teachings, swing levels represent price points with expected clusters of buy or sell orders. Traders can target these liquidity levels/pools for position accumulation or distribution, using swing points to define stop loss and take profit levels in their trades.
Overall, swing points provide valuable information about market dynamics and can assist traders in making more informed trading decisions.
🔹 Logic of Validation
The validation process in this script determines whether a detected market structure shift or break represents a confirmed breakout or a sweep.
The breakout is confirmed when the close price is significantly outside the deviation range of the last detected structural price. This deviation range is defined by the 17-period Average True Range (ATR), which creates a buffer around the detected market structure shift or break.
A sweep occurs when the price breaches the structural level within the deviation range but does not confirm a breakout. In this case, the label is updated to 'SWEEP.'
A visual box is created to represent the price range where the breakout or sweep occurs. If the validation process continues, the box is updated. This box visually highlights the price range involved in a sweep, helping traders identify liquidity events on the chart.
🔶 SETTINGS
The settings for Short-Term, Intermediate-Term, and Long-Term Structures are organized into groups, allowing users to customize swing points, market structures, and visual styles for each.
🔹 Structures
Swings and Size: Enables or disables the display of swing highs and lows, assigns icons to represent the structures, and adjusts the size of the icons.
Market Structures: Toggles the visibility of market structure lines.
Market Structure Validation: Enable or disable validation to distinguish true breakouts from liquidity sweeps.
Market Structure Labels: Displays or hides labels indicating the type of market structure.
Line Style and Width: Allows customization of the style and width of the lines representing market structures.
Swing and Line Colors: Provides options to adjust the colors of swing icons, market structure lines, and labels for better visualization.
🔶 RELATED SCRIPTS
Pure-Price-Action-Structures.
Market-Structures-(Intrabar).
Indicator

Machine Learning Cross-Validation Split & Batch HighlighterThis indicator is designed for traders and analysts who employ Machine Learning (ML) techniques for cross-validation in financial markets.
The script visually segments a selected range of historical price data into splits and batches, helping in the assessment of model performance over different market conditions.
User
Theory
In ML, cross-validation is a technique to assess the generalizability of a model, typically by partitioning the data into a set of "folds" or "splits." Each split acts as a validation set, while the others form the training set. This script takes a unique approach by considering the sequential nature of financial time series data, where random shuffling of data (as in traditional cross-validation) can disrupt the temporal order, leading to misleading results.
Chronological Integrity of Splits
Even if the order of the splits is shuffled for cross-validation purposes, the data within each split remains in its original chronological sequence. This feature is crucial for time series analysis, as it respects the inherent order-dependency of financial markets. Thus, each split can be considered a microcosm of market behavior, maintaining the integrity of trends, cycles, and patterns that could be disrupted by random sampling.
The script allows users to define the number of splits and the size of each batch within a split. By doing so, it maintains the chronological sequence of the data, ensuring that the validation set is representative of a future time period that the model would predict.
www.pulsewire.com
Parameters
Number of Splits: Defines how many segments the selected data range will be divided into. Each split serves as a standalone testing ground for the ML model. (Up to 24)
Batch Size: Determines the number of bars (candles) in each batch within a split. Smaller batches can help pinpoint overfitting at a finer granularity.
Start Index: The bar index from where the historical data range begins. It sets the starting point for data analysis.
End Index: The bar index where the historical data range ends. It marks the cutoff for data to be included in the model assessment.
Usage
To use this script effectively:
1 - Input the Start Index and End Index to define the historical data range you wish to analyze.
2 - Adjust the Number of Splits to create multiple validation sets for cross-validation.
3 - Set the Batch Size to control the granularity of each validation set within the splits.
4 - The script will highlight the background of each batch within the splits using alternating shades, allowing for a clear visual distinction of the data segmentation.
By maintaining the temporal sequence and allowing for adjustable granularity, the "ML Split and Batch Highlighter" aids in creating a robust validation framework for time series forecasting models in finance. Indicator

Indicator
