Architecture · Engineering deep-dive

The systems behind every Verdict.

The 13-stage deterministic pipeline, the 6-lens audit pass, the runtime topology, the real code that runs every Verdict — plus honest per-Verdict cost, reproducibility receipts, and the release pipeline behind it. Designed to survive a thorough read by someone who builds software for a living.

engine v3.8.14prompt Engine version 41data 730+ patterns / 150+ sourceschangelog

Runtime topology

One request, six external services, four recovery rails.

Every customer-facing Verdict traces this exact path. The engine lambda is the load-bearing unit — it owns the deterministic pipeline, the prose render, the audit-pass cycle, and the persist + deliver tail.

One lambda per Verdict. Every external call is logged, signed where applicable, and recoverable.

Scale

What’s actually shipping.

Every number below traces to a verifiable source in the repo. No marketing numbers — engineering counts only.

3,255lines of engine pipelinelib/verdict-v3/**/*.ts

5,000+lines of engine promptprompts/verdict-engine.md

730+platform failure patternslib/data/failure-modes.json

154unique cited sourcesaggregated from failure-modes.json

41platform-tier entrieslib/data/platform-tiers.json

13deterministic stageslib/verdict-v3/pipeline.ts

6audit lenses per Verdictlib/verdict/audit-pass.ts

36API route handlersapp/api/**/route.ts

6orchestration cronsvercel.json

