Skip to main content

Universe Scanner

Who it’s for
Users who know what conditions they want and need the instruments that meet them
Assumes
You have read the discovery vocabulary

Where Opportunity Radar runs three fixed detectors and tells you what it found, the Universe Scanner runs your filters over a named universe and tells you which instruments passed, and, just as importantly, which failed and why.


What is this?

A filter engine over an instrument universe. You define criteria (metric, operator, value) and the scanner evaluates every instrument in the universe against all of them, returning matches with the metric values that produced the match.

Why does it exist?

Two reasons the Radar cannot serve.

Your condition may not be one of the three detectors. "Above the 200-day moving average, in the top quartile of 60-day return, with turnover above ₹50 crore" is a perfectly reasonable screen and no detector expresses it.

A rejection is information. The scanner reports why each instrument failed. That turns a screen from a black box that returned four results into something you can debug: was the filter too tight, or was the data missing?

How does it work?

StepStageDetail
1UniverseThe instrument set you selected
2MetricsComputed per instrument
3Your criteriaMetric, operator and value
4Matches and rejectionsPassed, or failed with a stated reason
5RankingBy the metric you chose

Metrics

Every metric declares four things that matter:

PropertyWhy it matters
CategoryPRICE, LIQUIDITY, MOMENTUM, VOLATILITY, TECHNICAL, QUALITY, FUNDAMENTAL
UnitPRICE, PERCENT, CURRENCY, SHARES, RATIO, SCORE, COUNT
Minimum barsSessions of history the metric needs to be meaningful
AvailabilityWhether a feed exists for it at all

Two of those deserve emphasis because they are where most confusion about screeners comes from:

Below its minimum bars, a metric is ABSENT. Not zero

A 60-day return computed on 30 bars is not a flat 0%. It is not a return. The scanner reports it as unavailable rather than as a number, so an instrument with insufficient history is not silently ranked as if it had a neutral value.

Unavailable metrics are shown disabled, not hidden

Where no feed exists, the metric appears greyed out with a reason rather than being removed from the list. A silently missing option looks like a product gap; a disabled one with a reason is a data gap, and the difference matters when you are deciding whether to trust a screen.

Operators

GT, GTE, LT, LTE, BETWEEN, OUTSIDE.

Criteria

One testable statement about an instrument, plus the words to explain it. Criteria are reported, not applied, a criterion tells you "strong trend, outperforming the benchmark, liquid enough to trade" in language, separately from the filter arithmetic that produced the pass or fail.

Archetypes

Pre-built scanner definitions for four intents, as a starting point rather than a constraint:

ArchetypeShape
MOMENTUMReturn and trend-position criteria
BREAKOUTRange-position and volume criteria
MEAN_REVERSIONExtension-from-mean criteria
LIQUIDITYTurnover and volume floors

Load one, then change it. The archetype is a template.

Rejections

Every instrument that did not match carries a reason:

ReasonMeaningWhat to do
FAILED_FILTERThe metric was available and did not passYour filter is working. Loosen it if the set is too small
METRIC_UNAVAILABLENo value for that metric on that instrumentA data gap, not a verdict on the instrument
NO_BARSInsufficient price historyThe instrument is too new or too thinly traded

A screen returning three matches out of two hundred means something different depending on whether the other 197 were FAILED_FILTER or METRIC_UNAVAILABLE. This is the scanner's most useful output and it is easy to skip past.

Ranking

Matches are ordered by a metric you choose. Each metric declares a rank direction (higher_is_better, lower_is_better, or unranked) so ranking on a metric where "more" is not "better" is not silently wrong.

Runs

A scan is a run with a status: RUNNING, READY or FAILED. Runs are addressable, so a result set can be revisited rather than re-described.


How do you use it?

  1. Choose the universe and market.
  2. Load an archetype, or start empty.
  3. Add criteria, metric, operator, value. Unavailable metrics are visible and disabled.
  4. Choose the ranking metric.
  5. Run it. Read the matches and the rejection breakdown.
  6. Take a candidate into the builder, or save it.

Example

Illustrative. Not a real result.

Criteria

  • 60-day return GTE 12%
  • Close GT 200-day SMA
  • 20-day average turnover GTE ₹50 crore

Ranked by 60-day return, higher is better

Result: 7 matches from a 200-instrument universe.

Rejections: 168 FAILED_FILTER, 19 METRIC_UNAVAILABLE (60-day return needs 60 sessions; these have fewer), 6 NO_BARS.

What to take from it: the filter is doing real work, 168 instruments genuinely failed. But 25 were never evaluated on the return criterion at all, so the screen covered 175 instruments, not 200. That is the kind of thing a screener that only shows matches will never tell you.


Limitations

Point-in-time only. The scanner evaluates the current state. It is not a historical screen and does not tell you what would have matched last month.

Metrics are what exist. The metric list is the platform's, not arbitrary. A condition you can express in words but not in an available metric cannot be screened.

Minimum-bars gaps shrink your universe silently unless you read the rejections. See the example above.

A match is not an evaluation. Seven instruments passing your filters means seven instruments passed your filters. Whether the filters express something worth trading is your question.

Fundamental metric coverage varies. FUNDAMENTAL category metrics depend on your tenant's entitled data feeds. See Indicators.


Next