Continuity

The ultimate repair tech that can't invent a part. Continuity takes a dead circuit board from symptom to the exact failed component — grounded and verified in Amazon Aurora.

Comment

ABOUT THE PROJECT

Continuity

An AI repair tech can't be allowed to guess. A wrong call doesn't just sound wrong — it scraps a board, or ships a fire hazard back to a customer.

Continuity is a bench diagnostic instrument for board-level electronics repair. A technician types a symptom — "no power" — and Continuity walks the board's actual circuit graph, tells them the one component that failed, and shows them the exact pin to probe. Every part it names is a real row in the database. Every conclusion is re-checked by deterministic SQL before a human ever sees it. It is an AI that is honest by construction — and the thing that makes it honest is the database.

The core idea: the database makes the agent honest. The model can reason, but it can only cite what Amazon Aurora will return. There is no row for a part? Then there is no such part. The agent literally cannot invent a component, because the only way it can "see" the board is by querying rows that exist.

Inspiration

Board-level repair is where electronics repair gets hard — and where most shops give up. Diagnosis lives in the heads of a few senior technicians. Juniors swap parts on a hunch ("swap-and-pray") and burn through margin. The documentation that exists is buried in PDFs, a dozen incompatible boardview formats, and forum threads that end with "did you ever fix it?"

So good boards get scrapped. The UN Global E-waste Monitor puts it at 62 million tonnes discarded every year — most of it repairable. Meanwhile right-to-repair laws are now requiring manufacturers and shops to fix instead of replace. The demand is mandated; the expertise doesn't scale.

We wanted to give every repair shop the instinct of its best technician — without that knowledge walking out the door. And we refused to build the obvious thing (a chatbot that confidently makes up part numbers), because in repair, a confident hallucination is worse than "I don't know."

What it does

Continuity takes a dead board from symptom → root cause → the exact pin to probe, and turns each repair into institutional memory.

A real run, exactly as it happens in the app:

  1. A tech types "no power."
  2. The agent walks the board's power tree with a recursive query — USB-C (J15) → buck regulator (U7) → the PP5V0 rail → the SoC (U1) — and narrows to the suspect.
  3. It records measurements: PP5V0 reads 0 V, and 0.15 Ω pad-to-ground — a dead short.
  4. It returns a verified root cause: C29, the input decoupling cap, shorted — with the repair protocol and the pin to probe.
  5. A deterministic verifier re-checks that finding against the board (does the refdes exist, is it on that rail, does the measurement support a short) and stamps it VERIFIED ✓. The model doesn't get to vote.
  6. The tech clicks Confirm root cause → the case is embedded into the shop's private vector memory.
  7. Next week, a different tech types "5 volt rail won't come up" — different words, same fault — and Continuity recalls the shop's own prior repair by meaning, via vector search.

Five things every repair business actually needs, and each is impossible without the database:

  • Grounded diagnosis — the agent can only name parts that exist as rows.
  • Deterministic verification — every finding is re-checked by SQL, not trusted from the model.
  • A shared team bench — a shop is a team; every technician sees the same repair history, with attribution.
  • Compounding memory — confirmed repairs become a private, searchable knowledge base that gets smarter every week.
  • Cross-shop intelligence — an anonymized benchmark ("C29 is the #1 no-power cause") computed across shops without any shop seeing another's data.

How we built it — and why Amazon Aurora is the hero, not a bucket

Most apps treat the database as storage. For Continuity, the database is the product's integrity layer. Everything load-bearing is a deliberate Aurora (PostgreSQL) design decision.

  Technician types a symptom
        │
        ▼
  ┌────────────────────────────────────────────────┐
  │  AGENT  (tool-using LLM)                          │
  │  may ONLY call tools that read real Aurora rows   │
  └────────────────────────────────────────────────┘
        │  trace_net · inspect_component · record_measurement
        ▼
  ┌────────────────────────────────────────────────┐
  │  AMAZON AURORA  (PostgreSQL, IAM auth, no pwd)    │
  │  • the board IS the schema: components, nets,     │
  │    pins, edges  → WITH RECURSIVE power trace      │
  │  • pgvector (HNSW)  → semantic recall of cases    │
  │  • RLS policies + SECURITY DEFINER aggregates     │
  └────────────────────────────────────────────────┘
        │  every refdes resolves to a row — or "no such part"
        ▼
  ┌────────────────────────────────────────────────┐
  │  DETERMINISTIC VERIFIER  (SQL, not the model)     │
  │  re-checks each finding against the board          │
  └────────────────────────────────────────────────┘
        │
        ▼
  Verified root cause + exact pin to probe
        │  tech confirms the fix
        ▼
  Embedded into the shop's private memory (pgvector)
  → the bench gets smarter every week
  • The board is a graph, and the graph is the schema. Components, nets, pins, and typed edges are relational tables. Tracing a power rail is a WITH RECURSIVE traversal in Postgres — the agent doesn't "reason about" the circuit, it queries it. This is what makes grounding real: the model's tools return rows, so the model can only speak in rows.
  • pgvector for semantic case memory. Confirmed findings are embedded (1024-dim) and indexed with HNSW for sub-linear similarity search. A symptom in plain English ("won't power on") finds the right past case even when the words don't match.
  • Row-Level Security + SECURITY DEFINER for honest multi-tenancy. Each shop's data is scoped to its tenant. The cross-shop benchmark is a SECURITY DEFINER function that reads every shop's confirmed repairs and returns only percentages — the aggregate crosses the boundary by design; the rows never do.
  • IAM database authentication — the app connects to Aurora with short-lived IAM tokens via Vercel's OIDC. There is no database password anywhere in the stack.
  • A deterministic verifier turns the model from an oracle into a witness: it proposes; SQL checks; only verified findings are shown.

