Deployment, MLOps and Model Governance

Introduction

A predictive model becomes valuable only when it operates reliably in the environment where decisions are made. Training a model in R is therefore only one stage of the data-science lifecycle. Deployment involves exposing a model to applications, analysts, or automated decision systems. MLOps extends software engineering and DevOps practices to machine-learning systems, whose behavior depends not only on code but also on data, features, parameters, infrastructure, and changing operating conditions. Model governance provides the controls that make model use accountable, traceable, secure, and compliant.

In production, a model may fail even when its validation accuracy was high. Input schemas can change, upstream data can become unavailable, class proportions can shift, prediction latency can exceed service limits, or the relationship between predictors and outcomes can change. Consequently, professional model delivery requires reproducible builds, version control, testing, observability, controlled releases, incident management, retraining policies, and documented responsibility.

This chapter presents an integrated framework for operationalizing models developed with R. It addresses APIs and applications, deployment architectures, automation, monitoring, drift detection, retraining, governance, security, reliability, and technical debt.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish batch, real-time, streaming, and embedded model deployment.

2. Design an R-based prediction service and explain its operational requirements.

3. Apply versioning, reproducibility, testing, CI/CD, and controlled release practices.

4. Select meaningful performance, data-quality, drift, reliability, and fairness metrics.

5. Design retraining and rollback policies using explicit decision rules.

6. Evaluate model risk, documentation, security, privacy, compliance, and technical debt.

7. Propose a governed end-to-end MLOps lifecycle for a production use case.

1. From Model Development to Production Service

A machine-learning system has at least four coupled artifacts:

• Code: data preparation, feature engineering, model training, scoring, and monitoring logic.
• Data: training data, reference data, production inputs, labels, and metadata.
• Model object: learned parameters, feature definitions, preprocessing transformations, and dependencies.
• Runtime environment: R version, packages, operating system, hardware, network, secrets, and configuration.

Saving only an R model object is insufficient. A model may depend on factor levels, imputation rules, scaling parameters, column order, or package behavior. A production release should therefore identify the exact code revision, data snapshot or data query, feature schema, model artifact, dependency lockfile, configuration, and approval record.

A useful distinction is between offline validation and operational validation. Offline validation asks whether a model generalizes to a test sample. Operational validation asks whether it can receive valid inputs, respond within service-level objectives, survive dependency failures, protect sensitive information, produce auditable predictions, and remain accurate after deployment.

Deployment patterns

Batch scoring applies a model periodically to a known dataset. It is appropriate for monthly credit-risk reports, daily demand forecasts, or overnight customer segmentation. Batch systems simplify latency requirements but require reliable scheduling, data completeness checks, and reconciliation of outputs.

Online synchronous scoring exposes a prediction endpoint that responds to a request. It is used for fraud screening, recommendations, or real-time eligibility decisions. It requires low latency, concurrency management, authentication, input validation, and high availability.

Asynchronous scoring accepts a request, places it on a queue, and returns a job identifier. Results are retrieved later or delivered through an event. This pattern is useful for computationally expensive scoring and avoids forcing the client to maintain a long connection.

Streaming scoring consumes events continuously and produces predictions as events arrive. It requires ordering, duplicate handling, event-time semantics, state management, and careful treatment of late or missing events.

Embedded or edge scoring packages a model into an application or device. It reduces network dependence but makes updating, resource constraints, security, and consistency more difficult.

The correct choice depends on decision latency, data freshness, volume, cost, availability, privacy, and the consequences of delayed or incorrect predictions.

2. Serving Models with R

A prediction service typically contains five layers:

1. Interface layer: receives HTTP or message requests.

2. Validation layer: checks authentication, schema, ranges, missingness, and permitted categories.

3. Feature layer: applies the same transformations used during training.

4. Inference layer: loads the approved model and generates predictions.

5. Response and observability layer: returns a controlled response and records metrics, traces, and non-sensitive audit information.

R models can be served through frameworks such as `plumber`, deployed through Shiny applications, or integrated into platforms that support containerized R services. A minimal conceptual `plumber` endpoint is:

```r

#* Predict risk

#* @post /predict

function(req, res) {

x <- jsonlite::fromJSON(req$postBody)

validate_input(x)

newdata <- build_features(x)

p <- predict(model, newdata = newdata, type = "response")

list(probability = unname(p))

}

```

