Technical, Data and AI Communication

Introduction and Context

Artificial intelligence and machine learning systems do not create value merely by producing accurate predictions. Their value depends on whether people can understand, evaluate, trust, govern and appropriately use their outputs. Communication is therefore a technical capability as well as a linguistic one. An AI practitioner may need to explain a model to software engineers, present performance results to executives, document a data pipeline for auditors, design a dashboard for operational staff, or explain an automated decision to an affected individual.

These audiences differ in prior knowledge, goals, authority and tolerance for uncertainty. A data scientist may want calibration curves and confidence intervals; a manager may need to know whether the system improves cost, safety or service quality; a customer may simply need to know why a decision was made and how to challenge it. Effective communication preserves technical truth while making information usable for a particular audience.

This chapter develops a practical framework for communicating technical, data and AI concepts. It addresses audience analysis, technical documentation, data visualisation, dashboards, model explanations, uncertainty, limitations, risk and responsible communication. The emphasis is on communication that supports sound decisions rather than merely impressive presentation.

Learning Objectives

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

1. Adapt technical explanations to specialist and non-specialist audiences.

2. Structure clear and maintainable technical documentation.

3. Select appropriate data visualisations and avoid misleading displays.

4. Design dashboards around decisions, users and operational context.

5. Explain model behaviour using appropriate global and local explanation methods.

6. Communicate uncertainty, assumptions, limitations and risk accurately.

7. Identify ethical, legal and governance responsibilities in AI communication.

8. Evaluate the quality of a technical explanation or data product.

1. Communication as Translation, Not Simplification

Technical communication is sometimes described as “simplifying” complex material. Simplification can be useful, but careless simplification removes qualifications, assumptions or uncertainty. A better description is translation: the communicator changes terminology, level of detail, examples and visual form while preserving the meaning that matters for the decision.

A useful communication chain is:

Evidence → interpretation → decision → action

Evidence may be a dataset, model output or evaluation result. Interpretation gives that evidence meaning. A decision applies criteria such as cost, safety or fairness. Action is what someone does as a result. Communication should make these links visible. For example, “the model has 92% accuracy” is incomplete. The audience also needs to know the task, evaluation data, class distribution, error types, time period and consequences of errors.

1.1 Audience analysis

Before communicating, identify:

• Purpose: inform, persuade, enable action, obtain approval or support accountability.
• Audience expertise: technical, domain-specific, managerial or public.
• Decision authority: what can the audience decide or change?
• Information needs: what evidence is necessary for that decision?
• Risk exposure: who bears the consequences if the information is misunderstood?
• Communication channel: report, presentation, dashboard, API documentation, meeting or public notice.

A technical explanation should be proportionate. Giving a non-specialist a mathematical derivation that does not help their decision creates cognitive load. Giving engineers only a high-level slogan prevents implementation and review. Good communication uses layered information: a concise conclusion first, followed by evidence, methods and technical detail for those who need it.

1.2 Plain language and precision

Plain language does not mean informal or imprecise language. It means direct wording, defined terms and a logical sequence. Compare:

• Weak: “The algorithm leverages a robust predictive architecture to optimise risk stratification.”
• Stronger: “The model estimates the probability that a patient will require readmission within 30 days. Clinicians use the estimate to identify patients who may benefit from additional review.”

The second version states the task, time horizon and intended use. It does not claim that the model identifies certainty or replaces clinical judgement.

A useful pattern is term–meaning–consequence:

1. Define the technical term.

2. Explain what it means in this system.

3. State why it matters to the audience.

For example: “Calibration measures whether predicted probabilities correspond to observed frequencies. A well-calibrated group of cases predicted at 0.7 should contain approximately 70% positive outcomes. Calibration matters because staff use the probability as a basis for allocating attention.”

2. Technical Documentation

Documentation is a durable form of communication. It enables reproducibility, maintenance, onboarding, auditing and responsible use. Documentation should be treated as part of system design, not as an administrative task performed at the end.

2.1 Documentation layers

A complete AI system commonly requires several related documents:

1. Purpose and scope document: problem definition, intended users, intended use and prohibited uses.

