Intelligent Control, Governance and Emerging Practice

Introduction and Context

Control engineering is moving from systems designed entirely from explicit mathematical models toward systems that combine models, data, learning, perception and distributed computation. This transition is driven by increasingly complex plants, uncertain operating environments, large sensor datasets, networked infrastructure and the need for adaptive autonomy. Examples include autonomous vehicles, collaborative robots, smart grids, advanced process plants, medical devices and unmanned aerial systems.

Intelligent control does not mean that conventional control theory has become unnecessary. Rather, intelligent methods extend the control engineer’s toolbox. Classical feedback remains essential for stability, disturbance rejection and predictable performance. Machine learning may assist with modelling, prediction, optimisation or decision-making, but it introduces additional concerns: data quality, distribution shift, explainability, cybersecurity, verification and accountability.

The central engineering question is therefore not “Can artificial intelligence control the system?” It is: “Which control functions should be model-based, learned, supervised by humans, or allocated to a safety mechanism, and how can the complete system be validated throughout its life?”

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain system identification and distinguish it from machine-learning-based prediction.

2. Compare neural, fuzzy and reinforcement-learning control.

3. Formulate the role of digital twins in monitoring, control and lifecycle management.

4. Evaluate edge, cloud and hybrid control architectures.

5. Design validation and assurance strategies for autonomous systems.

6. Discuss explainability, functional safety, cybersecurity, ethics and accountability.

7. Compare technology choices using performance, risk, lifecycle cost and governance criteria.

1. Intelligent Control as a Layered Engineering Discipline

A control system can be understood as a hierarchy. At the lowest level, sensors measure physical variables and actuators influence the plant. A regulatory controller maintains variables such as position, speed, temperature or pressure. Above this level, supervisory control selects operating modes, constraints and set points. At still higher levels, optimisation, planning and business decisions determine production schedules or mission objectives.

Learning methods are most safely introduced first in functions that are advisory, supervisory or predictive. For example, a learned model may estimate product quality, while a conventional controller remains responsible for actuator commands. In a more advanced architecture, reinforcement learning may select targets for a proven inner-loop controller. Direct learned control of safety-critical actuators requires substantially stronger evidence because the learning system may behave unexpectedly outside its training distribution.

A useful decomposition is:

• Plant layer: physical process, actuators, sensors and communication interfaces.
• Control layer: feedback laws, estimators and constraint handling.
• Learning layer: identification, prediction, optimisation or policy generation.
• Supervision layer: mode management, fault handling and human interaction.
• Assurance layer: monitoring, safety interlocks, cybersecurity and audit records.

This decomposition supports the principle of defence in depth: no single learned component should be the only barrier against a hazardous outcome.

2. System Identification and Data-Centred Modelling

2.1 Purpose and terminology

System identification is the experimental process of constructing a mathematical model of a dynamic system from measured inputs and outputs. The model may be used for simulation, prediction, controller design, fault detection or digital-twin operation. Identification differs from ordinary curve fitting because temporal dynamics, excitation, noise, operating conditions and feedback must be considered.

A discrete-time state-space model is commonly written as

x[k+1] = f(x[k], u[k], w[k]),

y[k] = h(x[k], u[k], v[k]),

where x[k] is the state, u[k] the input, y[k] the measured output, w[k] process disturbance and v[k] measurement noise. In a linear time-invariant approximation,

x[k+1] = Ax[k] + Bu[k] + w[k],

y[k] = Cx[k] + Du[k] + v[k].

The matrices A, B, C and D describe state evolution, input influence, measurement mapping and direct input-output transmission. The linear model is an approximation valid over a specified operating region; it should not be treated as a universal physical law for a nonlinear plant.

2.2 Identification workflow

A defensible identification study includes:

1. Define the purpose. A model for prediction may require different fidelity from one used for controller synthesis.

2. Select variables and sampling time. Sampling must capture the dominant dynamics while respecting sensor and computational limits.

3. Design excitation. Inputs should explore relevant modes without damaging the plant. A constant input cannot identify dynamic behaviour adequately.

4. Acquire and condition data. Time alignment, calibration, filtering, missing-data treatment and sensor validation are essential.

5. Choose model structure. Options include transfer functions, state-space models, grey-box physical models, Gaussian processes and neural networks.

