MobilityOps/docs/07-data-quality.md

Data-quality rules

Run rules after seed/import, after relevant commands and through an explicit scan service. Rules must be deterministic and explainable.

DQ-01 Possible duplicate customer

Signals and example weights:

• exact normalized email: 60;
• exact normalized phone: 50;
• exact postal code: 10;
• strong normalized full-name similarity: up to 30.

Open an issue at score >= 70. Store individual signals; do not expose a mysterious AI-only confidence.

Resolution:

• merge into selected survivor;
• reject as not duplicate;
• defer.

Merge rewires booking references, preserves the loser as a tombstone and audits before/after values.

DQ-02 Missing required field

Required for active customers: first name, last name and at least one of email or phone. Required for active vehicles: registration number, make, model and location.

DQ-03 Odometer regression

Flag an inspection or maintenance reading below the canonical odometer. Never lower the canonical value automatically.

DQ-04 Booking overlap

Flag overlapping reserved or active bookings for one vehicle. Normal write APIs reject new overlaps; the seed/import path may create one controlled legacy conflict.

DQ-05 Vehicle status conflict

Examples:

• status available while an active booking exists;
• status rented without an active booking;
• status available while critical open quality issue exists;
• status maintenance with an active booking.

Lifecycle

Detection is idempotent by (rule_type, entity_type, entity_id, evidence fingerprint) while open. Resolved issues remain historical. Reintroduced evidence creates a new issue linked to the prior issue where useful.