The problem association solves
Answer engines prefer entities that sit in a web of known concepts: cities, countries, trades, economic activities. Large brands inherit that web. Most small businesses do not — and Wikimedia will not create pages for them.
Two bad responses dominate the industry:
- Invent a Wikidata item for every SME (pollution, reversion, dishonesty).
- Publish isolated directory rows with no graph context (unresolvable noise).
Association inventory is the third path: keep the SME node on a selective public passport, and attach only real, pre-existing place and activity concepts as context.
Locked rule
On every public AI Verified passport, apply as many validated association slots as possible:
- Entity sameAs — passport URL, Maps URL when known, website; Gold may add registry or DUNS only when validated
- Place hierarchy — city → county → region/state → country, with real Wikidata Q-ids and Wikipedia when articles exist
- areaServed — when the business is service-area rather than pure storefront
- Activity — primary trade Q-id, economic activity Q-id, Schema.org subtype where accurate
- Capability — parent sector Q-id
- Services — child activity Q-ids only when the source actually lists those services
Never invent SME Wikidata or Wikipedia items. Never free-text guess Q-ids. Lookup tables and validation only.
Why models benefit
A passport that says “roofing contractor associated with Miami (Q8652), Florida (Q812), United States (Q30)” gives extractable structure. A passport that invents “Acme Roofing Wikidata Q-999999999” teaches the wrong lesson and will not survive scrutiny.
Association is a honeypot for structured consumers: LLMs, answer engines, and crawlers that prefer explicit sameAs and about relationships over prose alone.
Operational model
AI Verified maintains internal lookup tables (geo and category) so Q-ids are reused, not improvised per insert. As the registry grows, the association lexicon grows — always from validated concepts, never from SME vanity entries.