This fragment is illustrative rather than production-ready. A production implementation must define `validate_input`, handle malformed JSON and missing fields, avoid exposing stack traces, apply authentication and authorization, load a known artifact, and record a correlation identifier. It should also distinguish client errors, such as invalid input, from server errors, such as a failed model load.

Training-serving consistency

A major source of failure is training-serving skew: the feature computed during training differs from the feature computed in production. For example, training may calculate customer age from a trusted date column, while production receives a manually entered age. The two pipelines should share tested transformation code or use a governed feature store. Any difference must be explicit, versioned, and validated.

Input validation should include data types, required columns, permitted categorical levels, numerical ranges, units, timestamps, and missing-value rules. Validation is not merely defensive programming: it prevents silent model misuse and creates an auditable contract between the service and its consumers.

Packaging and environments

A reproducible deployment commonly includes:

• an R project and dependency lockfile, such as one generated with `renv`;
• a container image with a fixed base image and operating-system libraries;
• a serialized model artifact with metadata;
• automated tests and a build specification;
• externalized configuration for endpoints, thresholds, and resource limits;
• a secrets manager rather than credentials embedded in code.

Serialization formats must be treated carefully. An artifact created under one R or package version may not behave identically under another. The deployment process should test loading and scoring the artifact in the exact runtime image intended for production.

3. MLOps as a Lifecycle System

MLOps is not simply automated model training. It is a set of technical and organizational practices that coordinate development, operations, data management, risk management, and business ownership across the model lifecycle.

A representative lifecycle is:

1. Define the decision, users, benefits, harms, and success criteria.

2. Acquire and govern data.

3. Develop features and candidate models.

4. Validate technically, statistically, ethically, and operationally.

5. Register the approved model and its documentation.

6. Release it through a controlled deployment process.

7. Monitor data, service behavior, outcomes, and risks.

8. Investigate incidents and drift.

9. Retrain, recalibrate, replace, retire, or roll back the model.

The lifecycle is iterative. Monitoring may reveal that a feature is unavailable at scoring time, that labels arrive too late for immediate performance measurement, or that a policy change has invalidated the target definition.

Versioning

At minimum, version the following independently but link them through a release identifier:

• source code and infrastructure code;
• raw-data references and data extracts;
• schemas and feature definitions;
• model parameters and preprocessing objects;
• package and container dependencies;
• configuration, decision thresholds, and policies;
• evaluation reports, approvals, and deployment history.

A model registry can store artifact location, version, stage, owner, training period, intended use, metrics, limitations, approval status, and retirement date. “Latest model” is not an adequate production reference; deployments should use immutable versions.

Continuous integration and delivery

Continuous integration (CI) runs automated checks whenever code changes. These may include unit tests for transformations, schema tests, data-quality tests, model-interface tests, security scans, and reproducibility checks. Continuous delivery (CD) builds and prepares a release, while continuous deployment automatically releases it when policy permits.

Model releases often need more controls than ordinary software releases. A pipeline may require statistical evaluation against a baseline, review by a model-risk function, fairness analysis, approval of training data, and a rollback plan before deployment.

Common release strategies include:

• Blue-green deployment: maintain two environments and switch traffic between them.
• Canary deployment: send a small proportion of traffic to the new version and compare results.
• Shadow deployment: run the new model without using its decisions, comparing predictions and operational behavior.
• A/B testing: allocate traffic to alternatives when randomization is valid and ethical.

A rollback should restore the last known-good model and compatible feature pipeline, not merely replace one file. Database schemas, thresholds, and downstream consumers may also need version-compatible rollback.

4. Observability and Monitoring

Monitoring should answer four questions: Is the service available? Are inputs and outputs valid? Is the model still useful? Is the system operating within ethical, legal, and business constraints?

Service and infrastructure metrics

Typical metrics include request rate, error rate, response latency, queue depth, CPU and memory usage, restart frequency, timeout rate, and dependency availability. Percentiles such as p95 or p99 are often more informative than average latency because a small number of slow requests may affect users disproportionately.

For a service-level indicator, if 9,950 of 10,000 requests meet the latency objective, the compliance rate is

\[

\text{SLO compliance} = \frac{9,950}{10,000}=0.995=99.5\%.

\]

This calculation assumes that each request is counted once and that the numerator is defined consistently. It does not measure predictive quality.

