The One Person Who Knows Where Everything Is

The distinction that makes this tractable is between what the records hold and what the map holds. The records hold transactions: dated entries, amounts, parties, documents, allocations. The map holds connections: that these two accounts are the same real customer, that this customer's payments always arrive on the twenty-eighth, that this brand name is supplied by one firm who will not answer the phone, that this job lost money and it is not the job everyone assumes.

Those connections are almost all derivable from records, but they are not present in the records. They have to be read out of them, and the reading was done once, by one person, and never written down. This is the ordinary condition of a business that has grown by adding customers rather than by adding process, and it is not a failing of anybody. It is just what happens when the knowledge is stored in a person instead of in a structure.

The moment it becomes a business risk is not the person's leaving. It is the first time somebody else needs the map while the person is present and busy. At that point the business discovers that the answer to a routine question depends on one person's availability, and that is much harder to solve than it would have been a year earlier.

It helps to sort the contents of the map, because the categories behave differently. Some of it is a naming problem. Some of it is a sequence problem. Some of it is an exception list, which is the most valuable and the most fragile part. Some of it is a set of relationships between records that exist separately. And some of it is judgement, which is not knowledge and cannot be captured as a rule.

Naming is the cheapest to fix and the most commonly mistaken for a crisis. A business can end up with three customer records for one customer because the counter typed one spelling, the phone team typed another, and the accountant typed a third. The map-holder knows they are the same and the system does not. This is an identity problem rather than a data-entry problem, and it will not be solved by telling people to type more carefully, because the spelling each of them uses is the one they hear.

Sequence is the second category. The map knows what normally happens next: after this job is delivered, this invoice goes out, then this follow-up happens, then this person is paid. None of that is stored as a dependency; it is stored as a habit. When the person is away, the sequence does not run, and nothing in the records flags its absence, because a missing step and a slow week look identical from the data.

Notice what the example does not claim. It does not claim the business was badly run, or that the map-holder was indispensable, or that software would have prevented the whole thing. It claims something narrower and more useful: a specific question had exactly one possible answer, and that answer was not in the records. Everything else about this failure is ordinary.

This is also why the standard advice, write it down, lands badly. Written-down knowledge that nobody reads is a document, and a document does not answer a question at four in the afternoon while the phone is ringing. The map only becomes a record when the answer is attached to the thing somebody is about to do.

The temptation is to treat this as a documentation project with a timeline, a phase and a deliverable. That is the wrong shape, and it fails for a boring reason: the map-holder is the only person who can extract the map, and they will only extract it for questions that are actually being asked. A documentation phase asks for the whole map at once, which is a month of unstructured recall nobody has ever enjoyed.

The shape that works is to attach the map to a record that already exists and already gets opened. Someone asks which of two accounts to invoice. The answer gets written onto the record, in the field that person will read next time, with the reason. Someone asks why a total did not match. The explanation gets attached to the adjustment or the reconciliation, where a later reader will hit the same discrepancy. The map does not get extracted. It gets laid down one answer at a time, next to the record that needed it.

Duplicate customer records are the fastest case, because the merge is a real decision somebody already knows how to make. Detection flags candidates, a person reviews them, and nothing merges automatically; match rules and merge behaviour are a setup decision, not something that happens on its own. The map-holder's contribution is not the merge, it is the sentence explaining why these three records are one customer, and that sentence is the part that has to survive.

Honesty here is worth more than completeness. Some of the map is not a missing field; it is judgement built from years of being slightly wrong. How hard to chase a customer who has paid late before. Whether this job is worth taking. Which of two suppliers will actually deliver what was promised. None of that can be captured as a rule that a system will apply correctly, and pretending otherwise produces a process that sounds rigorous and gets bypassed within a month.

What can be done with judgement is to record that it was exercised, by whom, and on what. A note attached to a decision is not a rule, and it should not be presented as one. It is a trace: it tells the next person that this was a judgement call rather than a default, which is exactly the distinction that gets lost when the person who made it is not in the room.

The same applies to relationships. The fact that one supplier is honest and another is not is a real and important piece of knowledge, and it is not a record either. What a record can hold is that the decision was made on that basis, so that a later reader is not surprised when the choice is repeated.

The honest way to describe this work is that it is small, continuous and mostly undocumented, and that no product can do it for you. There is no onboarding team at NoxOrigin, no implementation project, no change-management programme, no training course and no data-cleaning service, and no dedicated support tier beyond the documented platform support. Migration is scoped work when it is done with you, and it is still your people deciding what is true.

What the platform does is narrow and worth stating precisely. It stores events with dates, named people and the values involved. It links records so that a connection is held once instead of in somebody's memory. It does not decide whether two records are the same party, and it will not tell you which of your customers pays on time. Those are answers somebody in your business already has, and the work is putting them where the record can use them.

If the map-holder is leaving rather than merely away, the same five questions are the right order to work through, starting with grouping, because a wrong merge is much harder to unpick than a missing note. And the first week of using any new system is where habits are set; What to Do in the First Week with a New System covers that week specifically.

The test of whether this is working is not whether the documentation is complete. It is whether the business can answer a routine question on a day when the person who usually answers it is not available. If it can, the map has become a record. If it cannot, the map is still a person, and the risk has not changed shape, only its deadline.

For the closely related failure where a second set of records quietly takes over from the first, see The Two Sources of Truth. For the identity problem underneath a lot of this, see One Customer, Two Records: The Identity Problem.