Three analysts share a scan. In January it was written by one of them, in March a second widened the universe because it was returning too little, and in May the first one narrowed a threshold back without noticing the March change. By July the desk is comparing this quarter's hit rate against last quarter's and reaching conclusions. Every one of those conclusions is unsound, and nobody in the room knows it, because the artifact they are comparing across has quietly become two different artifacts with one name.
This is not an exotic failure. It is the default outcome of letting a research input live in a tool where editing is easy and history is not kept. Anyone who has run a shared spreadsheet model has seen the same thing. The reason it bites harder with scan definitions is that a spreadsheet at least shows you the formula, whereas a scan silently returns a plausible list either way.
Comparability is the whole reason to bother
It is worth being precise about what the governance is for, because "version control is good practice" will not survive contact with an analyst who is busy.
The reason is that almost everything a desk wants to know about an idea-sourcing channel is a comparison over time. Is the channel producing more or fewer names than it did. Are those names converting to positions at a stable rate. Has the sector mix drifted. Did the change we made in March help. Every one of those questions assumes the thing being measured held still, and a scan definition that drifts makes all of them unanswerable in a way that is invisible from the output.
The second reason is narrower and sharper. When someone asks why a name was surfaced, the answer has to name a version. Pointing at the current definition and saying it was probably close to this is not evidence, especially when the tool lets anyone overwrite it.
A scan needs an owner and a name that does not lie
Two conventions do most of the work here and both are cheap.
The first is a single named owner per scan definition. Not a team, not a desk. A person, whose job is to approve changes and who is answerable if the definition drifts. Shared ownership of a mutable artifact is a well-understood way of producing no ownership at all. The owner does not have to be the most senior person and often should not be, since the useful property is availability rather than authority.
The second is versioned naming. A scan carries a name and a version, and the version increments on every change that could alter the result set. That includes threshold edits, universe edits, wording edits, and filter state, because the filter state is part of the definition even though it lives in a different part of the interface. In Sentinel, the direction, urgency, asset class and market status selections all shape what a run returns, and a version record that captures the request text but not those selections is recording a fragment.
Names should describe the constraint, not the intent. "Quality momentum" is intent and it will mean four things to four people. "US mid cap, twenty day relative strength, borrow available" is a constraint, and when someone edits it into something else the name stops matching and the mismatch is the alarm.
Fork or edit, and the rule that decides
Most of the drift I have seen comes from analysts editing a shared scan when what they wanted was their own. It is an entirely reasonable thing to do in the moment, since editing is one click and forking feels like clutter.
The rule that resolves it is about whose question is being asked. If the change makes the scan better at the job it already had, it is an edit and it goes through the owner. If the change makes it answer a different question, it is a fork and it gets a new name and a new owner, even if the text differs by one clause. An analyst who wants the same scan run on small caps has a new question, not an improvement.
The tell that a fork was needed and an edit was taken instead is a changelog full of reversals. When a threshold goes from thirty to fifty in March and back to thirty in May, two people were using one scan for two purposes and taking turns. That pattern is worth watching for explicitly, because it is the cheapest available signal that your definition inventory is too small for the work the desk is doing.
What belongs in a changelog entry
Four fields, and the discipline is that the entry is written before the change is applied rather than after.
- What changed, as a diff. Old value and new value, not a description. "Tightened the liquidity floor" tells a future reader nothing. The two numbers tell them everything.
- Why, in one sentence tied to evidence. The useful why is almost always an observation about output. Too many names, too few names, a rejection rung firing on eighty percent of results, a sector concentration nobody wanted. A why that reads as a preference rather than an observation is a flag that the change is untested taste.
- Expected effect on the result set. Written down before the run. This is the field that turns changes into experiments, because a change that was expected to cut the list by a third and instead cut it by nine tenths has taught you something about the universe that you would otherwise have shrugged past.
- Comparability break, yes or no. An explicit flag saying whether output before and after this change may be pooled in any analysis. Most changes break comparability. Marking it at the point of change is trivial, and reconstructing it later from a stack of diffs is a miserable afternoon.
Deprecation, because scans never die on their own
The end of the lifecycle gets no attention and causes real damage. Scan definitions accumulate. Nobody deletes one, because deleting feels risky and keeping feels free. Two years in, the desk has forty definitions, nine of which anyone runs, and a new analyst has no way to tell which nine.
Give definitions a review date and a status. Active means someone runs it and the owner stands behind it. Deprecated means it still exists for reconstructing old output but must not be used for new work. Retired means the definition is archived with its history and cannot be run. The archived version stays, because your audit obligations attach to what was used at the time, not to what you currently think is good.
The trigger for review is not a calendar so much as a change in circumstance. The obvious ones are a model version change at the vendor, a change to your mandate or exclusion list, and a change to the underlying data coverage. The less obvious one is a period of inactivity. A definition that has not been run in a quarter is either deprecated in practice or is about to be run by someone who assumes it was maintained, and both of those are worth catching before they turn into a position.
The operational version of this is one line on a schedule. Once a quarter, the owner of each active definition confirms in writing that it is still active and still theirs. Anything that comes back unclaimed is deprecated by default rather than by argument, which is the only way this list ever gets shorter.