The Market Reversal Engine describes its own workflow in one sentence: tag setups by class and route the survivors into the Universal Trading Engine. That sentence contains the entire method, and most people skip the first half and go straight to the second, which is how you end up automating a thing you never checked.
The order is deliberate. Tagging is how you find out whether a kind of setup works for you. Routing is what you do afterwards, to the ones that did. Doing it backwards means the automation is running your hypothesis rather than your evidence, and it will run it faster than you can notice it failing.
A class is a combination, not a ticker
The most common mistake is to treat "BTC reversals" as a class. It is not, because it bundles together trades with completely different characters. A class is a repeatable combination of the fields on the row, and on this feed there are four that define one.
The instrument or instrument group. The timeframe from the TF column. The direction, meaning whether the row is overbought and short or oversold and long. And the type, which in the capture reads SCALP on every visible row and is the field that tells you the intended holding period.
Combine those and you get something like "BTC and ETH, 15m, overbought short, scalp". That is a class. It is narrow enough that every instance is genuinely the same trade, and it is broad enough to accumulate instances. "BTC reversals" fails the first test and "BTC 15m overbought short scalp on a Tuesday" fails the second.
The reason the definition has to be this mechanical is that you are going to compare instances later. A class whose membership depends on how you felt about a chart cannot be evaluated, because you cannot tell whether the good results came from the setup or from the days you were paying attention.
The evidence a class needs before it goes anywhere near autopilot
Set a bar and keep it. Mine has three parts and none of them are statistical sophistication, they are just refusals to skip steps.
First, a real count of hand-taken instances. Not rows you observed, instances you traded or paper traded through to an exit, with the exit recorded. Twenty is a working minimum for a scalp class and it is genuinely a minimum. Below that you are looking at noise with a label on it.
Second, homogeneity. Go back through the instances and check that they really were the same trade. If half of them came from one week when a single asset was in one particular regime, you have one observation repeated, not twenty observations. This is the check that kills more candidate classes than any other, and it is the one people skip because it is tedious.
Third, and this is the one nobody wants to hear, the class has to have survived a losing stretch while you were still taking it. A class you validated across nothing but a favourable run has not been tested, it has been flattered. You want to have seen it lose four in a row and to know what that felt like, because the automated version will do that too and you will be the one deciding whether to switch it off.
Three classes that should never be promoted
Some setups work for you and still do not belong in an automated route. The distinction is not about quality, it is about whether the thing that makes them work can be written down.
The first is any class where your entry depends on a judgement the row does not contain. If you take the setup only when the volume spike looks right, or only when the price is at a level you drew last weekend, then the profitable part of your process lives in your eyes and the automation will take the other instances too. It is not running your strategy, it is running the strategy minus its best filter.
The second is any class that requires an exit decision. A bracketed entry with a pre-set stop and target is automatable precisely because both exits are defined in advance. If your version involves moving the stop when something happens, or taking half off when it feels extended, then what you have is a discretionary trade with a signal trigger, and handing it to a router will change the results in a direction you have not measured.
The third is the low-frequency class. If a class produces two instances a month, automating it saves you almost no time and costs you the one thing manual execution provides, which is a human looking at the market before the order goes in. Automation is for the classes that are too frequent to babysit, and the setups tile in the capture read 2 in the last 24 hours against a 7 day average of 30.3 per day, which tells you the feed's daily volume is uneven enough that both regimes exist inside the same product.
What switching it on actually changes
Two things change and only one of them is the one people expect.
Frequency changes, obviously. A class you took four times a week because that is when you were at the screen becomes a class that takes every instance, including the 05:30 one and the 22:21 one, both of which appear in the capture. Your realised sample size per month goes up, which is good for learning and immediately larger for risk. Size the automated version off the new frequency, not the old one, because the same per-trade risk at three times the count is three times the exposure.
The other change is that you are no longer there. Every soft assumption you were unconsciously enforcing, the days you did not trade because the market felt wrong, the instance you skipped because you had already lost twice that morning, disappears. Some of those were superstition and some of them were risk management, and you will not know which until the automated version has run for a while.
So start it at a fraction of your manual size. Not because the class is unproven, you already proved it, but because the automated version is a different sample of the same class and it deserves its own small track record before it gets full size.
Write the demotion rule before you write the promotion
The decision that matters is not which class goes on. It is what takes it off, and that has to exist in writing before anything is switched on, because after it is running you will be negotiating with a position rather than with a rule.
Two triggers are enough. A hard one, stated as a drawdown in dollars on that class specifically, at which the route is turned off regardless of what you think is happening. And a soft one, stated as a count, where a fixed number of consecutive losses puts the class back on manual for a stretch so you can watch instances again with your own eyes.
Keep the two numbers on the same page as the class definition. A tagged class with a definition, an evidence log, a size and a demotion rule is a small piece of infrastructure that will still make sense to you in six months. A class that exists only as a filter you rebuilt this morning is a habit, and habits do not survive a bad month.