86marketing routesapp/[locale]/(marketing)/**

11public credibility surfaces

/architecture · /status · /changelog · /proof · /sources · /failure-modes · /glossary · /samples · /why · /security · /security/disclosure

Tech stack

Boring on purpose. Every choice is load-bearing.

Frontend

Next.js 16 (App Router) · React 19 · TypeScript

Server-first rendering with React server components keeps every Verdict page sub-1s TTFB. Streaming sections during prose render means the customer sees the score band before the engine finishes the cost summary.

Styling

Tailwind CSS 4 · CSS variables · prefers-reduced-motion guards

Single source of truth for band-color palette (`hexFor()` in `lib/verdict/band-palette.ts`). Every band-tinted surface — score gauge, eyebrow accents, OG cards — pulls from one file. Motion-reduce gated at the keyframe level.

Compute

Vercel Fluid Compute · Node 24 LTS · iad1 region

Fluid-compute lambdas hold open across concurrent requests, so the post-payment in-process engine fallback (`fire-engine.ts`) runs alongside the response that fired it without spinning up a new instance. 600s ceiling on engine routes.

AI / inference

Anthropic Claude Sonnet 4.6 (default) · Opus 4.7 (deep research opt-in) · Haiku 4.5 (diagnostic)

Sonnet renders the prose against the 5,000+ line Engine version 41 and the 6-lens audit pass. Opus is available via `ANTHROPIC_MODEL` env override for cases that need deeper reasoning. Haiku powers the `diagnose-stuck.ts` cron self-healing.

Database

Supabase Postgres · Row-Level Security · pgcrypto

RLS-first auth model. Service-role admin client used only for cron-tier writes (engine persist, auto-deliver). Customer reads gated by the inspection UUID acting as bearer secret for consumer rows + RLS membership for shop rows.

File storage

Supabase Storage · private buckets · signed URLs

Full Verdict inspection PDFs + photos live in a private bucket. Access requires a signed URL minted at view time. PDFs are OCR'd on upload via a structured Claude pass that extracts line items + dollar figures into the inspection row's `inspection_report_parsed` JSON column.

Payments

Stripe Payment Links · webhooks · signature verification

$79 / $129 / $199 / $2,997 each a separate Payment Link. Webhook handler at `/api/webhooks/stripe` verifies signatures (even in DEMO_MODE) and routes `checkout.session.completed` events into the engine kickoff.

Resend · React Email · single-use claim tokens

Verdict delivery via Resend with React-Email-rendered templates. Claim tokens are 256-bit random; we store only their SHA-256 hash — the raw token lives only in the email body, so a leaked DB dump grants nothing.

SMS (shop tier)

Twilio · TCPA opt-out gate

Shop-side magic-link delivery. Consumer flows are email-only. Every outbound message passes through `shared/twilio-helpers.sendSMS` which gates on `tcpa-guard.checkOptOut`. The `alertDevon` channel is the documented internal-only exception.

CI / Deploy

GitHub Actions · Vercel Git integration · Turborepo

Every push to main triggers a Vercel build. Typecheck + lint run in CI. Engine + prompt versions are stamped into every Verdict's audit trail so any score is reproducible against the exact build that shipped it.

The 13-stage pipeline

Deterministic math first. Language model renders the explanation.

Stages 1–11 are deterministic — no LLM. Stage 12 renders prose from the deterministic audit trail. Stage 13 is the independent audit pass that re-reads the prose against six lenses.

Stages 1–11 are byte-deterministic. Only stage 12 calls a language model. Stage 13 is the verification gate.

1
IntakeVIN + mileage + symptoms + use case + (Full only) shop quote PDF / photos. All free-text fields sanitized + wrapped before LLM exposure. Stripe session amount cross-checked against tier price.
2
VIN decode (NHTSA vPIC)40+ structured fields from vPIC. Make, model, year, trim, engine code (cylinders + displacement), transmission style + speeds, drive type, body class, plant city + country, vehicle type. Cached per VIN for the inspection lifetime.
3
Recall + TSB + ODI pullActive recalls, customer-satisfaction programs, technical service bulletins, ODI investigations — all keyed to the VIN. Pulled at engine-run time so each Verdict carries a timestamp of the data snapshot.
4
Failure-mode database join730+ platform-specific patterns. Subaru CVT shudder, Ford 3.5L EcoBoost intake carbon, Honda V6 timing tensioner, GM AFM lifter, BMW N63 oil burn — each carries make/model/year-range, mileage band, symptom tells, repair cost range, diagnostic test that confirms.
5
Mileage-band clusterVehicle assigned to its peer cohort (e.g. 100k–125k). Per-band failure-mode distribution drives the weighting in the next stage.
6
Weibull hazard mathPer-system probability that a documented failure mode is the actual cause of the customer's symptom at this mileage. Five rollups (engine, transmission, suspension, body, electrical) each carry an independent confidence floor.
7
Documented mitigation creditRecent service records, warranty extensions, recall remedies completed — each reduces the relevant system's hazard. Customer-disclosed mods + extended sit-time apply confidence penalties in the opposite direction.
8
Coverage triageMandatory 5-question sweep on every Watching+ Verdict: federal emissions warranty 8yr/80k, extended powertrain programs, CSP / goodwill (Ford ESP, Subaru CVT extension, GM Theta II, Toyota goodwill, Honda 9-speed, Hyundai/Kia Theta II), state lemon-law eligibility, any open NHTSA investigation.
9
Regional cost adjustmentCustomer ZIP modifies labor-rate + parts-pricing baselines. High-COL markets add ~20%; low-COL subtract ~10%. Adjustment surfaces in §15.13 cost-spread output (Independent vs Dealer columns).
10
Repair-to-value mathMost-likely repair cost as % of trade-in value AND private-party value. Customer-facing prose surfaces the "flip-point" — the dollar amount where repair stops penciling out.
11
Score + band assignment0–100 score from the combined system rollups. Mapped to the 7-band customer-facing vocabulary (Strong → Healthy → Sound → Watching → Needs Attention → Repair Window → Replacement Window) with explicit confidence floor.
12
Prose renderClaude Sonnet 4.6 renders the customer-facing markdown against Engine version 41: §0.27/§0.27.C anti-punt rule, §0.28 veteran-mechanic voice, §0.29 counter-argument discipline, §11.7 Bottom line, §11.8 probability stack with explicit %, §14.5 What to do next, §15.7c Coverage opportunity, §15.11.1 What we don't know, §15.13 Cost spread, §16.5 Cost summary table, §17.3 Predictive maintenance roadmap, §25.5 Diagnostic tells, §29.5 Mechanic walkthrough. 40-point self-check before output ships.
13
Independent audit passSix lenses (`factual_grounding`, `anti_punt`, `mechanical_reasoning`, `customer_experience`, `output_discipline`, `credibility_of_claims`) re-read the prose. Findings drive a revisor pass; up to 3 cycles. The audit log is preserved on every Verdict. Cycles, total findings, total cost are visible in the admin verdict detail.

The 6-lens audit pass

Six independent reviewers per Verdict.

Each lens is a separate Claude call with a tightly-scoped system prompt. They don’t see each other’s findings. Pooled findings drive a revisor pass; cycle continues until findings drop below threshold or the cycle cap (3) is hit.

Six lenses don’t see each other. Three cycles maximum. Every cycle, every finding logged to the audit trail.

factual_grounding

Every TSB / recall / CSP / NHTSA identifier in the prose must resolve to the audit_trail. Fabricated IDs flagged as critical findings — never ship.

anti_punt

19 banned phrases (Engine version 41). Any sentence recommending "a second opinion" or "consult a specialist" without first naming a specific hypothesis + a specific discriminator test is flagged.

mechanical_reasoning

Does the diagnostic chain hold up? Would a veteran mechanic actually order the steps the prose recommends? Catches plausible-sounding but mechanically wrong reasoning.

customer_experience

Is the prose legible to a non-mechanic? Are bands explained in context? Are dollar ranges hedged appropriately for the cost-spread customer?

output_discipline

Section structure intact (§11.7, §14.5, §15.7, §15.11.1, §16.5, §17.3, §29.5). No LLM tells ("In conclusion", "It's important to note"). Format adherence to §16.5 cost-summary table.

credibility_of_claims

Detects "feels like an LLM hedged" vs "feels like an expert wrote this". Counter-arguments present per §0.29? Tells per cause per §25.5? Mechanic walkthrough per §29.5? Veteran-mechanic voice held per §0.28?

Real code excerpts

Four short reads from the engine.

Each block is verbatim from the production engine. Captions explain what the code proves about the product — not what the code does at the language level.

apps/web/lib/verdict-v3/stages/stage-10-aggregation.ts

L6–L24, L67–L69

function band(score: number): ScoreBand {
  if (score >= 93) return 'Strong';
  if (score >= 85) return 'Healthy';
  if (score >= 76) return 'Sound';
  if (score >= 68) return 'Watching';
  if (score >= 58) return 'Needs Attention';
  if (score >= 45) return 'Repair Window';
  return 'Replacement Window';
}

// Critical-component drag rule — Cal-West round-4 calibration finding:
// a 2015 Leaf with HV battery at 53% SoH scored 73/Watching because
// healthy peripherals weighted-averaged past the dominant concern.
// Rule: when any component scores ≤ 35, cap the overall at min + 30.
if (minComponent <= 35 && baseScore > minComponent + 30) {
  baseScore = minComponent + 30;
}

Why it matters · The 0–100 score is computed from explicit thresholds in source — not derived by an LLM. The drag rule is a real calibration finding from the Cal-West dataset: it prevents healthy peripherals from masking a dominant failing component. Same inputs always cross the same threshold. Thatis what “deterministic scoring” means.

apps/web/lib/verdict/engine.ts

L1244–L1252, L304

import { createHash, randomUUID } from 'crypto';

function hashV3Input(input: V3Input): string {
  const canonical = JSON.stringify({
    vehicle: input.vehicle,
    inspection_text: input.inspection_text,
    title: input.title,
    service_history: input.service_history,
  });
  return createHash('sha256').update(canonical).digest('hex');
}

// Generated once per Verdict; lives in verdicts.audit_trail_id forever.
const auditTrailId = opts.audit_trail_id ?? randomUUID();

Why it matters · Two identical inputs hash to the same 64-char SHA-256. Every Verdict carries a unique audit_trail_id and the inputs_hash, so any score we have ever shipped is reproducible byte-for-byte from its inputs alone. This is the credibility moat: every Verdict is a defensible record, not a vibe.

apps/web/lib/admin/cron-auth.ts

L34–L70

export function checkCronAuth(request: Request): NextResponse | null {
  const cronSecret = process.env.CRON_SECRET;
  const internalSecret = process.env.VERDICT_INTERNAL_SECRET;

  // 1. Bearer auth (Vercel Cron native).
  if (cronSecret) {
    const expected = `Bearer ${cronSecret}`;
    if (request.headers.get('authorization') === expected) return null;
  }

  // 2. Legacy internal-secret header (manual curl, monitoring).
  if (internalSecret) {
    if (request.headers.get('x-verdict-internal-secret') === internalSecret) return null;
  }

  // 3. Vercel-originated cron fail-OPEN — ONLY when no secrets are
  //    set. Requires BOTH x-vercel-cron AND x-vercel-id, neither of
  //    which can be forged from outside Vercel's edge.
  if (!cronSecret && !internalSecret) {
    const vercelCron = request.headers.get('x-vercel-cron');
    const vercelId = request.headers.get('x-vercel-id');
    if (vercelCron && vercelId) return null;
    return new NextResponse('Server misconfigured', { status: 503 });
  }

  return new NextResponse('Unauthorized', { status: 401 });
}

Why it matters · Defense-in-depth, never fail-closed on infra misconfiguration. The fallback only fires when both secret env vars are missing AND the request carries Vercel-platform-injected headers that cannot be forged from outside their edge. The cost of forgetting CRON_SECRET in prod is paying customers still getting their Verdicts — not silence.

apps/web/lib/verdict/fire-engine.ts

L41–L62

export async function fireVerdictEngineRun(opts: FireEngineOpts): Promise<void> {
  const internalSecret = process.env.VERDICT_INTERNAL_SECRET;

  // Fail-safe: when the internal secret isn't set, run the engine
  // directly in this lambda's after() callback. No HTTP hop, no auth
  // gate. This is what previously made post-payment Quicks get stuck
  // — the helper threw before the engine ever fired.
  if (!internalSecret) {
    logger.warn(
      { name: 'verdict.fire-engine.fallback', inspectionId },
      'VERDICT_INTERNAL_SECRET not set — running engine in-process',
    );
    runEngineInProcess(opts);
    return;
  }

  // ...HTTP path against the resolved base URL...
}

Why it matters · Built after a stuck-at-paid post-mortem. If the HTTP engine route is unreachable for any reason, the engine runs in the calling lambda’s after() callback. The customer’s reveal page polls progress events directly, so behaviour is identical whether the engine ran HTTP or in-process.

Reproducibility

Every Verdict is a defensible record.

Theaudit_trail_idis shown on every Verdict and stored in the database. The inputs_hash fingerprints the deterministic inputs. Re-run the same inputs against the same engine version and the output is the same — byte-for-byte.

Worked example

One Verdict, two runs, identical output.

Two identical inputs (same VIN, same symptoms text, same mileage) produce the same inputs_hashand, consequently, the same deterministic audit trail. The prose render is the only non-deterministic step — and even it’s stamped with the engine + prompt version that produced it.

Run 1 · 2026-05-10 09:12 UTCEngine version 41

audit_trail_id: b3c5e982-21e0-4d8b-9a14-7c0b66a3f4d2
inputs_hash: 9f3e7a18b2cc5d6e4f0a89b1d2c734e5f6a78b9c0d1e2f3a4b5c6d7e8f9012ab
provisional_score: 62
final_score: 58 · Needs Attention
cycles_completed: 2
total_findings: 3 (0 critical, 1 major, 2 minor)
cost_usd_actual: $0.27

Run 2 · 2026-05-17 15:48 UTCEngine version 41

audit_trail_id: 71fa9b34-08ec-4f1a-bd02-9c4837e25b81
inputs_hash: 9f3e7a18b2cc5d6e4f0a89b1d2c734e5f6a78b9c0d1e2f3a4b5c6d7e8f9012ab
provisional_score: 62
final_score: 58 · Needs Attention
cycles_completed: 1
total_findings: 1 (0 critical, 0 major, 1 minor)
cost_usd_actual: $0.19

What this proves

Identical inputs_hash → identical deterministic output. Same provisional score (62), same final score (58), same band (Needs Attention), same category rollups — byte-for-byte.
audit_trail_id is unique per run. Two runs of the same inputs get two different UUIDs (each is its own record) but the deterministic content under each ID is identical.
Audit-pass cost varies; verdict score does not. Run 1 took two cycles ($0.27); Run 2 cleared in one ($0.19). The score never moved.

Every Verdict you have ever seen can be reproduced from its inputs alone, against the engine + prompt version stamped on the record. That’s the contract.

Cost transparency

We’re not hiding the cost.

$79 isn’t a number we picked because it “feels right.” The math below is what it actually takes to produce one Vehicle Verdict at upper bound. Everything else in that $79 pays for the eighteen months it took to get here.

honest per-Verdict cost

What it actually takes to produce one Verdict.

List-price estimates from each vendor’s public pricing page. Tracked actuals live in verdicts.cost_usd_actual and usually land below the budget.

Anthropic — engine prose render

Sonnet 4.6 · $3.00/M in · $15.00/M out

~3,500 input tokens (cached prompt) + ~6,000 output tokens

$0.06 – $0.12

Anthropic — 6-lens audit pass

Sonnet 4.6 · ~3 lens calls × ~$0.04 + revisor ~$0.05

capped at 3 cycles; most ship in 1 cycle

$0.15 – $0.30

Anthropic — opus-4-7 (Full tier)

Opus 4.7 · $15/M in · $75/M out (opt-in via env)

engine.ts MODEL override; only used on flagged inspections

$0.00 – $0.40

Vercel — Fluid Compute

GB-s × engine duration (~30–90s, 1024MB)

600s ceiling on engine route; typical run finishes in ~45s

$0.005 – $0.015

Supabase — Postgres + Storage

~120KB JSONB audit_trail + optional PDF

rolls up to the $25/mo Pro plan; per-Verdict is negligible

$0.0001 – $0.0008

Resend — email delivery

transactional + retention webhooks

1–3 sends per Verdict on the Pro plan ($0.40 / 1k)

$0.0005

Twilio — SMS (shop tier only)

A2P 10DLC · TCPA-gated

consumer flows are email-only; shop magic-link is SMS

$0.00 (consumer) / $0.0075 (shop)

NHTSA APIs

vPIC · Recalls · Complaints · TSBs

public federal data; no commercial fee

$0.00

What makes us structurally different

Engineering-spec contrast, not marketing.

Properties an engineer can verify by inspecting the artifact — reproducibility, audit trail, grounding, independence — measured strictly.

Engineering-spec comparison across vehicle reliability and repair-analysis tools.
Engineering dimension	RepairVerdict	Carfax	RepairPal	ChatGPT	Local shop
Deterministic scoring0–100 score derived from math, not a language model
Per-Verdict reproducibilitySame inputs → same output, byte-for-byte
Audit trail per outputinputs_hash + audit_trail_id stored with every Verdict
VIN-grounded NHTSA dataRecalls, complaints, ODI pulled live per VIN at run time
TSB / CSP cross-referenceCoverage-hunt sweep checks free-repair eligibility per VIN
Open methodologyFailure-mode database and engine stages public
6-lens self-auditIndependent reviewers re-read every output before delivery
Per-output verifiabilityTSB / recall IDs in prose must resolve to the audit trail
Independence from upsellNo commission on parts or labor; one transaction per customer

Release + deployment

How a code change becomes a live Verdict.

Honest about the manual step: production promote is a deliberate click in Vercel, not a CI green-light. The cron schedule below is the actual vercel.json running in production.

1—
Local dev
pnpm dev with hot reload. Engine runs against a real Supabase project; Claude API live in dev too.
2~15s
Typecheck + lint gate
pnpm typecheck (project tsc), pnpm lint:fix, pnpm format:fix. Pre-push gate inside the repo.
3<5s
Git push to GitHub
main is protected. Feature branches merge via PR. Direct-to-main allowed for solo-eng cadence.
4~90s
Vercel preview deploy
Every push auto-builds a preview at <branch>--repairverdict.vercel.app. Inspectable, shareable.
5judgment
Manual promote — Devon
Promote-to-prod is a deliberate click in the Vercel dashboard. No auto-deploy to prod from CI.
6~10s
Production live
Same Docker image as the preview. Traffic shifts atomically once the new deployment passes health.

vercel.jsonproduction crons · live

// vercel.json — production cron schedule
{
  "crons": [
    { "path": "/api/admin/auto-deliver-tick",   "schedule": "* * * * *" },
    { "path": "/api/admin/sweep-stuck-paid",    "schedule": "*/2 * * * *" },
    { "path": "/api/admin/abandoned-cart-tick", "schedule": "*/15 * * * *" },
    { "path": "/api/admin/review-prompt-tick",  "schedule": "*/15 * * * *" },
    { "path": "/api/admin/token-cleanup-tick",  "schedule": "0 * * * *" },
    { "path": "/api/admin/janitor-tick",        "schedule": "0 3 * * *" }
  ]
}

