Failsafe

Inspiration

Most recovery plans are inventories. They tell you there is a bank account, an email address, and a phone. They rarely show that the bank account and the email may both depend on that same phone.

Our test case made the problem concrete. Lose the household phone and you lose the authenticator plus the recovery number for the primary email. Seven more accounts depend on that email. The accounts still exist, but the family cannot reach them.

Failsafe started with one question: what would stop the next person from getting in?

What it does

Failsafe maps the people, accounts, devices, documents, and payment methods a household relies on. For each item, it records the possible recovery paths, who reported the relationship, when it was checked, and what kind of evidence supports it.

The analyzer then looks for loops, shared failure points, unreachable accounts, stale claims, and access that should have ended. A household can pick one weak path, run a consent-based drill that stops before anything destructive, fix what failed, and test it again.

Failsafe never asks for passwords, recovery codes, tokens, or copies of private documents.

How we built it

We kept the architecture simple: one Next.js application and PostgreSQL as the source of truth. A household graph is small enough to analyze in memory, so we did not add a graph database. Drizzle handles the typed data model, while reviewed SQL migrations enforce row-level security.

The analysis code lives in its own package. It receives a graph snapshot and returns findings and readiness inputs. It cannot import the AI client, the database, HTTP code, or React.

GPT-5.6 is used where language helps. The OpenAI Responses API can turn an interview reply into a proposed graph change or explain a finding that the analyzer already produced. Zod validates the response, and a person must confirm a proposal before it changes the graph.

For Build Week, Codex with GPT-5.6-sol was our working environment. We used it to move from the PRD into TypeScript and SQL, trace authorization and RLS across each route, write and run tests, check the deployed flows in a browser, and debug the Vercel release.

Challenges we ran into

Recovery is full of AND and OR rules. An account might require both an identity document and a support call, while offering a completely separate path through email and SMS. We needed to model those choices without saving the secrets involved.

Evidence was the other tricky part. A participant saying that recovery worked is useful, but it is weaker than an observed pass in the exact scenario being tested. We had to carry that distinction through drills, findings, and readiness instead of flattening everything into a green checkmark.

Authorization also had to survive background work. Route handlers and jobs both need the same household boundary, idempotency rules, and PostgreSQL RLS context.

Accomplishments that we're proud of

We made the AI boundary enforceable in code. A model cannot create a finding, change its severity, verify evidence, or decide that a household is ready. Those decisions come from stored facts and deterministic code.

The complete demo loop works: map a path, analyze it, practice recovery, create a repair, and re-test. The current checkout passes formatting, lint, type checking, 71 automated tests, and a production build.

What we learned

We expected the graph algorithm to be the difficult part. Provenance mattered more. A recovery claim without a reporter, date, evidence class, and scenario is easy to overstate.

An LLM helps someone describe a messy situation and understand a result. Deterministic analysis remains the authority for safety claims.

What's next

Before using Failsafe with real households, we need an independent application and RLS review, live exercises for deletion, restore, key rotation, MFA, notifications, temporary-file cleanup, and OpenAI, plus usability and authenticated load testing.

Those checks are listed as open pilot gates in the repository. The current build does not clear them.

Try it out

Open failsafe-tawny.vercel.app for the public overview. Create an account, start a household, map 10 to 15 critical items, run the analysis, and schedule one safe drill. Use synthetic data only.

The source is at github.com/Mithun1504/failsafe.