How statisticians, actuaries and operations research analysts work: the math they use, pairing it with code, credentials, evidence, and explaining results honestly.

Foundations for Math, Statistics & Analytics Careers

Write the result the way an analyst might first write it, with the point estimate, the interval and any technical terms.

Rewrite the headline as one sentence that starts with the decision it affects, for example: 'We should plan for between X and Y.'

Express one probability as a natural frequency (for example '3 in 10' instead of '30%'), and any risk change in absolute terms as well as relative terms.

Add one sentence on what drives the uncertainty and one on what would narrow it.

Replace every vague word (likely, significant, probably) with a number or remove it.

Make a simple chart or sketch that shows the range, not just a single number.

Explain it out loud to your listener in under one minute, then ask them to repeat back what they would do.

Note anything they misunderstood and revise your wording.

## Why this matters

Every analysis carries uncertainty: the sample might be unrepresentative, the future might differ from the past, the model is a simplification. Managers and clients still need to make decisions. If you hide the uncertainty, they will be overconfident; if you bury them in caveats, they will ignore you. Explaining uncertainty clearly, in terms of the decision, is one of the most valued skills in statistics, actuarial work and operations research.

## Say a range, not just a number

A **point estimate** is a single best guess: "We expect 1,200 claims next quarter." It sounds precise but hides how wrong it could be. A **range** shows the uncertainty: "We expect about 1,200 claims, very likely between 1,050 and 1,350."

Statisticians often report a **confidence interval**, for example a 95% interval. Technically, a 95% confidence interval comes from a procedure that captures the true value in about 95% of repeated samples. In plain language for a non-specialist you can say: "Our best estimate is 1,200; the data are consistent with anything from about 1,050 to 1,350."

For forecasts, a **prediction interval** describes where a future value is likely to fall. It is usually wider than a confidence interval for an average, because individual outcomes vary more than averages.

## Use numbers, not vague words

Words like "likely", "possible" or "significant" mean different things to different people. In studies of how people interpret these words, "likely" has been read as anything from about 50% to over 90%. Some organisations fix the meanings: the Intergovernmental Panel on Climate Change, for example, uses "likely" to mean a 66 to 100% probability. Unless your audience shares a defined scale, give the number.

The word "significant" is especially risky. In statistics it means a result is unlikely to be explained by chance alone under a particular test; to a manager it means "large and important". A tiny effect can be statistically significant in a big sample. Say how big the effect is.

## Natural frequencies and absolute risk

People understand counts better than percentages and conditional probabilities.

- **Natural frequencies:** "3 out of every 10 similar projects ran over budget" is easier to grasp than "a 30% probability of overrun".
- **Absolute versus relative risk:** "The new process cuts defect risk by 50%" sounds dramatic. If defects fall from 2 in 1,000 to 1 in 1,000, say both: "It halves defects, from 2 per 1,000 parts to 1 per 1,000."

## Worked example: a staffing forecast

An analyst forecasts call-centre volume for next month.

**Technical version:** "The model's point forecast is 42,000 calls, with an 80% prediction interval of 38,000 to 47,000. The upper tail is heavier due to weather-related surges."

**Manager version:** "Plan for about 42,000 calls. In 8 out of 10 months like this, volume falls between 38,000 and 47,000. The bigger risk is on the high side, mostly from storms. If we staff for 42,000, we have roughly a 1 in 10 chance of more than 47,000 calls and long waits. Staffing for 45,000 would cost about 6% more and cut that risk substantially. The forecast will tighten once we have the first week's data."

The manager version starts from the decision, gives a range, uses natural frequencies, says which direction the risk lies, offers options with costs and says what would reduce the uncertainty.

## Show the uncertainty in charts

- Draw intervals as error bars or shaded bands, not just a line.
- For forecasts, a "fan chart" with darker bands for more likely ranges works well.
- Label what the band means ("80% of outcomes fall in the shaded area").
- Avoid chart styles that imply false precision, such as many decimal places.

## Common mistakes

- **Reporting a single number** as if it were certain.
- **Using "significant" without saying how big.** Give the size of the effect.
- **Relative risk alone.** Always give the baseline.
- **Too many caveats.** Keep the main uncertainty in the headline; put the technical details in an appendix.
- **Implying certainty you do not have**, or false precision such as "1,203.6 claims".

## Quick recap

- Give a best estimate and a range, and say what the range means in plain words.
- Replace vague words with numbers; distinguish statistical significance from importance.
- Use natural frequencies and absolute risk; start from the decision and show uncertainty in charts.

## Try it

Open the **Do** tab and rewrite an uncertain result for a non-specialist, then test it on a listener.


Explain a range and a probability clearly to a manager who is not a specialist.

Explaining uncertainty

Communicating uncertainty

Confidence Intervals, Clearly Explained!!!