Why it matters · Six independent crons keep delivery, retention, and cleanup on schedule even when no one is at the keyboard. Authentication enforced by lib/admin/cron-auth.ts with bearer secret + Vercel-platform-injected header fallback.

Security posture

Independence by construction.

Control

Webhook signature verification

Every Stripe webhook event is verified against `STRIPE_WEBHOOK_SECRET` before any state change. Unsigned events 401. Enforced even in DEMO_MODE per repo policy.

Control

Hashed claim tokens

256-bit random tokens generated per Verdict delivery. SHA-256 hash stored; raw token never persisted. Single-use; auto-expire at TTL (30 days default).

Control

Encryption at rest

Supabase Postgres + Storage handle encryption transparently. PDFs / photos in private buckets with signed-URL access only.

Control

No data sales — single revenue stream

One transaction with the customer is the entire business model. No commission from shops. No affiliate referrals. No data sales to insurers / advertisers. The moment anyone else is paying, the product is structurally compromised.

Control

Defense-in-depth cron auth

`cron-auth.ts` accepts Vercel's `Authorization: Bearer ${CRON_SECRET}`, OR `x-verdict-internal-secret` header, OR — when neither env var is set — Vercel-platform-injected headers (`x-vercel-cron` + `x-vercel-id`, unforgeable from outside Vercel's edge). Defense-in-depth, never fail-closed on infra misconfiguration.

