--- title: "Four Copies of the Same Lookup Rule Hid Behind One Broken Feature" canonical: https://dxdev.com/everyday-ai/four-answers-to-one-question/ datePublished: 2026-03-01 --- The event pointed to the wrong category, and we had just watched its link disappear after it was added. This was supposed to be ordinary work. An event belongs to a category. Connect the two, and the connection should stay put. Instead, the result changed depending on which part of the feature someone used. Sometimes the link vanished. Sometimes it pointed somewhere it should not. Sometimes the system refused to make the connection because it said one already existed. That last answer was the maddening one. A link could appear to be there, yet another part of the same feature would insist it was not. Or the system would say the link already existed while the part that removes links could not find it. Nothing about that feels trustworthy when you are the person trying to use the feature. ## Reading each piece alone got us nowhere At first we treated the strange results as separate problems. We read the instructions behind the event page. Then we read the part that makes a link, the part that removes one, and the part that checks for a duplicate. Each little piece looked sensible on its own. It cost an afternoon, plus the kind of patience that disappears when a simple task changes its story every time you try it. The real question was much smaller: what name should this event use when the system needs to find it again? There were two possible answers. Most of the time the event used a username. In some cases, when there was an organization name, it was supposed to use that instead. That rule had been copied into **four** different places. One place used the full rule. It chose the organization name when that applied, otherwise the username. Another place used only the username. The other two had their own versions. All four were trying to answer the same question, and nothing guaranteed they would give the same answer. A **resolver** is the technical name for a small named rule that answers one repeated question. In plain English, it is one label maker instead of four people writing labels from memory. ## Why the behavior looked random That difference explains the confusing behavior. The linking step could file the event under the organization name. The duplicate check could look only under the username and decide nothing was there. The removal step could look in the wrong place too. Each step could be doing exactly what its own instructions said while the whole feature was still wrong. We finally saw the shape of the problem in the change itself. Four nearly identical lines of instructions had to change at once. Their outer shape matched, but each had a slightly different way of choosing the event's identity. It was like finding four handwritten notes about where the spare house key lives. One says under the flowerpot, one says by the back door, and one says the key is already gone. No single note is the bad one. The problem is that there are four notes. ## One place to decide The repair was pleasantly boring. The choice moved into one small named place. It applied the organization name or username rule once, and every part of the feature used that same answer. The page lookup, the link, the removal, and the duplicate check all stopped making up their own version of the rule. After that, the four paths could not disagree about where the event belonged. If the rule ever needs to change, there is one place to change it. If the rule is wrong, it will be wrong in one visible place instead of in one hidden corner out of four. That is much easier to find and repair. We used to think repeated instructions were mainly a future housekeeping problem. Four copies mean four things to remember when something changes. That is true, but it is not the whole problem. When the repeated instruction answers a question like "Which one is this?" or "Does this already exist?", the copies are competing answers in the present. The feature is already capable of contradicting itself. This does not mean every repeated sentence needs a grand new system around it. A grocery list can say "milk" twice without causing harm. The warning sign is more specific: a value that gets worked out in more than one place, especially when different actions all depend on it. Creating a record, finding it, removing it, and checking whether it exists should not each be allowed to decide what "it" means. Pick one process in your own business that has a name, number, or status written down in several places, such as a customer number on a form, a price in two spreadsheets, or a label used by more than one step. Ask who gets to give this thing its name. If the answer is several places, depending on what you are doing, put the rule in one named place before the copies start contradicting each other.