You open the scanner on Thursday and eight of the ten names were there on Wednesday, and six of them were there last Friday. The first time this happens it feels like confirmation, as though the tool has found something durable and is politely insisting. After two weeks it starts to feel like the scanner is broken. Usually it is neither. Repetition is almost always an artifact of how the search was set up, and the specific artifact is diagnosable in about five minutes.
There are three candidate causes and they are worth ruling out in order, because the first one is free to check and people almost never check it.
First, confirm the scan actually ran
A scanner that has not run will serve you its last result set indefinitely, and a stale result set is visually identical to a fresh one. Same layout, same tickers, same confident little direction labels. Nothing on the row itself tells you it is three weeks old.
Sentinel puts the answer in the header. There is a last-scan timestamp, a counter for how many scans ran today, and an auto-run state with a kill switch next to it. At the capture in the screenshot below, the panel showed sixty-one active signals alongside zero today and zero this week, with the last scan stamped May 14 2026 and auto-run switched off. That is a scanner in a museum. Every one of those sixty-one lines would look perfectly normal on a row-by-row basis, and all of them describe a market that has since moved on.
So the first diagnostic is not clever. Read the timestamp. If the scan has not run since you last looked, you have not found persistence, you have found a cached page.
Repetition is a property of your universe
Assume the scan did run. The next question is how many things could possibly have appeared.
People underestimate this badly, because the universe is usually set once and then never looked at again. If you have the asset class filter on stocks, a market status filter of open now, and a size or volume floor somewhere in your request, the set of names eligible to appear may be a few hundred rather than a few thousand. Ask any ranking system to return the top ten from a pool of three hundred and the top ten will be sticky, because ranking is a continuous function and the market does not reshuffle three hundred names overnight.
This is why the same scan feels different on crypto than on equities. Sentinel's class filters cover stocks, crypto, forex, commodities, bonds and ETFs, and those pools have wildly different sizes and wildly different turnover at the top. A ten-name list off a bond universe repeating is nearly meaningless. A ten-name list off a broad crypto universe repeating is worth a second look, because there is a lot more that could have displaced it.
The test takes one run. Ask for fifty rows instead of ten. If rows eleven through fifty are full of names you have never seen, your universe is fine and your cap was the problem. If the whole fifty looks familiar, the universe is small and you are seeing all of it.
The liquidity floor does more work than you think
The second structural cause is the floor, and it is the one I would bet on if I had to pick blind.
Every sensible retail scan has some floor on tradeability, because a name that trades forty thousand dollars a day is not investable at any size you would bother with. But floors compound with conditions in an unhelpful way. The names that clear a volume floor are, definitionally, names with sustained attention. The names with sustained attention are the ones that keep generating whatever condition you are scanning for. So the floor does not just remove the illiquid tail, it selects for exactly the population that will keep reappearing.
Work an example. Suppose you have a $6,000 account, you cap any single position at $1,500, and you want to be no more than one percent of a day's volume so you can get out without being the tape. That gives a floor around $150,000 of daily dollar volume, which is a genuinely low bar and probably fine. Now suppose you copied a floor from somewhere and it sits at $20m a day. Same account, same conditions, but you have just restricted yourself to a pool where the incumbents rarely change, and the repetition follows mechanically. The floor was not wrong in any absolute sense. It was wrong for your size by two orders of magnitude.
Three edits that break the loop
Assuming the scan is fresh and you still see the same faces, these are the three changes worth making, in the order I would make them.
- Rank on change, not level. Most repetition comes from asking for the highest reading of something. The highest reading is a slow-moving quantity. Ask instead for the largest move in that reading over a short window and the list turns over, because a name that has been at the top for a month has no change left to show. This one edit fixes more repetition than the other two combined.
- Shorten the window so names have to requalify. A condition measured over ninety days keeps a name eligible for ninety days. Measured over five sessions, a name has to earn its place again this week. Sentinel's urgency filter is a coarse version of the same idea, since Immediate, Developing and Watch are three different staleness tolerances, and running everything at the widest one guarantees a stable list.
- Exclude the incumbents for one run. Take the ten names you keep seeing, put them on an exclusion list, and run the scan again. This is a diagnostic more than a fix. If what comes back is ten reasonable names you had simply never been shown, the ranking was hiding a real opportunity set behind a short cap. If what comes back is obvious junk, the incumbents were incumbents for a reason and you can stop worrying.
When the repeat is telling you something real
Sometimes the same names keep coming back because the same names keep qualifying, and that is a genuine finding rather than a bug. The way to tell is whether the name is reappearing for the same reason or a new one.
A ticker that shows up ten sessions running on one trigger that fired once and has not refreshed is a single event being reported ten times. That is one data point wearing a costume. A ticker that shows up ten sessions running because the condition keeps being met on new days, with a new trigger date each time, is persistence, and persistence in a condition is information.
This is why the trigger date matters more than almost anything else in a scanner row, and why it is worth insisting on having it as a column. Without it you cannot distinguish an echo from a repeat, and those two things call for opposite responses. The echo means your scan is misconfigured. The repeat means the market is doing something and you have been staring straight at it for two weeks while assuming the tool was stuck.