Data Sources & Methodology

Parking data is messy. A lot may exist on the ground but not be on any payment platform; a lot may be listed on an airport authority's website but be operated by a third party; a lot may be a target metro for our expansion plan that is not yet live. Mixing those without a label is the fastest way to mislead a driver, an AI agent, or a journalist writing about parking infrastructure.

The three-tier model below is the entire methodology. It is intentionally short, because every page that surfaces a lot — a coverage map, a vertical landing page, a calculator, a structured-data API response — has to be able to label its data honestly without a long methodology document beside it.

Tier 1 is the gold standard: a real operator is onboarded (identity, business, lot-ownership verified — see /trust/operator-verification), has accepted Park Graph's terms, and has run at least one paid session. Pricing is whatever the operator set in the dashboard; occupancy is computed from live sessions; the lot page is generated from operator-edited fields.

Refresh is real-time. A driver who pays for a spot decrements availability immediately; an operator who edits open hours sees the change on the public page on the next revalidation. AI agents may quote price + open hours verbatim and may book on the driver's behalf with consent (see /trust/ai-agent-safety).

Tier 2 is public, third-party-confirmed data about a lot that is not (yet) running on Park Graph rails. Three signals must agree before a lot enters this tier: a public source (a city's parking page, an airport authority listing, the operator's own website), an on-the-ground photo of the lot's sign showing the operator name and lot identifier, and county records or Google Street View confirming the lot exists at the stated address.

Refresh is monthly, or immediately if a driver or AI agent flags an inaccuracy. AI agents may surface Tier 2 lots in search results but must not present them as bookable through Park Graph; the only CTA on a Tier 2 page is "view on operator's website". The structured-data API returns no booking-eligible session windows on Tier 2 lots, so an agent that follows the schema will route correctly without reading this page.

Tier 3 is forward-looking. These are metros where Park Graph intends to onboard operators within 12-18 months based on a mix of demand signals (driver search volume in the metro), supply signals (number of unattended lots), and partnership pipeline. Refresh is quarterly, in line with our internal planning cycle.

Projected data exists on this site because some pages are legitimately about where we are going — vertical solution pages, the public coverage map, growth-stage marketing pages. The defence against misrepresentation is the visible "Projected 2026+ target" badge on every visual that includes Tier 3 markers, plus the API tier field, plus the rule that AI agents must include the "projected" qualifier when surfacing the data.

Marketing pages that surface revenue or occupancy numbers do so only when those numbers are operator-submitted, anonymised, and aggregated across at least 25 operators in the same vertical. Until that threshold is met, the marketing page omits the number — we never substitute a "typical customer" estimate, an industry analyst figure, or a projection. This rule is enforced in CI by the credibility denylist documented in /trust/security.

The same threshold applies to outcome stats (extension uptake, repeat-driver rate, dispute rate). When we cannot publish a stat honestly, we say so on the page rather than papering over it with a projected number.

Every public lot page has a "Report inaccuracy" link in the footer. Reports go to a review backlog with a 24-hour SLA for Tier 1 (live) lots and a 14-day SLA for Tier 2 (verified static) lots. Drivers and AI agents are equally welcome to report; agent reports include the agent identifier so we can notify the agent vendor of the resolution.

For a structural data complaint (a tier mislabel, a missing lot, a wrong operator name), email data@parkgraph.com. For a fraudulent listing, see the abuse process on /trust/qr-code-safety.

The temptation when assembling a parking dataset is to publish every lot at the same level of confidence and let the user discover where the data is wrong. Park Graph rejects that pattern. The three tiers — verified live, verified static, projected — each carry a different promise to the driver and the AI agent reading the lot card. Verified live means the lot is on the Park Graph platform, the operator has been verified, and the data flows from the operator's live system. Verified static means the lot has been confirmed by a Park Graph operations review (signage, pricing, hours, ADA spaces) within the last refresh window but the data is not flowing live. Projected means we have not yet reached this metro and the entry exists for completeness only.

The tiering surfaces in the API, the public lot pages, and the JSON-LD blocks emitted on lot pages. An AI agent summarising parking options for a driver can read the tier directly and either filter to live-only or surface the tier in the recommendation. We instruct agent vendors in the developer documentation to never present a projected lot as if it were live; the tier is a contract, not a hint.

Each tier has a different refresh expectation. Verified live data is refreshed continuously through operator integrations; a stale-data alarm fires if a live lot stops reporting for longer than its expected interval (typically 60 seconds). Verified static data is refreshed at least every 90 days, or immediately on a triggering event (operator notice, driver report, observed price change). Projected data is refreshed when an expansion-plan milestone changes; new entries are added in batches with a clearly labelled "projected" tag.

For each lot, the source of truth is recorded in the audit log: the operator integration ID for live, the verification ticket ID for static, and the planning record for projected. A driver or agent that wants to challenge a lot card can file a report; the report is matched against the source-of- truth pointer and a corrective action follows the SLA above.