Data-quality monitoring

Monitor missingness, range violations, unexpected categories, duplicate records, schema changes, stale timestamps, unit changes, and volume anomalies. Data-quality checks should distinguish an expected seasonal change from a pipeline failure. For example, a fall in transactions on a public holiday may be valid, whereas a zero count caused by an expired database credential is not.

Prediction and outcome monitoring

Monitor prediction distributions, score concentration, class rates, confidence or uncertainty indicators, and decision thresholds. Once ground-truth labels become available, monitor outcome metrics such as accuracy, precision, recall, calibration, expected loss, or domain-specific utility.

For binary classification, with true positives (TP), false positives (FP), true negatives (TN), and false negatives (FN),

\[

\text{Precision}=\frac{TP}{TP+FP},\qquad

\text{Recall}=\frac{TP}{TP+FN}.

\]

These definitions require a binary decision and nonzero denominators. Precision measures the proportion of positive predictions that are correct; recall measures the proportion of actual positives detected. A model can have high recall but low precision, so the choice depends on the relative cost of missed cases and false alarms.

Monitoring must account for delayed labels. A fraud label may arrive weeks later, and a default label may require months. Until labels arrive, teams can monitor leading indicators such as input validity, score distributions, review rates, and proxy outcomes, while clearly identifying that these are not substitutes for measured performance.

5. Drift Detection and Retraining

Data drift is a change in the distribution of inputs. Concept drift is a change in the relationship between inputs and the target. Prediction drift is a change in model outputs. They are related but not equivalent. A changed input distribution does not automatically imply degraded performance, and stable input distributions do not guarantee stable relationships.

For a numerical feature, a simple monitoring statistic is the difference in means:

\[

\Delta \bar{x}=\bar{x}_{production}-\bar{x}_{reference}.

\]

This is easy to interpret but sensitive to scale and insufficient by itself. Distributional methods such as the Kolmogorov–Smirnov statistic, population stability measures, quantile comparisons, or divergence measures can provide additional evidence. Statistical significance must be interpreted with sample size: very large samples can make trivial differences significant. Practical thresholds and business impact are therefore essential.

For categorical data, compare category proportions, including the rate of new or unknown categories. For performance drift, compare a current evaluation window with a reference window using confidence intervals or appropriately designed statistical tests. The reference period, window length, sampling method, and multiple-testing policy should be documented.

Retraining policies

Retraining should not be triggered solely by an arbitrary calendar schedule. A mature policy combines:

• scheduled retraining when data and labels are regularly available;
• performance thresholds linked to business loss;
• drift thresholds interpreted with domain expertise;
• major changes in policy, population, or data collection;
• incident-driven retraining or rollback;
• minimum data-volume and data-quality requirements.

A retrained model must pass the same validation gates as a new model. Automatic retraining without automatic validation and approval can reproduce data errors at high speed. Retraining may also worsen fairness, calibration, interpretability, or stability even when an aggregate metric improves.

6. Model Governance and Documentation

Model governance assigns accountability and establishes evidence that a model is appropriate for its intended use. It should be proportional to risk. A model recommending music does not normally require the same controls as one influencing lending, employment, medical treatment, or public benefits.

Important governance roles include:

• Model owner: accountable for purpose, resources, and lifecycle decisions.
• Data owner: accountable for data rights, quality, and permitted use.
• Model developer: responsible for implementation and technical evidence.
• Validator or reviewer: independently challenges assumptions and results.
• System operator: responsible for deployment, reliability, and incident response.
• Business or domain owner: confirms that outputs support a legitimate decision process.
• Affected-person or compliance function: evaluates legal, ethical, and user impacts.

A model card or equivalent record should describe intended use, prohibited use, training population, data sources, features, target definition, evaluation design, subgroup results, known limitations, calibration, operational requirements, monitoring plan, human oversight, and retirement conditions. A data sheet should document data provenance, collection process, licensing, consent considerations, transformations, missingness, representativeness, and known biases.

Governance should preserve a decision trail: who approved the model, which version was used, what input data and threshold applied, what explanation was shown where required, and how an appeal or correction was handled. Logging must be balanced against privacy and data-minimization obligations.

Fairness and responsible use

Fairness cannot be reduced to one universal metric. Possible assessments include group-specific error rates, selection rates, calibration, equal opportunity, and equalized odds. These criteria can conflict, especially when base rates differ, so the organization must justify which harms are most important and what legal and social context applies.