Create a project folder with subfolders: data/raw, data/processed, src (or notebooks), output, and a README file.

Put the downloaded dataset in data/raw, and write in the README where it came from, the download date and its licence.

Write a short script or notebook that reads only from data/raw, does one cleaning step, and saves the cleaned file to data/processed.

Add one analysis step that produces a table or chart in output/. If anything is random, set a seed.

Record the software and library versions you used in the README or a requirements file.

Restart your Python or R session completely and run everything from the top. Fix anything that fails.

Write the exact commands or steps to reproduce the results at the top of the README.

Optional: put the folder under version control with Git and make a first commit (do not commit private or very large data files).

## Why this matters

An analysis that only works on your laptop, in your head, on the day you ran it, is fragile. Next month the data updates and you cannot remember which cells you ran. A colleague cannot check your numbers. An auditor or regulator asks how a reserve figure was calculated and nobody can say. **Reproducible analysis** means someone else, or future you, can rerun the work from the raw data and get the same results. In actuarial work and regulated industries this is often required; everywhere else it is simply good practice.

## Reproducible versus replicable

- **Reproducible:** same data, same code, same results.
- **Replicable:** new data, same method, consistent conclusions.

This lesson is about the first. It is the foundation for the second.

## The core habits

**1. Never edit raw data.** Keep the original files exactly as downloaded or delivered. Every cleaning step happens in code, and the output is saved as a new file. Anyone can then see and rerun every change.

**2. Use a clear folder structure.**

```text
claims-analysis/
  README.md          what this is, where the data came from, how to run it
  requirements.txt   software and versions
  data/
    raw/             original files, never edited
    processed/       outputs of cleaning scripts
  src/               scripts or notebooks, numbered in run order
  output/            tables and charts for the report
```

**3. Script everything.** Avoid manual copy-paste steps between tools. If a step must be manual, write it down in the README.

**4. Make notebooks run from top to bottom.** Notebooks such as Jupyter are excellent for exploring, but cells run out of order can produce results that cannot be recreated. Before you share, restart the kernel and run all cells in order.

**5. Set seeds for randomness.** Simulations, train/test splits and random samples should use a fixed seed so results repeat.

**6. Record versions.** Library updates can change results. List the versions you used, for example in a `requirements.txt` file.

**7. Use version control.** Git records every change to your code with a message explaining why. It also lets you go back to the exact code behind last quarter's report.

**8. Write a README.** Explain the question, data sources (with dates and licences), how to run the analysis and where the outputs go.

## Worked example: turning a messy analysis around

**Before:** An analyst downloads a claims spreadsheet, deletes some rows that look wrong, adds a column by hand, copies a pivot table into a slide and emails it. A month later the manager asks for the same chart with new data. The analyst cannot remember which rows were deleted.

**After:**

1. The original file is saved in `data/raw/claims_2026-09.csv`.
2. `src/01_clean.py` removes rows with negative claim amounts (and logs how many), adds the new column and writes `data/processed/claims_clean.csv`.
3. `src/02_summary.py` builds the summary table and chart in `output/`.
4. The README says: "Run `python src/01_clean.py` then `python src/02_summary.py`."

Next month the analyst drops the new file in `data/raw`, updates one file name and reruns. The manager also asks why 37 rows were excluded; the cleaning log answers immediately.

## Make it checkable

- Add simple **sanity checks** in code: totals match the source, no negative ages, row counts are as expected.
- Print or save a short **log** of what each step did.
- Ask a colleague to run your project from the README before you rely on it.

## Privacy and data handling

Reproducibility does not mean publishing everything. Do not put personal, confidential or licensed data in public repositories. Share code and documentation, and describe how authorised people can obtain the data.

## Common mistakes

- **Editing raw files by hand.** Changes become invisible and unrepeatable.
- **Out-of-order notebooks.** Always restart and run all before sharing.
- **Hard-coded personal file paths** such as `C:/Users/me/Desktop`. Use paths relative to the project folder.
- **No record of versions or seeds.**
- **Committing secrets or private data** to version control.

## Quick recap

- Reproducible means same data plus same code gives the same results.
- Keep raw data untouched, script every step, use a standard folder layout, set seeds, record versions, use Git and write a README.
- Test by rerunning from a clean start, and have someone else try.

## Try it

Open the **Do** tab and set up a small reproducible project on your own computer.


Structure an analysis project so that someone else can rerun it and get the same results.

Reproducible analysis

Reproducible Data Analysis in Jupyter, Part 1/10: Loading and Visualizing Data

## Why this matters

Models decide who gets a loan, what an insurance policy costs, which patients get extra care and where police patrol. A model can be mathematically correct and still treat people unfairly, mislead decision-makers or be used for something it was never designed to do. Statisticians, actuaries and operations research analysts are often the people best placed to notice. Professional codes expect them to speak up.