6. Estimate parameters. Least squares, prediction-error methods, maximum likelihood and Bayesian approaches are common.

7. Validate independently. A test dataset, preferably collected under different conditions, is required.

8. Quantify uncertainty and operating limits. The model should state where it is credible.

For a linear regression y = Phi theta + e, ordinary least squares estimates parameters by minimizing the squared residual norm. Under standard assumptions—correct model structure, sufficiently informative data, zero-mean errors uncorrelated with regressors and finite variance—the estimator is useful, but closed-loop data or correlated disturbances can violate these assumptions. Instrumental-variable or closed-loop identification methods may then be needed.

2.3 Validation metrics and pitfalls

A prediction error such as e[k] = y[k] − y_hat[k] is not by itself sufficient evidence of model adequacy. Engineers should inspect residual autocorrelation, cross-correlation with inputs, error distributions, performance across operating regimes and worst-case deviations. Common metrics include mean absolute error and root mean square error:

MAE = (1/N) sum from k=1 to N of |e[k]|,

RMSE = sqrt((1/N) sum from k=1 to N of e[k]^2).

Both have the same units as the output. RMSE weights large errors more strongly than MAE. Metrics must not be compared across variables with different scales unless normalisation is justified.

Important pitfalls include insufficient excitation, sensor bias, hidden variables, nonstationary behaviour, data leakage between training and test sets, and identifying a model only around a safe nominal operating point. A model can have low average error and still fail dangerously during a rare transient.

3. Neural, Fuzzy and Hybrid Control

3.1 Neural control

Neural networks approximate nonlinear mappings using layers of weighted connections and nonlinear activation functions. In control, a network may represent a plant model, inverse dynamics, disturbance estimator, state observer, policy or optimisation surrogate.

A model-based neural predictive controller may learn a state transition x[k+1] = f_theta(x[k],u[k]) and choose a sequence of future inputs by minimising a cost such as

J = sum from i=0 to H−1 of ||y[k+i|k] − r[k+i]||_Q^2 + ||u[k+i]||_R^2,

subject to model and actuator constraints. Here H is the prediction horizon, r is the reference, Q and R are nonnegative weighting matrices, and the notation y[k+i|k] denotes a prediction made at time k. This formulation is meaningful only when the learned model is sufficiently accurate over the predicted region and constraints are enforced reliably.

Neural methods are attractive for high-dimensional perception and strongly nonlinear systems. Their limitations include data dependence, opacity, extrapolation failure, computational demand and vulnerability to adversarial or corrupted inputs. A neural controller should therefore be bounded by action limits, runtime monitors and a fallback controller.

3.2 Fuzzy control

Fuzzy control expresses expert knowledge through linguistic rules such as: “If position error is positive large and velocity is positive, apply negative-large control.” A fuzzy inference system contains membership functions, a rule base, an inference mechanism and defuzzification.

Fuzzy control is useful when a precise plant model is unavailable but qualitative expertise exists. It can interpolate smoothly between operating regions and represent nonlinear relationships in an interpretable form. However, rule explosion, subjective membership design, tuning difficulty and weak formal guarantees can become serious problems as the number of variables increases.

3.3 Neuro-fuzzy and hybrid designs

Hybrid controllers combine the transparency and prior knowledge of fuzzy or physical models with the adaptation capability of neural learning. A model-based controller may provide nominal stability while a learned component estimates disturbances. Another common arrangement uses a neural network to tune fuzzy membership functions, with independent safety limits on the resulting command.

The design objective should be explicit: learning may improve tracking, reduce energy use, compensate for ageing or detect faults. It should not be added merely because a method is fashionable.

4. Reinforcement Learning for Control

4.1 Markov decision formulation

Reinforcement learning (RL) models sequential decision-making. At time k, an agent observes state s_k, selects action a_k according to a policy pi, receives reward r_k and transitions to a new state. The objective is generally to maximise expected discounted return:

G_k = sum from t=0 to infinity of gamma^t r[k+t],

where 0 <= gamma < 1 is the discount factor. The Markov assumption requires that the current state contains sufficient information to predict future evolution given the action. In physical systems this assumption may fail if unmeasured temperatures, delays or actuator dynamics are omitted.

A value function is the expected return under a policy. Model-free methods learn values or policies from experience, while model-based RL uses an estimated transition model for planning. Exploration is a major issue: actions that help learning may be unsafe on a real plant.