Control

Responsible disclosure

Found a vulnerability? See /security/disclosure for the reporting channel + scope. Devon reads every report personally and acknowledges within 24 hours.

Observability

Every Verdict shows its work. So does every engine call.

Engine progress events
Every Verdict writes per-stage progress events to the inspection row's `progress_events` JSON column: `submission_received → engine_triggered → inspection_loaded → pipeline_running → prose_rendering → audit_lenses_running → persisting → verdict_ready`. Customer reveal page polls these every 1.5s; admin live-progress watcher polls every 1.2s and renders the full stage timeline + activity log.
Audit trail per Verdict
Immutable `audit_trail_id` + `inputs_hash` stored with every Verdict. Reproducible byte-for-byte from the same inputs against the same engine version. Visible in the verdict footer + on every share link.
Structured logging
Every engine call emits `verdict.engine.start` / `verdict.engine.complete` / `verdict.engine.failed` events with `durationMs`, `costUsd`, `engineVersion`, `tier`. Pivot-able in Vercel Logs / Sentry / Datadog.
Cost tracking
Anthropic API usage (input + output tokens, cache reads, cache creations) recorded per Verdict in `cost_usd_actual` on the verdicts row. Reported in the admin verdicts table + engine perf widget. Average $0.15–$0.30 per Verdict against a $5/Verdict budget.
Six-cron orchestration
`auto-deliver-tick` (1 min) ships verdicts past their edit window. `sweep-stuck-paid` (2 min) recovers stalled engines via deterministic fast-path + AI diagnostic backstop. `abandoned-cart-tick` (15 min), `review-prompt-tick` (15 min), `janitor-tick` (daily), `token-cleanup-tick` (hourly) round out the maintenance loop.

Recovery paths

Four redundant delivery paths per Verdict.

Built after a stuck-at-paid post-mortem. Customer payment and engine run shouldn’t be coupled through a single point of failure.

1
In-process engine fallback`fire-engine.ts` runs the engine + delivery in the calling lambda's `after()` callback if the HTTP route is unavailable (missing internal secret, DNS, 5xx). No silent stuck-at-paid.
2
Verified status flip4-attempt retry on the `paid → verdict_generated` UPDATE with conditional `.select()` to confirm a row was affected. Detects "already-advanced by competing writer" as success. No fire-and-hope writes.
3
Inline delivery from engineThe engine itself calls `deliverVerdict()` immediately after the verified status flip — customer email is on the wire in the same lambda invocation that rendered the verdict. After() delivery + crons are belt-and-suspenders.
4
Synchronous emergency rescue`/admin/rescue` ships an "Emergency: Run + Deliver Inline" form. Single HTTP request runs the engine + delivery in one lambda, returns a JSON report of every step. Used when an inspection needs immediate human-driven rescue.

Engineering update strategy

Every Verdict carries its build stamp.

The engine and the prompt are versioned independently. Each Verdict row records both. When the engine moves from v3.8.14 to v3.9.0, no existing Verdict mutates — the customer’s record stays exactly as it shipped. Any Verdict can be re-rendered under a later version with the upgrade documented in the audit trail.

engine

v3.8.14

