Diagnostic Platform

Command Center

Built in a living room after shifts. Verified by the creator of hexagonal architecture. Independently evaluated against the patterns used by Segment, Palantir, and Stripe.

01
84%
of dealers report AI tools produce ineffective or unusable outputs.

Lotlinx survey of 215 dealership executives, March 2026. 84% of dealers report AI tools produce ineffective or unusable outputs.

The gap between marketed “AI” and usable output is the industry’s largest unsolved problem.

Command Center’s claims are traceable to code — every feature on this page maps to a verified source path.

53.8%

of total dealership gross profit now comes from fixed operations — a record high. The software sold to serve it doesn’t work.

22.4%

average warranty claim denial rate. 78% of claims kicked back at least once before payment.

69%

of technicians report job burnout. 48% say warranty work is the single worst part of working at a dealership.

Sixteen companies analyzed. None demonstrates offline-first operation, on-device inference, or pre-transmission PII scanning. Command Center ships architecture — verified against source code, evaluated against the patterns used by Segment, Palantir, and Stripe.

02 — The Architecture

Built using hexagonal architecture — not because it was clever, but because the bay demanded it. The scan tool eats the only Ethernet port. The Wi-Fi password is on a sticky note from three years ago. It has to run offline. It has to work with whatever database the shop already licenses. It can’t care which AI provider sits behind it.

Hexagonal architecture means the business logic never touches the outside world directly. Databases, AI providers, scan tools — any of them can be swapped without rewriting the application. It’s the pattern used by Segment, Palantir, and Stripe to keep enterprise systems from collapsing under their own dependencies.

Constraint 01
Offline-First

No cloud dependency. No internet required to function. Bidirectional sync queues offline and pushes when connectivity returns. The system doesn’t brick when the network goes down — it degrades gracefully to local SLM inference.

Constraint 02
AI Locked Behind Ports

Deterministic. Temperature locked at 0.2. Won’t fill a gap with a guess. PII-scanned before anything touches a network. Post-generation pin verification cross-references every connector and pin against the vehicle’s actual netlist database.

Constraint 03
Database-Agnostic

SQLite with WAL mode. 24 versioned migrations. Eight databases per vehicle. SHA-256 audit hash chains. sqlite-vec for semantic search. A schema scanner auto-discovers and maps unknown OEM database formats without manual configuration.

Constraint 04
Provider-Agnostic

AI providers, databases, vision engines, sync targets — all swappable through a single JSON config file. The swappable proxy hot-swaps AI backends live, with a smoke-test atomic commit. No restart. No degraded state.

Constraint 05
Six-Layer AI Constraint System

Structured output enforcement. Controlled generation parameters. Database-grounded context injection. Token budget enforcement. Post-generation audit with a separate system prompt. Auto-search feedback loop so the model requests data instead of guessing.

Constraint 06
Cross-Industry Validated

Independently evaluated against the architecture patterns used by Segment, Palantir, Stripe Radar, Linear, VS Code, GitHub Copilot, and Shopify. Held up against every comparison.

Constraint 07
Built for the Bay, Priced for the Bay

~$3/month AI inference cost per dealership. Cloud sync $0–$25. Hardware: $0–$800 one-time (runs on existing bay machines). No enterprise DMS pricing. No per-seat licensing. No hidden infrastructure fees. The cost model matches the floor it was built on.

“

omg, that’s amazing… sweet — that’s exactly what it is supposed to do :)

Alistair Cockburn — creator of Hexagonal Architecture, after reviewing the codebase

03 — What It Does
Diagnostic Foreman
01
Interactive Diagnostic Foreman

Turn-by-turn chat that queries 10 local databases per request — DTC definitions, TSBs, pinouts, harness routing, component locations, flowcharts, symptom bytes, and symptom-based procedures. Pulled from the vehicle’s actual OEM databases. Cites sources so the tech can verify.

Warranty Narrative Engine
02
Warranty Narrative Engine

Generates OEM-compliant 3Cs narratives (Complaint, Cause, Correction) with measurements, TSB citations, and the specific language auditors look for. OEM-specific compliance rules auto-loaded from VIN. Multi-operation support — handles overlapping labor, TSB-guided multi-phase repairs, repeat labor codes, and complex dependency chains in a single narrative. Structured-output enforcement. Labor code suggestion post-generation.

Dual Audit Pipeline
03
Dual Audit Pipeline

Pattern-based rules engine and semantic AI audit run in parallel. Catches missing measurements, vague language, logical flow gaps, undocumented tools. Results merged and sorted by diagnostic impact. Interactive correction workflow preserves the full audit trail.

Knowledge Capture and SLM Training
04
Knowledge Capture & SLM Training

Master tech diagnostic reasoning preserved through LoRA fine-tuning. Trains on approved stories AND rejected ones — with admin reasoning. Dealership-owned AI models. The OEM’s own chargeback window serves as the quality signal. Auto-training during idle.

Pocket Bridge Mobile Companion
05
Pocket Bridge — Mobile Companion

Local WebSocket server connects the desktop to a phone with no cloud intermediary. Phone-based diagnostic chat, VIN scanning, document capture. Live PID streaming from OEM scan tool. Three-tier consent gate. Rolling token auth every 120 seconds.

Vision and Ingestion Pipeline
06
Vision & Ingestion Pipeline

Self-healing vision pipeline captures claim codes from legacy scan tools through screen OCR. Filesystem polling for binary claim data. Thread-safe deduplication. Schema-agnostic OEM database ingestion auto-discovers and maps unknown formats.

Fleet & Training Dashboard
07
Fleet & Training Dashboard

Two analytics panels in one view. Training Status — all users see per-OEM SLM model quality tiers (BEST / HEALTHY / WEAK / COLD) based on story count and approval rate. In-progress training detection, untrained story counts, LoRA version tracking. Fleet Comparison (ADMIN/FOREMAN only) — side-by-side rooftop breakdowns with fleet-wide totals. Server-side PostgreSQL RPC with 5-minute client-side cache.

Shop Floor Display
08
Shop Floor Display

Real-time RO status board for large-format shop floor monitors. CDP-based extraction from Tekion's web application — no API access required. Self-contained HTML dashboard served over local HTTP. Multi-device support: TV, tablet, and phone layouts from the same web adapter. Connection-loss state machine with hysteresis recovery (requires consecutive successes, not just a single poll). Vault caching for resilience. Manual controls: freeze/unfreeze, on-demand announcements, manual RO cards, scheduled recurring announcements. Configurable dealership name.

Dealership Messaging
09
Dealership Messaging Platform

Real-time direct messaging between technicians in the bay. No phone. No yelling across the shop floor. Slide-out panel from the desktop application. Group conversations with name-filtered participant selection. Read receipts, unread badges. Offline-first: messages write locally and sync to the cloud when connected. Rate-limited and emoji-blocked for workplace-appropriate professional communication. Built on the same Supabase real-time infrastructure and sync pipeline as the rest of the platform — no separate chat service required. Feature-flagged for controlled rollout.

Why It Can’t Be Copied
Six Interlocking Moats
Hexagonal architecture — no competitor has ports-and-adapters. Retrofitting it into a monolithic DMS is a rewrite, not an upgrade.
14 provisional patent filings covering 22 patentable ideas — warranties, diagnostics, vision, training, ingestion, encryption.
Zero-impact legacy tool ingestion — screen OCR, filesystem polling, CDP extraction, and UIA bridge. No OEM scan tool or DMS has an open API.
Closed-loop AI self-improvement — the OEM’s own chargeback window serves as the training quality signal. No human curator required.
Offline-first — local SLM inference, local databases, SyncQueue outbox. Cloud sync is best-effort, not required.
Verified differentiation — 16 companies analyzed. None demonstrates local inference, PII scanning, shop floor display integration, or hexagonal architecture in its marketed offering.
See It Working

Architecture diagrams prove structure. Video proves existence. Recordings of the desktop application running on a machine in a transmission bay — not a mockup, not a prototype, not a slide deck.

DIAGNOSTIC SHELL

Interactive Diagnostic Foreman

Turn-by-turn AI-guided diagnosis. Queries multiple OEM databases per request. Sources cited in every response. Live state cards populate from each AI turn. Running offline with local SLM inference.

WARRANTY TOOL

Warranty Narrative Engine

3Cs narrative generation (Complaint, Cause, Correction). OEM-specific compliance rules loaded from VIN. DTC auto-extraction. Labor code suggestion. PII-scanned. Dual-audited. Saved with tamper-evident hash chain.

SHOP FLOOR DISPLAY
◆
Demo Coming Soon

Live Shop Floor Board

Real-time RO status extraction from Tekion via Chrome DevTools Protocol. Multi-device dashboards (TV, tablet, phone). Connection-loss state machine with hysteresis recovery. Manual controls, announcements, vault caching.

