2026-03-06

Signal

Event-place relationship mapping breaks down when events are assigned to places based on geographic proximity rather than semantic relevance: the internal-mapper integration surface exposed this as a systemic issue affecting hundreds of entity relationships, not an edge case in a few records.

Evidence

• Project: internal audit: Two sessions on internal-mapper integration pipeline
• Focus: Mining articles and events from existing places in the internal-tourism-api data model; investigating how events relate to their parent places
• Problem found: Events appeared unrelated to their assigned statefare/place: geographic co-location was the assignment criterion, not topical relevance
• Debug approach: Traced event-place relationship mapping end to end; compared event categories and descriptions against place types
• Volume: 19 automated code-review sessions on internal-sync-server codebase

So What (Why Should You Care)

If you’re building a knowledge graph that links events to places, the assignment criterion you choose determines the quality of every downstream query against that graph. Geographic proximity is cheap to compute: it just compares coordinates. But it’s brittle: it assigns a “Downtown Jazz Festival” to a state park hiking trailhead because they’re in the same zip code. The resulting graph is technically complete (every event has a place) but semantically wrong (most events don’t belong to their assigned places).

Semantic relevance is harder to compute: it requires comparing event titles, categories, and description keywords against place type, name, and description. But it produces a graph that supports the queries you actually care about: “what events are happening at this type of venue?” or “which places have the highest event density for outdoor recreation?”

The internal audit audit pipeline uncovered this problem because it evaluates output quality, not just output presence. A simpler pipeline would check “does this event have a place assigned?” (yes, always). The quality audit asks “does this place make sense for this event?”: and the answer was often no. Auditing for semantic validity rather than structural validity reveals an entirely different class of problem.

The 19 code-review sessions on internal-sync-server reflect how fundamental this fix was: it required changes throughout the relationship-mapping layer, not just a configuration tweak.

The practical consequence of geographic-vs-semantic assignment is visible in the data queries the system supports. If a tourism app asks “what events are happening at hiking trails in the region?” and the events were assigned to their nearest geographic place (which might be a hiking trail) but actually belong to a different venue category, the query returns wrong results. The data model looks correct: every event has a place: but the answers are wrong because the assignments are wrong.

This is a form of data quality problem that’s harder to detect than missing values or null fields. Missing values are obvious. Wrong assignments look like correct data at first glance. You only discover them when you ask questions that depend on the assignment being meaningful. The two sessions today spent investigating this problem were driven by exactly that discovery: a query that should return plausible results was returning events that clearly didn’t belong to their assigned places.

The systematic nature of the problem: affecting hundreds of entity relationships, not a handful: is what makes it worth a fix at the architecture level rather than a manual correction of the affected records. Manually fixing today’s bad assignments doesn’t prevent new bad assignments from being created by the same algorithm tomorrow. The fix has to go into the relationship-mapping layer itself.

What’s Next

• Debug and fix event-place relationship mapping in the internal-mapper integration
• Define semantic relevance criteria for event-place assignment (title keywords, category matching, place type compatibility)
• Validate fixes against the problematic event cases found today

Log

• internal audit: two sessions on internal-mapper integration pipeline
• Investigated how events relate to their parent places in the internal-tourism-api data model
• Identified core issue: events assigned to places based on geographic proximity, not semantic relevance
• Debugged event-place relationship mapping for cases where events appeared unrelated to their assigned place
• 19 automated code-review sessions on internal-sync-server codebase