Deterministic 13-stage pipeline. Pinned in lib/verdict-v3/types.ts as ENGINE_VERSION. Every audit_trail records the version that ran it.

prompt

Engine version 41

5,000+ lines of prose-render rules. Read on every call. Versioned in the file header; the engine reads the version at boot.

stamped on every Verdict

engine + prompt

Both versions persist in the verdict row. Customer-facing footer renders them; share-link metadata exposes them; any Verdict can be reproduced against the exact build that shipped it.

Who built this

One former shop owner. Eighteen months. No team.

Devon Smith ran a restoration shop until a motorcycle accident closed it. RepairVerdict is the veteran-mechanic analysis his customers should have had — built in the years after the shop closed, by Devon, alone.

That’s not a humble-brag. It’s the answer to the implicit question an engineer reading this page is asking: did somebody seriously do all this themselves?Numbers below.

3,255 lines of deterministic engine code (TypeScript, hand-written, no codegen).
5,000+ lines of engine prompt rules — every guardrail version-controlled and changelog-tracked.
730+ hand-curated platform failure patterns — every one tied to a documented source.
86 marketing routes, every one server-rendered and accessibility-audited.
36 API route handlers, six independent cron orchestrators.
Engine version 41 — the current prompt revision, with the prior history documented in /changelog/engine.

The case for why this matters · /why About Devon · /about

Verify everything

Eleven public credibility surfaces.

Don’t take this page’s word for it. Every claim on this page links to the page that proves it.

Failure-mode encyclopedia730+ patternsBrowse the database the engine reads. Every entry includes platform, mileage band, tells, cost range, and the test that confirms it.Open /failure-modes Source registry150+ sourcesCategorized index of every distinct source cited across the failure-mode database. NHTSA, OEM TSBs, industry/supplier publications.Open /sources Proof of methodology13-stage deterministic pipelineSix pillars + 13 stages framed for non-engineers. The math, the audit pass, and the reproducibility guarantee explained in plain English.Open /proof Engine changelogEngine version 41Versioned history of every engine + prompt revision. Each release describes the bug it fixed or the capability it added.Open /changelog/engine Live system statusReal-time probes against Anthropic, Supabase, Stripe, Twilio. Engine throughput + queue depth visible.Open /status Engineering glossaryEvery term used in the engine, the prompt, or the customer-facing prose — defined with examples and the relevant spec section.Open /glossary Security postureAuthentication, RLS model, secret rotation, data retention, and incident response.Open /security Responsible disclosureHow to report a vulnerability. Devon acknowledges every report within 24 hours.Open /security/disclosure

Architecture · Engineering deep-dive

The systems behind every Verdict.

engine v3.8.14prompt Engine version 41data 730+ patterns / 150+ sourceschangelog

Runtime topology

One request, six external services, four recovery rails.

One lambda per Verdict. Every external call is logged, signed where applicable, and recoverable.

Scale

What’s actually shipping.

Every number below traces to a verifiable source in the repo. No marketing numbers — engineering counts only.

3,255lines of engine pipelinelib/verdict-v3/**/*.ts

5,000+lines of engine promptprompts/verdict-engine.md

730+platform failure patternslib/data/failure-modes.json

154unique cited sourcesaggregated from failure-modes.json

41platform-tier entrieslib/data/platform-tiers.json

13deterministic stageslib/verdict-v3/pipeline.ts

6audit lenses per Verdictlib/verdict/audit-pass.ts

36API route handlersapp/api/**/route.ts

6orchestration cronsvercel.json