04 — Architecture Traced From Code

Every claim on this page is verifiable against actual source code — not a pitch deck, not a whiteboard diagram. Below are the call graphs, port boundaries, and data flows traced directly from the codebase. The flow is verified. The port boundaries are real. The code is the documentation.

01
OEM-Agnostic Warranty Narrative Engine
How a VIN becomes a defensible warranty story — with zero manufacturer hardcoding, including multi-operation claims
VIN decode → OEM identified, manufacturer-specific compliance rules loaded Prompt assembly → OEM-aware prompt built with structured-output enforcement, grounded in the vehicle’s databases. Multi-operation scenarios — overlapping labor, TSB-guided multi-phase repairs, repeat codes, dependency chains — handled in a single narrative pass. AI routing → per-OEM fine-tuned local language model invoked (online/offline swappable via config) PII scan → phone numbers, emails, SSNs scrubbed before ANY save — at save, sync, and training export Dual audit → pattern-based rules engine + semantic AI audit run in parallel, up to 5 correction rounds Storage → cryptographic hash chain on every edit — tamper-evident audit trail, not a mutable document

Why this is defensible: PII is scrubbed before the story touches any network. Post-generation verification cross-references every connector and pin against the vehicle’s actual netlist database. The AI is constrained to structured output with controlled generation — it cannot “fill a gap with a guess.” The audit trail is cryptographically tamper-evident. If an OEM charges back, the dealership has a hash-verified chain of every edit, every prompt, and every audit flag — not a Word document.

02
Multi-Manufacturer Ingestion — Schema-Unknown, Database-Agnostic
The warehouse that doesn’t care which OEM’s database you bought
Schema scanner → auto-discovers and maps unknown OEM database formats — no manual configuration Query pipeline → bundles per-vehicle database paths (DTC definitions, documents) into a unified context Semantic search → vector search across the diagnostic corpus, builds structured context from matched results Prompt injection → context assembled and injected into the diagnostic turn — sources cited in every response

8 database categories per vehicle: DTC definitions, flowcharts, TSBs, pinouts, harness routing, component locations, symptom bytes, symptom procedures. All read through abstract ports — zero OEM-specific imports exist in the domain layer. The schema scanner means a new OEM database format is discovered and mapped without new code. The diagnostic shell queries all databases in parallel per user question and cites the specific source in every response.

03
Screen Watcher & Sentinel Vision Engine
Claim code capture from legacy scan tools — no API required
Dual-sensor capture: Sensor 1: screen OCR — captures active window when a claim screen is open, extracts claim codes via the OCR engine port Sensor 2: filesystem polling — monitors warranty claim directories for binary receipt files, parses and deduplicates Both feed → a coordinator that parses claim codes, VIN, job card, and function — saves to local vault Sentinel vision stack: → object detection model identifies UI regions on-screen → vision-language model extracts text from detected regions → if confidence falls below threshold, degrades to OCR fallback automatically

Self-healing: When vision confidence degrades — due to a tool update, UI change, or resolution shift — the system runs on-device calibration. A validation gate measures whether calibration improved accuracy. If it made things worse, the system rolls back automatically. No cloud retraining pipeline. No manual intervention. The system monitors itself and fixes itself.

04
Supabase Push/Pull — Offline-First Sync Orchestrator
Cloud sync is best-effort. The system doesn’t brick when the network goes down. Includes server-side fleet analytics.
On story save → narrative payload encrypted, queued to durable outbox — zero data loss during offline periods Background sync loop: PUSH PHASE → drains outbox to remote storage when connectivity is available PULL PHASE → retrieves pending narratives, users, claim codes, documents, audit events, model updates, and training status Model sync → downloads newer LoRA adapters trained at other workstations — fleet-wide model improvement Fleet analytics → PostgreSQL RPC function get_organization_stats aggregates per-rooftop story counts, approval rates, and fleet-wide totals server-side. No raw narrative data pulled to the workstation. Fleet cache → 5-minute TTL client-side cache with manual invalidation from the Rooftop Management panel Health visibility → real-time sync status indicator in the sidebar — Ready, Unstable, Failed, or Offline — polled continuously

Failure is visible, not silent: The dual-storage pattern (local vault + remote storage) means no data is lost when offline. The sync outbox is a durable database, not an in-memory buffer — a power loss during an offline period loses nothing. The health indicator shows sync health in real time so ops can see degradation before it becomes data loss.

05
Document Capture — Dual Pipeline, Phone-to-Desktop + Manual
Battery tests, A/C slips, repair orders — captured, extracted, synced
PIPELINE A — Phone-to-Desktop (Pocket Bridge): Technician photographs a document on their phone (battery test, A/C slip, repair order) → Image sent via local WebSocket to the desktop — no cloud intermediary → Document type validated, image decoded, text extracted via vision-language model → Saved locally, pushed to remote storage (fire-and-forget, non-blocking) → Result sent back to the phone — success, extracted text, sync status PIPELINE B — Desktop Viewer (manual push/pull): Card list of captured documents with detail view, type filters, and sort options Manual push/pull per document for controlled sync

Hexagonal at every layer: The capture service is constructed fresh per capture — zero persistent state. All dependencies are injected through abstract ports: vision extraction, local persistence, and remote storage. Processing runs in a background thread so VLM inference never blocks the UI. Every captured document passes through PII scanning before persistence or sync.

06
OEM LoRA Pipeline — Closed-Loop, Per-Manufacturer, Self-Training
How a dealership builds its own AI, trained by its own warranty results, with zero human curation
Approved & rejected warranty stories → exported as structured training data (PII-scrubbed) On-device fine-tuning → applied to the local language model — training runs during idle, no cloud required Trained adapter → merged into the base model, quantized for efficient inference, routed per manufacturer New adapter → pushed to cloud storage, downloaded by other workstations across the fleet Loop closes → every new warranty outcome feeds the next training round — the system sharpens with every claim Training Status → dashboard panel shows per-OEM model quality tiers (BEST / HEALTHY / WEAK / COLD) based on story count and approval rate. All users see it — not role-gated.

Why this is a moat: The OEM’s own chargeback decisions close the loop. A rejected story is training data for what not to write. An approved story that passes audit is training data for what to write. Every technician’s diagnostic reasoning, every successful warranty narrative, every chargeback lesson — absorbed into the model instead of walking out the door when the tech goes home. After a year in the bay, the model has learned from thousands of real claims, across every manufacturer the shop services. That trained model is the dealership’s IP — an asset that grows more valuable with every repair order, and that no other shop has. A competitor would need years of deployment data to replicate this, and the training loop itself is patent-protected.

07
Deeper Systems — What Else the Code Reveals
Subsystems traced from the codebase that deserve visibility
PII SCANNER: phone/email/SSN detection before every story save, sync, and training export three intercept points — no PII in prompts, no PII in training data, no PII on remote storage CONSENT GATE: three-tier authorization — READ and NAVIGATE are pass-through; CRITICAL actions require explicit consent phone-based approval via Pocket Bridge — the technician must approve before any CRITICAL action executes single-use tokens, atomically consumed to prevent replay MULTI-LANGUAGE: warranty narrative generation in English, French, and Spanish UI language selector; runtime prompt instruction injected for target language — no separate prompts ENTERPRISE DMS: abstract ports for repair orders, parts catalogs, customer profiles, scheduling, warranty billing real adapters wired for CDK Fortellis, Tekion Cloud, PartsTech, and Infomedia Microcat when config is populated when config is populated all enterprise integrations default to test doubles — zero coupling to any one vendor HARNESS & PINOUT: structured harness and pinout queries with PNG wiring diagram discovery three injected ports — harness data access, image discovery, and schema-backed column mapping

PII scanner alone is a competitive moat: Of 16 competitor products analyzed, zero perform PII scanning before data leaves the device. Most stream VINs and repair histories to consumer-tier AI APIs with no sanitization. The three intercept points (save, sync, training export) mean PII is caught at every egress boundary — even if one check is somehow bypassed, the next one catches it.

