A Canadian finance function validates an AI-assisted workflow, documents the testing, records the control in its framework, and moves on. Six months later the framework still describes a system that was tested in March. The question this article asks is whether anything about the system in March is still true, and the answer is that nobody in the organisation knows, because the thing that changed did not belong to them.
Key Takeaway
Model drift is the degradation of a deployed system's performance as conditions move away from those it was validated under. The 2026 complication is that most teams no longer train their own models: weights do not drift on their own, but providers ship silent updates, retrieval indexes get re-embedded, prompts get tuned and tool schemas evolve, so drift has become a system-level property rather than a model-internal one. The model an application was tested against in one month may not be the one answering requests the next. Practitioner guidance reports a peer-reviewed study finding temporal degradation in 91% of models tested, though we have not verified that against the original. Failures rarely look like outages; they look like quiet degradation, which is precisely the failure a complacent human reviewer is least likely to catch. Population Stability Index thresholds of 0.1 and 0.2 are heuristics borrowed from credit risk modelling that require per-feature calibration, and retraining on drift signal that does not correlate with a measured performance drop wastes compute and can degrade calibration.
A Note On Sources
We should be direct about the evidence base for this article, because it differs from the previous two in this series.
Automation bias rests on four decades of peer-reviewed human factors research. Benchmark contamination rests on a large academic preprint literature. Production drift monitoring for language model systems has, at the time of writing, comparatively little peer-reviewed literature and a large body of practitioner and vendor content.
Almost every source cited here is a commercial blog published by a company selling observability, evaluation or governance tooling. That does not make the content wrong, and practitioners running these systems are genuinely the people who know how they fail. It does mean the material is written by parties with an interest in organisations concluding that they need monitoring products, and readers should weigh it accordingly.
One peer-reviewed figure appears below, reported at second hand, and we flag it as unverified. Where we describe something as established, we mean established in practitioner consensus rather than demonstrated in the literature, and we have tried to mark the distinction throughout.
The Inversion
The structural change that makes classical drift thinking inadequate, and it is the organising point of this article.
Practitioner guidance states it precisely: the 2026 wrinkle is that most teams are no longer training their own models, and while model weights do not drift on their own, model providers ship silent updates, retrieval indexes get re-embedded, prompts get tuned, and tool schemas evolve. Every one of those changes can shift end-to-end behaviour in the same way a classical model retraining could, which is why production teams now treat drift as a system-level metric rather than a model-internal one[1].
Consider what classical drift theory assumed. An organisation trained a model on data it held, deployed it, and monitored for the world moving away from the training distribution. The model was a fixed artefact; the environment was the variable.
The current arrangement inverts one half of that. A Canadian finance function using an AI capability is typically consuming a model it did not train, cannot inspect, and does not control the version of. The model is now also a variable, and it varies according to decisions made by a vendor for reasons that have nothing to do with the customer's workflow.
Another source puts the consequence in one sentence: the model your application was tested against in March may not be the one answering requests in April[2].
That sentence is the whole governance problem. Every validation, every test result, every control sign-off describes a system configuration. If the configuration can change without notice, the evidence has an expiry date the organisation does not know and cannot set.
The Classical Taxonomy
The vocabulary, which remains useful even where it is incomplete.
Data drift occurs when the statistical properties of input data change over time, causing a system to encounter phrases, terms or structures it was not originally trained on, resulting from shifts in user behaviour, emerging terminology or evolving industry-specific language; model drift refers to the gradual degradation of a model's predictive power[3].
Model drift in traditional machine learning refers to the statistical divergence between the data a model was trained on and the data it encounters at inference time, with covariate shift, prior probability shift and concept drift as the canonical categories, detected by tracking feature distributions, monitoring prediction confidence, and comparing outputs against a ground truth baseline[2].
Three warning signs are offered: accuracy decay without a data change, input data diverging from training data, and predictions skewing toward one outcome[4].
The distinction worth carrying forward is between the inputs changing and the relationship changing. If the population of documents your system processes shifts, that is data drift and may be detectable by watching the inputs. If what counts as a correct answer changes, because a rule changed, a policy changed or a standard was amended, that is concept drift and watching the inputs will not reveal it.
Canadian finance work is unusually exposed to the second kind, and this is our own observation. Tax rates change annually, thresholds are indexed, standards are amended, and regulatory guidance is reissued. A system that was correct in one year can be systematically wrong in the next without a single input distribution moving, because the world's answer key was reissued.
The Modes That Do Not Fit
The failure types that the classical categories do not capture.
One source identifies drift modes that do not map neatly onto the traditional categories. Semantic drift occurs when the meaning of the vector embeddings produced by an embedding layer, or the embeddings generated for retrieval, begin to shift relative to the space the system was built against. Behavioral drift describes changes in the statistical distribution of outputs even when inputs have not fundamentally changed. Performance drift is the degradation of task-specific quality over time[2].
Another source lists the mechanisms by which generative pipelines drift differently: through prompts, knowledge staleness, upstream model updates, and retrieval corpora[4].
Semantic drift deserves particular attention for finance functions using retrieval over their own documents, which is the dominant architecture for internal knowledge tools. If the embedding model changes, or the index is rebuilt with different parameters, the geometry of the retrieval space changes. Queries that previously surfaced the right document may surface a different one, with no error, no alert and no visible failure.
Behavioral drift is the mode most relevant to the silent-update problem below, because it captures the case where nothing in the organisation's own environment changed at all.
The Silent Update
The specific mechanism that most Canadian finance functions have no process for.
If you use an API provider, the underlying model may be updated silently[2]. The same guidance notes that a typical stack runs a named commercial or open-source model behind a gateway, and that provider updates sit alongside re-embedded indexes, tuned prompts and evolving tool schemas as sources of end-to-end behavioural change[1].
Three observations follow, and the second and third are our own analysis.
The change originates outside the organisation's change management. A finance function has a process for its own system changes: request, test, approve, deploy, document. A provider update passes through none of it and generates no artefact in the organisation's records.
The change is not necessarily a degradation. A provider updating a model is usually improving it on aggregate measures. But an aggregate improvement can decompose into gains on tasks the organisation does not perform and losses on tasks it does, which is the same decomposition problem this publication has described in relation to hallucination mitigations. Improvement in general is not improvement for you.
And the change invalidates the evidence rather than merely the performance. Even where behaviour is unchanged, the organisation can no longer honestly assert that the system in production is the system it tested, because it has no way to establish that.
The practical mitigations available to a buyer are limited but real: version pinning where the provider offers it, contractual notice of model changes, and a regression test suite that runs on a schedule rather than only at deployment. The last of these is the one that works regardless of what the provider offers, and it is the recommendation this article returns to.
Drift Without Any Model Change
A source of behavioural change that is entirely internal and frequently undocumented.
Output distribution is directly controlled by sampling parameters, and drift can occur without any model change if inference configurations are modified[2]. The same source notes that systems are remarkably sensitive to prompt phrasing, so small changes in how users phrase queries, or changes in system prompt templates, can shift which mode the model operates in[2].
This matters because prompts and configuration parameters are usually not under change control in a finance function. A model version is recognisably a system component. A prompt template feels like content, and a temperature setting feels like a preference, so both are commonly edited by whoever is closest to the workflow without a record.
The consequence is a system whose behaviour can change materially through edits that leave no trace, made by people acting entirely reasonably, in a component nobody classified as controlled.
Our recommendation, offered as analysis, is that prompt templates and inference parameters should sit under the same version control as code, with changes recorded and the regression suite re-run. This is inexpensive and it converts an invisible source of drift into a logged one.
Failures Look Like Quiet Degradation
The characteristic that determines what a monitoring programme has to be designed to catch.
Most failures in production do not look like dramatic outages. They look like quiet degradation: a fraud model that approves slightly more bad transactions, a classifier that routes slightly more tickets to the wrong queue, a ranking model that slowly erodes conversion, or an assistant that becomes less helpful as product and policy content changes[5].
Guidance elsewhere adds that embedding-based metrics catch what statistical tests miss, being semantic degradation that looks grammatically perfect but is factually compromised[6].
Connect this to the human factors argument this publication has set out separately. Automation complacency and automation bias produce reviewers who accept outputs that appear normal. A system failing loudly, producing obvious nonsense, is caught by any reviewer. A system producing slightly-worse-but-plausible output is precisely the failure the human control is least equipped to detect.
So the two problems compound rather than offset. The most likely failure mode is the one the primary control is worst at catching, which is an argument for instrumented monitoring rather than reliance on people noticing.
The scale of the exposure is worth noting. Practitioner guidance reports a peer-reviewed study finding temporal degradation in 91% of models tested[4]. We have not accessed that study and cannot vouch for the figure, its methodology or the population of models it covers, and we cite it only to indicate that the practitioner consensus treats degradation as normal rather than exceptional. The same source frames it as drift being the norm, not the exception[4].
Drift Without Loss, Loss Without Drift
The finding that determines the architecture of a monitoring programme.
A model can drift without obvious performance loss, described as benign drift, and performance can drop without obvious drift metrics, through silent concept drift or a pipeline bug. That is why a reliable setup is layered: data quality, then drift signals, then performance signals, then a response playbook[5].
Both halves matter and they cut in opposite directions.
Drift without loss means input distribution alarms will fire on changes that do not harm anything. An organisation that treats every drift signal as an incident will generate false alarms, and false alarms drive detection systems into disuse, which is the mechanism this publication has described in the human factors context.
Loss without drift means input monitoring alone will miss real failures. If the correct answer changed, or a pipeline stage broke, the inputs can look identical while the outputs are wrong.
The layered architecture follows directly. Input monitoring is necessary and insufficient. It must be paired with outcome measurement, and the two must be read together, because it is the correlation between them rather than either alone that identifies a problem worth acting on.
Drift Is Not Hallucination
A diagnostic distinction that determines whether a remediation effort is aimed at the right thing.
Guidance states it directly: misidentifying drift as hallucination, or the reverse, sends engineering teams down the wrong remediation path entirely. Hallucination is a stochastic event, in which the model confidently invents a fact it was never taught, independent of time or distribution. Model drift represents the internal degradation of a model's reasoning capabilities due to infrastructure shifts, updated library versions, or slight tuning changes in proprietary APIs. By identifying whether a failure is caused by an external change in data or an internal shift in the model, teams can decide whether to update the input pipeline or trigger a retraining cycle. A clear taxonomy is the foundation, and misclassifying the drift type wastes engineering cycles and delays remediation[6].
The operational test that separates them, offered as our own analysis, is temporal correlation. Hallucination is described as independent of time or distribution, so a hallucination rate should be roughly stable across periods on a stable task. Drift is by definition temporal, so its signature is an error rate that moves with time.
That produces a practical diagnostic any finance function can run without specialist tooling. Hold a fixed test set, run it monthly, and plot the error rate. A flat line with scatter is a stochastic error process. A trend, or a step change, is drift, and a step change in particular points at a discrete event such as a provider update, an index rebuild or a prompt edit.
Without that time series, the two failure modes are indistinguishable from inside an organisation, and the remediation chosen will be a guess.
PSI And Its Limits
The metric most familiar to a finance audience, and the caution that accompanies it.
Guidance sets out conventional thresholds: a Population Stability Index below 0.1 is generally treated as no significant shift, 0.1 to 0.2 as moderate drift worth investigating, and above 0.2 as significant drift that warrants action. But it immediately qualifies them: these thresholds are heuristics from credit-risk modeling and should be calibrated per feature, since high-cardinality categorical columns and long-tailed numerics can produce noisy PSI even on stable distributions[1].
The credit risk provenance is worth dwelling on for this audience, because many Canadian finance and risk professionals encountered PSI in scorecard monitoring and carry the 0.1 and 0.2 thresholds as settled knowledge.
They are conventions, not statistical results. They were adopted in a context of relatively low-dimensional, well-understood features, and transplanting them to the feature space of a document processing pipeline imports the convention without the context that made it reasonable.
The specific failure mode named, that high-cardinality categorical columns and long-tailed numerics produce noisy PSI on stable distributions, describes a lot of finance data. Supplier names, account codes and transaction descriptions are high-cardinality categoricals. Transaction amounts are long-tailed. A monitoring programme applying default thresholds to such features will generate alerts on stable data.
A broader metric set is available, including KS, Wasserstein, JS and KL divergences, and chi-square[5], each with its own sensitivities.
Where Statistical Tests Run Out
The methodological shift practitioners describe, reported with appropriate scepticism about its source.
Traditional data science relies on the Kolmogorov-Smirnov test or the Population Stability Index, and while these are excellent for numerical tabular data, they struggle with the high-dimensional embedding spaces of generative AI; the claim is that in 2026 semantic detection has overtaken statistical sampling[6].
The proposed alternative measures the distance of a new production output from the dense core of the model's baseline logic, so that an output landing in a low-density region signals a high probability of drift even if grammar and tone remain flawless, with detection described as possible within sub-200 millisecond windows for high-throughput systems[6].
We report this with reservations. The source is a commercial blog, the claim that semantic detection has overtaken statistical sampling is an assertion rather than a demonstrated result, and the latency figure is a product characteristic rather than a research finding.
The underlying observation nevertheless seems sound and is worth extracting from its marketing frame: statistics designed for low-dimensional tabular features do not straightforwardly transfer to high-dimensional embeddings, and a monitoring approach for a text workflow that only watches tabular metadata is watching the wrong space.
What To Measure In An LLM Workflow
The concrete signal set practitioners report using.
In language model and agent systems the equivalents of classical accuracy metrics are faithfulness, groundedness, task success, tool-call accuracy and downstream conversion[1]. Teams track embedding drift on inputs and retrieval results, prompt structural drift, output quality with online evaluators such as faithfulness and groundedness, and tool-call distribution shifts, with platforms computing these signals on each trace and triggering evaluation gates when drift correlates with evaluation score drops[1]. The most powerful detection layer is described as using a reference-grade model to evaluate the outputs of the production model[2].
Two translations for a Canadian finance function.
Faithfulness and groundedness are the same properties this publication has described in the hallucination measurement context, which means a firm that has built an evaluation set for one purpose already has the instrument for the other. Drift monitoring and quality evaluation are the same measurement performed on a schedule rather than once.
And using a model to evaluate a model imports the circularity described in that earlier article, where the judge is itself a language model that can return the wrong verdict and requires calibration against human labels. That caution applies with equal force here, and more so, because a judge model is also subject to silent provider updates. A drift detector that drifts is a difficult thing to reason about.
Retraining On Noise
The discipline that separates a monitoring programme from a treadmill.
Guidance is explicit: monitor continuously and retrain when drift is correlated with a measurable drop in evaluation or business metrics, because retraining on noise wastes compute and can degrade calibration[1]. The management framing offered elsewhere is a continuous cycle of detect, diagnose and retrain rather than a one-off fix[4].
The conditional is the important part. The trigger is not a drift signal; it is a drift signal that correlates with a measured performance drop. That follows directly from benign drift being real: inputs can move without harm, and responding to every movement is both wasteful and, per the warning about calibration, potentially harmful.
For a finance function that does not retrain models, the analogous actions are re-tuning prompts, rebuilding a retrieval index, changing model version, or adjusting routing thresholds. Each is a change to a validated system and each therefore requires its own validation, which means the cost of responding to a drift signal is not only the change but the re-testing.
The under-appreciated risk is churn. A team that adjusts prompts every time a metric wobbles produces a system whose configuration is never stable long enough to be characterised, and it will have no reliable baseline against which to detect the next real change. Stability has evidentiary value, and changing things in response to noise destroys it.
The Layered Setup
The architecture, which follows from the two-sided gap above.
The recommended structure is layered: data quality, then drift signals, then performance signals, then a response playbook[5]. Guidance frames drift monitoring as a reliability practice, to be treated the way site reliability engineering treats latency and error budgets, with dashboards, action-oriented alert thresholds and a response runbook tied to business impact[5].
The layers do different jobs and fail differently.
Data quality catches pipeline breakage, which is the cause of loss-without-drift and is both the most common and the most fixable failure. Missing fields, encoding changes, truncated documents and upstream schema changes belong here.
Drift signals catch input movement, and their weakness is benign drift generating alerts on harmless change.
Performance signals catch outcome degradation and are the only layer that measures what actually matters, but they require ground truth, which is why the private evaluation set described in the contamination article is the load-bearing asset.
The response playbook converts a signal into a decision. Without it, a monitoring dashboard produces information nobody is authorised to act on, which is a common and expensive outcome.
The action-oriented threshold point deserves emphasis. An alert that does not correspond to a defined action is an alert that will eventually be ignored, and the base rate mechanism described in the human factors article predicts exactly that trajectory.
The Governance Gap
Bringing the argument back to what a control framework actually asserts. This section is our own analysis.
A validation record says a system was tested on a date and performed to a standard. In a world of silent provider updates, re-embedded indexes and unversioned prompts, that record supports a narrower claim than it appears to: it establishes what a configuration did on a date, not what the current configuration does.
Three consequences for a Canadian finance function.
Point-in-time validation is not sufficient evidence of ongoing control effectiveness for a system whose components can change without notice. The evidence needs a recurring component, which is a scheduled regression run rather than a deployment gate.
The change management framework needs to acknowledge changes it does not authorise. Most frameworks enumerate changes the organisation makes. This one has to account for changes made to it, which is an unusual category and one that existing templates generally lack.
And the system inventory needs to record configuration, not just capability. Which model version, which embedding model, which index build, which prompt version, which sampling parameters. Without that, the organisation cannot say what changed when performance moved, which is the diagnostic question the whole taxonomy above exists to answer.
The Canadian Regulatory Overlay
Where this intersects with obligations, noted briefly and with care.
Practitioner guidance observes that under the EU AI Act, continuous monitoring of high-risk AI systems is becoming a compliance obligation[4].
We report that as the source states it and have not verified it against the legislation, and it concerns a jurisdiction outside Canada.
The Canadian position is different and this publication has examined it separately in the context of OSFI's model risk guidance, which applies to federally regulated financial institutions rather than to businesses generally. Most Canadian businesses deploying AI in finance workflows are not subject to a prescriptive continuous monitoring obligation.
The reason to note the direction of travel anyway is that regulatory expectations tend to propagate into commercial expectations. A firm's customers, lenders, insurers and auditors may ask about ongoing monitoring before any regulator does, and an organisation that can demonstrate a scheduled regression programme is answering a question that is likely to be asked more often rather than less.
A Worked Case: The April That Was Not March
A Canadian firm using an AI workflow to extract terms from client agreements. The reconstruction illustrates the mechanisms rather than reporting a specific engagement.
In March the firm tests the workflow on eighty representative agreements, measures extraction accuracy, documents the result and records the control. Performance is acceptable and the workflow goes live.
In April the provider ships a model update. Nothing in the firm's environment changed, no ticket was raised, and no artefact exists in the firm's records. On the guidance above, the model answering requests may not be the model that was tested[2].
In May a team member improves the system prompt, reasonably and without a record, because a prompt template is not classified as a controlled component. Small changes in system prompt templates can shift which mode the model operates in[2].
In June the retrieval index is rebuilt to include a new document set, changing the embedding space[2].
By July, extraction is slightly worse. Not obviously wrong, not producing errors anyone reports, just occasionally missing a clause. That is quiet degradation[5], and it is the failure human review is least likely to catch.
The firm cannot diagnose it, because it has three candidate causes, no time series, and no record of when each change occurred. Had it re-run the March test set monthly and logged configuration, the step change would have identified both the timing and, by elimination, the cause.
What To Do
Keep the validation set and re-run it on a schedule. Monthly is a reasonable default. This is the single highest-value control here and it requires no tooling beyond what validation already produced.
Plot the error rate over time. Scatter around a flat line is stochastic error; a trend or step change is drift, and a step change points at a discrete event.
Log configuration, not just capability. Model version, embedding model, index build, prompt version, sampling parameters, with dates.
Put prompts and inference parameters under version control. Drift can occur through configuration change alone, and these components are usually uncontrolled.
Ask providers about version pinning and change notice. Then design assuming you may not get either.
Build the layered stack. Data quality, drift signals, performance signals, response playbook. Input monitoring alone misses loss without drift.
Calibrate thresholds to your features. PSI conventions of 0.1 and 0.2 are credit-risk heuristics, and high-cardinality categoricals and long-tailed numerics are common in finance data and produce noisy readings.
Gate action on correlated performance drops. Retraining or re-tuning on noise wastes effort and can degrade calibration, and it destroys the stable baseline you need to detect the next real change.
Attach an action to every alert. Alerts without defined responses become ignored alerts.
The Limits Of This Analysis
Several caveats matter and the evidence base is the main one. Almost every source cited here is a commercial blog published by a vendor of observability, evaluation or governance tooling, and all have an interest in organisations concluding they need such tooling; none is peer reviewed. The one peer-reviewed figure, the reported finding of temporal degradation in 91% of models tested, reaches us at second hand through such a source and we have not accessed the study, its methodology or the population it covers. The claim that semantic detection has overtaken statistical sampling, and the sub-200 millisecond detection figure, are vendor assertions rather than demonstrated results. Model and version names appearing in sources are reported as stated and not verified. The EU AI Act characterisation is reported from a secondary source and not checked against the legislation; readers in Canada should note it concerns another jurisdiction. The Canadian concept-drift observation about annually changing tax and accounting rules, the temporal diagnostic for separating drift from hallucination, the governance gap analysis, the churn argument and the worked case are our own analysis rather than findings in the cited material. This article does not address retrieval architecture, evaluation set construction, statistical power in monitoring, incident response procedure, or OSFI's model risk requirements in any detail, several of which this publication treats separately. Nothing here is a substitute for advice on monitoring design in a specific environment.
Frequently Asked Questions
What has changed about model drift?
Why does that matter for my control framework?
How do I tell drift from hallucination?
Can I just monitor my input data?
Are the standard PSI thresholds reliable?
Should I act on every drift signal?
References
- Future AGI. (2026, May 14). Model Drift vs Data Drift in 2026: Detection and Mitigation Guide, on drift as a system-level metric given provider updates, re-embedded indexes, tuned prompts and evolving tool schemas; the LLM signal set of faithfulness, groundedness, task success, tool-call accuracy and downstream conversion; PSI thresholds and the caution that they are credit-risk heuristics requiring per-feature calibration; and retraining only where drift correlates with a measurable drop. Note: published by a vendor of AI observability tooling. futureagi.com/blog/model-vs-data-drift-how-to-identify-and-handle-it
- Stackpulsar. (2026, April 11). LLM Model Drift Detection 2026: Monitoring AI Degradation, on the classical categories and their detection, semantic, behavioral and performance drift, silent upstream model updates and the March to April framing, prompt sensitivity, sampling parameter changes producing drift without model change, and reference-grade model evaluation of production outputs. Note: published by a vendor of monitoring tooling. stackpulsar.com/blog/llm-model-drift-detection
- Orq.ai. (2025, February 26). Understanding Model Drift and Data Drift in LLMs, on the distinction between data drift as changing input distributions and model drift as degrading predictive power, and on shifts in user behaviour and evolving terminology as sources. Note: published by an LLM operations vendor. orq.ai/blog/model-vs-data-drift
- Lumenova AI. (2026, July). Model Drift vs. Concept Drift: Detection and Mitigation for 2026, on drift as the norm rather than the exception and the reported peer-reviewed finding of temporal degradation in 91% of models tested, the three warning signs, generative pipelines drifting through prompts, knowledge staleness, upstream updates and retrieval corpora, the detect-diagnose-retrain cycle, and the EU AI Act monitoring characterisation. Note: published by an AI governance vendor; the 91% figure is reported at second hand and we did not access the underlying study. lumenova.ai/blog/model-drift-concept-drift-introduction
- All Days Tech. (2026, January 2). Model Drift in Production: Detection, Monitoring and Response Runbook, on failures as quiet degradation with the fraud and routing examples, the metric set including PSI, KS, Wasserstein, JS/KL and chi-square, benign drift and silent concept drift, the layered data quality to response playbook structure, and treating monitoring as a reliability practice with action-oriented thresholds. Note: a practitioner guide published on a commercial site. alldaystech.com/guides/artificial-intelligence/model-drift-detection-monitoring-response
- Lines n Circles. (2026, June 7). The 2026 Guide to LLM Drift Detection: Monitoring Semantic Degradation, on the drift versus hallucination taxonomy and the cost of misclassification, model drift from infrastructure shifts and proprietary API tuning changes, core-distance from a baseline density and low-density outputs signalling drift despite flawless grammar, the claimed limits of KS and PSI in high-dimensional embedding spaces, and the sub-200 millisecond detection claim. Note: published by a commercial consultancy; the semantic-detection and latency claims are assertions rather than demonstrated results. linesncircles.com/Blog/Enterprise/LLM_drift_detection
This article discusses production monitoring practice and is provided for general informational purposes. Its sources are practitioner and vendor publications rather than peer-reviewed literature, and all cited vendors sell related tooling. The one peer-reviewed figure referenced is reported at second hand and unverified. Nothing here is a substitute for advice on monitoring design in a specific environment.