How Community Data Works is a dedicated GeoLira view for this part of the observatory. It combines the route-specific interface with the same source, freshness, privacy and evidence boundaries used across the platform.
Several gates separate the form from the aggregate
A check-in first passes schema and consent validation. Only known fields, 1-5 score ranges, approved categories and an optional two-letter country code are accepted. The system also checks local_date and rejects records that violate the contract. Only accepted records are eligible for aggregation.
The structural filter removes duplicates and out-of-window records
CommunityPulseAbuseFilter requires the correct schema, evidence class, consent version and submission_id. It rejects duplicates, invalid timestamps, unsupported locale, invalid country codes and values outside the contract. This filter does not fingerprint users and is not a promise of complete resistance to automation, so the submission layer also requires an external rate limit.
Aggregation preserves privacy and evidence boundaries
After filtering, statistics are published from the first eligible submission and a category from its first response. As more check-ins arrive, values become the mean of the current sample. Individual submission identifiers do not become public, but with a sample size of 1 an aggregate may reflect one person's response. The aggregate remains COMMUNITY_SELF_REPORT and Community Pulse remains AUTHORED_INDEX.