08
Fleet Comparison Dashboard & Training Status
Multi-rooftop analytics, admin-gated rooftop CRUD, and per-OEM training quality for every user — no DMS integration required
TRAINING STATUS (all users): Data source → vault.get_training_dashboard_stats(rooftop_id) queries training_jobs table (latest SUCCESS per OEM) + stories table (per-OEM approval rates) + active PENDING/RUNNING jobs + count_untrained_stories() Tier logic → BEST (500+ stories, 90%+ approval) / HEALTHY (50+ stories, 80%+ approval) / WEAK (below thresholds) / COLD (no training runs). Composite badge: story count + approval rate, both from actual data — no estimates. UI rendering → Summary stat cards (TRAINED OEMs, IN PROGRESS, UNTRAINED STORIES, BEST MODELS) + per-OEM rows with tier badge, story count, approval rate, LoRA version. In-progress OEMs highlighted in gold. FLEET COMPARISON (admin/foreman only): Role gate → DashboardController checks current_user.role — ADMIN and FOREMAN see fleet panel; TECHNICIAN sees only local stats Data source → SyncCoordinator.get_fleet_stats() checks 5-minute TTL cache. On miss, calls remote_storage.pull_organization_stats(org_id) Server-side compute → PostgreSQL RPC get_organization_stats(org_id) aggregates fleet-wide totals and per-rooftop counts server-side — zero raw narrative data transferred UI rendering → Fleet stat cards (5 cards: total, approved, rejected, pending, approval rate) + per-rooftop table with own rooftop gold-highlighted ROOFTOP MANAGEMENT (admin-gated, behind admin PIN): Refresh → remote_storage.pull_rooftops(org_id) → GET /rest/v1/rooftops filtered by org_id Add → remote_storage.register_rooftop(org_id, name, display_name) → POST with optional nickname field (e.g., "Chevy Dealership") Update → remote_storage.update_rooftop(id, {name, display_name, location_code}) → PATCH Deactivate → soft-deactivate via timestamp rename → original name freed for reuse Cache invalidation → every mutating operation calls sync_coordinator.invalidate_fleet_cache() → next dashboard load pulls fresh data

Why this matters to an acquirer: Fleet comparison operates entirely at the database layer — no DMS integration required. The Rooftop Management panel lets an organization add, rename, and deactivate dealerships from within the application itself, without touching Supabase directly. display_name support means rooftops can carry human-friendly nicknames alongside their legal names. The PostgreSQL RPC function runs server-side aggregations (counts, approval rates by status) — no raw narrative payloads leave the database. The Training Status panel gives every user in the organization a single glance at which OEMs have trained models, what tier they've reached, and how many stories are still untrained. All five new port methods on BaseRemoteStorage are hexagonal-compliant, with mock implementations for local testing.

05 — Complete Feature Inventory

What the deep scan surfaced. 50+ code-verified subsystems organized by category — from the diagnostic shell down to the infrastructure services that keep production running. Every entry here exists in the source code. No marketing. No roadmap.

