Goal
Decide and codify what happens when two sources contribute conflicting facts about the same place — e.g. OSM says "no ramp at entrance", a user submission says "ramp present, photo attached".
Tracking under #10.
Why this matters
The API is a pure data layer (CLAUDE.md) — it doesn't decide accessibility for the user, but it does store one canonical value per fact per place. When sources disagree we have to pick one (or expose both). Without an explicit rule we'll pick implicitly and inconsistently.
Inputs we already have
Commit 009d937 added:
place_status — administrative status of the place record
user_verified — whether a verified user has reviewed this place
external_ids — which external sources contributed
These were added with this kind of resolution in mind. This issue makes the rules explicit.
Open questions
- Default precedence order: is it
user_verified user submission > unverified user submission > OSM > other automated source? Codify it.
- Per-fact vs. per-place: does precedence apply at the
A11yComponent level (per-component ramp / step / width) or the whole AccessibilityProfile? Per-component is more useful but more complex.
- Freshness: does an old high-precedence fact get overridden by a fresh low-precedence one after some staleness window?
- Conflict visibility: when sources disagree, do we keep the losing claim somewhere (audit log? a
conflicts table?) so clients or moderators can see disagreement?
- Interaction with
a11y.AuditFlags: flags are deterministic from properties — but which source's properties feed the flag computation when sources disagree?
Out of scope
- Implementing the precedence engine. This issue is the rule design.
- Manual override / moderation UI.
Acceptance
A short design doc covering: precedence ordering, granularity, freshness rules, conflict-retention strategy, and the interaction with AuditFlags. Implementation tracked as separate sub-issues.
Goal
Decide and codify what happens when two sources contribute conflicting facts about the same place — e.g. OSM says "no ramp at entrance", a user submission says "ramp present, photo attached".
Tracking under #10.
Why this matters
The API is a pure data layer (
CLAUDE.md) — it doesn't decide accessibility for the user, but it does store one canonical value per fact per place. When sources disagree we have to pick one (or expose both). Without an explicit rule we'll pick implicitly and inconsistently.Inputs we already have
Commit
009d937added:place_status— administrative status of the place recorduser_verified— whether a verified user has reviewed this placeexternal_ids— which external sources contributedThese were added with this kind of resolution in mind. This issue makes the rules explicit.
Open questions
user_verified user submission > unverified user submission > OSM > other automated source? Codify it.A11yComponentlevel (per-component ramp / step / width) or the wholeAccessibilityProfile? Per-component is more useful but more complex.conflictstable?) so clients or moderators can see disagreement?a11y.AuditFlags: flags are deterministic from properties — but which source's properties feed the flag computation when sources disagree?Out of scope
Acceptance
A short design doc covering: precedence ordering, granularity, freshness rules, conflict-retention strategy, and the interaction with
AuditFlags. Implementation tracked as separate sub-issues.