2. Requirements specification: functional requirements, performance expectations, interfaces and constraints.

3. Data documentation: sources, collection process, schema, units, missing values, labelling, transformations, licensing and known biases.

4. Model documentation: algorithm, features, training procedure, version, hyperparameters, evaluation design and limitations.

5. Deployment and operations documentation: infrastructure, dependencies, monitoring, rollback and incident procedures.

6. User documentation: workflow, interpretation guidance, warnings and escalation routes.

7. Governance record: approvals, risk assessment, access controls, retention and change history.

These documents should cross-reference one another. A model card, for example, should identify the dataset version used for evaluation; the data record should identify its provenance; and the operations record should show which model version is deployed.

2.2 Documentation quality criteria

Good documentation is:

• Accurate: statements correspond to the implemented system.
• Complete enough for purpose: critical assumptions and limitations are not omitted.
• Current: it reflects the deployed version.
• Traceable: claims can be linked to data, code, tests or decisions.
• Accessible: intended readers can find and understand relevant information.
• Actionable: it tells users what to do, including when not to use the system.

Documentation should distinguish facts, interpretations and recommendations. “The validation sample contained 12,000 records” is a fact. “Performance may decline after deployment” is an interpretation or risk assessment. “Review performance monthly” is a recommendation. Distinguishing these categories improves accountability.

2.3 Reproducibility and version control

A result is more credible when another qualified person can reproduce or inspect it. Documentation should record code version, data snapshot, feature transformations, random seeds where relevant, evaluation protocol and software environment. Reproducibility does not always mean obtaining exactly identical outputs; some algorithms are stochastic and hardware can affect numerical results. In such cases, the documentation should state the expected variation and the controls used.

A change log should record what changed, why it changed, who approved it and how the change was tested. A model that is retrained with new data is not automatically equivalent to the previous model, even if its name remains the same.

3. Communicating Data and Statistical Results

Data communication requires more than reporting numbers. The communicator must explain what was measured, how it was measured and what conclusions are justified.

3.1 Descriptive and inferential claims

A descriptive claim summarises observed data: “Average waiting time in the sample was 18 minutes.” An inferential claim extends beyond the observed data: “The intervention reduced waiting time.” The second claim requires a suitable design, comparison and consideration of alternative explanations.

Important distinctions include:

• Correlation is not causation. Two variables may move together because of confounding, reverse causation or coincidence.
• Sample performance is not necessarily population performance. A model tested on one hospital or time period may not generalise elsewhere.
• Statistical significance is not practical importance. A small effect may be detectable in a large sample but irrelevant operationally.
• Average performance may hide subgroup differences. Overall accuracy can coexist with poor performance for a minority group.

When reporting a percentage, provide the denominator and population. “A 20% improvement” is ambiguous: it might mean a relative increase from 10 to 12 or an absolute increase of 20 percentage points from 50% to 70%.

3.2 Communicating uncertainty

Uncertainty is not a defect in communication; it is information about the strength and limits of knowledge. Common forms include:

• Measurement uncertainty: the quantity was not observed perfectly.
• Sampling uncertainty: results vary because only part of a population was observed.
• Model uncertainty: different plausible models produce different outputs.
• Data or distribution uncertainty: future cases may differ from training or evaluation cases.
• Aleatoric uncertainty: inherent variability in the phenomenon being predicted.
• Epistemic uncertainty: uncertainty caused by limited knowledge or data.

For a probability prediction, communicate that a probability is not a guarantee. If a model assigns a group of cases a probability of 0.8, a calibrated interpretation is that approximately 80% of comparable cases are expected to have the outcome over the relevant population and time period. It does not mean that each individual case has an “80% outcome.”

Confidence intervals, prediction intervals and probability ranges should be labelled correctly. A confidence interval describes uncertainty in an estimated parameter under specified assumptions; it is not automatically a range containing a fixed individual outcome. A prediction interval concerns a future observation and generally includes more variation.

3.3 Communicating risk

Risk communication should distinguish:

• Probability: how likely an event is.
• Impact: how serious the consequences are.
• Exposure: who or what is affected.
• Controls: measures that reduce likelihood or impact.
• Residual risk: what remains after controls.

