Methodology
Each verification run starts from a document fetched from the product's registered official URL. During discovery, an AI service candidate whose official page redirects to a different host is not registered.
Each field observation is stored as a field assertion that cannot be updated in place, and carries one of these states:
Verified: a value confirmed by the cited official evidence (it cites that evidence)
Unknown: no evidence establishes the value (it cites none)
Unknown is NOT equivalent to 'free', 'not supported', or '$0'. This registry does not fill fields by inference. A field without evidence stays Unknown, and a published claim must quote text found in the stored official snapshot. Field metadata is a projection of the current field pointers: a new value is recorded as a new assertion and published by switching the pointer. An applied review-rule change can be undone by a rollback through an internal route, which restores the previous routing version.
On a schedule, the monitor compares the pricing and capability facts of a newly fetched official page with the previous snapshot of the same page. A difference moves the product to Change detected, and re-verification either returns it to published, if all cited evidence is still present, or holds it as Needs recheck. Detected changes (pricing or capability added or removed) are matched against Watches and notify the watching users. A newer version seen in a registry listing for a known entity is recorded as a version change event and matched against Watches.
Discovery and Verification are separate stages. Discovery records possible products without treating their fields as verified. Verification retrieves evidence from the product's official URL, links it to each field, and validates the claim before publication. A candidate service examined is a product recorded in that search run's Candidate Set and evaluated to exactly one of Match, Excluded, or Evaluation Error. The covered regions, languages, and sources are limited; a Candidate Set is not a complete catalogue of every service worldwide.
Search Audit: search runs from the search API, the results page and chat store their Candidate Set as a Search Audit, with one decision and its reasons per candidate, together with the candidate, result, exclusion and error counts and the count per exclusion reason. Exclusion reasons are counted per reason, so reason counts can overlap and their sum is at least the number of excluded candidates. A candidate whose data cannot be evaluated is recorded as an Evaluation Error instead of stopping the search.
Query interpretation and ranking: a natural-language query is first interpreted by rules into structured conditions (such as quoted hard requirements and a price limit) plus keyword terms. In keyword search (the search API and chat keyword retrieval), candidates are ranked by keyword match, and where the database provides a full-text index, a BM25 ranking over the same candidates is merged by reciprocal rank fusion. The fusion can reorder candidates but never adds one that the keyword ranking did not find.
Identity records whether an entity's official domain is backed by evidence fetched from that domain. Status is the product lifecycle state, and transitions made by the state machine are recorded in a state history. Freshness is the time each field's current assertion was recorded from its source, published per field. Risk on the entity page is derived from verified security-related fields.
Fetch safety: the crawler refuses a destination that resolves to a private address before any request is sent, and it honours robots.txt for web pages; a fixed set of documented public API hosts is exempt. Each redirect destination is validated again before it is followed.
Watch demand raises a product's priority tier (HOT, WARM or COLD).
Registry scope and supply discovery: AI Services, Agent Skills, MCP Servers, and Open-source AI Tools are first-class entities in one registry. Automated daily runs persist the source, cursor, fetch result, candidate outcome and fetch failures in a run ledger. Neither a region nor a fixed item count is a completion claim: source coverage gaps are recorded as pending tasks and discovery continues.
Update lifecycle: discover, identify, register, verify, publish, monitor, detect change, re-verify (return to published or hold for recheck), match Watches, and notify. After publication the monitor re-fetches official sources on a schedule and compares their facts. When re-verification cannot confirm the published claims, the product is held as Needs recheck, and a field without evidence stays Unknown. The system preserves Unknown / Needs recheck instead of guessing, and a Human Review task can be opened only for a defined exception reason.
Evidence and Freshness: every verified field retains its evidence, the location of that evidence, and the time its assertion was recorded. Products whose latest official snapshot is older than the re-check interval are fetched again within a per-run budget, and a changed fact sends the product to re-verification instead of leaving it Verified. Ranking is independent of advertising and commercial relationships.
AI automation vs Human Review: discovery, extraction, verification and monitoring run without a human step, and claims that pass the evidence check are published. Human Review is reserved for exception cases (Entity Merge, Pricing, Capability, Security Warning, Vendor Dispute) that automation cannot safely resolve; we do NOT put every claim through a manual sign-off. Identities are never merged across Entity Kinds.
How to request a correction or dispute: submit the affected item, proposed correction, supporting official URL, and a contact address through /correction. It is stored in an internal review queue in the Received state.