At-risk knowledge#
At-risk knowledge ranks assets by how hard they would be to recover if their owner left. It is the surface that turns “we should write things down” into a list with a top item.
Publish something first
Risk is scored over knowledge assets, so an empty library scores nothing. The page says so plainly: run the calculation after knowledge is published.
Press Recalculate
Rescores every asset. It needs knowledge.write. From the ⌘K palette the action Recalculate continuity risk does the same and then opens this page.
Read the header, then the top of the list
The header states how many assets were assessed and how many are critical. Work the critical ones; the tail is not where the exposure is.
What the score is made of
- Concentration
- How few people hold this knowledge. One owner is the classic bus factor, and it is the strongest single driver of risk.
- Staleness
- How long since the underlying evidence was refreshed. Old knowledge about a system that has changed is worse than no knowledge, because somebody will act on it.
- Criticality
- How much else depends on it. This reads the graph, so an asset the memory map shows as a dependency of several projects scores higher than an isolated note.
Recalculate after a departure is announced, not after it happens
The list is most useful in the weeks before somebody leaves. Recalculate when a departure is known, filter to what that person owns, and you have the agenda for the handover.
Handover: the departure case#
Handover captures what a leaver knows, assigns a successor, and validates the transfer before the case closes. It is a state machine, and the console shows you exactly where a case is on it.
| Stage | What has happened |
|---|---|
| Initiated | A case exists for a named person. Nothing has been mapped yet. |
| Knowledge mapped | What this person holds has been identified from verified evidence and the graph. |
| Pack generated | A continuity pack has been built: a budgeted, prerequisite-ordered set of handover items. |
| Capture pending | Capture requests are outstanding: the gaps the pack found that only the leaver can fill. |
| Successor assigned | A named person is taking it on. |
| Completed | The transfer was validated and signed off. |
The console never offers an action the service would refuse
Every control on a case is gated on the runtime action set the backend reports for that case, so Generate pack disappears once a pack exists, and Complete only appears after a successor is assigned. If a button is not there, it is not a permission problem; the case is not at that stage.
Running a case, step by step#
Initiate
Handover → Initiate, and choose the departing person. You land in that case’s workspace.
Map what they know
The case pulls together the assets they own, the graph edges they sit on, and the expertise resolved to them. This is where Expertise earns its keep: ownership derived from evidence, not from a team page.
Generate the continuity pack
The pack is chosen by an optimizer under a time budget: a prerequisite-ordered set of handover items, with a readiness score that is the measured coverage of this person’s unique knowledge.
Raise capture requests for the gaps
Where the pack finds knowledge that exists only in somebody’s head, it raises a capture request against them. This is the stage that actually needs the leaver’s time. Start it early.
Assign a successor
Suggest successors ranks candidates from evidence, and Assign successor names one. From here the case is visible from the successor’s side.
Work the pack
The items are a checklist. Moving the last item to done is what completes a pack. Readiness is recomputed from item statuses, so the score moves as the work is done rather than only when the pack is rewritten.
Complete
Available once a successor is assigned and the transfer has been validated.
The three pack controls#
- Re-plan under a budget
- Runs the optimizer again with a new time budget in minutes. It replaces the items the optimizer authored and keeps the ones added by hand, and it rewrites the readiness score. That is a real loss of hand-ordered work, so it asks for confirmation.
- Item status
- The checklist itself. Each item moves through its states; the last one reaching done completes the pack.
- Assign
- Hands the pack to a named person with a due date, making them accountable for working it through. It tracks their progress against the pack’s items and carries its own deadline. It does not change who can read the knowledge inside.
Transfer validation, from the successor's side#
Transfer validation is the same open cases seen from the person taking the work on: capture readiness, the evidence tasks assigned to them, and the sign-off decision.
Open your case
Cases needing your validation are listed by person.
Work through the evidence tasks
Each is a thing you are being asked to confirm you can actually do, or a piece of knowledge you are being asked to confirm you have received.
Sign off, or do not
Sign-off is the successor saying the transfer landed. It is the one signal in the product that comes from the person who will be carrying the work, and refusing to give it is a legitimate and useful answer.
Do not close a case on the leaver's last day
Completion should follow validation, not the calendar. A case closed because somebody left is a case that recorded a date, not a transfer.
You are done when
At-risk knowledge shows a recalculated list with a critical count you can act on, and any open departure has a case with a generated pack, a named successor, and capture requests raised while the leaver is still there to answer them.
Something here wrong, missing, or no longer true of the product? Write to hello@evodira.com. Documentation that has drifted from the console is a bug and we treat it as one.