How matching works

What gets scored

Your requirement set is the scoreboard. A requirement is a capability, a compliance certification, or an integration, and each carries a priority of High, Medium, or Low. When what you add matches a name the catalog already tracks, the row takes the catalog's spelling and scores automatically against every product's documented data.

A requirement the catalog does not recognize becomes a custom row. Matching never guesses at custom rows: one counts as covered only when you mark it yourself in the scorecard, and until then it is unknown. Unknown never counts against a product; only an explicit miss does.

Where a check comes from

An automatic check means the product's listing documents the thing: the capability appears among its documented features, the certification or the integration is recorded on the listing. Matching is exact against that researcher-reviewed data, nothing fuzzy, so every check can be traced to the listing attribute that produced it.

Marks you set by hand in the scorecard carry into this ranking too, on the rows matching cannot read from a listing: your custom requirements. Automatic checks are never stored and never edited; they always restate what the listing documents.

How the ranking orders

Candidates are every published product in the catalog, wherever it is classified. Domain and Category labels grant no advantage: a product from an adjacent Domain that covers your requirements will appear. Products covering none of your requirements are left off the list.

Order comes from coverage weighted by priority. High-priority requirements count most, Medium counts normally, and Low is informational: it shows in the coverage fraction and never moves a product's position. Each explicit High-priority miss flags the row and sinks it in the order, because missing a must-have should cost more than any number of nice-to-haves can repay.

The number shown is always the plain fraction of requirements covered. The internal ordering weights are never displayed as a score, so a row can never look more precise than the data underneath it.

Reading a result row

Each row shows its coverage fraction and expands to the full breakdown: which of your requirements the product covers and which it misses, tallied per kind. An automatic check always points at something the product's listing documents, so the listing is where to verify any check you doubt. If the breakdown does not convince you, trust your own judgment over the rank.

Shortlisting from a row adds the product to your run, and the scorecard then tracks it side by side with your other picks, manual marks and commercials included.

Packs and matching

Loading an evaluation pack seeds researcher-curated capability requirements for your Domain. Matching treats a seeded row exactly like a row you added yourself, with the same priorities and the same scoring rules. Packs change where your requirement set starts, never how it scores.

Keeping it honest

Vendors don't influence matching or ranking. There is no paid placement and no sponsored rank. The way a product ranks higher is to document a capability it actually has, in materials our researchers can review.