A risk matrix can support prioritisation, but it is not a precise probability model. Categories such as “high” and “low” require definitions. A responsible report states the basis for ratings and avoids suggesting that a coloured cell is an objective measurement.

4. Data Visualisation

Visualisation is a reasoning tool. It can reveal trends, distributions, anomalies and relationships, but it can also mislead through inappropriate scales, selective data or decorative complexity.

4.1 Matching chart to question

• Comparison: bar chart or dot plot.
• Trend over time: line chart, with clear time intervals.
• Distribution: histogram, box plot or density plot.
• Relationship between two quantitative variables: scatter plot.
• Part-to-whole: a segmented bar; pie charts should be used sparingly when categories are few and comparison is simple.
• Geographic pattern: map, only when location is analytically relevant.
• Model performance: confusion matrix, ROC curve, precision–recall curve, calibration plot or error-by-group chart, depending on the question.

The chart type should follow the analytical task, not personal preference.

4.2 Principles of honest visualisation

Axes, units, time periods and denominators must be visible. Truncating a bar chart axis can exaggerate differences because bar length is interpreted from a common baseline. Line charts may use a nonzero baseline in some contexts, but the choice should be made explicit and should not distort interpretation. Colour should communicate meaning, remain readable in grayscale where possible and be accessible to people with colour-vision differences.

Avoid three-dimensional effects, unnecessary decoration and excessive precision. A chart displaying values to six decimal places suggests accuracy that the measurement process may not support. Annotation should identify the relevant event, not merely repeat the title.

4.3 AI performance visualisation

No single metric fully describes a classifier. For binary classification, a confusion matrix contains true positives, true negatives, false positives and false negatives. From it:

• Accuracy = (TP + TN) / (TP + TN + FP + FN)
• Precision = TP / (TP + FP), when TP + FP is nonzero.
• Recall (sensitivity) = TP / (TP + FN), when TP + FN is nonzero.
• Specificity = TN / (TN + FP), when TN + FP is nonzero.

These metrics answer different questions. Precision asks, “Among predicted positives, how many were positive?” Recall asks, “Among actual positives, how many were detected?” Their usefulness depends on the cost of errors and the decision context. Class imbalance can make accuracy particularly uninformative.

The receiver operating characteristic curve shows the trade-off between true-positive rate and false-positive rate across thresholds. The precision–recall curve is often more informative when positive cases are rare. Neither curve by itself determines the operationally correct threshold; that requires costs, capacity, policy and stakeholder judgement.

5. Dashboards for Decisions

A dashboard is not simply a collection of charts. It is an interface for monitoring conditions and taking action. Its design should begin with decisions and workflows.

A practical dashboard design process is:

1. Identify the users and decisions.

2. Define key questions and indicators.

3. Specify data sources, refresh rates and ownership.

4. Establish thresholds and escalation rules.

5. Design a hierarchy from overview to diagnosis.

6. Test with representative users.

7. Monitor whether the dashboard changes decisions appropriately.

A good operational dashboard normally contains a small number of prominent indicators, trends, comparisons with targets and a route to underlying detail. Every metric needs a definition. “Active users,” for example, could mean users who logged in, completed an action or generated an event during a stated period.

Dashboards should show data freshness, missingness and quality warnings. A green indicator based on data that stopped updating yesterday is dangerous. Automated alerts should include context and recommended action; too many alerts produce alert fatigue.

Worked Example: Interpreting a classification result

Suppose a screening model is evaluated on 1,000 cases. There are 100 actual positive cases. The model identifies 80 of them, so TP = 80 and FN = 20. Among the 900 actual negative cases, it incorrectly flags 90, so FP = 90 and TN = 810.

Accuracy is (80 + 810) / 1,000 = 0.89, or 89%.

Precision is 80 / (80 + 90) = 80/170 ≈ 47.1%.

Recall is 80 / (80 + 20) = 80/100 = 80%.

Specificity is 810 / (810 + 90) = 810/900 = 90%.

A non-specialist summary should not report only the 89% accuracy. It should explain that the model detects 80% of actual positive cases, while fewer than half of its positive alerts are true positives in this evaluation. Whether this is acceptable depends on the cost of missed cases, unnecessary follow-up and available capacity. The figures also depend on the evaluation population and threshold.

6. Explaining AI Models

Model explanation has several meanings. It may refer to explaining the model’s general behaviour, a particular prediction, the importance of input variables, the decision process, or the limitations of the evidence. These are not interchangeable.

6.1 Global and local explanations

A global explanation describes overall behaviour, such as performance by subgroup, partial dependence patterns or feature importance across a dataset. A local explanation addresses one prediction, such as why a particular application was assigned a high score.

Feature importance can be useful but is easy to overinterpret. Importance may reflect correlation rather than causation, and a feature being influential does not mean changing it would change the outcome. In correlated data, importance may be distributed among related variables or assigned inconsistently.

Methods such as LIME and SHAP can provide local or global approximations, but explanations are model- and context-dependent. They should be validated for stability and fidelity. An attractive explanation is not necessarily a faithful explanation.

6.2 Counterfactual explanations

A counterfactual states what would need to be different for an outcome to change, for example: “If verified income had been higher while other relevant conditions remained comparable, the score might have crossed the review threshold.” Counterfactuals must respect feasibility, causality, privacy and policy. Telling someone to change an immutable or protected attribute is inappropriate. A counterfactual should not imply that the individual alone caused the decision when the system also reflects institutional processes and historical data.

6.3 Explanation standards

An explanation should be:

• Accurate or faithful: it represents the system rather than a convenient story.
• Understandable: the intended audience can interpret it.
• Relevant: it addresses the decision and available actions.
• Complete enough: material limitations and uncertainty are disclosed.
• Non-deceptive: it does not imply causation, certainty or human-like reasoning without justification.

In high-impact settings, explanation should be supplemented by human review, appeal procedures, audit logs and documentation of the decision context.

7. Case Study: An Illustrative University Student-Support Dashboard

Background

A fictional university develops a model intended to identify students who may benefit from early academic support. The model uses attendance records, assessment submissions, prior progression information and engagement with learning systems. It produces a risk score for advisers.

Problem

The initial proposal presents a dashboard with a single red, amber or green label. Advisers worry that students may be treated as “at risk” without understanding why, and the institution has not defined how scores should be used. Students are concerned about privacy and the possibility that a historical disadvantage will be reproduced.

Analysis

The technical team finds that the model has good overall discrimination in historical data but weaker performance for a small student subgroup. Attendance data are also missing more often for students studying through placement arrangements. The model score is a probability estimate, not a diagnosis. A red label could result from several different patterns, and the model does not establish the cause of academic difficulty.

Approach and solution

The team redesigns the communication system as follows:

1. The dashboard displays the score, date of last update, evaluation population and a clear statement that it supports—not replaces—adviser judgement.

2. Advisers see contributing evidence categories, such as repeated missed submissions, but not misleading causal claims.

3. Missing-data warnings appear prominently.

4. The dashboard provides suggested questions for a supportive conversation rather than an automatic intervention.

5. Students receive a plain-language notice explaining the purpose, categories of data used, limits of prediction and route for correction or appeal.

6. The model is evaluated by subgroup using recall, precision and calibration, not only overall accuracy.

7. Access is restricted, activity is logged, retention periods are defined and advisers receive training.

8. The institution monitors outcomes for unintended effects and reviews the model before significant changes in data or policy.

Outcome

In this illustrative case, the redesigned dashboard improves transparency and reduces the risk that a score becomes a fixed label. Advisers report that the additional context supports more constructive conversations. However, the system does not eliminate risk. Students may still be misclassified, data may be incomplete and staff may over-rely on the visual signal. Continuous evaluation and human accountability remain necessary.

Learning points

The case demonstrates that communication is part of the control system. A technically valid model can produce harm if its interface implies certainty, hides missing data or fails to provide challenge and correction. Effective communication aligns model outputs with human decisions, institutional responsibilities and affected people’s rights.

8. Ethical, Legal and Governance Considerations

