# 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.