Give the same scanner output to two analysts on your team and ask each to bring back twelve names for the Monday list. If the overlap is four, you do not have a research process, you have two research processes that happen to share an office. That dispersion will show up later as unattributable performance, and it will show up sooner than that as an awkward silence in a review when someone asks why a name was dropped.
The fix is boring and it works. Write the triage down as an ordered ladder of rejections, put it under version control, and require that anything cut is cut by a named rung. Two analysts running the same ladder on the same list should land within a name or two of each other. If they do not, the ladder has a rung that is doing judgement work it should not be doing.
Undocumented triage is unmanaged risk
A scan that returns a couple of hundred names is not a research output, it is a queue. The value the desk adds is the compression, and compression is where the actual investment decisions get made. The name that never reaches an analyst's screen was rejected just as firmly as the one that got a full write-up and a no.
The problem is that undocumented compression is invisible to every control you have. Your attribution runs on positions taken. Your risk system runs on positions taken. Nothing in the stack sees the hundred and eighty-eight names that were quietly dropped, which means a systematic bias in the triage can run for a year without leaving a trace. If your junior analyst has been silently rejecting anything under two billion of market cap because that is what he did at his last shop, the effect on your book is real and your attribution will never tell you.
The second reason is defensibility. When a position goes wrong the question in the review is rarely "was the thesis good". It is "what else did you see at the time, and why did you pick this one". A ladder answers that in one line. Memory does not, and memory reconstructed six months after the fact is worse than no answer because it sounds like an answer.
Run the ladder in cost order, not importance order
The ordering principle is analyst minutes per rejection, cheapest first. This sounds like an efficiency point and it is partly that, but the real reason is contamination. A rung that requires an analyst to read about the company has already exposed that analyst to the story, and once someone has read the story they are no longer a neutral judge of whether the name clears a liquidity floor.
So the mechanical rungs run first, and they run on data the analyst does not have to interpret. Ideally they run before the list is distributed at all, as a filter on the queue rather than a task for a person. Sentinel already does some of this for you at the filter level, since direction, asset class and whether the underlying market is open are all selectable on the results view. Anything you can express as a filter should be a filter, because a filter is reproducible by construction and a habit is not.
The four rungs and what each is allowed to reject on
The ladder I would defend has four mechanical rungs before any human judgement enters. Each one is a threshold with a number, and the number lives in a config file rather than in a head.
- Tradeable size. Median dollar volume over a stated window, against your intended position and your participation cap. If a full position would take more than a set number of days to build at your cap, the name is out. This rung does most of the killing on any scanner output and it should, because it is the one rung that is purely about you rather than about the company.
- Borrow, for anything on the short side. Availability and indicative rate, checked against a ceiling in basis points. A short thesis you cannot finance is not a thesis. The direction split panel makes this cheap to apply, because you can separate the short candidates and run the borrow check as one batch rather than one name at a time.
- Mandate. Domicile, listing venue, instrument type, market cap band, sector exclusions, and anything your IMA or your ESG screen forbids. This rung is not negotiable and it should be automated, since a human applying an exclusion list by memory will get it right most of the time, and most of the time is the wrong standard for a compliance constraint.
- Event proximity. Distance to the next scheduled catalyst. This one cuts in both directions depending on your strategy, which is exactly why it has to be written down. A desk that wants to be positioned before an event and a desk that refuses to hold through one will build different books from the same scan, and both are defensible. What is not defensible is the same analyst applying it one way in March and the other way in June.
Two hundred names through those four rungs typically leaves something in the low tens. That is the number a team can actually work, and everything below this line is where analysts start earning their salaries.
The rungs that must not be in the ladder
A triage ladder fails in a specific way, which is that it grows a rung that reads like a threshold but is actually a judgement. "Reject if the story is weak" is not a rung. "Reject if we have looked at it before and passed" is a rung that will slowly turn your process into a closed loop, since the reasons you passed eighteen months ago have an expiry date that nobody is tracking.
The one I would watch hardest is any rung that references the scanner's own confidence or ranking. Ordering the queue by the tool's score is fine. Rejecting on it is not, because you have then delegated an investment decision to a ranking whose construction you did not specify and cannot inspect, and you will not be able to explain it in a review. Use the ranking to decide what gets looked at first. Use your own thresholds to decide what does not get looked at at all.
Calibrating the ladder once it exists
A ladder is only worth having if you measure it, and there are two cheap measurements.
The first is the rejection rate per rung, logged per scan. If a rung is rejecting almost nothing, it is ceremony and it should either be tightened or removed. If a rung is rejecting almost everything, it is not a triage step, it is your universe definition in disguise, and it belongs upstream at the scan configuration rather than downstream in the triage. A liquidity rung that kills eighty percent of every scan is telling you that the scanner is being pointed at a universe you cannot trade.
The second is a reversal log. Every time someone overrides a rung to keep a name, that override gets a line, a reason, and a name against it. Overrides are not misconduct, they are information. A rung that gets overridden four times a quarter has a threshold set in the wrong place, and the log is the only artifact that will ever tell you so. It also does something useful in reviews, which is that it converts "we made an exception" from an admission into a record.
The last thing worth writing into the procedure is the freshness check, because it is the one failure that survives a perfect ladder. A scanner with auto-run disabled will serve the same preserved queue every morning, and a queue that has not moved in weeks will pass all four rungs exactly as it did the first time. Log the scan timestamp alongside the shortlist. If the two analysts agree on twelve names drawn from a scan that ran three months ago, the agreement is not evidence that the process works.