Diagnostic Intelligence
Interactive Diagnostic Shell
Turn-by-turn AI-guided chat queries 10 databases per request. DTC definitions, flowcharts, TSBs, pinouts, harness routing, component locations, symptom bytes, symptom procedures, documents, AI knowledge base. Live state cards. Typewriter animation. Constrained JSON responses. Post-response pin verification against the netlist database.
Diagnostic Queue & Session Comparison
Browse, resume, inject, compare, or delete saved diagnostic sessions. Side-by-side diff of two sessions with common/divergent step detection and optional AI summary. Foreman can inject findings directly into a warranty story.
VIN Services & Vehicle Intelligence
Unified VIN decoding via NHTSA VPIC, CarQuery, and fueleconomy.gov. LRU cache (200 entries). Five-tab UI: Overview, Specifications, Recalls, Images, Service Info. Recall lookup by status, component, year. Maintenance schedules. Safety-critical recall flagging.
DTC Repository
Per-OEM structured diagnostic trouble code definitions. Searchable by code, system, or keyword. Linked to flowcharts, TSBs, and labor codes for each DTC. Powers the diagnostic shell's first query and warranty tool's auto-extraction.
Harness & Pinout Service
Wiring harness routing per vehicle. Connector locations, pin assignments, wire colors (SAE standard). Ground point distribution with voltage drop specs. Three hexagonal ports — data access (8 query methods), image discovery (PNG diagrams), schema-backed column mapping.
Warranty & Claims
Warranty Narrative Engine
3Cs generation (Complaint, Cause, Correction). OEM-specific compliance rules auto-loaded from VIN. DTC auto-extraction from notes. Labor code quick-select bar. Multi-operation support — overlapping labor, TSB-guided multi-phase repairs, repeat labor codes, dependency chains in a single narrative pass. Multi-language (English, French, Spanish). PII-scanned before save.
Dual Audit Pipeline
Pattern-based rules engine + semantic AI audit run in parallel. Five pattern checks: missing measurements, vague language, undocumented tools, time justification, logical flow. Up to 5 correction rounds. SHA-256 hash chain. 82% correction rate.
Story Vault
Full narrative history with RO/VIN/OEM/timestamp/approval status. 1,480-line VaultDB with 12 tables across 10 database mixins. 24 versioned migrations. Admin review panel (approve/reject with feedback). Bidirectional Supabase sync.
Admin Review Panel
Audit pipeline review and interactive regeneration. Approval/rejection workflow with feedback. SLM training dataset generation. Immutable append-only audit logging. FeedbackEngine generates closed-loop rules from rejected stories.
Claim Watcher — Passive Capture
Dual-sensor capture from legacy scan tools — zero API required. Sensor 1: screen OCR watches active window for claim screens. Sensor 2: filesystem polling monitors warranty directories for binary receipt files. Thread-safe deduplication. SPS2 receipt persistence.
Programming Logs & SPS2 Receipts
Captures and stores module programming session data. Tracks SPS2 receipts, calibration files, and module identifiers from OEM programming tools. Unique data capture point that no competitor addresses.
AI & Model Training
OEM LoRA Pipeline
Per-manufacturer LoRA fine-tuning on dealership warranty data. Auto-training during idle. 60-day story maturity gate. Zombie detection (8-hour timeout). Distributed training lock across workstations. Outputs per-OEM quantized GGUF models. Fleet-wide distribution via Supabase. Training Status dashboard (all users) — per-OEM model quality tiers (BEST/HEALTHY/WEAK/COLD) with story counts, approval rates, and LoRA version tracking.
Provider-Agnostic AI Backend
Swappable agent proxy for runtime hot-swap with smoke-test atomic commit. No restart. No degraded state. Separate providers for warranty (quality-prioritized) and diagnostic (speed-prioritized). Independent fallback prevents single-provider outages.
Knowledge Indexer (RAG Ingest)
Ingests images and documents into vector embeddings for the diagnostic shell. Uses a separate AI provider from the shell chat. Powers semantic search across repair documentation, schematics, and service manuals.
Sentinel Vision Engine
Object detection + vision-language text extraction + OCR fallback. Self-healing calibration loop — on-device training when confidence degrades. Validation gate with automatic rollback if accuracy worsens. 11 OEM tool window targets for UI automation.
Enterprise & Identity
Authentication & Authorization
PIN-based login with PBKDF2 hashing (100K iterations, 16-byte salt). Multi-role support (technician, foreman, admin). Legacy SHA-256 fallback. Supabase remote auth fallback when tech_id not cached locally. First-run detection and setup wizard.
Azure AD Enterprise SSO
Enterprise single sign-on via Azure AD identity provider. Falls back to local PIN when not configured. Organization and Rooftop models for multi-location deployment. User profiles with role and active-status tracking.
Three-Tier Consent Gate
READ and NAVIGATE actions pass through. CRITICAL actions require phone-based approval via Pocket Bridge with 5-second timeout. Single-use tokens, atomically consumed to prevent replay.
12 Enterprise DMS Ports
Abstract ports for repair orders, parts catalogs, customer profiles, scheduling, inventory, warranty billing, service history, claims submission, async polling, OAuth 2.0 tokens, offline sync queue, and SSO identity. Real adapters for CDK Fortellis, Tekion Cloud, PartsTech, and Infomedia Microcat. All default to test doubles.
15 Manufacturer Profiles
9 production-ready OEM profiles: GM, Ford, Honda, Toyota, Stellantis, BMW, Mercedes, Mazda, Subaru. Tesla disabled (pending review). 5 synthetic OEMs for testing. Per-OEM compliance rules, bad-terms lists, policy rules, and system prompts. VIN-based routing with GM fallback.
Fleet Operations
Fleet Comparison Dashboard
Role-gated — ADMIN and FOREMAN only; technicians see local stats exclusively. Fleet-wide aggregate stat cards + per-rooftop breakdown table with own rooftop gold-highlight. PostgreSQL RPC backend (get_organization_stats) — aggregation runs server-side, zero raw narrative data transferred. 5-minute client-side cache in SyncCoordinator with manual invalidation from Rooftop Management. Supabase REST API transport with mock fallback.
Training Status Panel
Visible to all users. Per-OEM SLM model quality tiers: BEST (500+ stories, 90%+ approval), HEALTHY (50+ stories, 80%+ approval), WEAK (below thresholds), COLD (not trained). Summary stat cards for trained OEMs, in-progress jobs, untrained stories, best models. LoRA version tracking per OEM. Powered by IVaultRepository.get_training_dashboard_stats() — queries training_jobs and stories tables locally. Introduced with VaultDB migration v22.
Rooftop Management Panel
Admin-gated (behind admin PIN in Settings). Full CRUD: refresh rooftop list from Supabase, add new rooftops with optional display_name/nickname (e.g., "Chevy Dealership"), update name/display_name/location_code, soft-deactivate via timestamp rename. All mutations hit Supabase immediately and invalidate the fleet stats cache. Five new port methods on BaseRemoteStorage — all hexagonal-compliant with mock implementations.
Data, Sync & Schema
Offline-First Sync Orchestrator
850+ line background sync loop. 7 synchronizers: narrative push/pull, claim codes, documents, audit events, training events, LoRA model polling. Durable outbox database — not in-memory buffer. Exponential backoff retry. Real-time health indicator.
PII Scanning & Field Encryption
Three intercept points: save, sync, training export. Detects phones, emails, SSNs, VINs, street addresses. Admin-configured name blocklist. Field-level AES-256-GCM encryption with OS-level key storage. Flagged PII triggers admin review. Zero of 16 competitors do this.
Schema Scanner & Router
Model-aware two-pass scanning (path-based then content-based). Schema router resolves VINs to OEM-specific schemas at the model level. AI-assisted column mapping with content-sampling confidence validation. Merge-save with conflict detection. Transparent v1-to-v2 schema conversion.
Document Capture — Dual Pipeline
Pipeline A: phone photographs document, sent via local WebSocket, VLM text extraction, saved locally, pushed to remote, result returned to phone. Pipeline B: desktop viewer with card list, detail view, 5 doc-type filters, manual push/pull. All hexagonal ports. PII-scanned.
Pocket Bridge — Mobile Companion
Local WebSocket server on port 8089. Four phone tabs: Foreman Chat, VIN Scanner, Manual Control, Doc Capture. QR-code pairing with rolling token auth. Live PID streaming from OEM scan tool. Self-signed TLS with SAN entries for all local IPs. PIN rate-limited (3 attempts/60s cooldown). Session invalidation on desktop logout.
Shop Floor Display
Real-Time RO Status Board
CDP-based extraction from Tekion's Repair Order list via Chrome DevTools Protocol. Two-pass JavaScript injection: text data (RO#, tag, vehicle, customer, tech, VIN, odometer) + flag colors parsed from computed CSS. Positional field mapping handles vehicle name splits, +1 technician indicators, and odometer formatting. Zero API access required.
Web Display Dashboard
Self-contained HTML/CSS/JS dashboard served over local HTTP via FastAPI + uvicorn on port 8090. Dark theme optimized for large-format shop floor monitors, color-matched to the Tkinter control panel. Three device layouts served from the same adapter: / (TV, card grid), /tablet (responsive clamp-based grid), /phone (vertical list with horizontal card scroll). Card grid with RO#, vehicle, customer, technician, flag badge, VIN, odometer. Configurable dealership name in header. 30-second auto-refresh (60s on phone for bandwidth). /data?fields= payload optimization for mobile. Freeze overlay with timestamp. Footer navigation across all three views.
Connection Health State Machine
Four-state degradation with hysteresis recovery: HEALTHY → DEGRADED (1-2 failures, display still updating) → FROZEN (≥3 failures, vault cache fallback, display frozen) → MANUAL_READY (300s frozen, operator notified to take manual control). Recovery requires N consecutive successes (same threshold as failures) — one failure resets the success counter to zero. Prevents flapping from intermittent CDP connections. Auto-recovery from MANUAL_READY follows the same hysteresis gate.
Vault Caching & Resilience
ShopFloorMixin — 10th VaultDB mixin. Snapshots cached to SQLite on each successful poll. Daily cleanup removes stale data. On data source failure, display falls back to last known cache rather than going blank. Scheduled announcements persist across restarts.
Manual Controls & Announcements
Freeze/unfreeze to lock display on a snapshot. Manual Mode — ignore CDP, show operator-added cards only. On-demand announcement banner. Scheduled announcements with date/time targeting and daily recurrence, managed via Tkinter control panel. Per-card manual delete. Thread-safe via threading.Lock.
Operator Control Panel
Dedicated Tkinter tab with browser launch/restart, display start/stop/freeze/manual, real-time health indicator (color-coded HEALTHY/DEGRADED/FROZEN/MANUAL_READY). Device-specific launch buttons — TV, Tablet, Phone — open the corresponding layout in the default browser. Announcement post/dismiss. Manual RO card add/remove/clear with flag dropdown. Scheduled announcement management with DEACTIVATE and delete. All routed through ShopFloorController for hexagonal boundary compliance.
Dealership Communications
Real-Time Direct Messaging
Inter-technician chat via Supabase Phoenix Channels WebSocket. Slide-out panel from the right edge of the desktop application. Conversation list with participant names, last message preview (40 chars), relative timestamps, and unread count badges. Per-conversation message view with left/right alignment — self-messages on the right with blue background, others' messages on the left with sender name. Input bar with Enter key support and Send button. "Do not enter customer information" disclaimer on every message input.
Group Conversations
Multi-participant conversations via checkbox-based participant selection. Name filter bar for narrowing user lists in large dealerships. First message sent inline during conversation creation — no multi-step wizard. Conversation ID generated from SHA-256 hash of sorted participant list for deterministic deduplication. Close and auto-reopen lifecycle — closed conversations reappear when a new message arrives.
Offline Message Queue & Sync
Local-first writes via SQLiteMessagingAdapter (three tables: conversations, messages, conversation_members). Messages persist locally before remote push. Background sync loop every 10 seconds — pulls new messages from Supabase, pushes pending locals, marks synced. Sync status column on each message (pending/synced). Fire-and-forget remote push — user is never blocked waiting for the network. Idempotent inserts (INSERT OR IGNORE) prevent duplicate messages from overlap between real-time and polling.
Content Policy Enforcement
Rate limiting: 10 messages per 10 seconds per technician (in-memory dict with threading.Lock) — generous for normal conversation, prevents abuse. Emoji blocked: only ASCII printable characters allowed — workplace-appropriate enforcement and encoding-safe for PostgreSQL. UTF-8 sanitization on all messages (encode → decode with errors='replace'). No self-messaging — single-participant conversations blocked at the service layer. All validation in the domain service (core/messaging_service.py), not in the adapter.
Infrastructure & Production Hardening
Health Check Service
Probes 24 adapter keys at startup. Reports health status of every wired dependency. Critical failures surface before the UI loads.
Database Backup Service
Automated backups with daily (7 retained) and weekly (4 retained) rotation. SQLite backup to rolling files. Silent and automatic.
Config Validation Service
Phase 0 startup gate. Validates all provider config files before any DI wiring begins. Critical issues raise RuntimeError — the system refuses to start broken.
Feature Flags
Runtime feature toggles driven by provider_config.json. Enables safe rollout of capabilities across deployments. Admin-controlled, no code changes required.
Crash Reporter
Application crash detection with structured error reporting. Reports tracebacks, system state, and adapter status. Autonomous detection — no user needed to file the bug.
Setup Wizard
First-run configuration wizard. Guides initial setup: provider config, API keys, hardware profile detection, synthetic database initialization. Enterprise onboarding in under 10 minutes.
Hardware Profile Service
4-tier classification based on GPU, NPU, RAM, and CPU capabilities. Auto-selects optimal AI backend and model size per machine. Enables SLM inference on hardware as modest as a shop laptop.
Metrics & Structured Logging
Performance metrics collection across AI adapters. Structured JSON logging with enough context to diagnose without reproducing. Event-driven notifications for training completion and sync failures.
Connection Pool & Thread Safety
SQLite connection pooling with WAL mode and busy timeout. Shared SLM singleton with threading.Lock. Thread-safe claim watcher with multi-sensor coordination. Async executor with backpressure and retry decorator.
Automated Test Suite
86 test modules, 1,509 tests — 1,490 passing, verified 2026-08-07 (15 live-model tests marked heavy/slow and excluded from the default CI run by design; 4 skipped without the ML stack). 52% line coverage on core + adapters (20,613 statements). Hexagonal contract tests verify all 65 port interfaces against 36 adapter implementations. VaultDB integration tests against real SQLite. Full SLM training smoke test (8-step LoRA pipeline). 0 security vulnerabilities across all dependencies. CI/CD via GitHub Actions on Windows/Python 3.12. Cold startup: 0.30 seconds.
PII & Secrets Scan
Clean across all production source files. Zero hardcoded Gemini, Supabase, or OpenAI keys. Zero private keys. Zero SSNs. PII detection at three intercept points (save, sync, training export) with AES-256-GCM field-level encryption. Source-level scan verified 2026-07-04.
Memory Footprint
34.3 MB idle after DI wiring (2026-07-04). Python 3.12 baseline of 17.2 MB + 17.1 MB for all 18 registrars. Runs comfortably on a 4 GB shop laptop with standard dealership software already running. Lazy-loaded AI models (SLM, ONNX, Tesseract) incur additional memory only on demand.
Secrets Management
API keys stored in Windows Credential Manager with JSON fallback. Timing-safe PIN comparison. Supabase service_role key migration to Credential Manager. Zero hardcoded secrets — verified by automated audit.
Synthetic OEM Data Pipeline
5 manufacturers, 10 vehicle models. Complete databases per vehicle: labor codes, netlists, schematics, TSBs, flowcharts, DTC definitions, recall libraries, wiring diagrams. Python generation/validation/repair scripts. All legal-risk-free.
Degraded-Mode Design
System never crashes on missing config. Keyword search activates when embedding API is unavailable. Local inference falls back to config-prescribed model when cloud is offline. Graceful degradation, never bricking.
PDI Form Automator
Pre-Delivery Inspection form automation. Generates and opens pre-filled PDF inspection forms. Backed by the PDIConfigService registered in the DI container.
Event Bus Architecture
17+ event categories across the system. auth.*, admin.*, hotkey.*, claim_watcher.*, diagnostic.*, warranty.*, labor.*, doc_capture.*, harness.*, telemetry.*, and more. Loose coupling between subsystems — publish/subscribe, not direct calls.
Home Dashboard
Technician workflow overview. Central landing screen showing current session status, pending reviews, training status, and quick-launch access to the diagnostic shell, warranty tool, and document capture. Training Status panel (all users) — per-OEM SLM model quality tiers (BEST/HEALTHY/WEAK/COLD) with story counts and approval rates. Fleet Comparison panel (ADMIN/FOREMAN only) — per-rooftop stats table with fleet-wide totals, own rooftop gold-highlighted, powered by PostgreSQL RPC with 5-minute cache.
Settings & Administration Panel
Admin PIN-gated access to all configuration. Provider config via JSON. Feature flag management. API key management. User management (register, deactivate, sync). Rooftop Management — add, rename, nickname (display_name), and deactivate dealership rooftops, with immediate Supabase sync and fleet cache invalidation. Audit log viewer with tamper-evident verification.
06 — Verification
Due Diligence Access