AI communication can distribute power. People who control technical language may influence decisions while affected groups lack the information needed to challenge them. Ethical communication therefore requires attention to fairness, accessibility, privacy and accountability.

Do not disclose personal or sensitive information unnecessarily. Explain data use, retention, access and legitimate purpose in language people can understand. Avoid presenting protected attributes as causes of individual outcomes when they are used only for auditing, and document why such attributes are included or excluded.

High-impact uses may be subject to data-protection, equality, consumer-protection, sector-specific and emerging AI regulation. Legal requirements vary by jurisdiction, but responsible practice commonly includes transparency, data minimisation, security, human oversight, impact assessment, record keeping and mechanisms for contesting decisions. Compliance should not be treated as a substitute for ethical judgement.

Communicators should disclose conflicts of interest, selective reporting, known performance gaps and material limitations. Marketing claims such as “bias-free,” “fully autonomous” or “understands human behaviour” are generally indefensible without exceptionally strong evidence and precise definitions.

9. Contemporary Developments and Professional Practice

Generative AI is increasingly used to draft documentation, summarise analyses, generate code and create explanatory text. Its outputs require review because it can invent sources, omit caveats, expose confidential information or describe an implementation inaccurately. Organisations should define approved tools, data-handling rules, review responsibilities and attribution practices.

Interactive explanation systems are also becoming more common. These can let users inspect scenarios, compare thresholds and view subgroup performance. Interactivity is valuable only when the underlying definitions and data are stable; otherwise, it can create a false impression of control.

Professional practice increasingly connects documentation with machine-readable metadata, model registries, data lineage and automated monitoring. This supports traceability, but automation does not remove the need for judgement. A monitoring alert still requires someone to interpret its significance and decide on an intervention.

10. Best-Practice Checklist

Before releasing a technical, data or AI communication product, ask:

• Is the purpose and audience explicit?
• Are key terms, units, denominators and time periods defined?
• Are claims supported by appropriate evidence?
• Are uncertainty, assumptions and limitations visible?
• Does the visualisation match the question and avoid distortion?
• Are model performance and subgroup differences reported appropriately?
• Does the explanation distinguish correlation from causation?
• Can users tell what action to take and when to escalate?
• Are data freshness, missingness and version information available?
• Are privacy, accessibility, fairness and appeal considered?
• Has the content been tested with representative users?
• Is ownership for maintenance and correction assigned?

Chapter Summary

Technical, data and AI communication translates evidence into forms that different audiences can understand and use without losing essential qualifications. Effective communication begins with purpose, audience and decision context. Technical documentation supports reproducibility, maintenance, governance and accountability through clear records of scope, data, models, deployment and change.

Data communication must distinguish description from inference, correlation from causation, statistical significance from practical importance and probability from certainty. Visualisations should match analytical questions, disclose units and denominators, and avoid misleading scales or decoration. Dashboards should be designed around decisions, workflows, data quality and escalation rather than around collections of attractive charts.

Model explanations may be global or local, descriptive or counterfactual, but they must be faithful, understandable, relevant and appropriately qualified. Performance metrics such as accuracy, precision, recall and specificity answer different questions and must be interpreted in context. The illustrative student-support case shows that interfaces, notices, review processes and governance are part of responsible AI system design. Ethical communication requires privacy, fairness, accessibility, transparency, human oversight and mechanisms for correction. Ultimately, trustworthy communication does not hide complexity; it organises complexity so that people can make better and more accountable decisions.

Key Terms

Audience analysis: Systematic identification of an audience’s expertise, needs, authority and risks.

Calibration: Agreement between predicted probabilities and observed outcome frequencies.

Confusion matrix: Table showing true positives, true negatives, false positives and false negatives.

Counterfactual explanation: Explanation describing a feasible change that could alter an outcome.

Dashboard: Visual interface that supports monitoring, interpretation and action.

Data lineage: Record of where data came from and how it was transformed.

Epistemic uncertainty: Uncertainty arising from limited knowledge or insufficient data.

Feature importance: Estimate of how influential variables are in model predictions.

Global explanation: Description of a model’s general behaviour across cases.

Local explanation: Explanation of an individual prediction.

