Selection criteria
What each engine weighs when it chooses who to name — which criteria are gates, which vary by segment, which are preference signals — and whether engines can see that you clear the gates.
Overview
Before an answer engine recommends anyone, it narrows the candidate brands through criteria in two stages. Gates come first: safety, compliance, certification, eligibility — fail one and you are dropped outright, however strong you are on price or reviews. The survivors are then weighed together on the segment criteria and the preference signals.
Selection criteria makes those criteria visible — per engine, in the engine's own words. It is derived by asking each of your tracked engines what defines the best offering in your category and industry, then structuring the answers into the criteria model. Because engines emphasise different things, the per-engine comparison is itself the deliverable: the same criterion can be a gate on one engine and a scored preference on another.
Gate clearance — the first thing on the page
The page leads with the question that matters most: can the engines see that you clear the gates? One table, one row per gate the engines name: which engines name it, which recorded fact answers it, and its status.
| Status | Meaning |
|---|---|
| Verifiable | An approved fact in your Claim library answers the gate and carries a source URL — engines can find the evidence. |
| No source URL | A fact answers the gate, but nothing in it points at a page an engine can verify. |
| Missing | No recorded fact answers this gate. An action is created in your Action list. |
Matching is name/token-based on every read, with a judge-assisted pass for the harder cases during each derivation run. Only an approved fact inside its validity dates clears a gate — a gate cleared by a claim nobody approved is not cleared. Clear the missing gates first: in regulated categories, a missed gate removes you from consideration before any other work can matter.
The criteria model
Every criterion carries two independent classifications:
Kind — how an engine applies it
| Kind | Behavior | Examples |
|---|---|---|
| Gate | Pass/fail, applied first. Failing removes the candidate entirely. | Certification, compliance standards, safety ratings, eligibility |
| Segment | Varies by buyer and context; resolved per segment. | Price tier, location and availability, product type |
| Signal | Lifts a candidate but never eliminates it. | Trust, reviews, reputation, recency |
Layer — where its meaning comes from
| Layer | Meaning | Examples |
|---|---|---|
| Universal | Applies in almost every industry. | Price, trust, availability, reviews, recency |
| Category | Shaped by the kind of offering — re-weights the signals. | Quality and safety as the category defines them |
| Industry | Concrete instances specific to your industry. | Named certifications, standards, technical specs |
The per-engine comparison
Below the gate table, one matrix: each criterion on a row, each engine in a column, the cell saying whether that engine treats it as a gate, a segment criterion or a signal. Open a row to read the engine's own words — the evidence quote behind each classification.
Deriving your map
- Set Category and Industry in Project Settings → Business Context (the setup wizard's business step collects the same fields). The derivation battery interpolates both, so they are required.
- Run the derivation from the Selection criteria page (or via the MCP tool
run_criteria_derivation). Each tracked engine — your active AI models, one per provider, up to eight — is asked what defines the best offering in your category and industry this year, followed by a probe on how those criteria differ across customer segments. - A judge model structures each answer into criteria with a kind, a layer, and a short verbatim evidence quote from the engine's own response, so every classification is explainable.
- Re-running updates in place — one map per engine, upserted, never duplicated.
Each derivation run counts as one AI analysis against your plan's daily allowance, regardless of how many engines run.
Honest caveats
- The map is derived from a single elicitation per engine — not a multi-run distribution. Treat it as the engine's stated worldview at derivation time, not a measured frequency.
- Engines re-weigh criteria over time. Re-derive periodically — quarterly is a reasonable default, or after major model releases.
- The map never ranks or scores criteria. The framework's measurement unit is inclusion frequency, and criteria are qualitative requirements — presenting them as a ranked list would misstate how engines choose.
Availability
Selection criteria requires the Advanced AI Insights feature (Professional plans and above). Deriving requires execute capability on the project; viewing is available to all project roles, including viewers. MCP parity: get_criteria_map (read) and run_criteria_derivation (execute, same gates and quota as the page).