The data room exists to answer every question a technical team would ask. No marketing. No white paper written in reverse. Just source-level evidence.

Architecture
36-Page Architecture Atlas
Full domain map. Port-adapter bindings. DI container wiring. Code-verified at 99.5% confidence.
Security
Security Self-Assessment & Testing
Encryption at rest (field-level AES-256-GCM). 0 active CVEs. No hardcoded secrets. PII scan: clean.
Privacy
Data Privacy Compliance
PII detection at three intercept points. CCPA/GDPR mapped. Data retention policy. Offline-first by design.
Testing
16-File Automated Audit Suite
Security. Architecture boundary. Code quality. Silent-failure detection. Resource handling. Provider-failure trace.
Competitive
Competitor Autopsy
16 companies dissected. Claims verified against source code. 50+ features vs. ~7 marketing claims.
Patents
14 Filings · 22 Patentable Ideas
204 claims mapped to specific code paths. Prior art verified. Filing-level enablement provided.
Integration
First 90 Days Integration Plan
12-week timeline. ~24 engineer-weeks. Adapter-swap strategy. Deployment checklist. Synthetic OEM data included.
Evaluation
Independent Architecture Evaluation
21 source files read directly. No documentation consulted. Verdict: genuinely well-architected application.
Pipeline
35 Feature Pipeline Docs
Per-feature pipeline specifications with operator manuals and SVG diagrams. Every major subsystem documented.
Engineering
Diligence Pre-Answer
31 pages pre-answering acquirer engineering questions: architecture, security, testing, deployment, dependencies, IP, future work.
Synthetic OEM Data — Zero-Legal-Risk Demonstration
Every system function runs against fully populated databases from five fictional manufacturers. No real OEM data was used in development or testing.
Amanda
Pioneer (SUV) · Summit (Luxury)
Most Mature
Apex
Aria (Sedan) · Atlas (Pickup)
Well-Populated
Faye
Horizon (EV) · Spark (EV)
Electric Vehicle
Richard
Voyager (Van) · Workman (Truck)
Commercial
Valentino
Avanti (Coupe) · Strada (Sports)
Performance

8 database categories per vehicle. Labor codes. Netlists. Schematics. TSBs. Flowcharts. DTC definitions. Recall libraries. Wiring diagrams. All synthetic. All verifiable. No legal risk for any party.

Data room available to qualified parties under NDA · In-person demonstration on request
Theodore Joseph
Lead Transmission Specialist · Starling GMC · Cocoa, Florida
Software engineering degree. Same hands in the bay.

I’m not a startup founder. I’m not looking for press. I’m a transmission guy who got tired of watching the knowledge walk out the door. I built something because nobody else was going to.

Contact
firestonevalentine@gmail.com LinkedIn
07 — Diligence Pre-Answer

The questions an acquirer's engineering team will ask during technical diligence — each traced directly against source code, not documentation. No marketing. No assumptions. Answers verified June 2026.

Architecture & Design
1.1 — "Is this Hexagonal Architecture actually implemented, or is it aspirational?"
Implemented and largely verified. 65 abstract base classes across 23 interface files in core/interfaces/ define contracts between domain logic and infrastructure. 73+ services wired across 17 registrar phases in the DI container. All 9 factory functions in the ProviderFactory read type from provider_config.json — Mock is the universal default; the system never crashes on misconfiguration.

Boundary compliance: 13 files in core/ import from adapters/. Two are genuine architectural violations (schema registrar, misc registrar). Six are backward-compatibility re-export aliases from an adapter migration. Five are justified by role (the factory must import adapters; the DI container must import registrars). Every violation is cataloged and triaged.

Known gap: Module-level mutable _settings in config.py remains a mutable dict. Derived globals go stale on update. Has an IConfigProvider port for provider_config.json but no equivalent port for settings.json values. Mitigation: wrap in injected config object (2 hours).
1.2 — "How do you handle circular dependencies?"
The one known circular dependency — config.py ↔ key_store.py — was broken by extracting shared constants into core/config_resolver.py. Both files import only from the resolver at module level. Lazy imports inside function bodies execute at call time, not import time — standard Python pattern, no cycle recurs.

Beyond that, lazy imports serve one main purpose: deferring heavy ML library loads (torch, onnxruntime, transformers, llama_cpp) to avoid bloating startup time. These sit inside vision detectors, training adapters, and the local SLM inference adapter — all intentional optimizations, not circular-dependency workarounds.

One cataloged violation: core/provider_factory.py imports from adapters/ via lazy imports inside factory functions — core depends on adapters through its factory, not through a port. Flagged M-7 in the final audit.
1.3 — "The DiagnosticShellController is ~57K chars. Isn't that a God object?"
No. The live file is 35,276 chars, 990 lines — a thick controller, not a God object. Five sub-controllers have already been extracted: QueryPipeline (the three-phase AI flow — the most important extraction), VehicleCascadeController, ShellToolsController, SchemaPathController, SessionRecoveryController, and PocketBridgeController. The remaining delegation wrappers are thin pass-throughs — wiring, not logic. Hard business logic is extracted into testable pipeline classes; sub-controllers handle their domains independently; the remaining glue code is proportionate.

The WarrantyController (40,987 chars, 1,239 lines) is denser but proportionate to the domain: it coordinates story generation, TSB lookup, audit loop, claim injection, labor suggestion, and PDF export — a complex multi-step workflow, not a design defect. Both controllers are acceptable by industry standards for production desktop applications and pose no maintainability risk.
1.4 & 1.5 — "How do you handle config drift?" / "Is the JSON comment pattern stable?"
Config drift does not reach the running system. Three prevention layers: (1) provider_loader.py validates every provider section against a known schema — unknown types or missing required fields trigger a logged substitution of the built-in default. (2) ConfigValidationService (Phase 0, before any DI wiring) confirms the file exists, parses as valid JSON5, and warns on missing sections or type keys. A missing config file blocks startup. (3) ProviderFactory per-function fallback: each factory function catches unknown types and falls back to a safe default (typically Mock).

If provider_config.json is missing entirely, the system starts with hardcoded defaults from _get_default_config(). Every adapter path — 9 sections, 29 allowed types — is validated before a single service is wired.

The JSON comment concern is not applicable: the system uses the json5 library exclusively, which natively supports // and /* */ comments. No manual comment-stripping code exists anywhere. A JSON5 round-trip preserves comments.
Security
2.1 — "There was a Supabase service_role key in settings.json. Is it still there?"
No. settings.json shows an empty string. The key was migrated to Windows Credential Manager under application "StarlingCommandCenter" with key name "supabase_service_key".

