What Leaves With Them 以 FalkorDB 分析員工離職時流失的知識

When a person leaves a company, the handoff list shows what they own. What only they know usually stays off it: a decision nobody else wrote down, a system nobody else touches, two teams that only talk through them.

We built a tool that finds those things before the last day. Here it is on one made-up engineer, Oskar.

Oskar handed in his notice. His last day is 9 October. His handoff list says he owns two systems, and the list is right.

Then we took him out of the company graph and watched what turned red.

What turned red is what the list leaves out: nobody else is connected to those two systems, two decisions rest on records only Oskar wrote, and he is the only link between the Support and Growth teams.

The company, and why we built this

His company, Quillfield Billing, is made up too: 14 people in four teams, eleven systems, sixteen decision records, tickets and chat messages, 403 records in all, written by a seeded script.

The problem is real for us. People have left our own team and taken what they knew with them, and the handoff list never showed what we were about to lose. So for Graph Hacks we built What Leaves With Them on FalkorDB. You pick a person, see what leaves with them, and plan the handoff before their last day.

What depends on Oskar

Click Oskar and you get what a spreadsheet already knows: two systems he owns, one team. Drag the depth slider to 4 and the graph follows his decisions instead of his systems. A decision he wrote constrains the ledger database. The billing API depends on the ledger. The admin console, the invoice renderer and the webhooks depend on the billing API. Seven more systems sit downstream of what Oskar decided, and every line carries the ids of the records that state it.

Remove him

"What breaks without this person" is a connectivity question, and FalkorDB answers it inside the database in three steps:

Copy people, teams, systems and decisions into a temporary graph, leaving the person out. Every link goes in both ways.
Run algo.WCC on the copy. A component with no person in it is something nobody else is connected to.
Drop the temporary graph.

CALL algo.WCC({nodeLabels: ['Person', 'Team', 'System', 'Decision'], relationshipTypes: ['LINK']})
YIELD node, componentId
RETURN labels(node)[0], node.key, componentId

For Oskar the copy has 44 nodes and 66 links. Creating a graph in FalkorDB is cheap, so every what-if question gets a fresh one and the real graph is never touched. algo.betweenness on the same kind of projection gives the third red number: Oskar was the only person linking Growth and Support.

Fourteen days to ask him

Press "Plan the handoff" and the clock starts. Each card asks Oskar about something only his records describe. He answers in writing, a colleague confirms, and the answer goes through the write gate. The two decisions that rested on Oskar alone go to zero, because a colleague's record now stands behind both.

The gate is plain code. A model may propose a fact; the gate checks that a line of a cited record states it, and keeps a receipt either way. When a fact ends it moves to a WAS edge, so questions about the present never read history.

The two systems are still red. The plan proposes a person for the SSO integration and says plainly that nobody in the graph has worked on the on-call runbook yet. And when you ask whether Oskar promised a customer anything on a phone call, the answer is "not in the graph", because no record says.

Remove someone yourself in the live demo

Then we removed everyone

Oskar was the person we were watching. So we asked the same question about the other 13, one removal at a time. All 14 took 383 ms on the live demo.

Five of the 14 take nothing measurable with them. The other nine each leave behind one to three things. And each measure points at a different person.

Oskar is the bridge. His betweenness score is 230; the next person has 109. Without him, Growth and Support have no link.

Selma Marsh, the Platform lead, is the lone author. Three accepted decisions rest on her records alone: SSO required for the admin console, per-tenant rate limits in notifications, and moving billing-api ownership from one engineer to another. She ranks fifth as a bridge, so a centrality score would not flag her. The systems those decisions name have five authors each in the records, which is why a list of systems looks fine.

Pavel Hollis is the blast radius. Remove him and nothing is left disconnected. But he owns auth, and seven systems within four hops depend on it, as many as for Oskar. One decision, rotating the auth signing keys every 30 days, rests on him alone.

One bus-factor number would have picked one of them and hidden the other two. Each is a different loss and needs a different handoff: a bridge needs introductions, a lone author needs a second author, and a blast radius needs a second owner who understands the dependency.

All 14 people, five measures

How we checked the answers

Agents in this project never write Cypher. They pick from 21 fixed tools with parameters, the same catalogue over HTTP and MCP, and every answer comes back with the graph path and the record ids behind it, or an honest "not in the graph".

We measured it on 82 questions about the same company. Plain retrieval over the same records was right 46.3% of the time, repeated stale facts on 4.9% and leaked personal data twice. The graph answered 100% with no model at all and 95.1% with a local model choosing the tool, with nothing stale and nothing leaked. We also attacked our own write gate 36 times. It stopped 13 on the first run and all 36 after 11 fixes.

What we learned about FalkorDB

What-if questions want throwaway graphs. Copying the company without one person, running algo.WCC and dropping the copy took a median of about 22 ms per person in our 14 runs. We never change the real graph to ask "what if".
Betweenness follows edge direction. Most edges in a knowledge graph point one way, so we write every link both ways into the projection. On 4.22 the score is an estimate; we average eight seeded runs and say so in the answer.
The hop bound can't be a parameter: *1..$depth fails on both 4.22 and 6.0.2, so the bound is a validated integer formatted into the pattern (FalkorDB #3350).
Test on both engines from day one. Cloud free runs 4.22 and Docker latest runs 6.0.x, and code written for one does not always run on the other. Our tests run on both. The eight things we ran into are in the repo, each with a repro.

What this does not show

The company is synthetic, and the script that wrote it put these risks in on purpose. The method finds them; that says nothing about how common they are in real teams. The router's rules and the agent's prompt were tuned after reading misses on this question set.

Try it

Open the live demo, click a person, press Remove and look at Show Cypher. Or ask the API:

curl -s -X POST https://what-leaves.retailbox-automation.com/v1/quillfield/tools/without \
  -H 'content-type: application/json' -d '{"person": "Selma Marsh"}'

Swap without for single_source, what_leaves (with "depth": 4) or bridges (with "top": 10).

What Leaves With Them

on FalkorDB 6.0.2 and 4.22 · MIT

When someone leaves a company, the agent shows what leaves with them and builds the handoff, every line with a graph path back to its source records. It walks a company graph in FalkorDB from the person to the decisions they made, the systems those decisions constrain, the people and teams who own those systems, and the things nobody else is connected to once the person is gone.

In a 2022 survey of 1,000 IT managers at large organizations in the UK and US, 67% said they were concerned about losing knowledge and expertise when people leave, and 64% said their organization had already lost knowledge that way (Sinequa press release, August 2022). We built it because people left our own team and took knowledge with them.

Try it: https://what-leaves.retailbox-automation.com. Pick a person, move the depth…

How we built it: the code, tests and docs were written with AI coding assistants under my direction; the concept, the design decisions and the acceptance of each change are mine. The demo agent runs on a local open model, and the video narration is an AI clone of my own voice.