A grounded, day-by-day path to putting Clara in the hands of a real warranty manager at Greatwest Kenworth. Built on the recordings and AI transcripts of the customer meetings you've shared with me, the existing Chrome extension codebase, and a thorough audit of every system Clara has to touch.
I'm putting this in writing before the work starts so you can see exactly what I'm committing to, where the risk is, and what I need from you to hit the dates.
It's grounded in the videos and AI transcripts of your meetings with Greatwest, Pape, Gary's shop, Maska and Sean. I've worked through every one of those, walked the existing Chrome extension codebase end to end, and done my own audit of the integration landscape for each system Clara has to talk to.
Read the surface for the shape of the plan. If you want to see the technical work underneath, open the technical detail blocks scattered through the page, they're there for the skeptical read. Everything in those blocks is backed by primary sources I can show you.
Across every meeting recording I've worked through, the story is the same. A single repair involves eight to ten technicians, each writing notes in their own voice, sometimes in their second language. A warranty manager has to turn that raw material into a formal Complaint / Cause / Correction narrative that PACCAR will approve on the first try, and when the story doesn't match the parts that were billed, or when small billable operations never make it into the write-up, the claim gets rejected. Clara's job is to sit inside that workflow and close the gap between what the techs wrote and what PACCAR will approve, without ever inventing content that wasn't actually there. That last part is not a style preference. It's a warranty audit constraint, and it shapes every part of the product.
Different customers run different stacks. Clara is four surfaces that share one backend so any customer, on any stack, has a real entry point.
One cloud service that every client talks to. Holds the narrative engine, the reconciliation engine, per-dealer training data, and the connectors to outside systems. Multi-tenant with per-dealer isolation.
A browser workflow for warranty analysts who can't (or don't want to) use a Chrome extension. Paste tech notes in, drag a screenshot from their DMS, get a clean CCC narrative out. Universal fallback for any customer whose DMS we can't reach directly yet.
Tenant management, training-data ingestion, analytics, deadline tracking (PACCAR's 45-day file and 30-day appeal windows). The surface where the CEO or the warranty-team lead sees how Clara is performing for the shop.
Our existing Chrome extension, migrated to the unified backend. Lives inside Decisiv, Karmak Blaze and PACCAR's warranty portal as a sidebar. This is how we intervene inside the customer's live workflow on day one, without asking them to change anything.
Two different customers in your meetings asked for the same thing from opposite angles. Greatwest wanted Clara to flag the case where the parts bill shows a clutch was installed but the tech's story never mentions replacing one. Sean's shop wanted Clara to catch the case where the tech clocked 7.1 hours but only described 5.6 hours of work, so they can add the missing operation to the story before it's timestamped and locked.
Those are the same feature. Clara's reconciliation engine checks what was documented (the tech story) against what was claimed (parts, hours, operations) and flags the gaps. We build it once and surface it in two places: in the warranty analyst's admin review, and (V1.5) in the foreman's live review at the time of repair. This is the piece that makes Clara more than "a better ChatGPT for warranty narratives."
Backend: FastAPI (async Python), PostgreSQL with pgvector for semantic search over per-dealer narrative corpora, Clerk for multi-tenant auth, LiteLLM fronting Anthropic's Claude models (Haiku for routine tasks, Sonnet for the hard ones). Production hosting on AWS (ECS Fargate + RDS) with Terraform-managed infrastructure that is portable to GCP or another provider if we need to move.
Frontend: React + TypeScript for the web app, dashboard, and Chrome extension. The extension's DOM-adapter pattern is already written, we're extending it for Blaze and migrating the backend-connection layer onto the unified API, not starting from scratch.
On the Windows companion agent. Deferred to V1.5+. The original plan assumed we'd need a Windows agent to reach customers running Karmak Fusion. New research (see the Karmak Fusion section below) shows we have three better paths into Fusion that don't require a desktop install. The Windows agent is still on the roadmap but is no longer blocking V1 for any prospect on our current pipeline.
Clara has to talk to four outside systems to do its job. Here's what each one is, who uses it, and exactly how we reach it, both on day one and long-term.
Where repair cases start. The service advisor opens a case in Decisiv, technicians log notes against it, the warranty manager reviews them. At many PACCAR dealers, including our first licensee, Decisiv sits upstream of the DMS, and its data syncs bidirectionally into Karmak Blaze or Karmak Fusion. That makes Decisiv the highest-leverage place to intervene when it's available: fix the narrative once, and it can propagate into the DMS without us touching the DMS directly.
Chrome extension overlay on the Decisiv web app. The same adapter pattern the existing Clara extension already uses, we're migrating it onto the unified backend.
Decisiv SRM Connect REST API via their partner program. Server-to-server, no browser required.
Decisiv is a Rails + Webpacker web app hosted at paccar.decisiv.net (and a small number of per-customer variants). It sets X-Frame-Options: DENY, which rules out embedding it in an iframe, the Chrome extension is the right approach today. It has no bot detection to speak of and the DOM is stable across releases, so a selector-based adapter is reliable.
SRM Connect API (V2 target). Decisiv publishes an official partner-gated REST API at srm-api.decisivapps.com, documented at api-docs.decisiv.net with OpenAPI 0.48.x. Resources: Platform API, Global Assets API, Service Provider API. It models the domain as case → operations → notes/tech stories, plus Global Assets for warranty context. Partner contact: Dillon Martell at Decisiv (sales@decisiv.com). The approval path is 2-4 months, which is why the Chrome extension remains the V1 wedge, but we design the backend around the SRM Connect resource shape so the eventual cutover is a backend swap, not a product rewrite.
A cloud-native, mobile-friendly dealer management system. Heavily adopted among Kenworth dealers, including our first licensee. Originally built by DSI Solutions and acquired by Karmak in September 2025, Karmak publicly committed in January 2026 to keeping both Blaze and Fusion alive as parallel products, so this is not a system on its way out.
Chrome extension DOM adapter. A stub already exists in our codebase; we extend it from the live DOM walkthrough Greatwest gave us during the kickoff.
Karmak Unity REST API once Blaze coverage lands. We pursue Karmak partner status in parallel.
Blaze is a browser-based SaaS at blz.dsisolutions.biz. Because it's a pure web app, the Chrome extension architecture works cleanly, same pattern as the Decisiv adapter, just different selectors.
Decisiv ↔ Blaze already has a bidirectional sync at dealers who run both systems: CCC narratives, operations and parts flow from Decisiv into Blaze when a case is exported to a repair order; tech stories and the RO number flow back. That's how the upstream-leverage story works at Greatwest specifically.
Karmak Unity REST API (V2 target). Unity is Karmak's official REST API at api.karmak.io, OAuth2 client-credentials, covering 85+ views including RepairOrderHeader, RepairOrderTask, and RepairOrderDetail, with the full field set we need (TaskComplaintComment, TaskCauseComment, TaskCorrectionComment, VMRSCode, SRTCodes, IsCustomerWarranty). Unity is confirmed for Fusion today; Karmak has stated Blaze coverage is on the roadmap but there is no public ETA. Applying to the Karmak Integration Partner program early is how we secure access for when it lands.
The Windows desktop enterprise DMS used by some of our prospects. Historically considered the hardest system to integrate with, which is why our first plan leaned on a screenshot-based fallback. Fresh research changes that picture entirely. We now have three real doors into Fusion that don't require waiting on a multi-month partner program, plus a screenshot fallback if none of them are available at a given customer.
Karmak's first-party Create RO XML feature in the Integrated File Transfer subsystem. Customer-configured, no Karmak approval needed.
Read-only SQL against Fusion's Microsoft SQL Server database, the same semantic layer Karmak's own report writer already exposes to customers.
A small helper reading and writing Fusion's WinForms controls via Microsoft UI Automation. Real controls, not pixel scraping.
Universal fallback in the web app. Works at any customer, on any DMS, even without integration access. Brittle compared to the three doors above, but always available.
Fusion's stack, confirmed from primary sources. Karmak's own Senior Software Developer job posting names the stack as "VB.NET / C# WinForms applications in Visual Studio." Karmak's DBA job posting names the backend as "Microsoft SQL Server, tables, indexes, stored procedures, views, triggers." Deployment runs in both on-prem and Karmak-hosted cloud configurations, confirmed from Karmak's 3.60 release notes. There is no public SDK, DLL or COM surface, that door is closed. But the three we do have are all real.
Door 1. Create RO XML via Integrated File Transfer. Fusion 3.60+ ships an in-product "Integrated File Transfer" subsystem. Admin forms PMU90700 and PMU90710 configure a file-transfer server and its mappings; PMB91065 handles automated XML imports including a named Create RO XML feed; PMB91080 is the symmetric export form. This is a normal admin feature the dealer already controls. No partner-program approval, no vendor escalation. We drop a cleaned CCC XML into a mapped folder on a schedule, Fusion ingests it. Open question: whether the XML feed supports UPDATE on an existing RO or only CREATE. That's the first thing we verify in the sandbox.
Door 2. Read-only SQL against Fusion's database. Fusion's reporting module (Fusion Report Writer) is built on embedded Logi Symphony over the production SQL Server database. That means there is already a published, customer-facing semantic layer that the dealer's own business users query every day. A read-only SQL login gives Clara structured access to RO headers, tasks, details, tech stories, VMRS codes, SRT codes, labor hours, and parts lines. It's the same surface Karmak's own reporting already exposes; we're just pointing it at a different consumer.
Door 3. UI Automation helper. Because Fusion is WinForms, its UI exposes a first-class Microsoft UI Automation tree with real, named controls (textboxes, grids, tabs, menus) that tools like pywinauto, FlaUI and Microsoft Inspect see natively. A small helper running inside the dealer's Windows session (or inside their Citrix / RDS image if Fusion is deployed remotely) can read the complaint/cause/correction textboxes and the multi-tech story panel directly, push them to Clara's API, and write the reformatted CCC back via UIA. No OCR, no loss of field structure.
Unity API stays on the roadmap. The Karmak Unity REST API remains the long-term target for Fusion, but it's a 6-12 month partner-program path. We pursue it in parallel, not on the critical path. None of the three doors above require it.
Not relevant for Greatwest specifically. Greatwest runs Blaze, not Fusion. The Fusion integration work is for customer #2 onwards. It does not block V1.
PACCAR's Dealer Warranty Web Claims portal. The final gate, where the warranty manager submits the formatted claim to Kenworth for approval. Web-based, PACCAR-branded, enforces CCC format, and (by reputation) actively penalizes narratives that read like generic AI output. It has a hard 45-day filing window from repair completion and a 30-day appeal window after a denial.
Chrome extension overlay on the DWWC portal. Final-stage validation and one-click submission of the Clara-approved narrative.
Deadline tracking baked into the admin dashboard, Clara watches the filing and appeal windows and nudges before they close.
PACCAR's warranty reviewers explicitly flag narratives that look machine-generated, generic phrasing, over-long sentences, boilerplate lead-ins, overly-perfect grammar. That's not a prompt concern we solve at the edges; it's a first-class product constraint. Clara's narrative engine is tuned against PACCAR's actual approved-narrative style, not a generic "professional English" target.
Deadlines as a feature surface. PACCAR's 45-day filing window (Policy C-A-009) and 30-day appeal window aren't just context; they're the reason customers repeatedly asked for a tracker across the meeting recordings I've reviewed. Clara stores every RO's state transitions and surfaces deadline risk in the dashboard before it becomes a write-off.
Decisiv is the highest-leverage surface when it's available, but the suite architecture means we can engage any customer regardless of their stack. Blaze-only shops get the Blaze Chrome extension directly (that's customer #1, Greatwest). Fusion-only shops get one of the three Fusion doors plus the web-app paste workflow as a V1 entry point. Any other DMS gets the universal screenshot-paste fallback in the web app until we build a real adapter. No prospect on our current pipeline is unreachable.
This is the honest shape of the work. Not "how fast can we move", but what's actually on the critical path, in what order, and with what decision points in between. The AWS foundation (Terraform, ECS, RDS Postgres with pgvector, Clerk wiring) is already in place, so every day below is application-layer work building on top of it, not infrastructure stand-up.
Create RO XML schema research for customer #2.Being honest about what we're not doing in seven days is the only way the dates are defensible.
Every one of these is a real ask from a real customer conversation. Every one of them is in the V1.5 or V2 backlog. None of them are in V1.
MitigationThe Chrome extension uses a selector-based adapter layer with a telemetry surface that catches broken selectors the first time an operator hits one. If an adapter breaks, the web-app paste workflow is a working fallback within minutes, not days.
MitigationNarrative tone is a first-class product constraint, not a prompt tweak. We tune against Greatwest's own approved-claim corpus, keep CCC length conservative, and never generate boilerplate lead-ins. Every output is reviewable and editable before it submits. If PACCAR flags something, we have the telemetry to isolate and retrain.
MitigationGreatwest doesn't run Karmak Fusion (they're on Blaze), so Fusion delays don't affect V1. The sandbox work is preparatory for customer #2 and runs in parallel, not on the critical path. If the sandbox never comes through, the web-app paste workflow is the V1 entry point for any Fusion customer.
MitigationGreatwest's 5K-10K annual repair orders is a more than sufficient corpus for per-dealer tuning. We're not waiting on cross-tenant learning, and we're not shipping a generic model, we're shipping a model tuned on their own approved claims. If a customer has no historical corpus at all, we use PACCAR's public guidance and approved-narrative examples as a warm start.
MitigationEvery new ask during pilot goes into the V1.5 backlog, not V1. The 7-day plan ships what's in it. Pilot feedback shapes V1.5, which starts the day after V1 lands. This is a cultural rule, not a process one, and I hold the line on it.
MitigationThis is the single most important guardrail in the entire product, because a hallucinated narrative is a warranty audit failure and a chargeback for the customer. Clara's narrative engine is explicitly constrained to reformat and clarify what's present, it is never allowed to invent content. Every output is diff-able against the source notes, every narrative passes through human review before submission, and the product refuses to "fill in the blanks" on missing information. Sean's "don't fill in the blanks" constraint is not a preference; it's the invariant.
Is the backend, web app and dashboard skeleton solid enough to put Greatwest's tenant on it for Phase 2? If yes, we proceed. If no, we spend the start of Day 3 fixing foundation issues before touching integration work.
Does the reconciliation engine catch real mismatches on Greatwest's own case data? Does the Decisiv and Blaze adapter round-trip correctly? If yes, we proceed to launch hardening. If no, we adjust scope: narrative engine ships, reconciliation becomes V1.5.
First real production narrative through Clara into Greatwest's pipeline. Human in the loop. If the output is clean, we go live. If there's a quality gap, we slip to Day 8 and tune, but no further without a conversation with you.
Used only if Day 7 slipped. Beyond Day 8, we stop, re-plan, and I come to you with a revised timeline and an honest root cause for why we missed. This is the honesty contract.