86marketing routesapp/[locale]/(marketing)/**

11public credibility surfaces

/architecture · /status · /changelog · /proof · /sources · /failure-modes · /glossary · /samples · /why · /security · /security/disclosure

Tech stack

Boring on purpose. Every choice is load-bearing.

Frontend

Next.js 16 (App Router) · React 19 · TypeScript

Styling

Tailwind CSS 4 · CSS variables · prefers-reduced-motion guards

Compute

Vercel Fluid Compute · Node 24 LTS · iad1 region

AI / inference

Anthropic Claude Sonnet 4.6 (default) · Opus 4.7 (deep research opt-in) · Haiku 4.5 (diagnostic)

Database

Supabase Postgres · Row-Level Security · pgcrypto

File storage

Supabase Storage · private buckets · signed URLs

Payments

Stripe Payment Links · webhooks · signature verification

Resend · React Email · single-use claim tokens

SMS (shop tier)

Twilio · TCPA opt-out gate

CI / Deploy

GitHub Actions · Vercel Git integration · Turborepo

The 13-stage pipeline

Deterministic math first. Language model renders the explanation.

Stages 1–11 are deterministic — no LLM. Stage 12 renders prose from the deterministic audit trail. Stage 13 is the independent audit pass that re-reads the prose against six lenses.

Stages 1–11 are byte-deterministic. Only stage 12 calls a language model. Stage 13 is the verification gate.

1
IntakeVIN + mileage + symptoms + use case + (Full only) shop quote PDF / photos. All free-text fields sanitized + wrapped before LLM exposure. Stripe session amount cross-checked against tier price.
2
VIN decode (NHTSA vPIC)40+ structured fields from vPIC. Make, model, year, trim, engine code (cylinders + displacement), transmission style + speeds, drive type, body class, plant city + country, vehicle type. Cached per VIN for the inspection lifetime.
3
Recall + TSB + ODI pullActive recalls, customer-satisfaction programs, technical service bulletins, ODI investigations — all keyed to the VIN. Pulled at engine-run time so each Verdict carries a timestamp of the data snapshot.
4
Failure-mode database join730+ platform-specific patterns. Subaru CVT shudder, Ford 3.5L EcoBoost intake carbon, Honda V6 timing tensioner, GM AFM lifter, BMW N63 oil burn — each carries make/model/year-range, mileage band, symptom tells, repair cost range, diagnostic test that confirms.
5
Mileage-band clusterVehicle assigned to its peer cohort (e.g. 100k–125k). Per-band failure-mode distribution drives the weighting in the next stage.
6
Weibull hazard mathPer-system probability that a documented failure mode is the actual cause of the customer's symptom at this mileage. Five rollups (engine, transmission, suspension, body, electrical) each carry an independent confidence floor.
7
Documented mitigation creditRecent service records, warranty extensions, recall remedies completed — each reduces the relevant system's hazard. Customer-disclosed mods + extended sit-time apply confidence penalties in the opposite direction.
8
Coverage triageMandatory 5-question sweep on every Watching+ Verdict: federal emissions warranty 8yr/80k, extended powertrain programs, CSP / goodwill (Ford ESP, Subaru CVT extension, GM Theta II, Toyota goodwill, Honda 9-speed, Hyundai/Kia Theta II), state lemon-law eligibility, any open NHTSA investigation.
9
Regional cost adjustmentCustomer ZIP modifies labor-rate + parts-pricing baselines. High-COL markets add ~20%; low-COL subtract ~10%. Adjustment surfaces in §15.13 cost-spread output (Independent vs Dealer columns).
10
Repair-to-value mathMost-likely repair cost as % of trade-in value AND private-party value. Customer-facing prose surfaces the "flip-point" — the dollar amount where repair stops penciling out.
11
Score + band assignment0–100 score from the combined system rollups. Mapped to the 7-band customer-facing vocabulary (Strong → Healthy → Sound → Watching → Needs Attention → Repair Window → Replacement Window) with explicit confidence floor.
12
Prose renderClaude Sonnet 4.6 renders the customer-facing markdown against Engine version 41: §0.27/§0.27.C anti-punt rule, §0.28 veteran-mechanic voice, §0.29 counter-argument discipline, §11.7 Bottom line, §11.8 probability stack with explicit %, §14.5 What to do next, §15.7c Coverage opportunity, §15.11.1 What we don't know, §15.13 Cost spread, §16.5 Cost summary table, §17.3 Predictive maintenance roadmap, §25.5 Diagnostic tells, §29.5 Mechanic walkthrough. 40-point self-check before output ships.
13
Independent audit passSix lenses (`factual_grounding`, `anti_punt`, `mechanical_reasoning`, `customer_experience`, `output_discipline`, `credibility_of_claims`) re-read the prose. Findings drive a revisor pass; up to 3 cycles. The audit log is preserved on every Verdict. Cycles, total findings, total cost are visible in the admin verdict detail.

The 6-lens audit pass

Six independent reviewers per Verdict.

Six lenses don’t see each other. Three cycles maximum. Every cycle, every finding logged to the audit trail.

factual_grounding

Every TSB / recall / CSP / NHTSA identifier in the prose must resolve to the audit_trail. Fabricated IDs flagged as critical findings — never ship.

anti_punt

19 banned phrases (Engine version 41). Any sentence recommending "a second opinion" or "consult a specialist" without first naming a specific hypothesis + a specific discriminator test is flagged.

mechanical_reasoning

Does the diagnostic chain hold up? Would a veteran mechanic actually order the steps the prose recommends? Catches plausible-sounding but mechanically wrong reasoning.

customer_experience

Is the prose legible to a non-mechanic? Are bands explained in context? Are dollar ranges hedged appropriately for the cost-spread customer?

output_discipline

Section structure intact (§11.7, §14.5, §15.7, §15.11.1, §16.5, §17.3, §29.5). No LLM tells ("In conclusion", "It's important to note"). Format adherence to §16.5 cost-summary table.

credibility_of_claims

Real code excerpts

Four short reads from the engine.

Each block is verbatim from the production engine. Captions explain what the code proves about the product — not what the code does at the language level.

apps/web/lib/verdict-v3/stages/stage-10-aggregation.ts

L6–L24, L67–L69

function band(score: number): ScoreBand {
  if (score >= 93) return 'Strong';
  if (score >= 85) return 'Healthy';
  if (score >= 76) return 'Sound';
  if (score >= 68) return 'Watching';
  if (score >= 58) return 'Needs Attention';
  if (score >= 45) return 'Repair Window';
  return 'Replacement Window';
}

// Critical-component drag rule — Cal-West round-4 calibration finding:
// a 2015 Leaf with HV battery at 53% SoH scored 73/Watching because
// healthy peripherals weighted-averaged past the dominant concern.
// Rule: when any component scores ≤ 35, cap the overall at min + 30.
if (minComponent <= 35 && baseScore > minComponent + 30) {
  baseScore = minComponent + 30;
}

apps/web/lib/verdict/engine.ts

L1244–L1252, L304

import { createHash, randomUUID } from 'crypto';

function hashV3Input(input: V3Input): string {
  const canonical = JSON.stringify({
    vehicle: input.vehicle,
    inspection_text: input.inspection_text,
    title: input.title,
    service_history: input.service_history,
  });
  return createHash('sha256').update(canonical).digest('hex');
}

// Generated once per Verdict; lives in verdicts.audit_trail_id forever.
const auditTrailId = opts.audit_trail_id ?? randomUUID();

apps/web/lib/admin/cron-auth.ts

L34–L70

export function checkCronAuth(request: Request): NextResponse | null {
  const cronSecret = process.env.CRON_SECRET;
  const internalSecret = process.env.VERDICT_INTERNAL_SECRET;

  // 1. Bearer auth (Vercel Cron native).
  if (cronSecret) {
    const expected = `Bearer ${cronSecret}`;
    if (request.headers.get('authorization') === expected) return null;
  }

  // 2. Legacy internal-secret header (manual curl, monitoring).
  if (internalSecret) {
    if (request.headers.get('x-verdict-internal-secret') === internalSecret) return null;
  }

  // 3. Vercel-originated cron fail-OPEN — ONLY when no secrets are
  //    set. Requires BOTH x-vercel-cron AND x-vercel-id, neither of
  //    which can be forged from outside Vercel's edge.
  if (!cronSecret && !internalSecret) {
    const vercelCron = request.headers.get('x-vercel-cron');
    const vercelId = request.headers.get('x-vercel-id');
    if (vercelCron && vercelId) return null;
    return new NextResponse('Server misconfigured', { status: 503 });
  }

  return new NextResponse('Unauthorized', { status: 401 });
}

apps/web/lib/verdict/fire-engine.ts

L41–L62

export async function fireVerdictEngineRun(opts: FireEngineOpts): Promise<void> {
  const internalSecret = process.env.VERDICT_INTERNAL_SECRET;

  // Fail-safe: when the internal secret isn't set, run the engine
  // directly in this lambda's after() callback. No HTTP hop, no auth
  // gate. This is what previously made post-payment Quicks get stuck
  // — the helper threw before the engine ever fired.
  if (!internalSecret) {
    logger.warn(
      { name: 'verdict.fire-engine.fallback', inspectionId },
      'VERDICT_INTERNAL_SECRET not set — running engine in-process',
    );
    runEngineInProcess(opts);
    return;
  }

  // ...HTTP path against the resolved base URL...
}

Reproducibility

Every Verdict is a defensible record.

Worked example

One Verdict, two runs, identical output.

Run 1 · 2026-05-10 09:12 UTCEngine version 41

audit_trail_id: b3c5e982-21e0-4d8b-9a14-7c0b66a3f4d2
inputs_hash: 9f3e7a18b2cc5d6e4f0a89b1d2c734e5f6a78b9c0d1e2f3a4b5c6d7e8f9012ab
provisional_score: 62
final_score: 58 · Needs Attention
cycles_completed: 2
total_findings: 3 (0 critical, 1 major, 2 minor)
cost_usd_actual: $0.27

Run 2 · 2026-05-17 15:48 UTCEngine version 41

audit_trail_id: 71fa9b34-08ec-4f1a-bd02-9c4837e25b81
inputs_hash: 9f3e7a18b2cc5d6e4f0a89b1d2c734e5f6a78b9c0d1e2f3a4b5c6d7e8f9012ab
provisional_score: 62
final_score: 58 · Needs Attention
cycles_completed: 1
total_findings: 1 (0 critical, 0 major, 1 minor)
cost_usd_actual: $0.19

What this proves

Identical inputs_hash → identical deterministic output. Same provisional score (62), same final score (58), same band (Needs Attention), same category rollups — byte-for-byte.
audit_trail_id is unique per run. Two runs of the same inputs get two different UUIDs (each is its own record) but the deterministic content under each ID is identical.
Audit-pass cost varies; verdict score does not. Run 1 took two cycles ($0.27); Run 2 cleared in one ($0.19). The score never moved.

Every Verdict you have ever seen can be reproduced from its inputs alone, against the engine + prompt version stamped on the record. That’s the contract.

Cost transparency

We’re not hiding the cost.

honest per-Verdict cost

What it actually takes to produce one Verdict.

List-price estimates from each vendor’s public pricing page. Tracked actuals live in verdicts.cost_usd_actual and usually land below the budget.

Anthropic — engine prose render

Sonnet 4.6 · $3.00/M in · $15.00/M out

~3,500 input tokens (cached prompt) + ~6,000 output tokens

$0.06 – $0.12

Anthropic — 6-lens audit pass

Sonnet 4.6 · ~3 lens calls × ~$0.04 + revisor ~$0.05

capped at 3 cycles; most ship in 1 cycle

$0.15 – $0.30

Anthropic — opus-4-7 (Full tier)

Opus 4.7 · $15/M in · $75/M out (opt-in via env)

engine.ts MODEL override; only used on flagged inspections

$0.00 – $0.40

Vercel — Fluid Compute

GB-s × engine duration (~30–90s, 1024MB)

600s ceiling on engine route; typical run finishes in ~45s

$0.005 – $0.015

Supabase — Postgres + Storage

~120KB JSONB audit_trail + optional PDF

rolls up to the $25/mo Pro plan; per-Verdict is negligible

$0.0001 – $0.0008

Resend — email delivery

transactional + retention webhooks

1–3 sends per Verdict on the Pro plan ($0.40 / 1k)

$0.0005

Twilio — SMS (shop tier only)

A2P 10DLC · TCPA-gated

consumer flows are email-only; shop magic-link is SMS

$0.00 (consumer) / $0.0075 (shop)

NHTSA APIs

vPIC · Recalls · Complaints · TSBs

public federal data; no commercial fee

$0.00

What makes us structurally different

Engineering-spec contrast, not marketing.

Properties an engineer can verify by inspecting the artifact — reproducibility, audit trail, grounding, independence — measured strictly.

Engineering-spec comparison across vehicle reliability and repair-analysis tools.
Engineering dimension	RepairVerdict	Carfax	RepairPal	ChatGPT	Local shop
Deterministic scoring0–100 score derived from math, not a language model
Per-Verdict reproducibilitySame inputs → same output, byte-for-byte
Audit trail per outputinputs_hash + audit_trail_id stored with every Verdict
VIN-grounded NHTSA dataRecalls, complaints, ODI pulled live per VIN at run time
TSB / CSP cross-referenceCoverage-hunt sweep checks free-repair eligibility per VIN
Open methodologyFailure-mode database and engine stages public
6-lens self-auditIndependent reviewers re-read every output before delivery
Per-output verifiabilityTSB / recall IDs in prose must resolve to the audit trail
Independence from upsellNo commission on parts or labor; one transaction per customer

Release + deployment

How a code change becomes a live Verdict.

Honest about the manual step: production promote is a deliberate click in Vercel, not a CI green-light. The cron schedule below is the actual vercel.json running in production.

1—
Local dev
pnpm dev with hot reload. Engine runs against a real Supabase project; Claude API live in dev too.
2~15s
Typecheck + lint gate
pnpm typecheck (project tsc), pnpm lint:fix, pnpm format:fix. Pre-push gate inside the repo.
3<5s
Git push to GitHub
main is protected. Feature branches merge via PR. Direct-to-main allowed for solo-eng cadence.
4~90s
Vercel preview deploy
Every push auto-builds a preview at <branch>--repairverdict.vercel.app. Inspectable, shareable.
5judgment
Manual promote — Devon
Promote-to-prod is a deliberate click in the Vercel dashboard. No auto-deploy to prod from CI.
6~10s
Production live
Same Docker image as the preview. Traffic shifts atomically once the new deployment passes health.

vercel.jsonproduction crons · live

// vercel.json — production cron schedule
{
  "crons": [
    { "path": "/api/admin/auto-deliver-tick",   "schedule": "* * * * *" },
    { "path": "/api/admin/sweep-stuck-paid",    "schedule": "*/2 * * * *" },
    { "path": "/api/admin/abandoned-cart-tick", "schedule": "*/15 * * * *" },
    { "path": "/api/admin/review-prompt-tick",  "schedule": "*/15 * * * *" },
    { "path": "/api/admin/token-cleanup-tick",  "schedule": "0 * * * *" },
    { "path": "/api/admin/janitor-tick",        "schedule": "0 3 * * *" }
  ]
}