Sensitive attributes may be needed for auditing even when they are excluded from prediction. Their collection and use require lawful basis, access controls, retention limits, and careful interpretation. Removing a sensitive attribute does not remove discrimination if correlated proxy variables remain.

Human oversight must be meaningful rather than ceremonial. Reviewers need adequate information, authority to disagree, time to investigate, and protection from automation bias. Users should know when an automated system materially influences a decision and how to request review when appropriate.

7. Security, Reliability, and Privacy

Machine-learning systems expand the attack surface of ordinary applications. Threats include unauthorized model access, data poisoning, adversarial or malformed inputs, model extraction, membership inference, prompt or feature manipulation, dependency compromise, and leakage through logs.

Core controls include least-privilege identities, network segmentation, encrypted communication, encryption at rest, secret rotation, dependency scanning, signed artifacts, input limits, rate limiting, audit logs, vulnerability management, and tested backups. Production logs should avoid raw personal data and should use pseudonymous identifiers where possible.

Reliability engineering treats failure as expected. A service should define availability and latency objectives, use timeouts and bounded retries, isolate failing dependencies, provide graceful degradation where safe, and test recovery. A fallback model or rules engine may be appropriate, but fallback behavior must be validated because it can create systematic risk. Disaster recovery plans should specify recovery time objective (RTO), the maximum acceptable time to restore service, and recovery point objective (RPO), the maximum acceptable period of data or state loss. These are organizational service requirements, not properties of model accuracy.

8. Technical Debt in ML Systems

Technical debt is the future cost created by expedient choices. In machine learning it includes:

• data dependency debt: undocumented sources, unstable upstream systems, and hidden correlations;
• pipeline debt: duplicated transformations and fragile orchestration;
• configuration debt: thresholds or environments that differ without control;
• monitoring debt: missing labels, weak alerts, or unowned dashboards;
• model debt: outdated assumptions, redundant models, and unclear retirement criteria;
• organizational debt: ambiguous ownership and inadequate review capacity.

A model may remain technically operational while its business meaning becomes obsolete. Debt should be recorded in a backlog, assigned an owner, given a risk rating, and reviewed during lifecycle gates. The cheapest time to remove a dependency or document a feature is usually before deployment.

9. Worked Application: Illustrative Loan-Delinquency Service

Background

Consider a fictional regional lender that estimates the probability that a consumer loan will become 30-days delinquent within the next 90 days. The score supports manual review and does not automatically reject applicants. The development team uses R and logistic regression, with a governed preprocessing pipeline.

Problem

The first version performed well in a historical test set but failed operational review. The production application supplied a categorical employment field with new values, one upstream feed sometimes delivered monthly rather than daily data, and the model had no documented rollback or monitoring plan. A fairness review also found different recall rates across demographic groups.

Analysis

The team defined the target using an observation window ending before the prediction time to avoid leakage. It separated development, validation, and time-based test periods. It identified the decision owner, data owner, model owner, and independent validator. Performance was evaluated using discrimination, calibration, subgroup errors, and an estimate of the cost of manual review and missed delinquency.

The team also examined whether the model used variables that were proxies for protected characteristics. It did not assume that excluding protected attributes solved the issue; instead, it used appropriately governed attributes for auditing and reviewed features with domain experts.

Approach and solution

The approved release included:

1. A versioned R project and locked package environment.

2. A schema contract requiring types, units, allowable categories, freshness, and missingness limits.

3. A shared feature pipeline used in training and serving.

4. A containerized API with authentication, input validation, timeouts, and structured error responses.

5. A model registry entry containing the artifact, data period, code revision, evaluation report, limitations, owner, and approval.

6. Shadow deployment for two weeks, followed by a canary release to 10% of traffic.

7. Monitoring for latency, feed freshness, unknown categories, score distributions, delayed delinquency labels, calibration, and subgroup recall.

8. A rollback rule if service reliability breached its objective or if validated performance fell below an approved threshold, subject to investigation and review.

9. A retraining process requiring fresh labels, data-quality checks, comparison with the incumbent, fairness assessment, and approval.

The endpoint returned a probability, model version, timestamp, and explanation appropriate to the user interface. It did not return sensitive internal features or debugging details.

Outcome