4.2 Safe and practical RL

Practical engineering approaches include:

• training in simulation before deployment;
• domain randomisation to expose the policy to parameter variation;
• offline RL from previously collected data;
• shielded policies that reject unsafe actions;
• action projection onto a certified constraint set;
• residual RL, in which learning modifies a baseline controller;
• human approval for unfamiliar states;
• gradual deployment with performance monitoring.

Simulation-to-reality transfer is limited by model mismatch, unmodelled contacts, sensor noise, latency and rare events. Reward design is also hazardous: an incomplete reward can encourage behaviour that maximises the numerical objective while violating the real mission. Safety constraints should therefore be represented separately from performance rewards wherever possible.

5. Digital Twins and Lifecycle Intelligence

A digital twin is a digital representation of a physical asset or process that is connected to the physical system through data and updated over time. A static engineering model or a one-time simulation is not necessarily a digital twin. The twin may combine first-principles equations, live measurements, reduced-order models and machine-learning estimators.

Digital twins support:

• design-space exploration and commissioning;
• condition monitoring and predictive maintenance;
• virtual sensing of variables that are difficult to measure;
• operator training;
• anomaly detection and root-cause analysis;
• what-if analysis for control changes;
• asset performance and energy optimisation.

A twin architecture should define data ownership, time synchronisation, model versioning, calibration procedures, uncertainty representation and cybersecurity boundaries. If the physical asset changes but the twin is not updated, the twin may produce confidently incorrect recommendations.

The twin should distinguish measured values, estimated values and simulated forecasts. It should record provenance and confidence, rather than presenting every output as equally authoritative.

6. Edge, Cloud and Hybrid Control Architectures

Control placement is a systems-engineering decision. Edge control executes close to sensors and actuators. It provides low latency, local autonomy and operation during communication outages, but may have limited computational resources. Cloud control provides scalable computation, centralised data and fleet-level learning, but introduces network delay, dependence on connectivity, privacy concerns and a larger cyberattack surface.

A hybrid architecture commonly keeps fast feedback and safety functions at the edge while using cloud or datacentre resources for model training, fleet analytics, maintenance planning and noncritical optimisation. The control loop must account for total delay, including sensing, computation, communication and actuation. Excessive or variable delay can degrade stability and performance even when the nominal controller is correct.

Design decisions should consider:

• maximum permitted latency and jitter;
• availability and degraded-mode operation;
• bandwidth and data costs;
• data sovereignty and privacy;
• update and rollback mechanisms;
• cybersecurity and authentication;
• energy consumption;
• maintainability and supplier dependence.

7. Autonomous Systems and Validation

Autonomy is not a single capability. It combines perception, localisation, prediction, planning, control, fault management and human interaction. Validation must therefore address both component performance and emergent behaviour at system level.

A useful assurance argument includes:

1. Operational design domain: the environments, weather, speeds, loads and mission conditions in which the system is intended to operate.

2. Hazard analysis: identification of unsafe control actions, failure modes and foreseeable misuse.

3. Requirements traceability: linkage from hazards to requirements, implementation, tests and evidence.

4. Scenario-based testing: nominal, boundary, rare, adversarial and degraded scenarios.

5. Formal or semi-formal analysis: reachability, invariant checking, runtime assurance or theorem proving where feasible.

6. Hardware-in-the-loop and field trials: progressive testing from simulation to representative physical environments.

7. Runtime monitoring: detection of sensor disagreement, out-of-distribution inputs, constraint violation and performance drift.

8. Incident learning: logging, investigation, corrective action and controlled model updates.

Testing only average performance is inadequate. Safety evidence must address low-probability, high-consequence events and interactions between independently acceptable components.

8. Explainability, Functional Safety and Standards

Explainability has multiple meanings. A controller may be interpretable because its rules are human-readable, explainable because it provides feature attributions, or auditable because its decisions and data provenance are recorded. These are not equivalent. A post hoc explanation can be plausible without accurately representing the internal causal process.

For high-consequence systems, useful evidence includes:

• monotonicity or physical constraints built into the model;
• interpretable features and operating envelopes;
• counterfactual tests;
• uncertainty estimates and confidence thresholds;
• complete logs of model, data and software versions;
• independent review and reproducible evaluation;
• a safe fallback when confidence is inadequate.

Functional safety concerns the ability of a system to avoid unacceptable risk arising from malfunctioning behaviour. Relevant standards depend on sector. Examples include IEC 61508 for functional safety of electrical/electronic/programmable electronic systems, ISO 13849 for safety-related parts of machinery control systems, ISO 26262 for road-vehicle functional safety, IEC 62443 for industrial automation and control cybersecurity, and ISO/IEC 42001 for artificial-intelligence management systems. Standards are not interchangeable and compliance with one does not automatically establish compliance with another. Their current editions, sector applicability and legal status must be checked in the project context.

Machine learning complicates conventional assurance because behaviour is inferred from data and may change after retraining. Configuration management, change impact analysis, dataset control, independent validation and controlled deployment are therefore essential.

9. Governance, Ethics and Accountability

Governance defines who may make decisions, under what authority, using which evidence, and who is responsible when outcomes are harmful. Technical responsibility cannot be transferred to an algorithm or a supplier.

A governance framework should assign accountability for:

• defining intended use and prohibited use;
• approving data sources and retention periods;
• assessing bias, privacy and security risks;
• accepting residual safety risk;
• authorising model updates;
• monitoring incidents and near misses;
• communicating limitations to operators and users;
• preserving appeal, override and shutdown mechanisms.

Ethical issues include unequal error rates, surveillance, loss of human agency, labour displacement, environmental cost of computation, inaccessible design and responsibility gaps in autonomous decisions. Privacy protection requires purpose limitation, minimisation, access control and retention discipline. Fairness cannot be assessed abstractly: the relevant harm, population, context and operational consequence must be specified.

A responsible system should provide meaningful human control. Human involvement must be realistic: an operator who receives hundreds of alerts, lacks authority or has insufficient time is not an effective safety barrier.

10. Lifecycle Cost and Technology Selection

Technology selection should compare total cost of ownership rather than purchase price. A lifecycle model may include acquisition, integration, verification, training, energy, connectivity, maintenance, cybersecurity, upgrades, downtime, incident response, decommissioning and disposal.

A simple discounted-cost representation is

LCC = C_0 + sum from t=1 to T of C_t/(1+i)^t,

where C_0 is initial cost, C_t is cost in year t, i is the discount rate and T is the evaluation horizon. The calculation is only meaningful when cost categories, inflation treatment, residual value and uncertainty are defined consistently. Safety and ethical consequences should not be reduced to arbitrary monetary values; they should be treated as constraints, risk criteria or separately reported decision factors.

A practical selection matrix can score alternatives against safety assurance, control performance, adaptability, explainability, cybersecurity, latency, maintainability, interoperability, energy use, supplier dependence and lifecycle cost. Weighting should be agreed with stakeholders, and sensitivity analysis should show whether a recommendation changes when weights or uncertain assumptions change.

The best architecture is often hybrid: proven feedback for immediate regulation, machine learning for prediction or optimisation, a digital twin for lifecycle insight, and independent safety mechanisms for hazardous conditions.

11. Illustrative Case: Learning-Assisted Control of an Autonomous Warehouse Vehicle

Background

This illustrative case concerns an autonomous electric warehouse vehicle that transports pallets between storage aisles and loading stations. It uses lidar, cameras, wheel encoders and battery sensors. The original system used a conventional path planner and PID velocity controllers.

Problem

As battery voltage declined and floor friction varied, energy use and tracking error increased. Management proposed replacing the controller with an end-to-end neural policy trained on recorded driving data. The safety team rejected immediate full replacement because the dataset contained few wet-floor events, sensor occlusions or unusual pallet placements.

Analysis

The engineering team decomposed the problem. Fast motor and velocity loops were already validated. The main opportunity was to predict traction variation and select energy-efficient speed references. Hazard analysis identified collision, overspeed, loss of localisation and unsafe recovery after communication failure as unacceptable outcomes.

A grey-box vehicle model was identified from controlled tests. A neural residual model estimated unmodelled longitudinal force, but its output was bounded. An optimisation layer selected speed references subject to aisle limits, stopping distance and battery constraints. The existing low-level controller remained responsible for actuator commands. Independent lidar-based protective stopping could override the commanded motion.

Validation and deployment

Training data were divided by route, day and environmental condition to avoid leakage. Tests included nominal routes, low battery, wheel slip, blocked aisles, sensor dropout and delayed cloud communication. Hardware-in-the-loop testing preceded limited pilot operation. The cloud was used for fleet analytics and retraining; all safety-critical functions remained on the vehicle edge computer.

Runtime monitors checked sensor consistency, residual-model confidence, speed limits and stopping capability. If any monitor failed, the vehicle reduced speed or entered a controlled stop. Model updates required version approval, regression testing and rollback capability.

Outcome

The learning-assisted design reduced energy consumption and improved tracking under tested friction variations without removing the validated safety barriers. Its benefit was smaller than that predicted by simulation, demonstrating the importance of conservative transfer assumptions. The project also revealed that data labelling and test-route diversity were major costs.

Learning points

1. Learning should target a clearly defined deficiency.

2. A hybrid architecture can preserve validated control functions.

3. Safety constraints must be independent of the performance optimiser.

4. Edge autonomy is necessary when communication loss must not cause danger.

5. Lifecycle governance includes data, model updates and incident review, not only initial commissioning.

12. Challenges and Emerging Practice

Important unresolved challenges include distribution shift, adversarial sensing, rare-event validation, specification of human values, certification of adaptive systems, reproducibility of large models and the energy cost of training. Digital twins may create false confidence when their uncertainty is hidden. Federated learning can reduce raw-data transfer but introduces aggregation, privacy and poisoning risks. Physics-informed learning can improve extrapolation, but physical constraints must be correctly formulated and may not guarantee closed-loop safety.

Emerging practice is moving toward assurance cases for AI-enabled systems, runtime safety envelopes, uncertainty-aware prediction, formal contracts between learned and conventional components, standardised model cards and datasheets, and continuous monitoring after deployment. Research increasingly focuses on combining control-theoretic guarantees with data-driven flexibility rather than treating learning and control as competing disciplines.

The professional control engineer must therefore be competent in dynamics, estimation, software, data engineering, cybersecurity, risk analysis and governance. Intelligent control is not merely an algorithm-selection exercise; it is a lifecycle systems-engineering discipline.

Chapter Summary

Intelligent control combines conventional feedback, mathematical modelling, data-driven learning and supervisory decision-making. System identification creates dynamic models from experiments, but model validity depends on excitation, noise assumptions, operating range and independent validation. Neural networks offer nonlinear approximation, fuzzy systems encode linguistic expertise, and reinforcement learning addresses sequential decision-making; each introduces limitations in data dependence, interpretability, extrapolation and safety.

Digital twins connect physical assets with evolving digital models for monitoring, prediction and lifecycle optimisation. Edge architectures provide low latency and resilience, while cloud resources support fleet analytics and training; hybrid designs often provide the best balance. Autonomous systems require operational-domain definition, hazard analysis, traceability, scenario testing, runtime monitoring and incident learning.

Explainability, functional safety, cybersecurity, ethics and accountability must be designed into the lifecycle. Relevant standards provide structured practices but do not remove the need for engineering judgement. Technology selection should use lifecycle cost, risk, maintainability and governance criteria rather than novelty or initial price. The preferred solution is frequently a hybrid architecture in which learning improves prediction or optimisation while independently validated control and safety mechanisms retain authority over hazardous actions.

Key Terms

System identification: Estimating a dynamic system model from measured inputs and outputs.

Grey-box model: A model combining physical knowledge with estimated parameters or learned components.

Residual: The difference between an observed value and a model prediction.

Distribution shift: A change between the data used for development and conditions encountered in operation.

Neural controller: A controller in which a neural network performs modelling, estimation, policy generation or control computation.

Fuzzy control: Control based on linguistic rules and membership functions.

Reinforcement learning: Sequential learning in which an agent selects actions to maximise expected return.

Policy: A rule or function mapping observations or states to actions.

Digital twin: A connected digital representation of a physical asset that is updated using operational data.

Edge computing: Processing performed near the sensors and actuators.

Cloud control: Control-related computation or analytics performed on remote networked infrastructure.

Operational design domain: The conditions and environments for which an autonomous system is intended to operate.

Runtime assurance: Monitoring and intervention during operation to keep behaviour within safe limits.

Explainability: The extent to which system behaviour can be understood, interpreted or audited.

Functional safety: Reduction of unacceptable risk caused by malfunctioning behaviour of safety-related systems.

Defence in depth: Use of multiple independent or partially independent protective barriers.

Lifecycle cost: Total cost of ownership over acquisition, operation, maintenance and disposal.

Model drift: Degradation caused by changes in the plant, environment, data or relationships represented by a model.

Accountability: Assignment of responsibility and answerability for system decisions and outcomes.

Review Questions

Short Answer Questions

1. What is the purpose of independent validation in system identification?

2. Distinguish edge control from cloud control.

3. Define distribution shift and explain why it matters for learned controllers.

4. What is the role of a runtime monitor?

5. Why is a hybrid control architecture often preferred for safety-critical applications?

Long Answer Questions

1. Explain a complete system-identification workflow, including excitation, data conditioning, model estimation and validation.

2. Compare neural, fuzzy and reinforcement-learning control in terms of strengths, limitations and appropriate applications.

3. Discuss how a digital twin can support control, predictive maintenance and lifecycle decision-making.

4. Explain the principal elements of an assurance argument for an autonomous system.

5. Analyse the relationship among explainability, functional safety, cybersecurity and accountability.

Analytical / Application Questions

1. Design a hybrid architecture for an autonomous mobile robot that must continue operating safely during cloud disconnection. Identify which functions belong at the edge, in the cloud and in an independent safety layer.

2. A learned controller performs well on average but fails during rare high-load transients. Propose a validation, monitoring and deployment strategy that addresses this weakness.

3. Compare two candidate intelligent-control technologies using lifecycle cost, safety evidence, adaptability, maintainability and governance. State the additional information required before making a final selection.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of system identification?

A. To estimate a dynamic model from measured system data

B. To eliminate all measurement noise physically

C. To replace every feedback controller with a neural network

D. To guarantee stability without testing

Correct Answer: A. To estimate a dynamic model from measured system data

Question 2

Which metric weights large prediction errors more strongly than MAE?

A. Median absolute error

B. Root mean square error

C. Classification accuracy

D. Correlation coefficient

Correct Answer: B. Root mean square error

Question 3

In reinforcement learning, the discount factor determines the relative importance of:

A. Sensor resolution and actuator range

B. Past training data and future plant data

C. Immediate rewards and future rewards

D. Cloud computation and edge computation

Correct Answer: C. Immediate rewards and future rewards

Question 4

Which function is generally most appropriate for cloud infrastructure in a safety-critical hybrid architecture?

A. Independent emergency stopping

B. The fastest actuator feedback loop

C. Physical overcurrent protection

D. Fleet-level analytics and model training

Correct Answer: D. Fleet-level analytics and model training

Question 5

What distinguishes a digital twin from a static simulation model?

A. A digital twin is connected to and updated from the physical asset

B. A digital twin never uses physical equations

C. A digital twin cannot include machine learning

D. A digital twin is used only before commissioning

Correct Answer: A. A digital twin is connected to and updated from the physical asset

Question 6

Why can direct reinforcement-learning exploration be hazardous on a real plant?

A. Exploration always reduces computational cost

B. Learning actions may violate physical or safety constraints

C. The plant cannot provide any measurements

D. Rewards cannot be represented numerically

Correct Answer: B. Learning actions may violate physical or safety constraints

Question 7

Which principle requires multiple protective barriers against hazardous outcomes?

A. Data minimisation

B. Open-loop optimisation

C. Defence in depth

D. Model compression

Correct Answer: C. Defence in depth

Question 8

What is the main purpose of defining an operational design domain?

A. To specify the conditions in which the autonomous system is intended to operate

B. To guarantee operation in every possible environment

C. To replace hazard analysis

D. To determine the discount rate for lifecycle cost

Correct Answer: A. To specify the conditions in which the autonomous system is intended to operate

Question 9

In the lifecycle-cost expression, what does i represent?

A. The prediction error

B. The discount rate

C. The sampling interval

D. The number of sensors

Correct Answer: B. The discount rate

Question 10

Which practice best supports controlled deployment of an updated learned model?

A. Replacing the old model without regression testing

B. Disabling all runtime monitoring

C. Version approval, validation and rollback capability

D. Using only the training dataset for acceptance

Correct Answer: C. Version approval, validation and rollback capability