## Where bias comes from

**Biased data.** If the historical data reflects past discrimination, a model trained on it learns that pattern. A well-known example: in 2018, Reuters reported that Amazon had abandoned an experimental recruiting tool after finding it penalised CVs that mentioned women's organisations, because it had learned from a decade of mostly male hires.

**Unrepresentative samples.** A survey or training set that under-represents some groups produces estimates that are less accurate for them.

**Proxy variables.** A model may not use a protected characteristic such as race directly, but other variables (postcode, school, shopping patterns) can stand in for it. This is called **proxy discrimination**.

**Wrong target.** A model can optimise the wrong thing. A widely cited 2019 study in *Science* by Obermeyer and colleagues found that a health-care algorithm used past health spending as a stand-in for health need. Because less money had historically been spent on Black patients with the same level of illness, the algorithm underestimated their need for extra care.

**Feedback loops.** If a model sends more inspections to one area, more problems are found there, which makes the model send even more inspections, regardless of where problems really are.

## Different ideas of fairness

There is no single mathematical definition of fairness. Common ones include:

- **Equal accuracy:** the model is equally accurate for each group.
- **Equal error rates:** for example, the same false positive rate across groups.
- **Calibration:** a predicted 30% risk means 30% for every group.

In 2016 ProPublica analysed a criminal risk-scoring tool (COMPAS) and reported that Black defendants who did not reoffend were more likely to be wrongly labelled high risk. The tool's maker argued it was equally calibrated across groups. Researchers later showed that, when groups have different underlying rates, it is mathematically impossible to satisfy all these fairness criteria at once. Choosing between them is an ethical and legal decision, not only a technical one, and it should be made openly.

## Misuse beyond bias

- **Using a model outside its purpose or range.** A model built to rank applicants for a scholarship is not valid for deciding who gets a job.
- **Hiding uncertainty** so a decision looks more certain than it is (lesson 1 of this module).
- **Data dredging (p-hacking):** testing many variations until one gives a "significant" result, then reporting only that one.
- **Goodhart's law:** when a measure becomes a target, people change their behaviour to hit the number, and it stops measuring what it used to.
- **Pressure to deliver a number.** Being asked to adjust assumptions until a project looks profitable or a reserve looks smaller.

## Worked example: reviewing an insurance pricing model

An actuary reviews a new car insurance model that uses 40 variables. Questions to ask:

1. **Legal:** which characteristics are prohibited or restricted by insurance regulation in this jurisdiction? Is any variable a close proxy for one?
2. **Data:** does the training data under-represent any group or region?
3. **Outcomes:** compare prices and error rates across groups and regions. Are differences explained by genuine differences in risk?
4. **Explainability:** can the insurer explain to a customer and a regulator why their price is what it is?
5. **Monitoring:** who checks the model after launch, and how often?

If something looks wrong, the actuary documents it, raises it with the responsible people and, if needed, follows the professional code's guidance on escalation.

## Professional codes

Each profession has written standards. The American Statistical Association publishes Ethical Guidelines for Statistical Practice at [amstat.org](https://www.amstat.org/your-career/ethical-guidelines-for-statistical-practice). Actuaries follow their society's Code of Professional Conduct (see [soa.org](https://www.soa.org/) and [casact.org](https://www.casact.org/)) and, in the US, the Actuarial Standards of Practice issued by the [Actuarial Standards Board](https://www.actuarialstandardsboard.org/). INFORMS publishes ethics guidelines for operations research and analytics at [informs.org](https://www.informs.org/). Checked on 2026-10-23.

Common themes: be honest about methods and limitations, respect privacy, avoid conflicts of interest, do not let clients or employers pressure you into misleading results, and consider who is affected by your work.

## Common mistakes

- **"The model is just math, so it is neutral."** Data, targets and choices carry values.
- **Removing a protected variable and assuming the problem is solved.** Check for proxies.
- **Checking only overall accuracy.** Look at results for each group.
- **Staying silent.** Professional codes expect you to raise concerns.

## Quick recap

- Bias enters through data, samples, proxies, wrong targets and feedback loops.
- Fairness has several definitions that cannot all hold at once; choose openly.
- Watch for misuse: wrong purpose, hidden uncertainty, p-hacking, Goodhart's law, pressure.
- Know your profession's code: ASA guidelines, actuarial codes and ASOPs, INFORMS ethics guidelines.

## Try it

This lesson has no activity. Watch the videos, then take the quiz in the **Do** tab.


Spot bias, proxies and misuse in statistical and decision models, and know the professional codes that apply.

Ethics of models

Algorithmic Bias and Fairness: Crash Course AI #18

The Truth About Algorithms | Cathy O'Neil

Explain uncertainty to non-specialists, make analyses reproducible, and recognise bias and misuse in models.