Model Drift and Silent Failure — When the Tool Changes Under You

Start with the shape of the failure, because it determines everything else. When a model degrades, the output does not become unreadable. It becomes marginally less accurate while remaining perfectly presentable. A figure that used to be lifted verbatim from the filing is now paraphrased into something close but not identical. A field that used to say "not stated" now gets a plausible guess. A summary that used to flag the one awkward sentence in the management commentary now smooths over it.

None of that trips an alarm, because there is no alarm to trip. The tool has no notion of correct — it produces text that fits the request, and text that fits the request is exactly what a wrong answer also looks like. The only entity in the system capable of noticing is you, and you are reading the output for its content, not auditing it against a baseline you no longer remember.

That last point is the real trap and it deserves stating plainly: your memory of how good the tool used to be is unreliable, and it drifts in the tool's favour. You remember that it "worked well". You do not remember that eight weeks ago it correctly returned "not stated in the filing" for a field that today it fills in with an invented number. Human recollection is not a baseline. Only a saved artefact is a baseline.

So the entire discipline reduces to one structural move. At a moment when you have verified the output and trust it, freeze a copy. From then on you are never comparing today against a memory; you are comparing today against a document. Everything else in this article is scaffolding around that single idea.

It is tempting to treat "the tool got worse" as one problem. It is three, they have different causes, and the fixes do not transfer. Separating them matters because when you notice a degradation you will want to know which one you are looking at — and the diagnostic question is different in each case.

The first is regime change, and it is the oldest problem in this business rather than anything to do with AI. A relationship that held in the market for a stretch of time stops holding. A screening rule that surfaced useful names during a broad advance surfaces nothing but noise in a long directionless range. A feature that carried information when volatility was elevated carries none when it compresses. The model did not change at all here. The world it was fitted to did. Anything learned from historical data carries an unstated assumption that tomorrow resembles the sample, and markets periodically decline to cooperate.

The second is a provider-side change. Hosted models are updated. Versions are retired, defaults are moved, safety behaviour is adjusted, and routing between variants can change without any announcement that reaches you. You did not upgrade anything; the thing behind your prompt is simply not the same thing it was last month. This is genuinely new relative to how traders are used to thinking about tools — you do not own this dependency, you rent it, and the landlord can renovate.

The third is the data layer, and in practice it is the most common of the three and the least discussed. A source website changes its page structure and your scraper now returns an empty field that a downstream step happily interprets as zero. A feed starts arriving an hour late. A column gets renamed and a join silently drops rows. A corporate action is not adjusted for. The model receives worse input and does what it always does — produces a fluent answer over whatever it was given.

This one is worth sitting with, because it has no analogue in the tools traders are used to. Your charting platform does not quietly replace the maths behind a moving average. Your broker does not silently change what a limit order means. But a hosted model is a service, not a possession, and services are maintained. Versions get deprecated. Defaults get moved to something newer. Behaviour gets adjusted for reasons that have nothing to do with you.

The practical consequence is that a prompt is not a stable instruction. It is a request to a system whose behaviour you do not control, and prompts are more brittle than they feel. A prompt that reliably returned a six-column table can start returning a narrative paragraph with the same information buried in it. A prompt whose "if it is not in the document, write not stated" rule was respected can meet a version more inclined to be helpful, which fills the gap instead. Nothing about that reads as a failure. It reads as a slightly different answer.

A newer version is also not automatically better for your job. Newer usually means better on broad benchmarks, and broad benchmarks are not your workflow. Your workflow is a specific extraction from a specific document type under a specific set of constraints, and a model that is stronger overall can be weaker on exactly that if it has become more verbose, more inclined to add context you asked it not to add, or more willing to infer.

There is no way to prevent this and it is not a scandal — it is the deal. What you can do is detect it fast, and the detection mechanism is the regression prompt in the next section. Beyond that, two habits help: pin an explicit version where the product lets you rather than accepting the default, and keep the number of distinct AI-dependent steps in your process small enough that you can re-verify all of them in one sitting.

Here is the mechanism, and it is deliberately unglamorous. Choose one task you genuinely rely on. Freeze an input for it — a specific filing PDF, a specific transcript, a specific block of text — and save that input file permanently, unchanged, forever. Write a prompt against that fixed input, save the prompt verbatim, and run it once while you are prepared to check the answer properly. Verify every claim in that answer against the source. Then save the verified output, with the date, and label it as the known-good baseline.

From that point you have a regression test. On a schedule, you re-run the identical prompt against the identical input and put the new output beside the saved one. You are not asking "is this answer good?" — a question you will answer generously when you are busy. You are asking "is this the same answer?", which is a comparison rather than a judgement, and comparisons survive tiredness.