Security posture

Independence by construction.

Control

Webhook signature verification

Every Stripe webhook event is verified against `STRIPE_WEBHOOK_SECRET` before any state change. Unsigned events 401. Enforced even in DEMO_MODE per repo policy.

Control

Hashed claim tokens

256-bit random tokens generated per Verdict delivery. SHA-256 hash stored; raw token never persisted. Single-use; auto-expire at TTL (30 days default).

Control

Encryption at rest

Supabase Postgres + Storage handle encryption transparently. PDFs / photos in private buckets with signed-URL access only.

Control

No data sales — single revenue stream

Control

Defense-in-depth cron auth

Control

Responsible disclosure

Found a vulnerability? See /security/disclosure for the reporting channel + scope. Devon reads every report personally and acknowledges within 24 hours.

Observability

Every Verdict shows its work. So does every engine call.

Engine progress events
Every Verdict writes per-stage progress events to the inspection row's `progress_events` JSON column: `submission_received → engine_triggered → inspection_loaded → pipeline_running → prose_rendering → audit_lenses_running → persisting → verdict_ready`. Customer reveal page polls these every 1.5s; admin live-progress watcher polls every 1.2s and renders the full stage timeline + activity log.
Audit trail per Verdict
Immutable `audit_trail_id` + `inputs_hash` stored with every Verdict. Reproducible byte-for-byte from the same inputs against the same engine version. Visible in the verdict footer + on every share link.
Structured logging
Every engine call emits `verdict.engine.start` / `verdict.engine.complete` / `verdict.engine.failed` events with `durationMs`, `costUsd`, `engineVersion`, `tier`. Pivot-able in Vercel Logs / Sentry / Datadog.
Cost tracking
Anthropic API usage (input + output tokens, cache reads, cache creations) recorded per Verdict in `cost_usd_actual` on the verdicts row. Reported in the admin verdicts table + engine perf widget. Average $0.15–$0.30 per Verdict against a $5/Verdict budget.
Six-cron orchestration
`auto-deliver-tick` (1 min) ships verdicts past their edit window. `sweep-stuck-paid` (2 min) recovers stalled engines via deterministic fast-path + AI diagnostic backstop. `abandoned-cart-tick` (15 min), `review-prompt-tick` (15 min), `janitor-tick` (daily), `token-cleanup-tick` (hourly) round out the maintenance loop.

