Which inputs does Role Reversal use?

Direct answer

Role Reversal is a chart-based concept that uses predefined inputs from price structure and a set of comparison rules. In practice, “which inputs” means: which market observations you feed into the rule set (for example, swing highs/lows or zones), which two sides you compare, and what conditions must be true for the rule to be considered satisfied.

Because Role Reversal is not a single universal formula with one fixed parameter set, the exact inputs depend on the specific ruleset you are using. This article explains a generic, self-checkable input model and highlights the main limitations.

Mechanism or definition

A simple way to describe Role Reversal is as a “role change” between two sides defined by prior structure.

Inputs you typically choose (define them explicitly):

Price-structure anchor(s): The chart elements you use as references. Examples include prior swing high/low points, recent pivots, or defined support/resistance zones.
Two sides to compare: You decide what “side A” and “side B” are in your rule. For instance, one side may represent the previous boundary that later acts as the opposite boundary.
Temporal/sequence requirement: Whether the role change must occur after a clearly defined event (for example, after price interacts with one boundary). This avoids mixing past and present context.
Validity conditions (triggers/confirmations): The rule conditions that make the role change count. These conditions are inputs because they decide what observations you accept (e.g., “the boundary is respected” or “structure changes”).
Definition of “respected” or “broken”: You must set a measurable interpretation of respect/break (for example, whether a close matters, or whether the touch is enough). This is often the biggest source of inconsistency.

Non-inputs to avoid:

You generally do not treat broker-specific settings, spreads, or execution quality as intrinsic inputs to the concept itself; those are market-participant conditions that can affect results, but they are not part of the abstract rule logic.

Evidence or example (assumption-based)

Here is an example of a concrete input set you can use to describe your rules, without assuming any live outcomes.

Assumptions (you must state them in your own test):

You use swing points to define two boundaries: Boundary A and Boundary B.
You require a sequence: first, price must interact with Boundary A; later, price must interact with the opposite boundary area.
You define “respect” as a price move that returns away from the boundary after the interaction.

Example input specification:

Input 1: Boundary A = the last visible swing high/low before the interaction.
Input 2: Boundary B = the prior opposite swing point that defines the alternative boundary.
Input 3: “Role change window” = the bars after the interaction where respect would be observable.
Input 4: Confirmation rule = price must leave the boundary in the expected direction for a minimum number of bars.

Under this setup, Role Reversal “uses” those four inputs: two structure anchors, a defined sequence, and measurable confirmation logic. If your own ruleset uses zones instead of swing points, or uses different confirmation logic, then the input list changes.

Limitations and risks (what can fail)

Ambiguous structure: If swing points/zones are subjective or overlapping, the chosen anchors can change depending on how you draw them. That changes the inputs and the outcome of the rule.
Rule overfitting to one definition: If you tune confirmation conditions to past charts without a stable definition (inputs stay “handpicked”), your model may fail when the same concept appears with slightly different structure.
Sequence confusion: If you do not enforce the temporal requirement, you may mix earlier context with later interactions, creating an apparent “role change” that is actually an artifact.
Market condition dependency: Outcomes vary with market conditions and costs; even if the abstract role-change logic is consistent, real results can differ with liquidity, volatility regimes, and transaction costs.

Verification or next question

To independently verify Role Reversal’s inputs, document your rules as an input checklist:

What are your structure anchors?
What defines side A vs side B?
What exact sequence must occur?
What measurable condition counts as respect or break?
What are your failure cases (when the rule should not apply)?