myodo — User Flows (MVP Beta)
Last Updated: 2026-04-25
Purpose: Engineering handoff document. Each flow shows what the user does, what happens behind the scenes, and what data is created or changed.
Scope: Everything in this document is MVP beta unless explicitly marked “Post-MVP.”
Table of Contents
- System Overview
- Driver Journeys
- 2.1 Driver Onboarding (Beta — Shop Invite)
- 2.2 Add Vehicle (Claim)
- 2.3 Pair OBD-II Device
- 2.4 View Service History & Health
- 2.5 Receive Notifications & Schedule Service
- 2.6 Manage Shop Connections
- 2.7 Relinquish / Transfer Vehicle
- 2.8 Dispute a Record
- Shop Journeys
- 3.1 Shop Onboarding (Beta — Invite Only)
- 3.2 Internal Admin Dashboard (Beta)
- 3.3 Upload Repair Orders
- 3.4 Receive & Handle Service Requests
- 3.5 Messaging & Appointments
- Entity Lifecycle Diagrams
- Data Entities Reference
- Third-Party Integrations
- Record Visibility Rules
- Driver App (Glovebox) Views
- 8.1 App Shell & Navigation
- 8.2 Vehicles (Home Screen)
- 8.3 Vehicle Detail Page
- 8.4 Driver Upload RO
- Scope Boundary
1. System Overview
Two products, two user types, one shared data layer.
graph LR
subgraph Driver["Driver (Glovebox)"]
D1[Add vehicles]
D2[View service history]
D3[Receive maintenance alerts]
D4[Request service from shop]
D5[Manage privacy & consent]
end
subgraph Shop["Shop (Dashboard)"]
S1[Upload repair orders]
S2[Receive service requests]
S3[Message customers]
S4[Appointment reminders]
end
subgraph System["myodo Platform"]
P1[Record parsing pipeline]
P2[Identity matching]
P3[Vehicle health engine]
P4[Notification engine]
P5[Telemetry ingestion]
end
D1 --> P2
S1 --> P1 --> P2 --> P3 --> P4 --> D3
D4 --> S2
P5 --> P4
End-to-End Lifecycle
The full loop — how a driver and shop interact through myodo from first contact to recurring service.
flowchart TD
subgraph Onboarding["Driver Onboarding (Beta)"]
A1[Shop signs up + gets verified] --> A2[Driver visits shop for service]
A2 --> A3[Shop tells driver about myodo]
A3 --> A4[Shop uploads repair order]
A4 --> A5[System parses RO: VIN, customer info, services]
A5 --> A6[Provisioned account created]
A6 --> A7[Shop sends invite from their email]
A7 --> A8[Driver claims account + consent flow]
end
subgraph Record["Record Flow"]
B1[Shop uploads repair order PDF] --> B2[OCR + AI parsing]
B2 --> B3[VIN decode + customer info extraction]
B3 --> B4[Records grouped under provisioned account]
B4 --> B5[Vehicle health updated]
end
subgraph Loop["Recommendation-to-Revenue Loop"]
C1[OBD-II reports mileage] --> C2{Service due?}
C2 -->|Yes| C3[Notification sent to driver]
C3 --> C4[Driver taps: Schedule with preferred shop]
C4 --> C5[Service request lands in shop Dashboard]
C5 --> C6[Shop accepts + schedules appointment]
C6 --> C7[Service performed]
C7 --> C8[Shop uploads new repair order]
C8 --> B1
end
A8 --> C1
A4 --> B1
The Core Loop
This is the business engine — the cycle that generates recurring revenue for shops and keeps drivers’ vehicles maintained. Everything else in the product exists to support this loop.
flowchart LR
A["Service need detected
(oil, tires, CEL)"] --> B["Driver notified
(email, SMS, in-app)"]
B --> C["Driver requests service
from preferred shop"]
C --> D["Shop receives request,
schedules appointment"]
D --> E["Service performed,
RO uploaded"]
E --> F["Record parsed,
health updated"]
F --> A
2. Driver Journeys
2.1 Driver Onboarding (Beta — Shop Invite)
During beta, driver onboarding is controlled through shop invites. The driver does not create their own account — the system provisions one from a parsed repair order, and the driver claims it.
At scale, drivers will also be able to sign up independently via the website. That flow is out of scope for beta.
Step 1: Shop uploads repair order
flowchart TD
A[Driver visits shop for service] --> B[Shop tells driver about myodo]
B --> C[Driver agrees to join]
C --> D[Shop uploads repair order PDF/image]
D --> E[OCR + AI parsing]
E --> F{Customer email and phone parsed?}
F -->|Yes| G[Provisioned account created]
F -->|No| H[Shop notified: missing customer info]
H --> I[Shop fills in email and/or phone from their records]
I --> G
G --> J{Existing provisioned account for this customer?}
J -->|Yes: same email or phone| K[New record grouped under existing account]
J -->|No| L[New provisioned account created]
K --> M[Customer appears in shop invite list]
L --> M
What gets parsed from the repair order:
- VIN → NHTSA vPIC decode → year, make, model, engine, trim
- Customer name, phone number, email address
- Service data: date, mileage, services performed, parts, labor, costs, DTCs, findings
Data created:
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Store file | source_documents | INSERT | file_url, shop_id, status=pending |
| Parse result | service_events | INSERT | vehicle_id, shop_id, date, mileage, services, costs |
| Vehicle | vehicles | UPSERT on VIN | vin, year, make, model, engine, trim |
| Provisioned account | users | INSERT | name, email, phone, type=driver, status=provisioned |
| Group records | service_events | Link to provisioned user via VIN + identity match | |
| Shop relationship | shop_driver_relationships | INSERT | shop_id, driver_id, is_preferred=true |
Step 2: Shop sends invite
flowchart TD
A[Shop sees customer in invite list on Dashboard] --> B[Shop clicks Send Invite]
B --> C{Shop email configured in profile?}
C -->|Yes| D[Invite email sent FROM shop email address]
C -->|No| E[Prompt shop to configure email in settings]
E --> F[Shop configures email relay/verification]
F --> D
D --> G[Driver receives invite email from shop]
The invite email is sent from the shop’s own email address, not from myodo. This requires the shop to configure their email in their profile settings. The system uses an email relay mechanism (engineer decides implementation — sender verification, SMTP relay, etc.) so the driver sees an email from a business they trust, not from an unknown platform.
Step 3: Driver claims account
flowchart TD
A[Driver opens invite email] --> B{Driver decision}
B -->|Claim| C[Verify identity: confirm email + phone]
B -->|Reject| R1[Driver clicks reject / request deletion]
R1 --> R2[PII scrubbed from provisioned account]
R2 --> R3[Anonymized service records retained on VIN]
C --> D[Consent flow]
D --> D1[Terms of Service]
D1 --> D2[Privacy Policy]
D2 --> D3[Data Processing consent]
D3 --> D4[Communication preferences]
D4 --> E[Set up authentication]
E --> E1{Auth method?}
E1 -->|Google OAuth| F1[Sign in with Google]
E1 -->|Email + password| F2[Create password]
F1 --> G[Account activated]
F2 --> G
G --> H[Glovebox populated: vehicle, service records, shop connection]
Data created/modified during claim:
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Identity confirmed | users | UPDATE | email_verified=true, phone_verified=true |
| Each consent step | consent_events | INSERT | user_id, type (tos/privacy/data_processing/comms), method, timestamp |
| Comms preferences | notification_preferences | INSERT | user_id, service_reminders (bool), promotional (bool) |
| Auth setup | users | UPDATE | auth_provider (google/email), status=active |
| Account activated | users | UPDATE | status=active, claimed_at=now() |
Data modified on rejection:
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Reject invite | users | UPDATE | status=rejected |
| Scrub PII | users | UPDATE | name=NULL, email=NULL, phone=NULL |
| Retain records | service_events | No change — records stay, anonymized (no PII link) |
Unclaimed accounts
If a provisioned account is never claimed, PII is automatically deleted after a configurable retention period (engineers decide timeline). Anonymized service records are retained on the VIN — the vehicle’s service history has value regardless of whether a specific owner claims it.
stateDiagram-v2
[*] --> provisioned: RO parsed, account created
provisioned --> active: Driver claims account
provisioned --> rejected: Driver rejects invite
provisioned --> expired: PII retention period exceeded
rejected --> [*]: PII scrubbed, anonymized records retained
expired --> [*]: PII auto-deleted, anonymized records retained
active --> active: Normal operation
Error states:
- RO parsing fails to extract VIN → flag for manual review
- Parsed email/phone missing → shop notified to fill in gaps before invite can be sent
- Driver tries to claim but email/phone don’t match → identity verification fails, retry or contact support
- Consent declined during claim → account remains provisioned, not activated
- Shop email not configured → shop prompted to set up email in profile before sending invites
2.2 Add Vehicle (Claim)
Two paths to the same result: driver provides a VIN, system decodes and creates a pending vehicle record.
flowchart TD
A[Driver taps Add Vehicle] --> B{Input method?}
B -->|License plate| C[Enter plate number + state]
C --> C1{Plate-to-VIN lookup}
C1 -->|Success| D[Display decoded: year, make, model]
C1 -->|Lookup failed| C2[Prompt manual VIN entry]
C2 --> E
B -->|Manual VIN| E[Enter 17-character VIN]
E --> E1{VIN format valid?}
E1 -->|No| E2[Show format error, retry]
E2 --> E
E1 -->|Yes| F[NHTSA vPIC decode]
F --> D
D --> G{VIN already in drivers garage?}
G -->|Yes| G1[Show duplicate warning, stop]
G -->|No| H{VIN exists in system?}
H -->|No| I[Create vehicle record, ownership=pending]
H -->|Yes, unclaimed| I2[Link driver as owner, ownership=pending]
H -->|Yes, claimed by another| J[Vehicle claimed by another driver]
J --> J1[Offer transfer request option]
I --> K[Vehicle appears in Glovebox garage]
I2 --> K
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Plate decode | (external API call) | — | plate, state → VIN |
| NHTSA decode | (external API call) | — | VIN → year, make, model, engine, trim |
| New vehicle | vehicles | INSERT (UPSERT on VIN) | vin, year, make, model, engine, trim, ownership_status=pending |
| Ownership link | ownership_periods | INSERT | vehicle_id, customer_id, started_at=now(), ended_at=NULL |
Key rule: Ownership stays
pending until a service record uploads that matches BOTH the VIN AND the driver’s identity info (name, email, or phone). Then it flips to verified.
2.3 Pair OBD-II Device
flowchart TD
A[Driver taps Add Device] --> B{IMEI input method?}
B -->|Photo of label| C[Camera capture, OCR extracts IMEI]
B -->|Manual entry| D[Type IMEI]
C --> E{IMEI recognized in telemetry system?}
D --> E
E -->|No| E1[Error: device not found. Contact support.]
E -->|Yes| F{Driver has vehicles?}
F -->|Yes| G[Select vehicle from garage list]
F -->|No| H[Add vehicle first]
H --> G
G --> I[Optional: enter current odometer for baseline]
I --> J[Confirm device + vehicle pairing]
J --> K[Device provisioned, telemetry flowing]
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Pair device | devices | INSERT/UPDATE | imei, vehicle_id, owner_id, status=active, nickname |
| Baseline mileage | mileage_readings | INSERT | vehicle_id, reading, source=app, timestamp |
| Audit trail | vehicle_events | INSERT | vehicle_id, event_type=device_coupled, device_id |
Telemetry feeds after pairing:
- Mileage readings (odometer snapshots at regular intervals)
- DTC detection (check engine light + fault codes)
- Trip data (ignition on/off with odometer deltas)
- Device status (online/offline/battery)
- GPS coordinates streamed to app in real-time but never persisted (privacy)
2.4 View Service History & Health
This is the core Glovebox experience. The data assembly rules are critical for engineers.
flowchart TD
A[Driver opens vehicle detail] --> B[Fetch service records for VIN]
B --> C{For each record: does ownership_period overlap record date?}
C -->|Yes| D{Does record PII match driver identity?}
D -->|Yes: identity matched| E[Show FULL detail: pricing, parts, labor, shop, findings]
D -->|No match| F[Show ANONYMIZED: date, mileage, services — NO pricing]
C -->|No: outside ownership| F
E --> G[Render unified timeline across all shops]
F --> G
G --> H[Vehicle dashboard]
H --> H1[Service history timeline]
H --> H2[Upcoming services: oil, tire, CEL countdowns]
H --> H3[Quick action: Schedule with preferred shop]
See Section 7: Record Visibility Rules for the full decision matrix.
2.5 Receive Notifications & Schedule Service
MVP notifications are mileage-based and require an OBD-II device.
flowchart TD
A[Telemetry system reports current mileage] --> B{Compare against last known service}
B -->|Oil change| C{Mileage delta >= threshold?}
B -->|Tire rotation| D{Mileage delta >= threshold?}
B -->|CEL detected| E[Device reports check engine light + fault code]
C -->|Due| F[Create notification: Oil change due in X miles]
D -->|Due| F2[Create notification: Tire rotation due in X miles]
E --> F3[Create notification: fault code + plain-language description]
F --> G[Deliver via email + SMS + in-app]
F2 --> G
F3 --> G
G --> H[Driver taps notification, deep link to vehicle detail]
H --> I[Driver sees Schedule with preferred shop button]
I --> J{Preferred shop has Dashboard account?}
J -->|Yes| K[Driver types free-text service description]
K --> L[Service request sent to shop Dashboard]
J -->|No| M[Show business card modal: name, address, phone]
M --> N[Driver calls shop directly]
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Detect need | service_needs | INSERT | vehicle_id, type (oil/tire/cel), detected_at, current_mileage, last_service_mileage |
| Send notification | notifications | INSERT | user_id, service_need_id, channel (email/sms/in_app), status=sent, sent_at |
| Driver reads | notifications | UPDATE | status=read, read_at |
| Submit request | service_requests | INSERT | driver_id, shop_id, vehicle_id, description (free text), status=pending |
Post-MVP: The free-text description becomes a natural language interface that parses into structured line items (like a cart).
2.6 Manage Shop Connections
flowchart TD
A[Driver opens Shop Connections settings] --> B[View list of connected shops]
B --> C[See which shop is preferred — star icon]
B --> D{Action?}
D -->|Change preferred shop| E[Select new preferred shop]
E --> E1{Revoke cross-shop history from old preferred?}
E1 -->|Yes| E2[Old shop loses cross-shop access — keeps own uploads]
E1 -->|No| E3[Old shop retains cross-shop access]
D -->|Edit permissions for a shop| F[Per-shop toggles]
F --> F1[Toggle: allow cross-shop history access — anonymized]
F --> F2[Toggle: allow promotional messages]
D -->|Revoke shop access| G[Confirm revocation]
G --> G1[Shop can no longer see cross-shop records]
G --> G2[Shop ALWAYS retains records they uploaded — cannot be revoked]
| Step | Entity | Operation | Fields |
|---|---|---|---|
| Change preferred | shop_driver_relationships | UPDATE | is_preferred=false on old, is_preferred=true on new |
| Toggle permission | shop_driver_relationships | UPDATE | cross_shop_history_visible (bool), promotional_messages (bool) |
2.7 Relinquish / Transfer Vehicle
Owner relinquishes (selling/giving away vehicle)
flowchart TD
A["Owner taps 'I no longer own this vehicle'"] --> B[Confirmation dialog]
B --> B1{Driver confirms?}
B1 -->|Confirm| C[Backend processing]
C --> C1[Clear vehicle owner]
C --> C2[Close ownership period]
C --> C3{OBD-II device paired?}
C3 -->|Yes| C4[Uncouple device from vehicle]
C3 -->|No| C5[Skip]
C4 --> C6[Purge telemetry data]
C5 --> D[Vehicle moves to Archived Vehicles — read-only]
B1 -->|Cancel| E[No changes]
Relinquish confirmation tells the driver:
- You will lose live health record, telemetry, and notifications for this vehicle
- Your historical service records from your ownership period become read-only in “Archived Vehicles”
- Any paired OBD-II device is uncoupled (device stays on your account)
New owner claims transferred vehicle
flowchart TD
A[New owner enters VIN] --> B{VIN status in system?}
B -->|Unclaimed — old owner relinquished| C[Claim vehicle normally]
B -->|Still claimed by someone| D[Vehicle currently claimed by another driver]
D --> E[Offer Submit transfer request]
E --> F[New owner provides reason: purchased, inherited, etc.]
F --> G[Internal ticket created for human review]
G --> H{Human decision}
H -->|Approve| I[Force-relinquish old owner + new owner claims]
H -->|Reject| J[Notify new owner — cannot transfer]
What new owner sees for pre-ownership records: Anonymized — date, mileage, shop name, services performed, findings. NO pricing, NO previous owner identity. Living Health Record transfers fully (follows VIN).
2.8 Dispute a Record
flowchart TD
A[Driver views a parsed service record] --> B[Driver believes record is inaccurate]
B --> C[Tap Dispute this record]
C --> D[Driver describes what is wrong — free text]
D --> E[Dispute submitted]
E --> F[Internal ticket created]
F --> G[Human reviews: parsed output vs. source document]
G --> H{Accurate?}
H -->|Parsing was wrong| I[Human corrects record, closes ticket]
H -->|Parsing was correct| J[Close ticket, notify driver]
| Step | Entity | Operation |
|---|---|---|
| Submit dispute | record_disputes | INSERT: record_id, user_id, description, status=open |
| Resolve | record_disputes | UPDATE: status=resolved, resolution_notes |
| Correct record | service_events | UPDATE: corrected fields |
Important: Drivers cannot manually edit parsed records. All corrections go through human review. This protects data integrity and serves as a feedback loop for improving the parsing pipeline.
3. Shop Journeys
3.1 Shop Onboarding (Beta — Invite Only)
During beta, shops join by invite only. There are two paths into the system — both converge at the same onboarding flow.
How shops get invited
flowchart TD
subgraph Path1["Path A: We invite them (pre-vetted)"]
A1[myodo team identifies shop through outreach] --> A2[Team sends invite email with unique sign-up link]
end
subgraph Path2["Path B: Shop finds us (request access)"]
B1[Shop discovers myodo through materials/word-of-mouth] --> B2[Shop fills request form: name, email, phone]
B2 --> B3[myodo team receives notification]
B3 --> B4[Brief interview to determine beta fit]
B4 --> B5{Decision}
B5 -->|Approve| B6[Send invite email with unique sign-up link]
B5 -->|Not yet| B7[Add to waitlist — follow up later]
B5 -->|Not a fit| B8[Polite decline]
end
A2 --> C[Shop clicks invite link → onboarding flow]
B6 --> C
Pre-vetted shops (Path A) have already been screened — no review step after they accept. Request-access shops (Path B) go through the interview before receiving an invite.
Onboarding flow
Onboarding must be completed in a single session — no partial saves. If a shop doesn’t want to lose progress, they need to finish. If onboarding is not completed within 48 hours of clicking the invite link, the myodo team is notified so they can follow up manually.
flowchart TD
A[Shop clicks invite link] --> B[Step 1: Shop Profile]
B --> B1[Contact name]
B1 --> B2[Shop name]
B2 --> B3[Phone number]
B3 --> B4[Contact email address]
B4 --> B5[Business address]
B5 --> B6[Hours of operation — structured input]
B6 --> B7[Website domain]
B7 --> C[Step 2: Legal Agreements]
C --> C1[Terms of Service]
C1 --> C2[Privacy Policy]
C2 --> C3[Data Processing / Service Provider Agreement]
C3 --> C4["Checkbox: 'I agree on behalf of [Shop Name]'"]
C4 --> C5[Signer name + title — for audit trail]
C5 --> D[Step 3: Email Configuration]
D --> D1["Explanation: customer invites will be sent from YOUR email address"]
D1 --> D2[Shop configures email relay / verification]
D2 --> D3["Clear messaging: drivers see an invite from a business they trust, not from an unknown platform"]
D3 --> E[Step 4: Set Up Authentication]
E --> E1[Engineers determine auth methods — email+password, Google OAuth, etc.]
E1 --> F[Step 5: First Repair Order Upload — MANDATORY]
F --> F1["Guided prompt: Pick your best customer — someone you know will want to sign up for this"]
F1 --> F2["Save a PDF of a service record for this customer"]
F2 --> F3[Drag-and-drop or file select uploader]
F3 --> F4[System parses RO: customer profile populates in invite list]
F4 --> F5[Shop sends first invite to that customer]
F5 --> F6["Note: We're happy to come by in person to see how your system works so we can figure out the easiest way to add PDF uploads to your standard workflow"]
F5 --> G["Onboarding complete — status: active"]
G --> G1[myodo team receives email notification: shop signed up]
G --> G2[Shop lands on Dashboard — ready to operate]
Why the first upload is mandatory: We want shops to experience the full loop — upload a record, see the customer appear in their invite list, and send the invite — so they’re confident using the system going forward. This is training, not busywork.
Why no partial saves: If a shop pauses halfway through, they forget to come back. One session keeps momentum and ensures they’re fully set up before they touch the Dashboard.
Hours of operation input
The hours input avoids duplicate effort for days with the same schedule:
flowchart TD
A[Do all days have the same hours?] --> B{Response}
B -->|Yes| C[Enter hours range]
C --> C1{Midday closure?}
C1 -->|Yes| C2[Add additional range — e.g. 8am-12pm, 1pm-6pm]
C1 -->|No| C3[Single range — e.g. 8am-6pm]
B -->|No| D[Show list of days with checkboxes]
D --> D1[Select days with same hours — e.g. Mon-Fri]
D1 --> D2[Set hours for that batch]
D2 --> D3{More days to configure?}
D3 -->|Yes| D4[Select next batch — e.g. Sat]
D4 --> D5[Set hours for that batch]
D5 --> D3
D3 -->|No| D6[Done — unchecked days are closed]
The stored format should be structured (per-day open/close ranges) so it can be displayed consistently across the platform.
Shop user roles
Shops have multiple user accounts with different privilege levels. The person who completes onboarding gets the admin role.
| Role | Upload ROs | Send customer invites | Message customers | Edit business info / hours / email | Add/remove shop users | Transfer admin |
|---|---|---|---|---|---|---|
| Admin | Yes | Yes | Yes | Yes | Yes | Can receive |
| Service Advisor | Yes | Yes | Yes | No | No | Can give away |
Adding service advisors:
flowchart TD
A[Admin opens shop user management] --> B[Clicks Add User]
B --> C[Enter advisor name + email]
C --> D[System sends invite email with link to accept role]
D --> E[Advisor clicks link → sets up auth → accepts role]
E --> F[Advisor now has Dashboard access with limited privileges]
Admin transfer: If a service advisor signed up first and the shop owner/manager wants to take over, the advisor can transfer admin privileges to the owner. The owner receives and confirms the transfer.
Upload attribution: Every upload is tied to the specific shop user who uploaded it, not just the shop. This provides accountability and audit trail.
Shop statuses (state machine)
stateDiagram-v2
[*] --> invited: myodo sends invite (pre-vetted or approved request)
invited --> active: Shop completes onboarding
invited --> onboarding_stale: 48hrs without completion
onboarding_stale --> active: Shop completes onboarding (late)
active --> suspended: Policy / billing issue
suspended --> active: Issue resolved
active --> churned: Deactivated / terminated
Beta request statuses (separate from shop statuses):
stateDiagram-v2
[*] --> pending: Shop submits request form
pending --> interviewing: myodo team reaches out
interviewing --> approved: Good fit — send invite
interviewing --> waitlisted: Not ready yet
interviewing --> declined: Not a fit
waitlisted --> approved: Later approved
Data created
| Step | Entity | Operation | Key Fields |
|---|---|---|---|
| Request access (Path B) | shop_beta_requests | INSERT | name, email, phone, status=pending, requested_at |
| Interview outcome | shop_beta_requests | UPDATE | status (approved/waitlisted/declined), reviewed_by, reviewed_at |
| Send invite | shops | INSERT | name (from request or manual), status=invited, invite_token, invited_at |
| Profile setup | shops | UPDATE | contact_name, name, phone, email, address, hours (JSON), website, status=invited |
| Legal agreements | shop_agreements | INSERT | shop_id, signer_name, signer_title, signed_at, ip_address, agreement_version |
| Email config | shops | UPDATE | email_relay_config (engineer decides structure) |
| Auth setup | shop_users | INSERT | shop_id, user_id, role=admin |
| First RO upload | source_documents | INSERT | file_url, shop_id, uploaded_by (shop_user_id), status=pending |
| Onboarding complete | shops | UPDATE | status=active, activated_at |
| Team notification | (internal email) | — | Shop name, contact info, link to admin dashboard |
| Stale alert (48hrs) | (internal email) | — | Shop name, contact info, invite sent timestamp |
Why the processing agreement matters: myodo is a data processor. Without a formal agreement there is no legal basis to receive/store the shop’s customer data. CCPA/CPRA requires a service provider agreement when a business shares consumer PII with a processor. Agreement must be reviewed by a privacy attorney before launch.
Why invite emails come from the shop, not myodo: The invite is sent from the shop’s own email address so the driver receives a message from a business they recognize and trust, not from an unknown platform. The shop verbally confirmed the driver’s interest in-person — the email is the follow-through on that conversation.
3.2 Internal Admin Dashboard (Beta)
An internal-facing tool for the myodo team to manage shops and monitor platform health during beta.
Core views (MVP)
| View | Contents |
|---|---|
| Active Shops | Shop name, contact name, email, phone, website, activated_at |
| Waitlisted Shops | Name, email, phone, waitlisted_at, notes from interview |
| Deletion Requests | User name (if available), request date, status (pending/completed), associated records |
Extra credit (engineer discretion)
| View | Contents |
|---|---|
| Requested Shops | Name, email, phone, requested_at, status |
| Per-Shop Metrics | ROs uploaded (count), customers invited (count), invites accepted vs. rejected |
Deletion request tracking: When a driver rejects an invite and requests data deletion (see Section 2.1 Step 3), or when an unclaimed account expires, the deletion must be logged. The admin dashboard shows these so the team can verify PII was scrubbed and anonymized records were retained correctly.
3.3 Upload Repair Orders
Uploading a repair order is the primary action in the system. It triggers record parsing, vehicle creation, account provisioning, and health updates.
flowchart TD
A[Shop uploads PDF/image of repair order] --> B[File stored in cloud storage]
B --> C[OCR extracts raw text]
C --> D[AI parses text into structured data]
D --> E{VIN extracted?}
E -->|No| E1[Flag for manual review]
E -->|Yes| F[NHTSA vPIC decode: year, make, model]
F --> G{Vehicle exists in system?}
G -->|No| G1[Create vehicle record]
G -->|Yes| G2[Link to existing vehicle]
G1 --> H{Customer info parsed? email + phone}
G2 --> H
H -->|Yes| I{Existing account matches this customer?}
H -->|No| H1[Shop notified: missing customer info needed]
I -->|Yes: active account| J[Record added to existing account]
I -->|Yes: provisioned account| K[Record grouped under provisioned account]
I -->|No match| L[New provisioned account created]
J --> M[Update Living Health Record]
K --> M
L --> M
M --> N[Check for service notifications — oil change, tire rotation]
N --> O[Record visible in shop Dashboard]
O --> P{Account active or provisioned?}
P -->|Active| Q[Record also visible in driver Glovebox]
P -->|Provisioned| R[Record held until account is claimed]
What gets extracted from a repair order:
- VIN → NHTSA decode → year, make, model, engine, trim
- Customer name, email, phone (for identity matching + account provisioning)
- Event date, mileage
- Services performed: category, operation, finding, parts, labor, cost per line
- Diagnostic trouble codes (DTCs)
- Findings / technician notes
- Total cost
| Step | Entity | Operation |
|---|---|---|
| Store file | source_documents | INSERT: file_url, shop_id, status=pending |
| OCR complete | source_documents | UPDATE: ocr_text, status=parsed |
| Vehicle | vehicles | UPSERT on VIN: vin, year, make, model, engine, trim |
| Parse result | service_events | INSERT: vehicle_id, shop_id, date, mileage, services (JSON), costs, dtcs, findings |
| Account (if new customer) | users | INSERT: name, email, phone, type=driver, status=provisioned |
| Account (if existing) | service_events | Link to existing user |
| Shop relationship | shop_driver_relationships | INSERT (if new): shop_id, driver_id, is_preferred=true |
| Health update | living_health_docs | UPSERT: vehicle_id, per-item status updates |
| Notifications | service_needs | INSERT (if triggered, only for active accounts) |
3.4 Receive & Handle Service Requests
flowchart TD
A[Driver submits service request from Glovebox] --> B[Request appears in shop Dashboard]
B --> C[Shop sees: customer name, vehicle, free-text description]
C --> D{Shop action?}
D -->|Accept| E[Shop sends message to customer — can propose date/time]
D -->|Decline| F[Shop sends decline message with reason]
D -->|Need more info| G[Shop messages customer with questions]
E --> H[Customer receives notification]
F --> H
G --> H
H --> I[Conversation continues via messaging thread]
3.5 Messaging & Appointments
flowchart TD
A[Shop Dashboard] --> B{Action?}
B -->|Send message| C[Select customer from customer list]
C --> D[Compose message in thread]
D --> E[Customer gets notification — email/SMS/in-app]
B -->|Create appointment| F[Select customer + vehicle]
F --> G[Set date, time, service type, notes]
G --> H[Appointment created]
H --> I[Reminder sent to customer before appointment]
B -->|View customers| J[Customer list — all customers linked to shop]
J --> K[Click customer: see vehicles + service history from this shop]
| Action | Entity | Operation |
|---|---|---|
| Send message | messages | INSERT: thread_id, sender_id, sender_type, content, sent_at |
| New thread | message_threads | INSERT: shop_id, driver_id, subject |
| Create appointment | appointments | INSERT: shop_id, driver_id, vehicle_id, scheduled_at, service_type, notes, status=scheduled |
| Send reminder | notifications | INSERT: type=appointment_reminder |
4. Entity Lifecycle Diagrams
Driver Account
stateDiagram-v2
[*] --> provisioned: RO parsed, account created
provisioned --> active: Driver claims account
provisioned --> rejected: Driver rejects invite
provisioned --> expired: PII retention period exceeded
rejected --> [*]: PII scrubbed, anonymized records retained
expired --> [*]: PII auto-deleted, anonymized records retained
active --> active: Normal operation
Vehicle Ownership
stateDiagram-v2
[*] --> pending: Driver adds vehicle (plate or VIN)
pending --> verified: Identity-matched record uploaded
verified --> verified: Normal operation
verified --> relinquished: Owner taps I sold this vehicle
relinquished --> pending: New owner claims VIN
pending --> contested: VIN already claimed by another
contested --> pending: Transfer approved by human review
contested --> [*]: Transfer rejected
Source Document (Repair Order)
stateDiagram-v2
[*] --> uploaded: File received
uploaded --> processing_ocr: Queued for OCR
processing_ocr --> processing_parse: OCR complete, LLM parsing
processing_parse --> parsed: Structured data extracted
processing_parse --> error: Parse failed
error --> processing_ocr: Retry / reparse
parsed --> disputed: Driver disputes accuracy
disputed --> parsed: Human resolves dispute
Service Request
stateDiagram-v2
[*] --> pending: Driver submits request
pending --> accepted: Shop accepts
pending --> declined: Shop declines
pending --> info_requested: Shop needs more info
info_requested --> pending: Driver provides info
accepted --> scheduled: Appointment created
scheduled --> completed: Service performed
Shop Account
stateDiagram-v2
[*] --> invited: myodo sends invite (pre-vetted or approved request)
invited --> active: Shop completes onboarding
invited --> onboarding_stale: 48hrs without completion
onboarding_stale --> active: Shop completes onboarding (late)
active --> suspended: Policy / billing issue
suspended --> active: Issue resolved
active --> churned: Deactivated / terminated
5. Data Entities Reference
This is not a schema — the engineer owns the data model. These are the entities the flows above require, with the relationships and key fields that must exist.
Entity Relationship Diagram
erDiagram
users ||--o{ vehicles : "owns (via ownership_periods)"
users ||--o{ consent_events : "logs consent"
users ||--o{ notification_preferences : "sets preferences"
users ||--o{ devices : "owns"
users ||--o{ service_requests : "submits"
users ||--o{ notifications : "receives"
vehicles ||--o{ ownership_periods : "tracks owners"
vehicles ||--o{ service_events : "has service history"
vehicles ||--o{ source_documents : "has uploaded records"
vehicles ||--o{ living_health_docs : "has health record"
vehicles ||--o{ health_observations : "has findings"
vehicles ||--o{ mileage_readings : "has odometer data"
vehicles ||--o{ trips : "has trip data"
vehicles ||--o{ vehicle_events : "has audit trail"
vehicles ||--o{ service_needs : "has detected needs"
vehicles ||--o{ devices : "paired with"
shops ||--o{ shop_users : "has staff"
shops ||--o{ source_documents : "uploads"
shops ||--o{ service_events : "associated with"
shops ||--o{ shop_agreements : "signs"
shops ||--o{ shop_assets : "receives"
shops ||--o{ appointments : "schedules"
shops ||--o{ message_threads : "participates in"
shop_users }o--|| users : "is a user"
shop_driver_relationships }o--|| shops : "connects to"
shop_driver_relationships }o--|| users : "connects to"
source_documents ||--o| service_events : "parsed into"
service_events ||--o{ health_observations : "generates"
service_events ||--o{ record_disputes : "can be disputed"
service_requests }o--|| shops : "sent to"
service_requests }o--|| vehicles : "for vehicle"
message_threads ||--o{ messages : "contains"
message_threads }o--|| shops : "involves"
message_threads }o--|| users : "involves"
appointments }o--|| shops : "at shop"
appointments }o--|| users : "for driver"
appointments }o--|| vehicles : "for vehicle"
users {
string id PK
string name
string email
string phone
enum type "driver | shop_admin"
enum status "provisioned | active | rejected | expired"
string auth_provider "google | email"
datetime claimed_at "NULL until claimed"
}
vehicles {
string id PK
string vin UK "UNIQUE — universal key"
string year
string make
string model
string engine
string trim
string customer_id FK
enum ownership_status "pending | verified"
}
shops {
string id PK
string name
string contact_name
string email
string phone
string address
json hours "structured per-day ranges"
string website
enum status "invited | onboarding_stale | active | suspended | churned"
datetime invited_at
datetime activated_at
}
shop_users {
string id PK
string shop_id FK
string user_id FK
enum role "admin | advisor"
enum status "invited | active | disabled"
datetime invited_at
datetime accepted_at
}
shop_beta_requests {
string id PK
string name
string email
string phone
enum status "pending | interviewing | waitlisted | approved | declined"
datetime requested_at
}
deletion_requests {
string id PK
string user_id FK
enum source "invite_rejection | account_expiry | user_request"
enum status "pending | completed"
datetime requested_at
datetime completed_at
}
ownership_periods {
string id PK
string vehicle_id FK
string customer_id FK
datetime started_at
datetime ended_at "NULL if current owner"
}
source_documents {
string id PK
string file_url
string shop_id FK "nullable — NULL for driver uploads"
string driver_id FK "nullable — NULL for shop uploads"
string uploaded_by FK "shop_user_id for shop uploads"
text ocr_text
enum status "uploaded | processing_ocr | processing_parse | parsed | error"
}
service_events {
string id PK
string vehicle_id FK
string shop_id FK
string source_document_id FK
date event_date
int mileage
json services
text summary "AI-generated one-liner, stored at parse time"
decimal total_cost
json dtcs
text findings
}
service_requests {
string id PK
string driver_id FK
string shop_id FK
string vehicle_id FK
text description
enum status "pending | accepted | declined | scheduled | completed"
}
shop_driver_relationships {
string shop_id FK
string driver_id FK
bool is_preferred
bool cross_shop_history_visible
bool promotional_messages
}
devices {
string imei PK
string vehicle_id FK
string owner_id FK
enum status "active | disabled"
string nickname
}
Users & Auth
| Entity | Key Fields | Notes |
|---|---|---|
users | id, name, email, phone, type (driver/shop_admin), status (provisioned/active/rejected/expired), auth_provider, claimed_at | Drivers can be provisioned (from RO parse) or active (claimed). See 2.1 for lifecycle. |
consent_events | user_id, type, method, timestamp | Immutable log — every consent action recorded |
notification_preferences | user_id, service_reminders, promotional | Per-user delivery preferences |
Vehicles & Ownership
| Entity | Key Fields | Notes |
|---|---|---|
vehicles | vin (UNIQUE), year, make, model, engine, trim, customer_id, ownership_status | VIN is the universal key |
ownership_periods | vehicle_id, customer_id, started_at, ended_at | Tracks who owned when — drives record visibility |
vehicle_authorized_users | vehicle_id, user_id, relationship | Spouse, family, etc. — requires verification |
Service Records & Health
| Entity | Key Fields | Notes |
|---|---|---|
source_documents | id, file_url, shop_id, uploaded_by (shop_user_id), ocr_text, status, uploaded_at | The raw uploaded file + OCR output. Attributed to specific shop user. |
service_events | id, vehicle_id, shop_id, source_document_id, event_date, mileage, services (JSON), total_cost, dtcs, findings | The parsed, structured record |
living_health_docs | vehicle_id, items (JSON: per-item status) | Running health status per vehicle — follows VIN, not owner |
health_observations | id, vehicle_id, service_event_id, item_id, status, measurement, notes | Individual inspection findings |
record_disputes | id, service_event_id, user_id, description, status, resolution | Driver-submitted accuracy disputes |
Shops, Users & Relationships
| Entity | Key Fields | Notes |
|---|---|---|
shops | id, name, contact_name, email, phone, address, hours (JSON), website, status, invited_at, activated_at | Status drives what the shop can do. Hours stored as structured per-day ranges. |
shop_users | id, shop_id, user_id, role (admin/advisor), status (invited/active/disabled), invited_at, accepted_at | Multi-user shops. First onboarder gets admin. Uploads attributed via this. |
shop_beta_requests | id, name, email, phone, status (pending/interviewing/waitlisted/approved/declined), requested_at | Request-to-join form submissions. Separate from shop records. |
shop_agreements | shop_id, signer_name, signer_title, signed_at, ip_address, agreement_version | Immutable audit record |
shop_assets | shop_id, qr_code_url, invite_link | Generated on activation |
shop_driver_relationships | shop_id, driver_id, is_preferred, cross_shop_history_visible, promotional_messages | Per-shop permissions controlled by driver |
deletion_requests | id, user_id, source (invite_rejection/account_expiry/user_request), status (pending/completed), requested_at, completed_at | Tracks all PII deletion events for compliance |
Devices & Telemetry
| Entity | Key Fields | Notes |
|---|---|---|
devices | imei, vehicle_id, owner_id, status, nickname, last_seen | OBD-II hardware units |
mileage_readings | vehicle_id, reading, source (device/app/repair_order), timestamp | Odometer snapshots from multiple sources |
trips | vehicle_id, device_id, started_at, ended_at, distance | Ignition on → off events |
vehicle_events | vehicle_id, event_type, device_id, timestamp | Audit trail: couple/uncouple/disable |
Notifications & Requests
| Entity | Key Fields | Notes |
|---|---|---|
service_needs | vehicle_id, type (oil/tire/cel), detected_at, current_mileage, last_service_mileage | Detected maintenance needs |
notifications | user_id, service_need_id, channel, status (sent/read/acted_on), sent_at | Delivery tracking |
service_requests | driver_id, shop_id, vehicle_id, description, status | Free-text requests (MVP) |
appointments | shop_id, driver_id, vehicle_id, scheduled_at, service_type, notes, status | Scheduled service visits |
Messaging
| Entity | Key Fields | Notes |
|---|---|---|
message_threads | id, shop_id, driver_id, subject, created_at | One thread per shop-driver pair per topic |
messages | id, thread_id, sender_id, sender_type, content, sent_at | Individual messages in a thread |
6. Third-Party Integrations
| Integration | Used In | Purpose | MVP? |
|---|---|---|---|
| Plate-to-VIN API | Vehicle claiming (2.2) | Decode license plate → VIN | Yes |
| NHTSA vPIC | Vehicle claiming (2.2) | Decode VIN → year, make, model, engine, trim | Yes |
| Google Document AI | Record upload (3.3) | OCR — extract text from PDF/image | Yes |
| OpenAI GPT-4o | Record upload (3.3) | Parse OCR text into structured service data | Yes |
| Email service | Notifications (2.5), onboarding | Transactional email delivery | Yes |
| SMS service | Notifications (2.5) | SMS delivery for opted-in users | Yes |
| Cloudflare Workers | Telemetry (2.3) | OBD-II data ingestion — firm infrastructure decision | Yes |
7. Record Visibility Rules
This is the core privacy model. Every record access must evaluate these rules.
flowchart TD
A[Request to view a service record] --> B{Who is requesting?}
B -->|Driver| C{Ownership period overlaps record date?}
C -->|No overlap| D[ANONYMIZED]
C -->|Yes| E{Record PII matches driver identity?}
E -->|Yes| F[FULL VIEW]
E -->|No| D
B -->|Shop| G{Shop uploaded this record?}
G -->|Yes| H[FULL VIEW]
G -->|No| I{Driver granted cross-shop access?}
I -->|No| J[NO ACCESS]
I -->|Yes| K[ANONYMIZED — no pricing, labor, or shop names]
What each view includes
| View | Shows | Hides |
|---|---|---|
| FULL | Date, mileage, shop, services, parts, labor, pricing, customer name, findings, DTCs | Nothing |
| ANONYMIZED (driver) | Date, mileage, shop name, services performed, findings | Pricing, parts cost, labor cost, customer identity |
| ANONYMIZED (cross-shop) | Date, mileage, services performed, findings | Pricing, labor times, other shop’s name, other shop’s contact info |
| NO ACCESS | Nothing | Everything |
Key invariants
- A shop always sees records they uploaded — this cannot be revoked
- Cross-shop records shown to shops are anonymized to protect competitive data (no pricing, no shop names)
- After vehicle transfer, the new owner sees pre-ownership records as anonymized
- The Living Health Record (inspection statuses) is vehicle-scoped — always shows full history regardless of ownership
- OBD-II telemetry (location, trips) is never transferred to a new owner — purged on relinquish
8. Driver App (Glovebox) Views
Sections 1–7 describe what happens behind the scenes. This section describes what the driver actually sees and interacts with.
8.1 App Shell & Navigation
Entry: Driver receives a business card with a QR code linking to the myodo website, or navigates to the URL manually. QR code / URL → login screen → home.
Layout: Main content area with a persistent side navigation bar.
Side nav items:
| Nav Item | Destination |
|---|---|
| Vehicles | Home screen — vehicle card grid (default) |
| Devices | OBD-II device management |
| Request Service | Service request form (to preferred shop) |
| Upload RO | Driver-uploaded repair orders |
| Settings | Account, privacy, shop connections, notification preferences |
On mobile, side nav collapses to a hamburger menu.
8.2 Vehicles (Home Screen)
The home screen is a grid of vehicle cards — one card per vehicle in the driver’s garage.
Vehicle card contents
┌─────────────────────────────────────────┐
│ 2019 Honda Accord EX-L │
│ │
│ Next oil change due at 67,500 mi │
│ Due in 1,230 mi (device) │
│ │
└─────────────────────────────────────────┘| Element | Source | Notes |
|---|---|---|
| Year, make, model | vehicles (from VIN decode) | Always shown |
| Next oil change due at X mi | Calculated: last oil change mileage + 5,000 | Shown if oil change record exists |
| Due in X mi | Calculated: due mileage − current device odometer | Only for vehicles with active OBD-II device |
If no oil change record exists for a vehicle, the card shows a prompt instead of the oil change status (see 8.3).
Click a card → navigate to vehicle detail page (8.3).
8.3 Vehicle Detail Page
Two-column layout. On mobile, the right column stacks on top — upcoming services and actionable items are prioritized above service history.
Header
| Element | With device | Without device |
|---|---|---|
| Year, make, model | Always | Always |
| Odometer | Current reading from device (live) | Mileage from last service record, labeled “Last service: X mi” |
Service records list
Each record appears as a row. Records are ordered by date, most recent first.
Owned record row (identity matched, within ownership period):
| Field | Source |
|---|---|
| Date | service_events.event_date |
| Mileage | service_events.mileage |
| Price | service_events.total_cost |
| AI summary | service_events.summary (generated at parse time, stored) |
Anonymized record row (no identity match, or outside ownership period):
| Field | Source | Notes |
|---|---|---|
| Date | service_events.event_date | Shown |
| Mileage | service_events.mileage | Shown |
| Price | — | Hidden |
| AI summary | service_events.summary | Shown (summary describes services, not pricing) |
| Shop name | — | Hidden |
| Visual indicator | — | Badge or icon indicating “anonymized record” |
No “View Original” link on anonymized records. Only the record owner can access the source PDF/image. Exposing the source document would defeat the purpose of anonymization.
Record drill-down (accordion)
Three levels of detail, each expanding on click:
flowchart TD
A["Record row: date, mileage, price, AI summary"] -->|Click| B["Expanded: list of jobs performed"]
B --> B1["Job 1: Oil & Filter Change"]
B --> B2["Job 2: Tire Rotation"]
B --> B3["Job 3: Multi-Point Inspection"]
B1 -->|Click| C1["Parts & labor for this job"]
C1 --> P1["Part: Mobil 1 5W-30 Full Synthetic - 5 qt - $42.99"]
C1 --> P2["Part: OEM Oil Filter #15400-PLM-A02 - 1 - $8.49"]
C1 --> L1["Labor: Oil & filter change - 0.5 hr - $35.00"]
B2 -->|Click| C2["Parts & labor for this job"]
C2 --> L2["Labor: Tire rotation - 0.3 hr - $25.00"]
Parts detail fields (as much as parsed):
| Field | Example | Notes |
|---|---|---|
| Part description | “Mobil 1 5W-30 Full Synthetic” | Always shown if parsed |
| Part number | #15400-PLM-A02 | Shown if parsed |
| Brand | Mobil 1 | Shown if parsed |
| Quantity | 5 qt | Shown if parsed |
| Price | $42.99 | Only on owned records |
Labor detail fields:
| Field | Example | Notes |
|---|---|---|
| Description | “Oil & filter change” | Always shown |
| Time | 0.5 hr | Only on owned records |
| Rate/price | $35.00 | Only on owned records |
View Original Document: Button or link at the bottom of the expanded record. Opens the source PDF/image in a new tab. Only visible on owned records.
Upcoming services panel (right column)
For beta, this panel shows one thing: the next oil change.
flowchart TD
A{Oil change record exists for this vehicle?}
A -->|Yes| B[Calculate: last oil change mileage + 5,000]
B --> C{Vehicle has active device?}
C -->|Yes| D["Display: Next oil change due at X mi + Due in X mi"]
C -->|No| E["Display: Next oil change due at X mi"]
A -->|No| F["Prompt: No oil change on record"]
F --> F1["Upload a record or ask your shop to upload your most recent oil change"]
F1 --> F2["Upload Record button -> Upload RO page"]
F1 --> F3["Request from Shop button -> Request Service page"]
Oil change detection: The parsing pipeline must identify oil changes in service records. When detected, the system stores the mileage and calculates the next due point.
| Scenario | Display |
|---|---|
| Oil change on record, device installed | “Next oil change due at 67,500 mi” + “Due in 1,230 mi” + [Schedule Service] |
| Oil change on record, no device | “Next oil change due at 67,500 mi” + [Schedule Service] |
| No oil change record | “No oil change on record” + prompt to upload or request |
The “Schedule Service” button links to the Request Service flow with the preferred shop pre-selected and “oil change” pre-filled.
Post-MVP: This panel expands to show tire rotation, brake inspection, and other service reminders powered by the Living Health Record and manufacturer intervals.
8.4 Driver Upload RO
Drivers can add their own repair records from any shop — even shops that aren’t on the myodo platform.
Use cases:
- Paper records the driver wants to digitize (camera capture)
- PDF repair orders from email (download and upload)
- Email forwarding (see below)
Upload methods
flowchart TD
A[Driver wants to add a record] --> B{Method}
B -->|File upload| C[Drag-and-drop or file select]
C --> D[PDF or image accepted]
B -->|Camera capture| E[Take photo of paper record]
E --> D
B -->|Email forward| F["Driver forwards shop email to their myodo ingest address"]
F --> G[System extracts PDF attachment]
G --> D
D --> H[Same parsing pipeline as shop uploads]
H --> I[Record attributed to driver, linked to vehicle via VIN]
Email forwarding: Each driver gets a unique ingest email address (e.g., records+{token}@myodo.co or similar — engineer decides format). The driver forwards an email from their shop that contains a PDF attachment. The system extracts the attachment and runs it through the standard parsing pipeline. The record is attributed to the driver.
Key differences from shop uploads:
- No shop_id on the source document (or shop is identified from the parsed record content)
- Record is attributed to the driver who uploaded it
- The driver automatically has full access to the record (they uploaded it)
- Identity matching still runs — if the parsed VIN matches a vehicle in the driver’s garage, the record links automatically
| Step | Entity | Operation | Key Fields |
|---|---|---|---|
| Upload file | source_documents | INSERT | file_url, driver_id, shop_id=NULL (unless parseable), status=pending |
| Parse | service_events | INSERT | vehicle_id (matched by VIN), summary, services, costs |
| Vehicle link | service_events | Link to vehicle in driver’s garage via VIN match |
9. Scope Boundary
What’s NOT in MVP Beta
Listed here so engineers can design with awareness but not build them yet.
| Feature | Why Deferred | Design Consideration |
|---|---|---|
| Living Health Record UI | Next major feature after launch | Data model and extraction logic should be designed now — the 40-item taxonomy across 8 categories. Just don’t build the driver-facing UI yet. |
| Manufacturer service intervals (Motor) | Requires Motor API integration | MVP uses simple mileage deltas for oil/tire. Data model should accommodate OEM-specific schedules later. |
| Fleet management | Separate user category | Driver data model should support multi-vehicle from day one. Fleet-specific reporting/bulk management is deferred. |
| NLP service request interface | Complex NL parsing | MVP uses free-text description. Structured line-item parsing is post-MVP. |
| CCPA/CPRA self-service | Needs legal review | Build the consent logging and data export infrastructure. Self-service UI is post-MVP but the data to support it should exist. |
| Forensic audit log | Scope too large for beta | Design immutable event logging from the start — retrofitting is painful. |
What IS in MVP Beta (Checklist)
- Driver onboarding via shop invite: RO parse → account provisioning → invite → claim + consent
- Invite rejection + PII deletion flow with anonymized record retention
- Unclaimed account PII auto-expiry (configurable retention period)
- Deletion request tracking and admin visibility
- Shop onboarding: invite-only, single-session, 5-step flow with mandatory first RO upload
- Shop beta request form (name, email, phone) with notification to myodo team
- Shop email configuration for sending customer invites from shop’s address
- Shop multi-user support: admin + service advisor roles with upload attribution
- Service advisor invite flow (admin adds → email invite → advisor accepts)
- Admin privilege transfer (advisor → owner/manager)
- Structured hours of operation input (batch-set by day groups)
- Stale onboarding detection: 48hr notification if shop doesn’t complete sign-up
- Internal admin dashboard: active shops, waitlisted shops, deletion requests
- Vehicle creation from parsed VIN (with NHTSA decode)
- OBD-II device pairing and telemetry ingestion
- Service history timeline with identity-matched vs. anonymized records
- Repair order upload, OCR, AI parsing, identity matching
- AI-generated record summary (one-liner) stored at parse time
- Preferred shop designation and shop connection management
- Mileage-based notifications: oil change, tire rotation, CEL
- Service requests (free-text to preferred shop)
- Driver app: vehicle card home screen with oil change status
- Driver app: vehicle detail with two-column layout (mobile-responsive, actions on top)
- Driver app: service record accordion drill-down (record → jobs → parts/labor)
- Driver app: upcoming services panel with oil change reminder (5,000 mi default)
- Driver app: “View original document” for owned records only
- Driver app: Upload RO (file upload, camera capture)
- Driver app: email forwarding ingest (unique address per driver, auto-parse PDF attachments)
- Shop Dashboard: upload ROs, receive requests, customer list
- Thread-based messaging between shops and drivers
- Appointment creation and reminders
- Vehicle relinquish and transfer request flow
- Record dispute submission and human review pipeline
- Record visibility rules enforced everywhere