Shadow testing revealed that the employment field would have produced a high rate of unknown categories in production. The schema contract and mapping policy were corrected before release. During the canary phase, latency remained within the service objective and score distributions were stable. Later monitoring detected a rise in delinquency that was not explained by input drift alone. Investigation identified a change in repayment policy, after which the target process and model were reviewed rather than blindly retrained.

Learning points

The case demonstrates that model quality is multidimensional. A model is not production-ready merely because its test-set metric is strong. Data contracts, operational tests, governance, fairness analysis, controlled release, and human interpretation are part of the model system itself.

10. Contemporary Developments and Strategic Implications

Modern MLOps increasingly uses feature stores, model registries, data contracts, infrastructure as code, policy-as-code, workflow orchestration, and observability platforms. Reproducible environments are being supplemented by software bills of materials and signed model artifacts. Privacy-enhancing techniques, federated learning, differential privacy, and confidential computing may reduce exposure in specialized settings, but they introduce computational, statistical, and governance trade-offs.

Generative AI and foundation models add new concerns: prompt and retrieval versioning, evaluation of nondeterministic outputs, content provenance, hallucination monitoring, prompt injection, model-provider dependence, and evaluation of harmful outputs. The same lifecycle principles remain applicable: define intended use, test realistic failure modes, monitor outcomes, control releases, document limitations, and retain accountable human ownership.

Senior practitioners should view MLOps as an operating model rather than a collection of tools. Tool adoption without clear ownership can increase complexity. The strategic question is not whether every organization should automate every stage, but which controls are necessary for the risk, scale, latency, and regulatory context of each use case.

Best-Practice Checklist

Before production approval, confirm that:

• the purpose, users, prohibited uses, and success measures are explicit;
• training and serving features are consistent and versioned;
• data provenance, permissions, quality, and target construction are documented;
• the artifact can be loaded and scored in the production runtime;
• code, data references, dependencies, configuration, and approvals are traceable;
• automated tests cover schema, transformations, inference, security, and failure paths;
• deployment has a canary, shadow, or equivalent controlled-release strategy;
• service, data, prediction, outcome, fairness, and drift monitoring have owners;
• label delay and uncertainty are acknowledged;
• retraining, rollback, retirement, and incident procedures are defined;
• privacy, security, explainability, accessibility, and human oversight are addressed;
• technical debt is recorded and managed rather than hidden.

Chapter Summary

Deployment transforms a statistical artifact into an operating decision system. Batch, online, asynchronous, streaming, and embedded patterns have different latency, reliability, data, and governance requirements. An R production service must package its model, preprocessing logic, dependencies, schema contract, configuration, and observability controls as one versioned release.

MLOps connects development, validation, deployment, monitoring, retraining, and retirement. Version control, registries, reproducible environments, automated testing, CI/CD, canary or shadow releases, and rollback procedures reduce operational risk. Monitoring must cover service health, data quality, predictions, delayed outcomes, fairness, and drift. Data drift, prediction drift, and concept drift are distinct and require context-sensitive interpretation.

Model governance establishes ownership, documentation, independent challenge, approval evidence, privacy safeguards, fairness evaluation, human oversight, and lifecycle accountability. Security and reliability controls protect both the service and affected people. Finally, technical debt is a central lifecycle concern: undocumented data dependencies, fragile pipelines, weak monitoring, and unclear ownership can make an apparently successful model unsafe or uneconomic to maintain.

Key Terms

Model deployment: Making a trained model available for operational predictions.

MLOps: Practices integrating machine learning, software engineering, data operations, and governance.

Batch scoring: Producing predictions periodically for a collected dataset.

Online inference: Generating a prediction in response to a live request.

Training-serving skew: Difference between feature processing during training and production inference.

Schema contract: Explicit specification of accepted fields, types, ranges, units, and freshness.

Model registry: Controlled repository of model artifacts, metadata, versions, and approvals.

CI/CD: Automated integration, testing, release, and deployment practices.

Canary deployment: Releasing a new version to a small traffic fraction before wider release.

Shadow deployment: Running a candidate model without allowing it to affect decisions.

Observability: Ability to understand system behavior through metrics, logs, and traces.

Data drift: Change in the distribution of model inputs.

Concept drift: Change in the relationship between predictors and the target.

Prediction drift: Change in the distribution of model outputs.

