CityLike — Data Governance & Trust

This page documents how CityLike collects local-business data, how we measure its quality, what we deliberately withhold, and what we guarantee to agents and companies that consume our data through the MCP gateway.

It is written to be checkable, not promotional. Where our data is weak, it says so.

---

1. What CityLike is

CityLike is data infrastructure for AI agents covering local businesses in Central Oregon (pilot: Redmond, Prineville, Sisters, La Pine, Madras, Terrebonne). Agents do not scrape our website — they call structured tools over the Model Context Protocol (MCP) and receive JSON.

Our product is the data and its provenance, not a chat interface.

2. Where the data comes from

Source	What it provides	Provenance field
County / state open data (ArcGIS)	business name, city, category, coordinates	geo_source: google/osm/import
OpenStreetMap	POIs, addresses, coordinates	geo_source: osm
Public business websites	website, phone, short description	description_quality
Keyword classifier / LLM re-check	category assignment	category_source: keyword/llm, category_confidence

Every business returned by the gateway carries a provenance block:

"provenance": {
  "category_source": "llm",
  "category_confidence": "high",
  "description_quality": "ok",
  "geo_source": "osm",
  "last_checked": "2026-09-21T09:14:03Z",
  "verified": true
}

verified: true alone means only "this record matched its source query at import time". It is not a completeness or correctness claim — the other fields are.

3. How we measure quality (and the current numbers)

We audit our own catalog with an independent model judge (gpt-oss:120b) on random samples, and we publish the result. Method:

1. Field coverage — count empty values per key field over the verified set.
2. Category correctness — a judge sees the business name and city only (never the description: see §4) and decides whether the assigned category plausibly matches.
3. Description class — deterministic template detection plus a judge for the remainder.

Measured 2026-09-21 on a 200-record random sample:

• category correct: 63% (37% wrong → being corrected in a full re-classification pass)
• description usable as a source: 51%; 49% were machine-generated templates and are now suppressed
• field coverage: phone present 39%, website 73%, address ~1%, coordinates 77%

These numbers are the reason this page exists. We would rather publish 63% and fix it than advertise "verified" and lose the first integration.

4. What we withhold on purpose

• Machine-generated descriptions are not served. A large share of the catalog's descriptions were generated from the assigned category. That makes them fluent, category-consistent, and worthless as evidence — worse than empty, because they appear to confirm the record. The gateway returns them only when a judge has confirmed the text is genuine; otherwise the field comes back empty.
• No invented values. If a field is unknown, it is returned empty. Agents are expected to treat empty as "unknown", not as "none".

5. Audit trail

Every agent call to the gateway is logged — successful and failed:

• AnalyticsAgentCall: agent key, tool, query, city/category filters, hit/miss, latency, timestamp.
• /var/log/citylike/mcp_auth.log: authentication failures (invalid or revoked keys), with source address.

Logs exist to (a) let a customer reconstruct what their agent asked and received, and (b) detect key abuse. They are retained for 12 months and then deleted.

6. What we do NOT do with customer queries

• We do not train models on customer query logs.
• We do not resell or publish query logs, individually or aggregated with attribution.
• Query text is stored for the audit trail only; it is never joined to a customer identity beyond the API key that made the call.

This is our Zero-Data-Retention-style commitment for query content: retained for audit, never used for model training or resale.

7. Keys, limits, and revocation

• Access is per-key: x-api-key header, SHA-256 hashed at rest (we cannot show you the key back).
• Rate limits are per key (default 60 requests/minute; higher on request) and enforced at the application layer, with an nginx-level burst guard in front.
• A key can be revoked instantly; revocation takes effect on the next request.
• Auth failures are rate-limited and fed into fail2ban-style blocking for repeated abuse.

8. Corrections, claims, and opt-out

• A business owner can request a correction or removal; corrections are applied to the record and the change is versioned in the audit journal (BusinessQualityAudit).
• Removal requests are honored for the business record and its derived fields.

9. Known limitations (as of 2026-09-21)

• Address coverage is ~1%. Do not build on address; use coordinates (lat/lon) with geo_source, or city.
• Category accuracy is a work in progress (63% on the audited sample). Records carry category_confidence, so a caller can filter to high/fixed and ignore the rest.
• No exact-count tool yet. The gateway returns lists (bounded by top_n), not aggregate counts; a count_businesses tool is planned.
• Coverage is Central Oregon only. Pilot cities are listed in §1.
• The gateway does not know the world. It answers from our catalog. Where the open web and our catalog disagree about a business, treat our record as "what our sources said at last_checked", not as ground truth about the world.

10. Contact

Data questions, corrections, key requests: info@koper.pro