FactGrid.org / Methodology

FactGrid // METHODOLOGY

How we collect data, what our audit tiers mean, and how we handle conflicts.

Status: Independent Verification Active Last Updated: 2026-04-25

Data Quality Summary

Computed at build time from live database

Independently Audited 31 / 37 84%
Data Coverage 37 / 37 100%
Last Pipeline Run 2026-04-24 Daily cycle
Open Conflicts 0 6 resolved
Update Frequency Daily Automated scraping
License CC BY 4.0 Open access
Status: Active Revision: Q1 2026 Pricing Audit Protocol Reference: factgrid.org/methodology

01. Data Collection

We run an automated scraper daily against a fixed list of public vendor URLs — pricing pages, API documentation, and public trust centers. We do not contact vendors, use affiliate dashboards, or request data directly from vendor representatives. Everything we collect is publicly accessible.

Each entry we capture includes three things: the source URL (the exact page we scraped), a timestamp (when we captured it), and a SHA-256 hash of the canonical payload (so you can verify the data hasn't changed). These are stored in our Trust Ledger, which is public.

What we scrape

  • Pricing pages Plan names, per-seat prices, billing cycles, minimum seat requirements
  • API documentation Rate limits, authentication methods, endpoint availability
  • SLA / Trust Center Uptime guarantees, incident response times, data residency
  • Feature pages Core feature availability, integration listings, platform limits

02. Verification Tiers

Every entity in FactGrid has a data status label that tells you exactly what work we did — and what we didn't do. There are four tiers:

INDEPENDENTLY_AUDITED Manual audit by FactGrid

We reviewed this data manually against primary source documentation. We checked for conflicts between the marketing page and the actual service agreement or API spec, resolved any discrepancies, and committed the final values. This is our highest confidence tier.

INDEPENDENT_AUDIT Automated extraction only

Data was pulled automatically from the vendor's public pages and has not yet been manually reviewed. The data is independently sourced (not vendor-supplied), but we haven't cross-checked it against a secondary source. Take it as a starting point, not a final answer.

PENDING_REVIEW In the audit queue

This entity has been extracted but is waiting for a manual review pass. We may have identified potential conflicts that need human judgment before we're comfortable calling it audited.

CONTACT_SALES Pricing not published

Automated scraping confirmed this vendor does not publish list prices publicly. Pricing is contract-based and varies by company size, modules, and negotiation. We do not fabricate pricing estimates. Other data points (API limits, SLA terms) may still be available.

What we never do: We do not accept data from vendor marketing teams, PR contacts, or "authorized representatives." We do not let vendors approve, edit, or remove their entries. The data is ours, sourced from public records.

03. Conflict Resolution

When two sources disagree, we don't silently pick one. We log the discrepancy as a conflict record (CR ticket), document both values with their sources, resolve it against the higher-authority source, and publish the resolution publicly. Both the original conflict and the resolution are permanently visible in our Conflict Ledger.

"Higher authority" follows a strict hierarchy: live API response beats a pricing page. Enterprise service agreement beats a marketing page. We never resolve conflicts by choosing the lower number or the vendor-friendly version.

Real examples from our conflict ledger

CR-1024 Monday.com · Pricing / API Tiers · 2026-03-19 ● RESOLVED
What we found

Monday.com's public pricing page listed plans "starting at $14/seat/month." Our automated checkout flow extraction captured the actual billing minimum: 2 seats required, and the live checkout total at $19/seat. A $5/seat discrepancy between the marketing page and the checkout, plus an undisclosed minimum seat requirement.

How we resolved it

Live checkout extraction took priority over the cached marketing page. We adopted $19/seat and logged the minimum seat requirement as a pricing constraint visible on the entity page.

CR-1028 HubSpot · SLA / Uptime · 2026-03-28 ● RESOLVED
What we found

HubSpot's marketing website quoted 99.9% uptime SLA. Their enterprise service agreement (ESA) specified 99.98% for the US-EAST-1 region. The marketing page was more conservative — which is unusual — but technically a different number.

How we resolved it

The enterprise service agreement is the binding document. We adopted 99.98% and noted the marketing page figure as a stale cached value. The ESA date is logged as the source authority timestamp.

Conflict resolution rules

  • A. The higher-authority source value is provisionally adopted until the CR is closed.
  • B. Resolution requires documented evidence from a primary source (MSA, API spec, live endpoint).
  • C. An open conflict record does not block data from being displayed — it is surfaced inline on the entity page.
  • D. Resolved CRs are retained permanently in the public ledger. We don't delete our mistakes.

04. Using This Data

All data is published under CC BY 4.0 — free to use, republish, build on, or feed into AI systems. Attribution required. No license fee, no paywall, no API key for read access.

Access the full dataset via our open API. If you find an error, submit it via our Corrections Policy — we review and respond.