How matching works

Three vocabularies, one translation system

Matching connects three things that are written in different languages:

• Your outcomes. The statements you select for your brief, written in buyer language: what you need to be true after you deploy something, not which product type to buy.
• Documented features. The capabilities recorded on each product listing. These are researched per Category and named consistently across products, so the same capability means the same thing wherever it appears.
• The routing between them. A hand-curated table that says which features count as evidence for which outcome, and how strongly. This is editorial work, maintained by us, and it is the whole brain of matching: the ranking is only as good as this table.

Every route carries a strength: a feature that directly covers an outcome contributes a higher weight than one that only approximately covers it, so near-misses count without dominating.

What gets scored

The outcomes you selected in your brief are the scoreboard. If you rewrote an outcome in your own words, it still scores exactly like the original: editing the text doesn't change the matching underneath it. Questions about positioning, procurement, or vendor process are context for your export, not capabilities, so they are not scored.

Outcomes you wrote yourself from scratch are shown alongside the results but not currently scored.

How candidates are selected

Candidate products are pulled from the whole catalog by capability, not by Domain or Category. Any published product carrying at least one feature your outcomes route to is eligible, wherever it is classified. A platform from an adjacent Domain that genuinely covers your outcomes will appear; a product in the “right” Category that covers nothing will rank at the bottom rather than being propped up by its label.

Results are ranked rather than filtered. Weaker matches sit lower in the list instead of being dropped. Outcomes covered by no product at all are called out above the results, because a visible gap is more useful than a misleading match.

Reading a result row

Each ranked product shows its coverage as a fraction of your requirements: your selected outcomes, the feature requirements those outcomes seed for you to edit, and any requirements you added yourself, each with a check or a dash. Below the outcomes, the row lists exactly which documented features produced the match, labeled “Matched on these features”. That list is the evidence: if it does not convince you, distrust the rank, not your judgment.

Two guardrails adjust how rows rank without changing what they show. A product whose only matched features are broad capabilities carried by most of the candidate set is flagged as matched on broad capabilities and sinks in the ranking, because a capability nearly everyone has does not distinguish anyone. And when overall coverage in an area is thin, the builder will say so plainly and ask what you are looking for.

Requirements you add yourself

Requirements of your own join the ranking two ways. Compliance certifications and required integrations you set in your brief's environment section arrive pre-selected on the matches page, and so do the capabilities your outcomes target, ready to edit. You can then continue adding more of those, plus capabilities from the Categories your results matched in. Each requirement joins the coverage count, so a product's fraction reads met over total across outcomes and requirements together, and the ranking re-orders. Nothing is filtered out, and each row shows which of your requirements it meets and which it does not.

This is deliberately additive. Requirements can promote a product, but the outcome evidence underneath never changes.

Domains without a live evaluation pack

Outcome scoring requires an evaluation pack for your Domain. Where one is not live yet, the matches page starts as a plain listing of the Domain's products in alphabetical order. Explicit requirements still rank: pick capabilities, compliance certifications, or integrations and the list reorders by how many each product meets, with products that carry a required capability joining from the wider catalog. Your brief still exports in full; we just will not fake outcome coverage we cannot back.

Why we publish the method and not the table

The routing table itself is the one part of matching we do not publish row by row. Feature names are public on every product listing, and every match shows the features it matched on. But publishing the full outcome-to-feature table would hand vendors a recipe: claim these exact features to rank on these exact outcomes. Since features are documented from vendor materials, that would erode the evidence the ranking depends on.

So the transparency contract is: the method is public, the weights and guardrails are public, and every individual result shows its evidence. The only thing kept private is the complete mapping, and that is a defense of the ranking's honesty, not a lever anyone can buy.

Keeping it honest over time

The routing table couples two vocabularies that evolve independently: outcomes in evaluation packs and the feature catalog. A rename on either side would break a route silently, so an automated integrity check runs nightly against the live catalog and fails loudly on any route that no longer resolves to a real feature. Coverage gaps surface in the same check and feed what the catalog researches next.

Vendors don't influence matching or ranking. There is no paid placement, no sponsored rank, and no way for a vendor to see or edit the routing table. The way a product ranks higher is to document a capability it actually has.