Front end: Next.js (App Router) on Vercel, designed as a warm "aluminium bench instrument" — dark phosphor board views against a machined faceplate — so the front end visibly mirrors the back end: every provenance card a technician taps is rendered from the exact database join the agent cited. Auth & teams: Clerk Organizations (a shop = an organization; technicians = members). Agent: a tool-constrained loop that is model-agnostic by design — it runs on an open model today and is one env var away from a frontier model, with no code change.

How it makes money (Monetizable B2B)

Continuity is a per-shop SaaS, priced on the two axes a repair business actually scales on: diagnostic volume and technicians on the bench.

Plan Price For Includes
Solo Free a single technician 1 seat · 25 diagnoses/mo · grounded + verified diagnosis
Shop $79/mo an independent repair shop up to 5 seats · 500 diagnoses/mo · private shop memory · team history + audit trail · fleet benchmark
Network Custom multi-location / OEM programs unlimited seats & volume · board-graph ingestion · API + SSO

Usage is metered per shop inside Aurora (the same counter shown live on the bench), and seats are managed through each shop's organization. The business model is built into the data model.

The moat compounds in the database. Every verified repair a shop confirms makes its private vector memory more valuable — and that memory is theirs alone. A shop that's used Continuity for a year has a diagnostic asset a competitor can't copy and a new hire inherits on day one. The longer they use it, the harder it is to leave.

Who pays and why: independent repair shops and OEM/insurance repair programs that are now legally on the hook to repair instead of replace. Continuity turns a first-week hire into someone who diagnoses like a senior tech — and keeps that expertise in the building.

Challenges we ran into

  • Making "no hallucination" a property, not a promise. Prompt-engineering an LLM to "not make things up" is hopeless. We instead made it structurally impossible: the agent's only window into the board is a set of tools that return database rows, and a deterministic SQL verifier has the final say. The integrity guarantee lives in the schema, not the prompt.
  • Honest multi-tenant isolation. Our app's database role is privileged, so we don't rely on RLS alone — every query is explicitly scoped to the shop, with RLS policies as a second guardrail, and cross-shop reads go through audited SECURITY DEFINER aggregates that return counts, never rows. We were careful to describe this accurately rather than overclaim.
  • Passwordless Aurora on serverless. Wiring IAM token auth (Vercel OIDC → RDS Signer) so there's no secret to leak took real plumbing, but it's the right way to run a database on the edge.
  • Designing a back end you can see. We wanted the UI to prove the database is real — so the live graph view, the verified stamps, and every provenance chip are rendered straight from the rows the agent queried.

Accomplishments that we're proud of

  • An agent that cannot invent a part — and a UI that lets you watch it refuse to.
  • The full loop works end-to-end on a free, open model: grounded trace → deterministic verification → confirm → vector recall of the shop's own prior repair, by meaning.
  • A genuine B2B product shape: teams, isolation, audit trail, usage metering, and a privacy-preserving cross-shop benchmark — not a single-user demo with login bolted on.
  • A database that is the hero of the application, the integrity layer, and the business model — all at once.

What we learned

  • Constraints are features. "The agent may only cite rows" sounds limiting; it's the entire value proposition.
  • The right database design can do what prompt engineering can't. Referential integrity is a hallucination guardrail. A recursive CTE is a reasoning engine. A SECURITY DEFINER aggregate is a privacy boundary.
  • Multi-tenancy is a day-one design decision, not a later refactor — once data is shared correctly across a team and isolated across shops, the product stops being a toy.

What's next for Continuity

  • Board ingestion: import a netlist / boardview so any device becomes a queryable graph — turning the seeded reference board into any board a shop sees.
  • More devices and a parts-inventory join (stock the part before the customer calls).
  • Billing wired to the existing per-shop meter, and SSO for Network customers.
  • A mobile bench companion so the tech reads the pinout at the board, not the desk.

BUILT WITH

amazon-aurora, postgresql, pgvector, aws-iam, next.js, react, typescript, vercel, vercel-oidc, clerk, ai-sdk, cohere, tailwindcss

Built With

Share this project:

Updates