A contractor who spent eighteen months across three of your teams finishes on Friday, so how do you work out which credential values they still hold?
answer
- the store saw only part of it
- reachability, not proven reading
- enumerate accounts and memberships
- memory leaves on Friday
- treat reachable as held
basics
~20 sReconstruct what was reachable, not what was read. Enumerate the repositories, channels, ticket queues, runbook pages and hosts their accounts could reach, work out which values were visible from each, and interview them and their teams before Friday.
solid answer
~50 sThe store cannot answer this. It can tell you which identities it authenticated and what those identities were permitted to read, which covers values fetched *through* it — and most of what a long-serving contractor holds never came through it. It came from a configuration branch they had checked out, a value pinned in a channel, an attachment on a ticket they worked, a runbook page they followed during an incident, a screen they were shown while pairing. So you build the list from **reachability**: enumerate every account and membership they held, and for each one work out which credential values were visible from it. Then interview them and their three teams while they are still reachable, because memory is the source that leaves on Friday. The output is an upper bound on possession, and you should treat reachable as held.
go deeper
Understand that leaving does not remove copies a person already made, and that the systems they could reach are the starting point for working out what they still have.
Explain why the store's record covers only values fetched through it, and name the paths that bypass it entirely: a checked-out configuration branch, a pinned message, a ticket attachment, a runbook page, a pairing session.
Run the reconstruction in order — enumerate accesses, map to visible values, interview before the last day, write rows back — and state plainly that the output is an upper bound you act on rather than a proven list.
Recognise the cost curve: reconstruction scales with tenure and access breadth, so the real intervention is recording handovers at the moment they happen and keeping the inventory current between departures.
## Why the question has no direct answer The instinct is to ask the secret store. The store's access record tells you which identities it authenticated, what those identities were allowed to read, and when they read it. That is genuinely useful and it is also a small fraction of the answer, because it only covers values that were **fetched through the store by that person's own identity**. A contractor who worked across three teams for eighteen months acquired values in other ways entirely: - A configuration branch they had checked out on their own machine, whose history carries values that were later removed from the current files. - A value pinned in a channel so the team would stop asking for it. - An attachment on a ticket they were assigned. - A runbook page they followed during an incident at 2am. - A value read off someone else's screen while pairing, or dictated over a call. - A value a teammate pasted to them directly so they could get started on day three. None of those is an event at the store. Some leave a record somewhere — a ticket and a pinned message do preserve *that* the value was shared, and with whom the channel was shared — but the handovers that happened person to person leave nothing at all. ## Build the list from reachability So the deliverable is reconstructed, and it is built in this order. 1. **Enumerate the accesses, not the actions.** Which repositories could their account read; which channels were they in; which ticket queues and runbook spaces; which hosts could they log into; which store paths was their identity permitted to read. This is the one part that is mechanical, and it should be done from the systems rather than from memory. 2. **Map each access to the values visible from it.** For a repository, read the current settings files and then the history. For a channel, search the pinned items and the era they were in it. For a runbook space, read the recovery steps. This step is where the existing inventory pays for itself: if a value already has a row naming its resting places, it falls out immediately. 3. **Interview, and do it before Friday.** Ask them directly: what did you have to be given to get started, what do you keep locally, what did you have to look up during an incident, what did you hand on to somebody else. Ask their three teams the same questions from the other side. This source is high yield and it is the only one with an expiry date on it. 4. **Write what you learn back as inventory rows.** Every value the exercise surfaces gets a row with its known copies updated. The measure of whether this went well is not Friday; it is whether the next departure starts from something better than a blank page. ## What the list honestly claims | Claim | True? | |---|---| | These values were reachable by that person | Yes, for everything step 1 and 2 found | | These are the values they actually held | No — reachable over-counts, usually heavily | | Nothing outside this list was reachable | No — unrecorded handovers are invisible by construction | | This is what to act on | Yes, because reachable is the only bound you can establish | The list is an **upper bound on possession that is itself incomplete**, which sounds contradictory and is not: it over-counts the accesses you found and misses the handovers nobody recorded. It can rarely be narrowed to what they actually held, because narrowing needs evidence of reading, and reading was mostly not recorded. The operating rule is therefore: treat reachable as held. Arguing that the contractor probably never opened that runbook page is a way of talking yourself into a smaller list without evidence. ## The fix is upstream of the exit interview The uncomfortable part of this exercise is that it is expensive precisely because the cheap moment already passed. Possession became unanswerable eighteen months ago, one handover at a time, and every one of those handovers was a moment when a single line — who received this value, when — would have cost seconds. A departure is simply the first time anybody asks. So the durable output is not the list. It is that the values it surfaced now have rows, and that handing a value to a person becomes something the estate records. What is then done with the list — which values are replaced, in what order and on what schedule — is a separate decision made over these rows by the owners named on them.
- The contractor's identity in the secret store was permitted to read one branch of the name space. Does that bound the list?It bounds the part of the list that went through the store, and that part is the easy part. It says nothing about values handed to them in a channel, a ticket or a pairing session, which is where most of a long-serving contractor's holdings come from. Use it as one input among several.
- Why interview the contractor at all if you assume reachable equals held?Because the interview finds values that reachability missed entirely — something a teammate pasted to them directly, a local file they kept, a value they passed on to a fourth team. It expands the list rather than shrinking it, and it is the only source with a deadline attached.
- The same reconstruction would take two weeks for a permanent employee who has been here six years. Is it still worth doing?Do it at reduced depth on the same structure: enumerate accesses mechanically, map only to values with an existing inventory row, and interview. The exercise scales badly with tenure, which is the argument for recording handovers as they happen rather than reconstructing them later.
saying these in an interview costs you the question
- Answers the question from the store's access record alone.
- Assumes a handover between two people left a record somewhere.
- Skips the interview because the person is leaving anyway.
- Reads only current settings files and not the repository history.
- Narrows the list by arguing the person probably never looked.
- Produces the list and records nothing back into the inventory.