Licensed to workshops · 2026

BAYLINE

white-label diagnostics, licensed per shop

White-label diagnostics, licensed per shop.

The product

TLDR

A diagnostic assistant that mechanic workshops license and run under their own name. Each shop gets its own instance, its own branding, and a tool the front desk can use to triage jobs before a spanner comes out. Part of the same family as Diagnostic Buddy and autocarebuddy; this is the one that invoices.

  • Licensed to workshops
  • 2026
3 jobs before an unlicensed build hits its cap
16 rebuild tasks shipped in a day, T1 through T16
120 second timeout on the diagnostic call, room to think
40 KB context clamp on every diagnostic turn

The build

Context

One tool, licensed shop by shop

Bayline is a PrizmaCore product, not a shop's own build. The README states the commercial model plainly: shops do not self-serve branding. PrizmaCore configures each build (brand, job cards, rates, hosted engine, device setup), issues a licence key, and invoices. An unlicensed build still runs, watermarked and capped at three jobs, which doubles as the sales demo.

The sale itself is a four-step sequence set out in the README: demo the eval build or the built-in demo mode, configure the shop's branding and defaults in a hidden Distributor Studio, generate a licence key with an expiry, then deploy the client's own Vercel project with that key set as an environment variable. Renewal never bricks a shop mid-job; an expired build keeps working behind a renewal banner until the key is rotated server-side.

The hidden Distributor Studio: shop name, contact line, logo, accent colour, job prefix, endpoint, region, units, currency and default labour-rate fields PrizmaCore sets before exporting a shop's build.
The hidden Distributor Studio: shop name, contact line, logo, accent colour, job prefix, endpoint, region, units, currency and default labour-rate fields PrizmaCore sets before exporting a shop's build.

What it does

Its own instance, its own job card

Each licensed shop gets its own baked build. Shop name, contact line, logo, accent colour, job prefix, region (AU, US or UK), currency, units, default labour rate, disclaimer text and free-manual base URL are all set once in Studio and exported into the shop's copy of index.html. Feature flags for photos, voice, VIN decode, manual linking and cost estimates turn on per shop too.

On the floor, a tech enters the vehicle, the DTC codes or "no codes", the complaint and the conditions once. The engine streams back a readback and ranked causes within seconds, then works one test per turn with one-push outcome buttons, so a diagnosis runs to a verdict without retyping context. Every job ends in a branded, printable job card, and customer identity (name, phone, rego, VIN) never reaches the diagnostic engine at all; only the locally generated card sees it.

Mid-diagnosis on job JC-0001: a misfire caution, wiring and service-data sourcing links, a 34% confidence gauge, the case board's next-test list, and the one-push buttons that report a test result.
Mid-diagnosis on job JC-0001: a misfire caution, wiring and service-data sourcing links, a 34% confidence gauge, the case board's next-test list, and the one-push buttons that report a test result.

The family story

Diagnostic Buddy proved the shape; bayline sends the invoice

Diagnostic Buddy came first: a guided diagnostic assistant built for automotive training, turning a vague symptom into a structured pathway with a confidence meter. It is a live prototype, honest about being a training aid rather than a production system.

Bayline carries the same diagnostic shape forward: guided one-test-per-turn reasoning, evidence before parts, a confidence-bearing engine, turned into a commercial product with a licence key, per-shop branding and a real invoice at the end of the sale. It sits in the same family as Diagnostic Buddy and autocarebuddy, three tools built on the same guided-diagnosis instinct at different stops on the road from training aid to paid product. The bayline repo does not state that it shares code with Diagnostic Buddy, so the lineage here is a family resemblance in the diagnostic thinking, not a documented fork.

Engineering

One HTML file and two serverless functions

The client is a single index.html: vanilla JavaScript, no build step, no framework, currently 2,828 lines covering CSS, markup and script together (CLAUDE.md's own architecture note calls it "~2,600 lines", so the file has grown since that was written). manifest.json, sw.js and the icon files make it installable as a PWA; none of them amount to a build system.

The backend is two Vercel serverless functions. api/diagnose.js holds the diagnostic system prompt, the Anthropic API call, streamed or plain, and the licence gate, running under a 120-second timeout so a long streamed turn on a hard case has room to finish. api/health.js reports ok, model and gated status without ever echoing a key. The only runtime dependency in package.json is the Anthropic SDK. Requests are clamped at roughly 40KB of context and up to three images per turn, and the non-streaming path validates the model's JSON shape with exactly one automatic repair retry before it fails.

Licensing is enforced twice: a client-side watermark and job cap a user can see, and a server-side check in api/diagnose.js that returns 403 to any request missing a valid licence header, which the README calls "the real enforcement."

The unlicensed eval build: an "evaluation build" watermark banner, a "0/3 evaluation jobs used" card, and the empty jobs list before any job is started.
The unlicensed eval build: an "evaluation build" watermark banner, a "0/3 evaluation jobs used" card, and the empty jobs list before any job is started.

Where it stands

Rebuilt in a day, not yet metered

The current build is a from-scratch rebuild. The git history runs T1 through T16, all sixteen tasks landing in a single day on 15 July 2026, with an internal access kit and two follow-up fixes landing the next day. CLAUDE.md confirms all sixteen done: streaming, photo input, voice dictation, VIN decode, free-manual linking, shop memory, bay-tool ergonomics, per-build customisation, CORS allowlisting and an offline DTC dictionary among them.

Per-key usage metering is explicitly on the roadmap and explicitly not built; it needs a KV store the project does not yet have, so a live trial key is unlimited calls against PrizmaCore's own API key for its lifetime, which is why the setup guide recommends short trial expiries. An OBD scan-tool integration is specced in a separate document and marked "approved, not in this build."