We reviewed 20 AI vendors across 60 official-source observations. Here is what the baseline can—and cannot—tell you.
An honest account of Scraper.io's first reviewed AI vendor baseline: its scope, coverage, evidence mix and missing temporal proof.
Written by
Scraper.io
Editorial
The first Scraper.io market is a deliberately bounded AI vendor baseline. It covers 20 vendors and 60 successful official-source observations captured on 4 August 2026. The reviewed output contains 90 populated values across a possible 240 fields.
Those numbers describe a useful baseline, not a finished live product. Sixty-five populated values have direct evidence and 25 are explicitly inferred. The collection does not yet contain reviewed historical product events, so it cannot honestly prove how well it tracks change over time.
Why start with AI vendors?
AI vendors publish a rich set of official material: product pages, documentation, pricing, integration lists, trust information and release notes. That makes the category useful for testing whether one schema can hold both commercial and technical facts.
The goal was not to claim an exhaustive database. The 20 companies were a schema and evidence test: can Scraper.io create a reviewed current view, preserve supporting observations and leave unsupported fields empty?
What the baseline contains
Each vendor has a stable identifier, canonical domain and a set of fields covering its summary, products, target customer, public pricing, free access, enterprise offer, API or SDK, open-source status, deployment, integrations, trust claims and latest product event.
The collector keeps the normalized candidate output separate from the reviewed output. Raw observations remain available as the evidence ledger, while recorded editorial decisions can be reapplied after a refresh.
- 20 reviewed vendor rows
- 60 successful official-source observations
- 12 possible fields per vendor, or 240 possible values
- 90 populated values after editorial review
- 65 directly evidenced values and 25 labelled inferences
What editorial review changed
Structured extraction can quote accurate text and still place it in the wrong column. A security statement can be mistaken for a deployment claim; a pricing page can describe a bundled product rather than the API being researched.
The editorial pass rejects unsupported assignments and moves values only when the captured source supports the new field. This lowers visible coverage, but the resulting table is more honest than the candidate extraction.
Coverage is useful only with its denominator
Saying that the baseline contains 90 reviewed facts sounds substantial. Saying that those values fill 90 of 240 possible field positions is more informative: 150 positions remain empty.
An empty field can mean the official sources did not state the answer, the source was outside the bounded collection or the evidence did not survive review. The baseline does not turn those states into guesses simply to make the table look complete.
The direct-versus-inferred split matters
Of the 90 populated reviewed values, 65 are directly evidenced in the captured snapshot. The remaining 25 are labelled inferred and retain the observations used to reach the interpretation.
That distinction allows different workflows to set different standards. An exploratory market map may use a cautious inferred category. A procurement or compliance decision may require a current direct statement and human review.
What the baseline cannot prove yet
The collection has no reviewed historical product events. It can show what the inspected official sources supported on the observation date, but not yet demonstrate reliable detection of pricing, packaging or product changes across time.
Calling the current artifact a continuously maintained change feed would overstate the evidence. Temporal proof requires another snapshot, stable entity and field matching, before-and-after events and review of both missed changes and false positives.
The next benchmark must test change precision, recall and evidence validity. A single current snapshot cannot cash a promise about monitoring history.
What happens next
The next useful step is not adding hundreds of vendors. It is refreshing a smaller stable set, recording immutable observations and reviewing the events produced between snapshots.
Customer feedback must also be captured at the value level. A useful market is not defined by coverage alone; it is defined by whether accepted, evidenced changes improve a real decision without creating an unmanageable review burden.
The baseline is evidence that the collection and editorial workflow can produce an inspectable current table. It is not evidence of demand, retention or temporal accuracy. Publishing both the useful result and its limits is part of the product standard Scraper.io is trying to build.