Clearance

The graph is the conflicts check.

Clearance is a conflicts-of-interest gate for small law firms. Before any new matter opens, it draws every connection between the new parties and the firm's history, and keeps the matter blocked until a lawyer signs the paths it drew.

The problem

Before a firm takes a new client, someone has to answer one question: have we ever been on the other side? At most small firms that check is a spreadsheet, ctrl-F and somebody's memory. A name search finds exact strings. It cannot find the subsidiary of a current client, the company that renamed itself, the officer of a party the firm declined last year. Those are the conflicts that surface mid-case, and missed conflicts are a well-known source of malpractice claims and disqualification motions.

How a check runs

  1. step 1

    Parties come out of the intake text

    Paste the inquiry as it arrived. An extractor pulls out the people and companies and their roles. The model's work ends here: it never decides anything.

  2. step 2

    Names resolve against the firm graph

    An exact normalized match is the only automatic match. A name that is merely close (initials, an old company name, a contained name) blocks the matter and asks a human, once. The answer is written back as an alias edge, so the same question is never asked again.

  3. step 3

    FalkorDB draws every path

    Deterministic openCypher traversals walk up to three hops of typed edges: subsidiaries, aliases, family ties, prior matters, declined consults. Every hop carries its source and date. The matter stays blocked until an attorney signs the drawn paths.

Why a graph, measured

The demo firm has ten planted conflicts. The graph finds all ten. A literal name search over the same data finds six: it misses the subsidiary, the alias, the family tie and the officer, because none of them share a string with the intake text. Every matter page shows that name-search baseline next to the drawn paths, labelled as what it is: this product with FalkorDB taken out.

10/10

graph traversal

6/10

literal name search

Reproduce it with one command: npm run eval.

Built to fail closed

Nothing auto-clears. An uncertain identity blocks the matter. A graph that is down blocks every matter. A clear with unresolved uncertainty is refused. Decisions write back into the graph as records: signed clearances, ethical walls with their screened attorneys, declined consults. The next check respects all of them, which is what makes the gate a record the firm can stand behind rather than a search box.

Judge this in 90 seconds

  1. Open New intake, click “Warehouse suit (the hero case)”, run the check. Three connection paths draw on, beside the name-search exhibit that found one.
  2. Approve the proposed ethical wall, signing as Mara Quinn. The wall is written into the graph.
  3. Run the same intake again: the path now shows the standing wall instead of a raw conflict.
  4. Try “Ambiguous name”: the gate refuses to guess who R. Kane is, asks once, and remembers the answer as an alias edge.
  5. Open Ask the firm for cited subgraph answers to the questions a managing partner actually asks.

Limits, stated plainly

  • The firm is synthetic and seeded, built for the hackathon. No real client data is involved.
  • Traversals stop at three hops by design; a longer chain is noise, not signal, for this decision.
  • The live demo extracts parties with a 72B open model (Qwen, via Featherless), capped per day, with a deterministic extractor taking over when the model is slow to answer. Either way, extraction only proposes names. The graph decides.
  • This is a hackathon build, not legal advice and not a system of record.

Stack: FalkorDB is the only datastore. Next.js on Vercel. Every verdict is a replayable openCypher query; the README documents the schema and the exact queries.