Model card: Documentation describing intended use, performance, limitations, and risks.

Model governance: Oversight, accountability, controls, and evidence across a model lifecycle.

Rollback: Restoring a prior approved version after a release problem.

Technical debt: Future cost created by expedient, fragile, or undocumented design choices.

Recovery time objective: Maximum targeted time to restore service after disruption.

Recovery point objective: Maximum targeted tolerable loss of data or system state.

Review Questions

Short Answer Questions

1. Why is saving only an R model object insufficient for reproducible deployment?

2. Distinguish batch scoring from online synchronous scoring.

3. What is training-serving skew, and why is it dangerous?

4. Define data drift and concept drift.

5. State two responsibilities of a model registry.

Long Answer Questions

1. Explain how an R prediction API should validate inputs, manage errors, protect secrets, and support observability.

2. Discuss how CI/CD and controlled deployment strategies reduce model-release risk.

3. Develop a monitoring framework covering service health, data quality, predictions, outcomes, and fairness.

4. Explain the roles of model governance, documentation, independent validation, and human oversight.

5. Analyze the major categories of machine-learning technical debt and propose lifecycle controls for each.

Analytical / Application Questions

1. A fraud model’s input distributions are stable, but its recall falls after a new payment policy is introduced. Diagnose the likely type of change and recommend an investigation and response.

2. Design a retraining and rollback policy for a credit-risk model whose labels arrive 90 days after prediction. Identify leading indicators, delayed outcome metrics, approval gates, and failure conditions.

3. Propose a deployment architecture for a hospital model requiring low latency, privacy protection, auditability, and human review. Justify the scoring pattern, security controls, monitoring plan, and governance roles.

Multiple Choice Questions with Answers

Question 1

Which artifact combination best supports reproducible model deployment?

A. Only the serialized model object

B. Model object, dependency environment, preprocessing logic, versioned metadata, and configuration

C. A screenshot of validation results

D. The training script without its data reference

Correct Answer: B. Model object, dependency environment, preprocessing logic, versioned metadata, and configuration

Question 2

Which deployment pattern returns a job identifier while processing continues in the background?

A. Synchronous online scoring

B. Embedded scoring

C. Asynchronous scoring

D. Static batch reporting

Correct Answer: C. Asynchronous scoring

Question 3

What is the primary purpose of a schema contract?

A. To increase model complexity

B. To specify accepted inputs and data-quality expectations

C. To replace model validation

D. To eliminate the need for monitoring

Correct Answer: B. To specify accepted inputs and data-quality expectations

Question 4

A canary deployment primarily involves:

A. Releasing the new model to all users immediately

B. Running the model only during training

C. Sending a small proportion of traffic to the new version first

D. Deleting the previous model before testing

Correct Answer: C. Sending a small proportion of traffic to the new version first

Question 5

If TP = 80 and FP = 20, what is precision?

A. 20%

B. 50%

C. 80%

D. 100%

Correct Answer: C. 80%

Question 6

A change in the relationship between predictors and the target is called:

A. Data drift

B. Concept drift

C. Schema validation

D. Prediction latency

Correct Answer: B. Concept drift

Question 7

Which statement about delayed labels is correct?

A. Leading indicators are always equivalent to measured model performance

B. Outcome monitoring can begin fully before labels exist

C. Operational and input metrics can be monitored while awaiting ground truth

D. Delayed labels make monitoring unnecessary

Correct Answer: C. Operational and input metrics can be monitored while awaiting ground truth

Question 8

Which practice best protects production credentials?

A. Embedding passwords in the R script

B. Printing tokens in logs

C. Storing secrets in a managed secrets system

D. Sharing one administrator account

Correct Answer: C. Storing secrets in a managed secrets system

Question 9

What is the main purpose of shadow deployment?

A. To allow a candidate model to make all decisions immediately

B. To compare a candidate’s behavior without using its decisions operationally

C. To avoid collecting monitoring data

D. To remove the incumbent model

Correct Answer: B. To compare a candidate’s behavior without using its decisions operationally

Question 10

Which item is most directly a model-governance activity?

A. Increasing CPU allocation without review

B. Documenting intended use, limitations, ownership, and approval evidence

C. Changing a threshold without recording it

D. Deleting historical evaluation results

Correct Answer: B. Documenting intended use, limitations, ownership, and approval evidence