Inspiration

A hospital updates an anticoagulation policy. The policy itself is now correct, but the old threshold may still appear in a protocol, a training module, an order set, or someone’s answer from memory.

Updating the source document is the easy part. Finding everything that depends on it, correcting those dependencies, and showing that the change reached the people doing the work is much harder.

We built Supersede for that gap.

What it does

Supersede turns a policy change into a traceable correction workflow.

In our demo, the fictional St. Marlowe hospital changes an anticoagulation threshold. A change owner records the old and new rules, and a second reviewer validates them. Supersede then maps the affected claims, documents, decisions, and professional roles.

From there, it:

  1. Extracts claims from source documents and checks each supporting quote against the submitted text.
  2. Shows the paths connecting the changed rule to downstream material.
  3. Creates realistic cases where the old and new rules lead to different decisions.
  4. Requires an expert to review and approve every case before it can be used.
  5. Gives affected people a correction task, followed later by a different case to check whether they can apply the new rule.
  6. Exports a checksummed audit bundle containing the evidence, approvals, results, and event history.

The Build Week demo uses Displace, Supersede’s hospital education configuration. It includes one policy change, three decision cases, and eight fictional personas.

The same foundation also powers Propagate, which focuses on correcting documents and claims without assessing individual people.

How we built it

Supersede is a TypeScript application built with Next.js 16, React 19, and PostgreSQL.

We used the OpenAI Responses API with GPT-5.6 for claim extraction, rule comparison, impact classification, case drafting, and response grading. Every model task returns structured output with its model and prompt version. Extracted quotations are checked against the submitted source before they can become evidence.

The model can propose an answer, but it cannot approve its own work. People validate policy changes, approve cases, and authorize releases. Approved records are immutable; changing one creates a new version and requires a new approval.

Drizzle handles ordinary typed queries. We used explicit SQL for the parts where the database should enforce the rule itself, including tenant isolation, append-only audit records, immutable versions, and recursive dependency traversal. pgvector and Gemini embeddings support evidence retrieval.

WorkOS handles authentication, Inngest runs durable workflows, private files live in R2-compatible storage, and Vercel hosts the application.

We used Codex throughout the build to implement the product across the interface, APIs, database migrations, and tests. It was especially useful when a small workflow change crossed several trust boundaries at once, such as versioning, role separation, audit history, and browser behavior.

Challenges we ran into

Every AI result needed a receipt

A convincing answer is not enough. Reviewers need to see where it came from.

Each extracted claim keeps its exact quotation, source version, location, confidence, model version, prompt version, and review state. If the quotation cannot be found in the submitted text, Supersede rejects it.

Approval needed real consequences

An approval attached to an editable record would make the audit trail meaningless. Approved cases and artifacts are locked. Editing one creates a new version that must go through approval again.

We also enforce separation of duties. A change owner cannot validate their own change, and one person cannot both author and release the same case.

Training data can become surveillance data

A connection between a role and a document only shows possible exposure to an outdated rule. It does not prove what a person knows.

Supersede records one response to one approved case, defaults to aggregate reporting, suppresses groups smaller than five people, and only exposes named results when an organization explicitly enables them.

We cut the feature that sounded most impressive

Our original plan included automated feeds that watched external sources for changes. They made the demo broader but did not solve the hard part.

We removed them and started with a policy change entered by one person and validated by another. That let us focus on the part that mattered: finding the consequences, correcting them, and producing evidence.

Accomplishments that we're proud of

  • Built the complete path from policy change to dependency mapping, correction, recheck, and audit export.
  • Verified extracted quotations against the original source instead of trusting citation-shaped model output.
  • Implemented cycle-safe graph traversal that preserves the full path to each affected dependency.
  • Enforced separation of duties and immutable approved versions in the application workflow.
  • Produced a checksummed ZIP containing a PDF report, JSON evidence, approvals, and CSV event history.
  • Created a public walkthrough that works without credentials and labels every person, response, and clinical detail as fictional.

What we learned

Generating a question takes one model call. Making that question trustworthy is the real work.

It must remain tied to the old and new source versions, show its evidence, survive expert review, become immutable after approval, and keep the same identity throughout the audit trail.

We also learned that rereading a policy is not the same as applying it. Supersede uses a realistic correction task and then a different case for the later recheck. Otherwise, the system may only be measuring whether someone remembers the first question.

Try it

Open the public St. Marlowe walkthrough.

It is read-only, requires no account, and uses entirely fictional data.

What's next

  • Test Propagate with a real, permissioned claims library and measure reviewer effort alongside extraction accuracy.
  • Review the audit bundle with medical, legal, and compliance teams.
  • Pilot the correction and recheck workflow with a small training cohort.
  • Add LMS, HR, and automated source-watching integrations only after the core workflow proves useful.

Built With

  • cloudflare-r2
  • drizzle-orm
  • gemini-embeddings
  • gpt-5.6
  • inngest
  • next.js
  • openai-responses-api
  • pgvector
  • playwright
  • postgresql
  • radix-ui
  • react
  • react-flow
  • tailwind-css
  • typescript
  • vercel
  • vitest
  • workos
  • zod
Share this project:

Updates