config.py _load_supabase_creds() reads from Credential Manager first. If it falls back to settings.json and finds non-empty values, it auto-migrates them to Credential Manager and clears the plaintext — a self-healing migration path. Both settings.json and provider_config.json are listed in .gitignore. Status: fixed.
2.2 — "Why does the manifest require Administrator privileges?"
Because it has to. OEM diagnostic tools (GDS2, Tech2, IDS) run elevated, and Windows enforces UI Automation integrity level matching at the kernel — a medium-integrity process cannot read the UIA tree of a high-integrity process. Without requireAdministrator, the screen watcher, PID monitoring, and diagnostic state capture features cannot function.

The manifest comments explicitly document this rationale and the long-term upgrade path: code-sign the binary, set uiAccess="true", and install to Program Files.

Security assessment: This is a correct engineering decision given the constraints. Every dealership workstation already runs OEM tools elevated. The PocketBridge WebSocket listening on the local network is the only elevated network surface, and it is bound to local-only traffic with self-signed TLS. An acquirer's security team would flag this for post-acquisition hardening, not as a design error.
2.3 — "How is PocketBridge secured?"
PocketBridge is a local WebSocket server on port 8089 connecting the mobile companion to the desktop. It never routes through a cloud intermediary.

TLS: Enabled. Self-signed certificates (RSA-2048, SHA-256, 365-day validity) generated once via certgen.py and persisted across restarts — no regeneration issue. SAN entries cover localhost, *.local, and all local IPs. The phone accepts the cert on first pairing and does not re-prompt.

Authentication: QR-code pairing with rolling token auth. PIN rate-limited (3 attempts per 60-second cooldown). Session invalidation on desktop logout.

Scope: Four phone tabs — Foreman Chat, VIN Scanner, Manual Control, Doc Capture. Live PID streaming from OEM scan tools. All data stays on the local network.

Post-acquisition hardening: The self-signed certificate and unencrypted private key on disk are adequate for single-rooftop deployment. An acquirer deploying at scale would upgrade to CA-signed certs or certificate pinning. Private key is intentionally unencrypted for local development — documented in code comments.
2.4 — "Is PII encrypted at rest?"
Yes. PII is encrypted before it leaves the workstation, and scanned + flagged before it's stored locally.

Cloud at rest: Narratives synced to Supabase are encrypted via AES-256-GCM with 96-bit random nonce before transmission. Two key modes: random key per workstation or derived key via PBKDF2-HMAC-SHA256 from rooftop_id + admin PIN for multi-workstation deployments — no manual key distribution.

Local at rest (SQLite): Stories are scanned, not encrypted. The Windows user profile is the security boundary for a single-user dealership workstation. Adding field-level encryption to the local database would add complexity without meaningfully improving security — anyone with filesystem access has already passed the Windows login.

Scanner coverage: Phones, emails, SSNs at story save time. Scanner is intentionally broad — false positives (part numbers matching SSN format) are handled through admin dismissal. Training exports add a separate PII scrub layer covering VINs, street addresses, and admin-configured customer name blocklists.

Key storage: Windows Credential Manager. Config file fallback exists only for headless development environments — documented in code comments.
AI / ML Dependencies
3.1 — "You depend on the Gemini API. What happens if Google changes the API, deprecates the model, or raises prices?"
Provider-agnostic by design. Four backends — gemini, openai, local (llama.cpp-based SLM), and mock. A change requires editing one type field in provider_config.json. No code changes.

Swappable at runtime: The agent_provider key in the DI container goes through SwappableAgentProxy, then optionally OEMLoRAProxy. Each layer wraps the previous — changing the underlying provider swaps all consumers transparently.

Local SLM path: Uses a GGUF-format model with llama-cpp-python. Operates entirely on-device — no data leaves the shop, no per-call API costs, and per-OEM LoRA fine-tuning makes it dealership-specific over time.

Key storage: API keys in Windows Credential Manager. Not in the source tree. Default config falls back to gemini-2.5-flash.
3.2 — "The genai.Client is created at startup with no timeout. Doesn't this block the UI?"
Identified and fixed. Both AI adapters now use lazy initialization with a 60-second timeout. gemini_agent.py (warranty AI) creates the client on first authenticated call, not at __init__. gemini_diagnostic_adapter.py (diagnostic shell) uses the same pattern with threading.Lock for concurrent access. Startup proceeds immediately; a hanging transport times out on a background thread rather than freezing the main thread.
3.3 — "Are the LLM prompts duplicated across adapters? If you change the audit criteria, how many files do you edit?"
Three prompt families are centralized. Warranty system prompt: core/system_prompt_builder.py — all three live adapters call build_warranty_system_prompt(). Diagnostic shell prompts: core/shell/prompt_templates.py. Audit prompt: core/audit_prompts.py.

Two are duplicated across two adapters each: Labor code suggestion (Gemini + local SLM) and OCR analysis (both use near-identical prompt text). The duplicated prompts produce identical behavior. Changing audit criteria touches one file. Changing labor or OCR behavior touches two files. Four hours to extract.
3.4 — "The system uses dual Gemini clients (AI agent + diagnostic AI). Do they share a key rotation path?"
Identified and fixed. The prior audit flagged independent key rotation — only the agent proxy received the new key, leaving the diagnostic client stale. AIProvidersRegistrar now wires agent_proxy.set_diagnostic_adapter(diag_ai) during registration, and SwappableAgentProxy.update_key() forwards the new key to both targets in sequence. A key rotation reaches both clients. The two adapters still use independent genai.Client instances (different models, different http_options), but key rotation is synchronized.
3.5 — "How do you prevent the LLM from hallucinating pin numbers, component locations, or labor codes?"
Six constraint layers, all code-verified:

1. Pydantic schema enforcement — core/shell/schemas.py: DiagnosticResponse and DiagnosticResponseFull constrain every field the LLM can return (DTC, system, interactive step, parts flagged, sources, highlights). The audit prompt enforces a JSON schema with is_compliant, feedback, and questions.

2. Temperature locked at 0.2 — diagnostic_service.py line 43. OEM profile overridable via manufacturer resolver; user-lockable with set_temperature() (clamped 0.0–1.0) to prevent further profile overrides.

3. Database-grounded context — search_service.py build_context() injects eight local data sources per prompt: semantic text, DTC definitions, documents, component locations, symptom bytes, netlist/pinouts, harness, TSBs, flowcharts, symptom procedures. The LLM is given the data — it doesn't guess.

4. Per-field character budgets — search_service.py _BUDGET caps each context field (pinout at 8k chars, TSB at 500k) to stay within Gemini's 1M token limit. Truncation logs a warning.

5. Post-generation audit with interactive correction — core/audit_prompts.py provides a separate system prompt checking for vague language, missing measurements, and logical gaps. warranty.py run_audit() runs on a background thread. Issues open an AuditPopupWindow; each answer triggers regeneration and re-audit, with prior answers fed back to prevent repetition.

6. Auto-search feedback loop — diagnostic_service.py _auto_search_loop(): the LLM can set needs_more_info: true with a search_query. The system executes a new database search and retries. Capped at 2 iterations.
4.1 — "Why does the test suite have 60+ failures?"
0 failed, 1,490 passed, 4 skipped — 100% pass rate. Verified August 7, 2026, from the canonical suite in the deliverable tree (1,509 tests collected; 15 live-model tests excluded by design via heavy/slow markers).

The original 60+ import failures (stale warranty_tool.* references in test_gemini_client.py and test_story_vault_separation.py) are gone — both files deleted and replaced by test_warranty_core.py. All 36 remaining logic/test-expectation failures (schema scanner, provider factory, backup service, sync tests, DI container) have been resolved.

Root cause: source changed, tests didn't follow. The failures were stale test expectations — not broken code. All 36 are now fixed. The test suite passes cleanly with zero failures.
4.2 — "What's your testing strategy for the AI components?"
Three levels of testing with deterministic mocks standing in for the LLM itself.

Prompt assembly: test_system_prompt_builder.py verifies the centralized warranty prompt builder — default GM persona, OEM profile injection via resolver, admin feedback rule injection.

Pattern audit: test_audit.py (35+ tests) and test_audit_patterns.py cover every external constraint layer: missing measurements, vague language, undocumented tools, time justification, logical flow, and the full run_pattern_audit() pipeline with deduplication.

Adapter contracts: test_local_slm_adapter.py covers warranty story generation, streaming, labor code suggestion, audit, and OCR analysis. test_validate_swap.py tests swappable proxy mechanics — swap validation, rollback on failure, OEM LoRA reload. test_oem_routing.py tests per-OEM LoRA routing. test_slm_pipeline.py covers training data export — PII scrubbing, encryption/decryption, admin permission enforcement, remote narrative fetching.

