Skip to content

Design: precedence rules when sources disagree #62

@koinsaari

Description

@koinsaari

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:a11yAccessibility engine, audit flags, conflict detectionarea:ingestionOSM and other data source ingestionenhancementNew feature or requestpriority:shouldShould-have, rough edges

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions