Mathematical Modelling, Decision Support and Responsible Tools

Introduction

Information technology systems increasingly support decisions about staffing, loans, hospital capacity, transport, cybersecurity, energy use and education. Such systems do not “discover” decisions automatically. They represent selected aspects of reality through data, variables, relationships and rules. A mathematical model is therefore both a technical artefact and a statement of assumptions.

For an IT professional, modelling involves more than entering formulas into a spreadsheet or training an algorithm. A useful model must be appropriately specified, validated against evidence, understandable to its users, robust under changing conditions and governed responsibly. This chapter develops a practical workflow for building and communicating models using spreadsheets, programming and AI-assisted tools. It also examines sensitivity analysis, privacy, bias, explainability and accountability in automated decision-making.

Learning Objectives

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

1. Define a modelling problem in terms of variables, objectives, constraints and stakeholders.
2. Distinguish descriptive, predictive and prescriptive models.
3. Build a simple model in a spreadsheet or program and check its units and logic.
4. Validate a model using data, tests, residuals, scenarios and expert judgement.
5. Conduct one-variable and multi-variable sensitivity analysis.
6. Explain how AI-assisted tools can support, but cannot replace, professional judgement.
7. Identify risks involving privacy, bias, explainability, security and governance.
8. Communicate model results with appropriate uncertainty and limitations.

1. What Is a Mathematical Model?

A model is a simplified representation of a real system for a stated purpose. It may be an equation, spreadsheet, simulation, database query, decision tree, optimisation program or machine-learning system. Every model excludes some details. The central question is not whether a model is a perfect copy of reality—it cannot be—but whether it is fit for its intended use.

A typical model contains:

• Inputs: observed or assumed quantities, such as demand, cost or population.
• Parameters: characteristics treated as fixed for a particular analysis, such as a tax rate or processing time.
• Decision variables: quantities controlled by a decision-maker, such as staffing level.
• State variables: quantities describing the current condition of a system.
• Outputs: calculated results, forecasts or recommendations.
• Constraints: conditions that must be satisfied.
• Objective: the quantity to maximise, minimise or otherwise evaluate.

A useful abstraction is:

Here, X is a vector of inputs, θ is a vector of parameters, D represents decisions, f is the model, and Y is the output. The notation does not imply that the relationship is exact; it states how the model maps assumptions and inputs to results.

Types of models

A model can belong to more than one category. For example, a predictive model may be embedded in a prescriptive system.

2. From a Real Problem to a Formal Model

2.1 Problem framing

The first stage is not selecting software. It is defining the decision. A good problem statement identifies the decision-maker, time horizon, affected groups, available resources, success criteria and consequences of error. “Use AI to improve recruitment” is too vague. “Rank eligible applicants for interview while satisfying legal requirements and reducing administrative time” is more precise, although it still requires careful definition of fairness and eligibility.

Stakeholders should be consulted because the person commissioning a model may not be the person affected by it. A model that reduces average waiting time could nevertheless worsen access for people with disabilities or those living far from a service centre.

2.2 Variables and units

Variables must be defined unambiguously. If c is cost, specify whether it is dollars per item, dollars per hour or total dollars. Unit consistency is a basic but powerful error check. For example, if a system processes r = 12 requests per hour for t = 5 hours, the number processed is:

The hours cancel correctly, leaving requests. Adding “12 requests per hour” to “5 hours” would be meaningless, because quantities with incompatible units cannot be added.

2.3 Assumptions

Assumptions may concern linearity, independence, constant rates, complete data, stable behaviour or measurement accuracy. They should be written down before results are interpreted. An assumption is not automatically a flaw; an undisclosed or implausible assumption is.

Consider a simple monthly cloud-service cost model:

where C is total monthly cost in dollars, F is fixed monthly cost in dollars, p is the price per compute-hour, u is compute-hours used, and s is storage cost per compute-hour-equivalent under the chosen simplification. This formula is valid only if the prices are constant over the relevant range and the storage term is genuinely proportional to u. If storage is billed independently in gigabytes, the model should instead use a separate variable, such as g, measured in gigabytes.

2.4 Objectives and constraints

A prescriptive model often has the form:

Here, D is the vector of decision variables, Z is the objective value, h_i represents a constraint, b_i is its limit, and m is the number of constraints. The model is meaningful only when decision variables, objective units and constraints are clearly specified.

For example, if x is the number of support agents scheduled and each agent costs £180 per shift, minimising labour cost is:

The integer condition matters: a schedule cannot normally contain 4.5 agents. If demand requires at least four agents, the mathematical optimum is four, but operational constraints such as breaks, skills and peak demand may require a richer model.

3. Building Models with Spreadsheets and Programs

Spreadsheets

A spreadsheet is useful for transparent, small-scale models. A robust layout separates:

1. Inputs: labelled assumptions and units.
2. Calculations: formulas that refer to input cells rather than repeating constants.
3. Outputs: key results and charts.
4. Checks: warnings for missing, negative or implausible values.
5. Documentation: source, date, owner and assumptions.

Suppose weekly demand is forecast at 1,200 units, each unit requires 0.25 labour-hours, and one worker provides 30 productive hours. Required labour-hours are:

The required number of workers is:

This is exactly ten only under the assumptions that demand is met, all productive hours are available and work can be allocated without skill or timing constraints. If the result were 10.2, the operational requirement would generally be rounded up to 11, not rounded to the nearest integer, because rounding down would leave insufficient capacity.

Spreadsheet risks include hidden cells, hard-coded values, copied formula errors, version confusion and accidental changes. Protection, peer review and test cases reduce these risks.

Programming

Programming is preferable when data are large, processes must be repeated, tests are required or reproducibility is important. A basic modelling workflow is:

validate inputs
transform data using documented rules
calculate or estimate the model
run automated checks
store outputs and metadata
report results with uncertainty and limitations

Good code uses meaningful names, functions with clear inputs and outputs, version control, reproducible environments and tests for boundary cases. A test might verify that zero demand produces zero variable cost, that negative demand is rejected and that a known small example produces a known answer.

Communicating outputs

A result should be reported with its decision meaning, not merely its numerical value. “The model predicts 10,000 visits” is weaker than “Under the stated assumptions, expected weekly visits are approximately 10,000; staffing should be reviewed if demand exceeds 11,000.” Charts should show units, time periods, denominators and uncertainty where relevant. Averages can conceal variation, so distributions, ranges or percentiles may be more informative.

4. Validation and Verification

Verification asks whether the model was implemented correctly: are formulas, code and data transformations faithful to the specification? Validation asks whether the specification is an adequate representation of the real system for its intended purpose.

Useful checks include:

• Dimensional checks: do units on both sides of an equation agree?
• Boundary checks: does the model behave sensibly at zero, maximum and minimum values?
• Comparison with known cases: does it reproduce a hand calculation or historical baseline?
• Historical validation: do predictions align with data not used to construct the model?
• Back-testing: would the model have performed acceptably at earlier dates?
• Residual analysis: are errors systematically larger for a group or condition?
• Stress testing: what happens under unusually high demand or missing data?
• Expert review: do domain specialists recognise the relationships and outputs?

For observed values y_i and predictions ŷ_i, the residual is:

A positive residual means the observation exceeds the prediction. For n observations, mean absolute error is:

MAE has the same units as the outcome and gives the average absolute discrepancy. It is useful when all errors should contribute proportionally. It can be misleading when large errors are especially costly or when observations have very different scales. Metrics must therefore match the decision context.

A model may be statistically accurate yet operationally inappropriate. For example, a model predicting average delivery time may have good overall error but systematically underestimate delays in remote regions. Validation should examine relevant subgroups and failure modes, not only an overall score.

5. Sensitivity, Scenarios and Uncertainty

Sensitivity analysis examines how output changes when an input or parameter changes. For output Y = f(x), a local sensitivity near x can be represented by:

This derivative describes the approximate change in Y for a small change in x, assuming other variables remain fixed and the function is differentiable. For a discrete spreadsheet model, one can use a finite difference:

A percentage sensitivity, often called an elasticity when the relationship is appropriate, is:

It compares proportional changes and is dimensionless. These measures should not be interpreted as causal effects unless the model and data justify a causal interpretation.

Worked sensitivity example

Suppose annual benefit is estimated as:

where a is revenue per unit (£50), c is variable cost per unit (£30), q is annual quantity (10,000 units), and F is fixed cost (£120,000). Then:

The break-even quantity satisfies B = 0:

If variable cost rises to £34 while other assumptions remain fixed:

The benefit falls by £40,000. The result is highly sensitive to the contribution margin a − c. The calculation assumes constant prices, a constant quantity, no capacity limit and no interaction between cost and demand.

Scenario analysis changes several assumptions together, such as a baseline, optimistic and adverse scenario. Monte Carlo simulation repeatedly samples uncertain inputs from specified probability distributions and calculates a distribution of outputs. Simulation results are only as credible as the chosen distributions, dependencies and model structure; random repetition does not remove modelling assumptions.

6. AI-Assisted Modelling

AI tools can help generate spreadsheet formulas, code templates, test cases, explanations, synthetic examples and alternative scenarios. They may also identify patterns in data or suggest model structures. However, an AI-generated answer is not evidence that the formula is correct, the data are lawful to use or the recommendation is fair.

A responsible workflow is:

1. Define the problem and acceptance criteria independently.
2. Provide the tool only with information authorised for that purpose.
3. Ask for explicit assumptions, units and sources.
4. Inspect every formula, transformation and code dependency.
5. Test against hand-calculated examples and edge cases.
6. Compare outputs with a simple baseline.
7. Conduct subgroup, privacy and security checks.
8. Obtain human review before consequential use.
9. Record prompts, model versions, data versions and approvals.
10. Monitor performance after deployment and provide a correction route.

AI systems can produce fabricated citations, insecure code, plausible but invalid reasoning and biased recommendations. Confidential information should not be pasted into a public service without authorisation. Organisations should define approved tools, retention rules, access controls and review responsibilities.

7. Responsible Automated Decision-Making

Privacy and data protection

Data minimisation means collecting only what is necessary for a specified purpose. Other safeguards include purpose limitation, retention schedules, access controls, encryption, pseudonymisation and secure deletion. Removing names does not guarantee anonymity: records may be re-identified by combining location, date and other attributes. Sensitive attributes require particular care, but excluding them from a model does not necessarily remove bias because proxy variables may remain.

A privacy assessment should ask: What is the lawful purpose? Which data are necessary? Who can access them? How long are they retained? Can individuals challenge an outcome? What happens after a breach?

Bias and fairness

Bias can enter through historical decisions, sampling, measurement, labels, feature selection, thresholds and deployment. Fairness is not one universal equation. Possible measures include group error rates, selection rates and calibration, but these can conflict when groups have different base rates. A technical metric must therefore be connected to a normative and legal decision about what fairness means in context.

Useful questions include:

• Is the target variable a valid measure of the desired outcome?
• Are some groups missing or under-represented?
• Does performance differ by group, location, language or disability?
• Will a seemingly neutral threshold produce unequal effects?
• Who benefits and who bears the risk of error?

Explainability and contestability

An explanation should be appropriate to its audience. Global explanations describe general model behaviour; local explanations describe why a particular case received an output. Feature importance is not automatically causation, and a simple explanation can be misleading if it omits uncertainty or human review.

People affected by consequential decisions should receive understandable information about the decision process, relevant factors, limitations and routes for correction. Human oversight must be meaningful: a reviewer should have authority, time, information and competence to disagree with the system.

Governance and accountability

Governance assigns responsibility across the model life cycle: design, procurement, data preparation, validation, deployment, monitoring, incident response and retirement. A model card or equivalent record may document purpose, intended users, data, evaluation, limitations, subgroup performance and prohibited uses. An audit trail should record input versions, model versions, decisions, overrides and approvals, subject to privacy requirements.

Regulatory obligations vary by jurisdiction and application. High-impact uses may require impact assessments, transparency, security controls, human oversight and records. Compliance is a minimum requirement, not proof that a model is socially beneficial.

8. Illustrative Case: Public Library Staffing Forecast

Background. A municipal library wants to schedule staff across five branches. It has hourly visitor counts, opening hours, staff skills and a limited budget. The proposed system forecasts hourly demand and recommends staffing.

Problem. A simple average forecast reduces total scheduled hours but creates queues at two branches during school holidays. Historical counts also under-record visitors who use digital services or leave before being served.

Analysis. The team defines the objective as minimising expected waiting time and labour cost, subject to minimum safety staffing and skill requirements. Demand is measured in visitors per hour, and staff capacity is measured in visitors served per productive staff-hour. The team separates training, illness and leave from demand effects. It evaluates errors by branch, hour, holiday period and neighbourhood.

Approach. A transparent baseline uses the same weekday and seasonal averages from prior years. A more complex forecast is tested only if it improves out-of-sample performance and does not create unacceptable subgroup errors. A scenario table examines ordinary, high-demand and staff-absence conditions. The recommendation is reviewed by branch managers, who can override it with a recorded reason. Visitor-level data are not needed, so the system uses aggregated counts and a short retention period.

Outcome. The model is accepted as decision support rather than an automatic scheduler. Managers receive forecasts, confidence ranges and a warning when conditions differ from training data. After deployment, the team monitors queue times, staff workload, forecast error and branch differences. The system is withdrawn for review if data quality falls below an agreed threshold.

Learning points. A technically accurate forecast is insufficient if the target is incomplete, constraints are omitted or users cannot challenge the output. The strongest design combines a simple baseline, explicit assumptions, measured performance, human accountability and continuous monitoring.

9. Best Practices and Limitations

A professional modelling checklist is:

• Define the decision, users, affected people and acceptable errors.
• Record variables, units, sources, assumptions and constraints.
• Start with the simplest adequate model and a baseline.
• Separate training, validation and test evidence where prediction is involved.
• Verify formulas and code independently.
• Test boundary cases, missing values and adversarial inputs.
• Use sensitivity and scenario analysis before presenting a single number.
• Report uncertainty, not false precision.
• Assess privacy, fairness, security and accessibility.
• Document ownership, approvals, versions, overrides and monitoring.
• Provide explanation and appeal mechanisms for consequential decisions.

Models have inherent limitations. Data may be incomplete, relationships may change, historical patterns may encode unfair treatment and optimisation may encourage gaming. Correlation does not establish causation. A model can also become invalid after a policy change, economic shock or change in user behaviour. Monitoring and periodic revalidation are therefore part of modelling, not optional administrative tasks.

Contemporary Developments

Modern modelling increasingly combines spreadsheets, cloud data platforms, software pipelines, machine learning, simulation and generative AI. This creates opportunities for faster experimentation but also increases dependency, complexity and supply-chain risk. Emerging practice emphasises lifecycle governance, model registries, reproducible pipelines, privacy-enhancing techniques, human-centred design and continuous evaluation after deployment. The important professional skill is not merely operating a tool; it is judging when a tool is appropriate, documenting why, and remaining accountable for its consequences.

Chapter Summary

Mathematical modelling translates a real decision into variables, relationships, objectives and constraints. Descriptive, predictive, prescriptive and simulation models serve different purposes. Spreadsheets provide transparency for small models, while programs support scale, testing and reproducibility. Verification checks implementation; validation checks whether the model is fit for purpose. Dimensional analysis, boundary tests, historical evaluation, residual analysis and expert review help reveal errors.

Sensitivity and scenario analysis show how assumptions affect outcomes. AI-assisted tools can accelerate coding and analysis, but their outputs require independent verification, authorised data use and human judgement. Responsible automated decision-making requires privacy protection, bias assessment, explainability, contestability, security, governance and post-deployment monitoring. A model should be treated as decision support embedded in a social and organisational context, not as an unquestionable authority.

Key Terms

Mathematical model: A simplified representation of a system used for analysis or decision support.

Input: A quantity supplied to a model.

Parameter: A model characteristic treated as fixed for an analysis.

Decision variable: A quantity selected by a decision-maker.

Constraint: A condition limiting allowable decisions or outputs.

Objective function: A mathematical expression to maximise, minimise or evaluate.

Descriptive model: A model that summarises observed conditions or events.

Predictive model: A model that estimates future or unknown outcomes.

Prescriptive model: A model that evaluates or recommends actions.

Verification: Checking whether a model is implemented according to its specification.

Validation: Checking whether a model represents the real system adequately for its purpose.

Residual: The observed value minus the predicted value.

Sensitivity analysis: Study of output changes caused by changes in inputs or parameters.

Scenario analysis: Evaluation of a model under coherent alternative assumptions.

Uncertainty: Imperfect knowledge about inputs, parameters, structure or outcomes.

Bias: Systematic distortion that can produce inaccurate or unfair results.

Explainability: The ability to communicate how a model produces or supports an output.

Data minimisation: Collecting and retaining only data necessary for a specified purpose.

Model governance: Processes assigning responsibility, controls and oversight throughout a model’s life cycle.

Contestability: The ability of affected people to question, correct or appeal a decision.

Review Questions

Short Answer Questions

1. Distinguish a model input, parameter and decision variable.
2. What is the difference between verification and validation?
3. Why are units useful when checking a mathematical model?
4. Define sensitivity analysis and scenario analysis.
5. State two risks of using generative AI to create model code.

Long Answer Questions

1. Explain how a real organisational problem can be translated into variables, objectives, constraints and outputs.
2. Compare spreadsheet-based modelling with program-based modelling, including strengths and risks of each.
3. Describe a comprehensive validation process for a predictive model.
4. Explain how privacy, bias and explainability affect automated decision-making.
5. Discuss why a model with good average predictive accuracy may still be inappropriate for deployment.

Analytical / Application Questions

1. A service has fixed monthly cost of £90,000, revenue of £40 per unit and variable cost of £25 per unit. Calculate the break-even quantity using q₀ = F/(a − c). Then identify one assumption that could make the result unreliable.
2. Design a sensitivity analysis for a staffing model in which demand, productive hours per worker and service time are uncertain. Specify the variables, scenarios and outputs to monitor.
3. A university uses an automated system to prioritise scholarship applications. Propose a responsible deployment plan addressing data minimisation, subgroup evaluation, explanations, human review, audit records and appeals.

Multiple Choice Questions with Answers

Question 1

Which component of a prescriptive model represents a quantity selected by the decision-maker?

A. Decision variable

B. Residual

C. Input record

D. Validation metric

Correct Answer: A. Decision variable

Question 2

A system processes 15 requests per hour for 4 hours. How many requests does it process under a constant-rate assumption?

A. 19 requests

B. 60 requests

C. 3.75 requests

D. 0.27 requests

Correct Answer: B. 60 requests

Question 3

What does verification primarily examine?

A. Whether the model is socially popular

B. Whether the implementation follows its specification

C. Whether all predictions are correct

D. Whether the model uses artificial intelligence

Correct Answer: B. Whether the implementation follows its specification

Question 4

For observed value y_i and predicted value ŷ_i, which expression is the residual?

A. y_i + ŷ_i

B. y_i ŷ_i

C. y_i − ŷ_i

D. ŷ_i − 1

Correct Answer: C. y_i − ŷ_i

Question 5

A benefit model is B = (50 − 30)q − 120000. What is the break-even quantity?

A. 2,400 units

B. 4,000 units

C. 6,000 units

D. 8,000 units

Correct Answer: C. 6,000 units

Question 6

Which practice best supports spreadsheet reliability?

A. Hard-coding every constant inside formulas

B. Separating labelled inputs, calculations, outputs and checks

C. Removing units to make the sheet shorter

D. Avoiding test cases

Correct Answer: B. Separating labelled inputs, calculations, outputs and checks

Question 7

Why can removing names from a dataset fail to guarantee privacy?

A. Names are always required for encryption

B. Other attributes may permit re-identification

C. Anonymised data cannot be stored

D. Aggregated data are always inaccurate

Correct Answer: B. Other attributes may permit re-identification

Question 8

Which statement about feature importance is correct?

A. It always proves causation

B. It is identical to a legal explanation

C. It can describe model behaviour but does not automatically establish causation

D. It eliminates the need for human review

Correct Answer: C. It can describe model behaviour but does not automatically establish causation

Question 9

What is a key purpose of scenario analysis?

A. To conceal uncertainty behind one forecast

B. To evaluate outputs under coherent alternative assumptions

C. To guarantee that a model is unbiased

D. To replace all validation data

Correct Answer: B. To evaluate outputs under coherent alternative assumptions

Question 10

Which action is most responsible before deploying an AI-assisted decision tool?

A. Accepting generated code without inspection

B. Uploading confidential data to any public service

C. Testing outputs, documenting assumptions and arranging human oversight

D. Removing all override mechanisms

Correct Answer: C. Testing outputs, documenting assumptions and arranging human oversight