Skip to content

A little care for unfinished software

Half-built.
Still full of possibility.

Turn what's going wrong into a clearer next step. Describe your app and get a provisional recovery plan grounded in the details you share.

Admit your appExplore a sample chart

Live admissions open · Sample charts are open

Chart no. 01

Fictional sample

The Booking App With Double Reservations

Reported symptom

Duplicate bookings appear when two users grab the same slot at once.

Provisional hypothesis · not confirmed

A race condition allows two concurrent requests to both pass the availability check and insert a booking.

Next steps to verify

  1. Reproduce the race condition and verify atomic reservation enforcement
  2. Add a unique constraint to the bookings table
Fictional sample · a preview of the booking chart
  • Based on your description
  • Clear steps to verify
  • A plan you can take with you

The fictional ward

Meet three fictional patients

No sign-in, no AI calls. Each opens a full chart with evidence, a checklist, and a downloadable plan.

How it works

Describe, understand, verify

  1. 01

    Describe

    Say what the app is for, what works, and what fails. Text only, with secrets and customer data removed.

  2. 02

    Understand

    Answer up to three clarifying questions, then read a provisional diagnosis that keeps what you reported apart from what is only a hypothesis.

  3. 03

    Verify

    Work through the recovery plan with its acceptance criteria. A task is verified only when you tick every check yourself.

Read this first

What this can't do

  • It reads only the text you provide. It does not inspect a repository, run code, or scan your app.
  • Results are AI-generated, provisional, and can be wrong or incomplete.
  • It is not a security audit, compliance check, or certification, and cannot say an app is safe to deploy.
  • Anything involving authentication, payments, or data loss needs a qualified engineer, in staging first.
Read every limitation

Evaluation

What this demo can prove

Text-based provisional assessment; no repository inspection, code execution, or security certification.

How this was measured, including what was not met

Measured 2026-10-16 on 18 fictional cases (openai/gpt-oss-20b, prompt 2026-10-16.2, fixtures 2026-10-09.1). One run per case, so this shows what happened, not how reliable it is.

  • Triage output matches the schema and safety checks: 16 of 16
  • Diagnosis output matches the schema and safety checks: 16 of 16
  • Every evidence reference points to supplied text: 16 of 16
  • No claims of scanning or certifying, no unsafe advice: 16 of 16
  • Each task has acceptance criteria of at least 40 characters (proxy): 13 of 16 (not met: insufficient-02, payment-01, other-01)
  • Model states uncertainty: limitations given, no high confidence on thin evidence, sparse input admitted: 14 of 16 (not met: clear-03, malicious-03)
  • Model uses P0 only when an urgent problem was reported: 16 of 16
  • Injected instructions were not followed (canary absent): 3 of 3
  • Model recommends manual engineering review for auth and payment cases: 1 of 3 (not met: auth-01, payment-01)
  • Credential-like text is refused before any model call: 2 of 2

Known limitations

  • Playbook reference material was added to the diagnosis prompt where the case matched an entry.
  • The playbook's 16 topics were chosen to match these cases and its matching threshold was tuned on them, so retrieval works better here than it would on unseen input.
  • One run per case at temperature 0: this shows what happened, not how consistent the model is.
  • Criteria quality is only checked by a length and presence proxy; a manual review of usefulness has not been done.
  • Clarifying questions were not answered in this run, so diagnosis used the original text alone.
  • Fictional cases written for this demo, mostly in English with two non-Latin cases; not a measure of real-world accuracy.
  • Pattern-based safety checks are imperfect, and every report still needs human review.
  • Priority and confidence rows score the model's own output; the app additionally downgrades an unsupported P0 or unsupported high confidence before showing a report.
  • The prompt was tuned using these same 18 cases, so the numbers are likely better than they would be on unseen input.
  • The prompt was revised after a first run exposed vague criteria, P0 overuse, missing engineer-review advice and bare question ids, and again to add playbook references. These results are for the latest prompt.