Model card: Structured documentation of a model’s purpose, performance, limitations and use conditions.

Precision: Proportion of predicted positives that are actual positives.

Recall: Proportion of actual positives that are correctly identified.

Risk: Combination of the likelihood and impact of a harmful event.

Specificity: Proportion of actual negatives correctly identified.

Technical translation: Adapting technical content to an audience while preserving important meaning.

Uncertainty: Lack of complete confidence about a measurement, estimate, prediction or conclusion.

Visualisation: Graphic representation used to explore, explain or communicate data.

Review Questions

Short Answer Questions

1. Why is technical communication better understood as translation than simple simplification?

2. Distinguish precision from recall.

3. What information should accompany a percentage reported in an AI evaluation?

4. State two characteristics of high-quality technical documentation.

5. What is the difference between a global and a local model explanation?

Long Answer Questions

1. Explain how audience analysis influences the structure and content of an AI communication product.

2. Discuss the principles of honest and effective data visualisation, including examples of misleading practice.

3. Explain how uncertainty and limitations should be communicated when presenting model predictions.

4. Compare technical documentation, user documentation and governance documentation.

5. Discuss the ethical and organisational responsibilities involved in explaining high-impact AI decisions.

Analytical / Application Questions

1. A fraud model has high accuracy but detects only 35% of actual fraud cases. Analyse why accuracy may be inadequate and recommend additional metrics and communication points.

2. Design a dashboard for hospital managers monitoring an AI early-warning system. Specify users, decisions, indicators, warnings, refresh information and escalation actions.

3. A loan applicant asks why an automated system rejected an application. Propose a responsible explanation that distinguishes evidence, uncertainty, actionable factors, privacy constraints and appeal rights.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of translating technical information for different audiences?

A. To remove all technical detail

B. To preserve important meaning while adapting content to audience needs

C. To make every audience use identical terminology

D. To replace evidence with persuasive language

Correct Answer: B. To preserve important meaning while adapting content to audience needs

Question 2

Which metric answers the question: among predicted positive cases, how many were actually positive?

A. Recall

B. Specificity

C. Precision

D. Accuracy

Correct Answer: C. Precision

Question 3

In the worked classification example, what was the model’s recall?

A. 47.1%

B. 80%

C. 89%

D. 90%

Correct Answer: B. 80%

Question 4

Which visualisation is generally most appropriate for showing a distribution?

A. Histogram

B. Pie chart

C. Flow diagram

D. Network graph

Correct Answer: A. Histogram

Question 5

What does calibration of predicted probabilities concern?

A. Whether predictions correspond to observed frequencies

B. Whether a model has the fastest runtime

C. Whether all features have equal importance

D. Whether a dashboard uses accessible colours

Correct Answer: A. Whether predictions correspond to observed frequencies

Question 6

Which statement about feature importance is correct?

A. It always establishes that a feature causes an outcome

B. It may reflect correlation rather than causation

C. It proves that changing a feature will change a prediction

D. It is identical across all models and datasets

Correct Answer: B. It may reflect correlation rather than causation

Question 7

What should an operational dashboard prominently communicate when data stop updating?

A. A decorative colour change only

B. The data freshness or quality warning

C. A higher model score

D. A new definition of the metric

Correct Answer: B. The data freshness or quality warning

Question 8

Which is an example of epistemic uncertainty?

A. Unpredictable variation inherent in customer behaviour

B. Limited knowledge caused by insufficient training data

C. A confirmed measurement recorded by a sensor

D. A fixed business rule

Correct Answer: B. Limited knowledge caused by insufficient training data

Question 9

Why should a counterfactual explanation be checked for feasibility?

A. To ensure it recommends changes that are possible and appropriate

B. To guarantee that the model is perfectly accurate

C. To eliminate the need for human review

D. To ensure every applicant receives the same outcome

Correct Answer: A. To ensure it recommends changes that are possible and appropriate

Question 10

Which practice best supports reproducibility of an AI result?

A. Reporting only the final score

B. Removing all version information

C. Recording data, code, evaluation protocol and environment

D. Using persuasive language instead of technical details

Correct Answer: C. Recording data, code, evaluation protocol and environment