48 lines
1.6 KiB
Markdown
48 lines
1.6 KiB
Markdown
# 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.
|