Two mock adapters provide deterministic responses: MockAgentAdapter (implements IAgentProvider — fixed responses for warranty story generation, audit, OCR, labor suggestion, DTC advice, service info) and MockDiagnosticAIAdapter (safe defaults for chat, embeddings, file upload, metadata extraction). The LLM itself is not unit-tested — it's an external dependency, integration-tested through the provider interface.

Known gap: No automated regression tests comparing AI output against expected approval criteria. Roadmap item: build a benchmark dataset from vault stored stories.
4.3 — "How do you test multi-OEM support without real OEM databases?"
No copyrighted OEM data was used — everything is original work or synthetic.

1. Manufacturer profiles (original work): Three complete OEM profiles in manufacturers/ (GM, Subaru, Mazda) document warranty compliance rules, narrative requirements, audit rules, and OEM-specific terminology. Built from publicly available sources — NHTSA-hosted bulletins, OEM warranty administration manuals (public documents), I-CAR position statements. No OEM database was accessed to build any profile. The ManufacturerResolver maps VIN first-3-characters to these profiles; system_prompt_builder.py injects OEM-specific persona, rules, and terminology into AI prompts. Same code, different OEM compliance.

2. Faux DB (100% synthetic): A documented 16-step playbook produces fictional manufacturers with fictional vehicles, fictional DTCs, fictional labor codes, and complete database structures matching the Schema Store v2 format. 5 fictional OEMs, 10 vehicle models. Structurally identical to real OEM databases but every data point is fictional. Zero copyright risk. An acquirer can route a synthetic VIN through the full pipeline and verify OEM-specific behavior.

3. Schema scanner tests: build_schema_variants.py creates variant databases with intentionally shifted column names (Mitchell1, Alldata, Identifix) to verify the scanner discovers and maps non-standard schemas regardless of OEM. test_schema_scanner.py (30+ tests) proves the scanner works against any naming convention.

What's NOT in the codebase: Actual OEM diagnostic databases — GM's labor codes, Ford's wiring diagrams, Toyota's DTC definitions. These are copyrighted, licensed products. The architecture is ready. An acquirer with existing OEM relationships provides the data; the code provides the behavior.
5.1 — "The requirements.txt is missing 15+ dependencies. What would break on a fresh install?"
Resolved. The original May 2026 audit found 9 packages listed with 15+ missing. The current requirements.txt lists 37 packages across 10 labeled sections. Every missing dependency is now present: google-genai, keyring, pymupdf, sqlite-vec, onnxruntime, transformers, pydantic, sounddevice, soundfile, edge-tts, SpeechRecognition, mss, pdfplumber, pywinstyles, keyboard, numpy, cryptography, qrcode — all with minimum versions.

Two packages are intentionally excluded with documented pre-built wheel alternatives (llama-cpp-python and just-playback — both require an MSVC compiler to build from source). A separate requirements-dev.txt provides pytest, pytest-mock, and pytest-cov.

Optional sections (Local SLM Training, Vision Pipeline, Screen Automation, Audio, Vector Search, Pocket Bridge, Azure AD) are labeled with explicit dependency gates. A minimal deployment needs only 9 core packages plus the chosen AI provider.
5.2 — "Command Center.spec references the deprecated Google Gemini SDK. Does the frozen .exe work?"
Resolved. The .spec file referenced in the original audit no longer exists in the project tree. The project runs from source. The google.generativeai → google.genai migration flagged by the audit was completed in the source code. A production PyInstaller build would reference the current requirements.txt (which already documents all hidden imports). This is a straightforward post-acquisition productionization step.
5.3 — "Why is this a Windows-only desktop application instead of a web app?"
The target is a dealership service bay. OEM diagnostic tools (GDS2, Tech2, IDS) are Windows-only and run elevated. The application reads their UIA trees — a kernel-enforced Windows capability. No web application can do this.

Dealership internet is unreliable — the J2534 passthrough device often monopolizes the Ethernet port. A web application fails offline; a desktop application with local SQLite databases operates continuously regardless of connectivity.

The core logic (core/, adapters/) is platform-agnostic Python. Only the UI layer (ui/, customtkinter) is Windows-tied. Porting to macOS or Linux requires a UI rewrite but zero core changes. The PocketBridge mobile companion already provides a web interface for phone access.
6.1 — "You're a solo developer. What's the bus-factor risk?"
The risk is real. Three structural mitigations:

1. Navigable without the developer. The hexagonal architecture uses standard Python patterns (ABCs, DI container, provider factory). A senior Python engineer can trace a warranty narrative from ui/views/warranty.py → core/system_prompt_builder.py → adapters/gemini_diagnostic_adapter.py in an afternoon. The architecture enforces the dependency direction.

2. Documentation exists for critical paths. The maps/ directory contains architecture-atlas, dependency-matrix, and pipeline-flowcharts. The Faux DB playbook documents the synthetic data pipeline. A triaged issue list is documented — a new contributor has an onboarding map on day one.

3. Nothing is custom. No custom ORM, no custom event loop, no custom build system. Standard Python 3.12+, standard packaging, standard libraries. The most exotic dependency (llama-cpp-python) is optional — Gemini API works without it.

Recommended transition: 3-month developer transition with the acquirer's engineering team. Month 1: pair-program architectural decisions into a formal ARCHITECTURE.md. Months 2–3: diminishing support as the team takes ownership. Standard solo-founder acquisition pattern.
6.2 — "How do you handle crash reporting in a desktop app without a cloud backend?"
core/crash_reporter.py (120 lines) installs as both sys.excepthook and threading.excepthook — every unhandled exception on any thread is captured. Structured JSON crash reports are written to the logs directory with timestamp, app version, Python version, platform, exception type, message, and full traceback.

A user-facing error dialog displays the report path so the technician knows where to find diagnostics. The dialog silently degrades if Tkinter isn't running — the crash reporter itself never crashes. Keyboard interrupts pass through to Python's normal handler.

Now Implemented: Telemetry & Observability. We integrated Sentry-SDK (fully compatible with self-hosted GlitchTip) directly into core/crash_reporter.py. If a telemetry_dsn is configured in settings.json, crash reports are securely uploaded in a non-blocking background thread.

Local PII Redaction: To satisfy strict dealership audits, the telemetry includes a recursive client-side before_send interceptor that scrubs all Gemini keys, 17-char VINs, phone numbers, and emails in local variables and stack traces before any data leaves the local workstation. If no DSN is provided, Sentry silently de-initializes with zero overhead.
6.3 — "How do you handle graceful shutdown when the process is killed?"
Three layers of shutdown protection:

1. Atomic settings writes — _save_settings() in config.py writes to a temp file first, then uses os.replace() for an atomic rename. A mid-write process termination cannot truncate settings.json. The non-atomic write gap documented in the May 2026 audit is fixed.

2. Ordered shutdown — ConnectionPoolManager.close_all_pools() is registered with atexit for clean connection pool closure. DiagnosticShellController.shutdown() provides ordered shutdown: flag → stop polling loops → stop I/O → cancel network → shutdown pools → join threads with timeout (3 seconds for vision thread).

3. Crash reporter — Any exception that escapes the shutdown sequence is captured and written as a crash report.
7.1 — "The claims document asserts support for Toyota, Ford, Stellantis, BMW, Mercedes. But the manufacturer resolver only has GM WMI codes. What's the actual state?"
The manufacturers/ directory contains 15 manufacturer directories — substantially more than the original audit's "empty stubs" characterization.

Production-ready profiles (WMI codes, compliance rules, audit rules, OEM terminology, scan tools, warranty policies):
• GM — full profile + labor codes, symptom DB, vision RAG
• Ford — full profile + bad terms
• Toyota — full profile (TIS Techstream, TIS Service Manual, Toyota Warranty Policy)
• Subaru — full profile (SSM4, Denso DST-i, STIS Service Manual, CARB battery coverage)
• Mazda — full profile (MDARS, IDS scan tool, M-MDS)
• Honda — full profile
• BMW — full profile
• Mercedes — full profile
• Stellantis — full profile

Tesla — disabled pending review (no public diagnostic data source available)

Faux DB (synthetic, for testing): Apex, Amanda, Faye, Richard, Valentino — 5 fictional OEMs

All nine production-ready profiles were built from public sources (NHTSA bulletins, warranty administration manuals, I-CAR position statements). No copyrighted OEM database was accessed. The actual diagnostic databases behind the profiles are copyrighted, licensed products — an acquirer with existing OEM relationships supplies the data.

7.2 — "How do you prove the multi-OEM architecture works without real Ford/Toyota data?"
The Faux DB synthetic data pipeline. 5 fictional manufacturers with 10 vehicle models, identical database structures to their real counterparts (Apex Atlas = Ford F-150, Apex Aria = Toyota Camry, Amanda Pioneer = Jeep Wrangler, Faye Horizon = Tesla Model S, etc.).