Recovery paths

Four redundant delivery paths per Verdict.

Built after a stuck-at-paid post-mortem. Customer payment and engine run shouldn’t be coupled through a single point of failure.

1
In-process engine fallback`fire-engine.ts` runs the engine + delivery in the calling lambda's `after()` callback if the HTTP route is unavailable (missing internal secret, DNS, 5xx). No silent stuck-at-paid.
2
Verified status flip4-attempt retry on the `paid → verdict_generated` UPDATE with conditional `.select()` to confirm a row was affected. Detects "already-advanced by competing writer" as success. No fire-and-hope writes.
3
Inline delivery from engineThe engine itself calls `deliverVerdict()` immediately after the verified status flip — customer email is on the wire in the same lambda invocation that rendered the verdict. After() delivery + crons are belt-and-suspenders.
4
Synchronous emergency rescue`/admin/rescue` ships an "Emergency: Run + Deliver Inline" form. Single HTTP request runs the engine + delivery in one lambda, returns a JSON report of every step. Used when an inspection needs immediate human-driven rescue.

Engineering update strategy

Every Verdict carries its build stamp.

engine

v3.8.14

Deterministic 13-stage pipeline. Pinned in lib/verdict-v3/types.ts as ENGINE_VERSION. Every audit_trail records the version that ran it.

prompt

Engine version 41

5,000+ lines of prose-render rules. Read on every call. Versioned in the file header; the engine reads the version at boot.

stamped on every Verdict

engine + prompt

Both versions persist in the verdict row. Customer-facing footer renders them; share-link metadata exposes them; any Verdict can be reproduced against the exact build that shipped it.

Who built this

One former shop owner. Eighteen months. No team.

That’s not a humble-brag. It’s the answer to the implicit question an engineer reading this page is asking: did somebody seriously do all this themselves?Numbers below.

3,255 lines of deterministic engine code (TypeScript, hand-written, no codegen).
5,000+ lines of engine prompt rules — every guardrail version-controlled and changelog-tracked.
730+ hand-curated platform failure patterns — every one tied to a documented source.
86 marketing routes, every one server-rendered and accessibility-audited.
36 API route handlers, six independent cron orchestrators.
Engine version 41 — the current prompt revision, with the prior history documented in /changelog/engine.

The case for why this matters · /why About Devon · /about

Verify everything

Eleven public credibility surfaces.

Don’t take this page’s word for it. Every claim on this page links to the page that proves it.

One request, six external services, four recovery rails.

What’s actually shipping.

Boring on purpose. Every choice is load-bearing.

Deterministic math first. Language model renders the explanation.

Six independent reviewers per Verdict.

Four short reads from the engine.

Every Verdict is a defensible record.

One Verdict, two runs, identical output.

We’re not hiding the cost.

Engineering-spec contrast, not marketing.

How a code change becomes a live Verdict.

Local dev

Typecheck + lint gate

Git push to GitHub

Vercel preview deploy

Manual promote — Devon

Production live

Independence by construction.

Webhook signature verification

Hashed claim tokens

Encryption at rest

No data sales — single revenue stream

Defense-in-depth cron auth

Responsible disclosure

Every Verdict shows its work. So does every engine call.

Engine progress events

Audit trail per Verdict

Structured logging

Cost tracking

Six-cron orchestration

Four redundant delivery paths per Verdict.

Every Verdict carries its build stamp.

One former shop owner. Eighteen months. No team.

Eleven public credibility surfaces.

One request, six external services, four recovery rails.

What’s actually shipping.

Boring on purpose. Every choice is load-bearing.

Deterministic math first. Language model renders the explanation.

Six independent reviewers per Verdict.

Four short reads from the engine.

Every Verdict is a defensible record.

One Verdict, two runs, identical output.

We’re not hiding the cost.

Engineering-spec contrast, not marketing.

How a code change becomes a live Verdict.

Local dev

Typecheck + lint gate

Git push to GitHub

Vercel preview deploy

Manual promote — Devon

Production live

Independence by construction.

Webhook signature verification

Hashed claim tokens

Encryption at rest

No data sales — single revenue stream

Defense-in-depth cron auth

Responsible disclosure

Every Verdict shows its work. So does every engine call.

Engine progress events

Audit trail per Verdict

Structured logging

Cost tracking

Six-cron orchestration

Four redundant delivery paths per Verdict.

Every Verdict carries its build stamp.

One former shop owner. Eighteen months. No team.

Eleven public credibility surfaces.