Your team already wrote the onboarding doc. Out loud.
The knowledge exists. It is just distributed across six people, two of whom are on call and one of whom is leaving.
Read the film transcript
Narration from this original film. Soft instrumental music plays underneath.
The reason the retry limit is three isn’t in the code. It left with someone in March.
Your best engineer’s context leaves in a two-week notice period, and the runbook doesn’t cover it.
Kept is a voice interview. June calls, asks about your work, and keeps what you say, in your words, in a jar that’s yours.
A new engineer opens the config and asks why it’s three. Kept answers from the March backfill and shows the exact words from the call.
The context survives the notice period. Kept. Keep the knowledge behind the work.
A new engineer's first month is spent finding out who to ask. The deploy quirks, the service that lies in its dashboards, the incident from last spring that explains three weird defaults. None of it is written down, because writing it down has never survived a sprint plan.
Kept captures it in conversation, the way your engineers already explain things, and links captured knowledge to available sources. You see what your department has covered and where it is thin. You never see a score of a person, because Kept does not make one. Coverage, not surveillance.
Keeping a knowledge item does not promise permanent access to its original transcript. Sources can become unavailable after retention or removal. Check what evidence is available before relying on an answer.
Read personal and workspace controls. The overview above is available as text; explore the guided text walkthrough for a step-by-step example.