Choose the input carefully, because a weak baseline tests nothing. It should contain a few specific numbers that must be reproduced exactly, at least one field that is genuinely absent so you can see whether the honest "not stated" survives, one sentence with hedged or ambiguous language, and enough length that the task is not trivial. A single clean paragraph will pass forever and tell you nothing. Do not use a document that will be revised, and do not use anything confidential — a public exchange filing is the natural choice, and it is public precisely so that keeping a copy is unproblematic.

Differences that show up are not automatically failures. A rephrased sentence with identical substance is fine. What matters is a short list of specific defects: a number that no longer matches the source, an absent field that has acquired a value, a constraint you stated that is no longer being respected, a structural change from table to prose, or new material that is not in the document at all. Any one of those means the tool has moved and your process is currently running on an assumption that expired.

Monitoring fails for boring reasons. It is proposed as a daily discipline, it survives eleven days, and then it quietly stops and nobody notices — which is the same failure mode as the thing it was meant to catch. So design the cadence for the version of you who is busy, not the version writing the plan.

There are two tiers and they do different jobs. The scheduled tier runs whether or not anything seems wrong, because the entire point is that nothing will seem wrong. The triggered tier runs on events that are known to precede a change. Neither replaces the other: scheduled checks catch slow decay, triggered checks catch discrete breaks.

Attach the scheduled check to something that already happens rather than to a date you have to remember. The first weekend of the month, or the session after quarterly results season ends, or the same morning you do your monthly journal review — the anchor matters more than the interval. Fifteen minutes once a month, actually performed, is worth more than a daily routine that lasted a fortnight.

The triggered checks are cheap because they are rare. Re-run the regression prompt when the provider announces anything, when the interface changes, when the response style feels different in a way you cannot name, when you find one error by accident, and when you are about to rely on the output for something that matters more than usual. That last one is the most valuable and the most often skipped — the moment before a decision is exactly when you want to know the tool is still the tool.

The third mechanism deserves its own treatment because people misdiagnose it constantly, and the misdiagnosis is expensive. When a systematic rule stops working, the instinct is to fix the rule — add a filter, retune a threshold, retrain on more recent data. Sometimes that is right. Often the rule is working exactly as designed and the conditions it was designed for have simply gone away.

Anything fitted to historical data carries an assumption that goes unstated because it is uncomfortable: that the future will resemble the sample. Markets do not guarantee that. Liquidity conditions change, participation changes, volatility expands and compresses, sectoral leadership rotates, and the relationships that held through one stretch of NSE history are not promised through the next. A method that met only one kind of market has not been tested against the others — it has merely not encountered them yet.

The practical distinction to draw is between a method that is failing and a method that is out of season. A trend-following approach in a long directionless range is not broken; it is in the environment that hurts it, and that environment will end. The way to tell them apart is not the recent result — it is whether the conditions the method depends on are currently present. If they are present and the method is failing, that is evidence. If they are absent, you have learned nothing about the method and you should not retune it on that evidence.

Which is why the quarterly step above asks about conditions rather than about performance. Write down, in advance and in plain words, what has to be true in the market for your approach to have a chance — the kind of participation, the kind of volatility, the kind of follow-through after a breakout. Then check whether those things were present. A rule you retune every time it underperforms is a rule that is being continuously refitted to the recent past, which is the same overfitting problem described earlier in this module, arriving through a different door.

Everything above collapses without a log, and the log is a plain file rather than a system. Date, what was checked, pass or fail, the specific defect, and what you did about it. That is the whole format, and the discipline is writing the entry on the months when nothing happened, because a run of unremarkable entries is precisely what makes an eventual change stand out.

The log also solves a problem you do not know you have yet. When something eventually goes wrong, the first question is when it started, and without dated entries the honest answer is "some time in the last several months" — which is not enough to work with. With them, you can bracket the change between two dates, which usually points straight at the cause: a product update in that window, a website redesign in that window, a market regime that turned in that window.

Alongside the log, keep a short dependency list: every step in your process that touches AI, what model and version it uses, what data it consumes, when it was last verified, and how bad it would be if it were quietly wrong. Most people discover on writing this that the list is longer than they thought, and that at least one item on it has never been verified at all. That discovery alone repays the exercise.

And keep the ambition modest. This is not a monitoring platform and it should never become one, because an elaborate one will not survive contact with a busy quarter. Two text files and fifteen minutes a month is the whole system. It works because it is small enough to keep doing, and a check you keep doing is the only kind that catches a failure that never announced itself.