An acquirer's engineering team can route a synthetic VIN (9AX...) through the entire pipeline — VIN resolution → OEM profile → compliance rule injection → AI prompt → narrative generation → audit — and verify the output matches the fictional OEM's compliance rules. Same code, different profile → different behavior. That proves the architecture works.

The Faux DB playbook documents a repeatable 16-step process. 2 new manufacturers in 4 hours.
Multi-Rooftop & Fleet Operations
7.3 — "How does the Fleet Comparison Dashboard work? Does it pull raw story data to every workstation?"
No raw data leaves the database. All aggregation runs server-side via a PostgreSQL RPC function get_organization_stats(org_id) defined in core/supabase_schema.sql. The function performs a single SQL query joining public.rooftops and public.synced_narratives, aggregating story counts by status (approved, rejected, pending) across all rooftops in the organization. Fleet-wide totals are computed in the same query.

Only aggregate numbers are returned: total stories, approved, rejected, pending, and approval rate — per rooftop and fleet-wide. The narrative_json column is encrypted and is never accessed by this function. The workstation never receives raw story data from other rooftops.

Caching: Results are cached client-side in SyncCoordinator with a 5-minute TTL. The Rooftop Management panel invalidates the cache on any rooftop add, rename, or deactivate — the next dashboard load pulls fresh aggregates.

Role gating: The dashboard controller checks current_user.role. Only ADMIN and FOREMAN roles see the fleet comparison panel. Technicians see only their own rooftop's local statistics. Security model: The PostgreSQL RPC runs as SECURITY DEFINER — the RLS bypass is intentional and limited to aggregate counts only. The encrypted narrative_json payload is not decryptable at the database layer. This is documented in the SQL file and the adapter code.
7.4 — "How does rooftop management work? Can an admin add or rename rooftops without touching Supabase directly?"
Yes. The Settings view contains an admin-gated Rooftop Management panel accessible only behind the admin PIN. From this panel, an admin can perform all lifecycle operations on rooftops without opening the Supabase dashboard or SQL editor.

Operations available:
• Refresh — remote_storage.pull_rooftops(org_id) fetches all active rooftops via GET /rest/v1/rooftops?org_id=eq.{id}&order=name.asc
• Add — remote_storage.register_rooftop(org_id, name, display_name) creates a new rooftop via POST. The display_name parameter supports human-friendly nicknames (e.g., "Chevy Dealership") distinct from the legal name
• Update — remote_storage.update_rooftop(id, {name, display_name, location_code}) modifies existing rooftop fields via PATCH
• Deactivate — soft-deactivation appends a timestamp suffix to the rooftop name, releasing the unique constraint on (org_id, name) so the original name can be reused immediately

Five new port methods were added to BaseRemoteStorage (in core/interfaces/storage_provider.py): pull_rooftops, register_rooftop, update_rooftop, deactivate_rooftop, and pull_organization_stats. All are implemented in adapters/supabase_storage_driver.py and no-oped in adapters/mocks/remote_storage_adapter.py — the system never crashes on missing cloud connectivity. The display_name column was added to the rooftops table via ALTER TABLE rooftops ADD COLUMN IF NOT EXISTS display_name TEXT DEFAULT '' — a non-destructive, idempotent migration safe for re-execution.

Cache invalidation: Every mutation triggers sync_coordinator.invalidate_fleet_cache(). The next dashboard load fetches fresh aggregates, ensuring the Fleet Comparison panel never shows stale data after a rooftop change.
8.1 — Priority-Ordered Issue Register (Updated June 2026)
Of 22 original audit findings: 8 fixed, 2 resolved, 1 improved, 1 assessed. Zero critical items remain. 10 remaining items are all LOW or TRIVIAL — ~12 hours total effort.

Fixed: AIAgent startup timeout ✓ Supabase key in settings.json ✓ requirements.txt completeness ✓ PocketBridge TLS ✓ _save_settings() atomic write ✓ Dual Gemini key rotation ✓ OEM LoRA short-retention ✓ Sentry-SDK Observability & Local PII Scrubber ✓ Selective Lazy-Loading GUI (<3s boot) ✓ Handoff Sync Freeze ✓ TclError Layout Packing ✓ FPDF Cross-Library Resilience ✓

Resolved: PyInstaller .spec (removed, runs from source) ✓ Test suite (0 failures / 1,490 pass, verified 2026-08-07 — 100% pass rate) ✓

Open (all LOW/TRIVIAL): pdi_config.json PII (30 min), Module-level _settings (2 hr), WAL mode gaps (2 hr), ConsentGate race (2 hr), sqlite-vec silent failure (15 min), OEM Router accumulation (1 hr), print() statements (15 min), missing __init__.py (5 min), log PII (30 min), duplicate import (5 min), hotkey hook (1 hr), vision shutdown delay (5 min).
8.2 — "What's the deprecation/dead code situation?"
Four items were identified in the original audit. Updated June 2026:

• core/shell/agent.py — Removed. No longer exists.
• core/database.py no-op stubs — Present. No callers depend on them. Low priority.
• core/repository.py — Removed. No longer exists.
• core/models.py / enterprise_models.py duplication — Both exist. Consolidation recommended.

Two of four resolved. Two remaining are low-risk cleanup.
9.1 — "What prevents a competitor from copying this with a generic LLM prompt?"
A generic LLM prompt produces text. It does not do eight things this program does:

1. Cross-reference the narrative against the OEM's compliance rules
2. Verify that referenced pin numbers exist in the vehicle's netlist
3. Check that the labor operation maps to the diagnosed DTC
4. Ground diagnostic steps in the OEM's published diagnostic flowchart
5. Run a post-generation audit pass (pattern-based + semantic)
6. Support interactive correction when the audit finds issues
7. Capture diagnostic tool state via background OCR
8. Produce an auditable trail with user attribution and timestamp

The six-layer constraint architecture is the moat. A competitor can ship a prompt wrapper in 2 months. A competitor cannot ship a system that does all eight with multi-OEM normalization, offline-first operation, and background OCR capture in under 18–24 months — and would need to engineer around 14 patents.
9.2 — "What's the patent enforcement strategy?"
14 provisional filings protect specific, implemented workflows — not abstract ideas. Each has at least one claim fully or partially implemented in source code. The patent cross-reference maps every claim to its implementation status.

Engineering-around cost: 18–24 months and $4–$8 million (5–8 senior engineers, patent landscape analysis, opportunity cost). The portfolio's breadth makes it economically impractical to engineer around without infringing at least some claims.

Trade secret protection provides a second layer. Temperature values, budget caps, matching algorithms, and prompt templates are embedded in source code — not disclosed in any public filing — and are the calibration that drives first-pass approval rates.
10 — What We Would Tell an Acquirer's Lead Engineer
"The architecture is hexagonal, enforced by 65 ABCs and a DI container managing 73+ services — a senior Python engineer will recognize the patterns immediately. The test suite passes 1,517 tests (1,514 passing, 1 expected RAM constraint, 2 skipped); all 36 previously-stale test expectations have been resolved. The requirements.txt is complete at 37 packages across 10 labeled sections, with dev dependencies cleanly separated.

Of 22 original audit findings: 8 are fixed, 2 resolved, 1 improved, 1 assessed as acceptable. Zero critical items remain. The 10 remaining items are all LOW/TRIVIAL — ~12 hours total effort. Two of four deprecated files removed.

Nine production-ready OEM profiles exist (GM, Ford, Honda, Toyota, Subaru, Mazda, BMW, Mercedes, Stellantis), built from public sources, with one disabled pending review (Tesla). The Faux DB (5 fictional OEMs, 10 models) proves the multi-OEM architecture works without requiring access to copyrighted data for diligence.

Fleet operations are fully implemented: a Fleet Comparison Dashboard (ADMIN/FOREMAN-gated) aggregates per-rooftop warranty stats server-side via PostgreSQL RPC with 5-minute client-side caching. The Rooftop Management panel (admin-gated, behind admin PIN) provides full add/rename/nickname/deactivate lifecycle for dealership rooftops from within the application — no Supabase dashboard access required. Five new port methods on BaseRemoteStorage, all hexagonal-compliant with mock fallbacks.

The six-layer constraint architecture is the technical moat — 8 specific capabilities a generic LLM prompt cannot replicate. 14 provisional patents protect specific workflows; engineering-around cost is $4–$8 million over 18–24 months.

This is a solo-built product on standard Python 3.12+. No custom infrastructure. An engineer familiar with hexagonal architecture can trace the full warranty narrative pipeline in an afternoon. We recommend a 3-month developer transition with diminishing support over months 2–3."