When two student records conflict, do not quietly replace one with the other and do not let the newest entry win by default. Keep both claims, identify where each came from, compare them with the evidence that controls the next decision, and mark the fact unresolved until an authorized person resolves it. While the conflict is open, block only the actions that depend on that fact. Then preserve the resolution, reviewer, time, reason, and superseded value.
For a driving school, a conflict might be a date of birth typed during signup that differs from a permit, a permit expiration extracted from an image that differs from a staff review, or a road-test appointment time that does not match the latest agency confirmation. The important question is not “Which field should we keep?” It is “Which decision uses this fact, and what evidence is strong enough for that decision?”
Separate a claim, its evidence, and the operating decision
A form entry, an extracted document value, and a verified fact are not equivalent. A student can claim an address. Software can read an address from an image. A staff member can compare the document with the school’s policy. A licensing agency can remain the authoritative source for the credential it issued. Those are different evidence states, even when the text is identical.
NIST’s current identity-proofing guidance distinguishes identity resolution, evidence validation, attribute validation, and identity verification. It also identifies state motor-vehicle departments as authoritative sources for driver-license data. A private driving school should not claim NIST compliance merely by following a similar distinction, but the model is useful: collecting a value is not the same as proving it. NIST SP 800-63A
Use three linked records:
- Claim: the exact value someone or something supplied.
- Evidence: its source, document or system, capture time, review state, and applicable date.
- Decision: whether the evidence is sufficient for a named purpose at a named time.
This prevents a high-confidence OCR result from being mistaken for legal verification, and it prevents one approval from becoming a permanent “ready” flag.
Resolve the conflict with a decision-specific order
- Freeze the dependent decision. If the disagreement affects road-test eligibility, do not dispatch that service. A phone-number conflict should not automatically stop an unrelated lesson.
- Preserve both claims. Record the literal values, source, actor, timestamp, and document or event reference. Do not destroy the older value merely to make the profile look clean.
- Define the question. “What is the student’s address?” may be too broad. The real question may be “Which address satisfies this branch’s pickup rule?” or “Which address appears on the credential required for this appointment?”
- Choose the controlling evidence for that question. Use the issuing agency or current original evidence when the school’s written policy requires it. Do not let a staff note outrank a current credential simply because it was entered later.
- Recheck dates and scope. A correct document can be expired, apply to another jurisdiction, or support identity without supporting the requested service.
- Record the resolution. Save the selected value, the rejected or superseded claim, reviewer, reason, supporting source, time, and next recheck trigger.
- Recalculate affected decisions. Reevaluate the journey stage, booking gate, dispatch gate, or guardian access that depended on the fact. Do not manually repair an unrelated progress field.
The W3C provenance model provides a general vocabulary for connecting an entity to the activity and agent that generated, revised, or derived it. A driving school does not need to implement that ontology, but its record should answer the same practical questions: where did this value come from, who changed it, and what was derived from it? W3C PROV-O
Use a conflict record that another staff member can audit
| Field | What to retain | Why it matters |
|---|---|---|
| Fact and purpose | Exact attribute plus the booking, dispatch, identity, pickup, guardian, or reporting decision | Stops one resolution from being reused outside its scope |
| Competing claims | Both literal values without silent normalization | Makes the disagreement visible |
| Source and actor | Student entry, guardian entry, staff entry, document, parser, provider, or agency source | Shows provenance and responsibility |
| Evidence state | Self-reported, extracted, submitted, reviewed, verified, expired, rejected, or indeterminate | Prevents a suggestion from becoming proof |
| Dates | Captured, issued, reviewed, effective, expired, and resolved where applicable | Exposes stale but previously correct evidence |
| Resolution | Controlling value, reviewer, reason, evidence reference, and recheck trigger | Lets the next employee reproduce the decision |
| Downstream effect | Which journey, booking, dispatch, access, or task decision changed | Prevents broad, unexplained blocking |
Security logs should also preserve enough context for later analysis. OWASP’s logging guidance summarizes the minimum as “when, where, who and what” and specifically includes data and configuration changes as events worth considering. Do not put raw identity documents or unnecessary sensitive values into general-purpose logs; retain a protected reference and the minimum audit detail instead. OWASP Logging Cheat Sheet
What RouteOS currently does—and where staff authority remains
In the RouteOS source snapshot reviewed September 2, 2026, Student Information separates canonical facts, provenance, document suggestions, review status, and policy decisions. Google Document AI extraction creates suggestions; it does not silently replace an existing fact or turn OCR into staff-verified evidence. Protected documents use a private storage boundary rather than ordinary public media.
Readiness is evaluated for a specific student, location, purpose, target date, jurisdiction, and, where needed, route region. Unknown jurisdiction, conflicting location evidence, missing policy support, invalid signatures, stale revisions, and incomplete documents can produce an indeterminate or blocked result when certainty is required. New York and New Jersey passenger-road-test policy packs were implemented in the inspected snapshot; that is not a claim that every state rule is already encoded or enabled for every school.
Customer Journeys can project the next step from live purchases, bookings, completions, student facts, and outcomes. RouteOS Road Test can observe or enforce supported readiness decisions depending on configuration. Staff still define the school’s evidence policy, review extracted documents, resolve conflicts, and handle exceptions. Document AI does not prove legal eligibility.
For the intake side of this process, see what a driving-school intake form should ask at each stage. For timing, see why a student can be bookable but not dispatch-ready. The broader student-journey guide explains why progress should be recalculated from authoritative records instead of repaired by hand.
Test the workflow with one controlled conflict
Use a synthetic student in a test environment. Enter one permit expiration date, attach evidence that suggests a different date, and confirm that the system preserves both sources rather than silently overwriting either. Then test four outcomes:
- the conflict is visible to an authorized reviewer;
- only the decision that depends on the expiration date is held;
- the reviewer can resolve it with a reason and evidence reference; and
- the affected readiness or journey result recalculates while the audit history remains intact.
If the conflict disappears after the latest edit, the workflow has a field but no evidence history. If every student action stops, the control is too broad. If the booking or dispatch proceeds without showing an unresolved material conflict, the control is too weak.
Research and implementation evidence reviewed September 8, 2026. This is an operational data-integrity guide, not a statement of any state’s licensing or record-retention law.