Narration

Decision-Grade for Practitioners Three is about interpretation and communication. This final session is about what you can honestly say from the data. We will use plain-English statistics, read charts for what they do and do not prove, and turn analysis into something a decision-maker can use without hiding uncertainty.

On-screen text

• Session 3 — Interpretation, Communication and Governed Visibility
• Your Organisation × Industrial Linguistics
• Session 3 of 3 140-minute facilitated session Last updated: 2026-07-05

Narration

Before starting the new material, do a quick self-check. Which parts of the course feel clearer now: metric definitions, source freshness, handling labels, traceability, dashboard trust, or decision context? The useful answer is specific. "Dashboards" is less useful than "I now know that dashboard refresh and source refresh are different." "Handling" is less useful than "I know that moving a summary across an environment boundary can still be a sharing decision." "Definitions" is less useful than "I know that active, deployed, and available can mean different things in different systems." The reason for this checkpoint is that Session 3 keeps returning to the same small set of questions. What is the source? Who owns it? How fresh is it? Which definition applies? What handling rule applies? What decision will it support? If those questions are not answered, AI makes the gap faster and harder to see.

On-screen text

• Quick recap of Sessions 1 and 2: definitions, handling, traceability, dashboards, decisions.
• Clearer?
• What feels clearer after Sessions 1 and 2?
• Still fuzzy?
• What still feels uncertain or under-defined?
• Hardest?
• Definitions, handling, traceability, dashboards, or communicating a recommendation?
• Poll, chat, or voice: all good.

Narration

There are six jobs today. Keep asking whether a chart, dashboard, or AI paragraph proves what it claims. Treat AI exhaust as a real data layer, because prompts, retrieval traces, logs, and summaries can reveal work patterns and sensitive inferences. Treat spreadsheet and document sprawl as a mapping problem. Keep governance separate from surveillance. Make the source of truth easier to find than the stale copy. Then communicate the result in a traceable, decision-ready form.

On-screen text

• Check claims
• Run plain-English checks before over-claiming from small or noisy numbers.
• Govern AI exhaust
• Recognise prompts, retrievals, transcripts, and summaries as a governed data layer.
• Map the estate
• Use a metadata-first, proportionate ladder for spreadsheet and document sprawl.
• Separate governance
• Tell governance apart from surveillance using purpose, notice, proportionality, access, and retention.
• Find truth
• Design root guides so humans and approved AI tools find the source of truth, not the stale copy.
• Communicate
• Produce traceable, decision-ready output in the capstone.

Narration

The next block applies the same inference logic to AI use itself. AI interactions leave traces. Some traces look like ordinary technical logs. Some look like collaboration history. Some look like records. Some look like drafts. Together, they can become a detailed picture of what people are asking, what sources they are using, which systems matter, and what operational issues are active. That residue is often called AI exhaust or AI debris. It is not useless. It can help with audit, records, cyber, source-traceability, and governance. But it is still data. It can be sensitive, misleading, incomplete, or over-interpreted. Ask two questions: what did the AI answer, and what did the interaction reveal?

On-screen text

On-screen text unavailable.

Narration

The prompt is only the most visible part of AI exhaust. An interaction can also leave retrieved files, search results, file names, access logs, and tool calls. It can also leave model metadata, generated summaries, output locations, and conversation history. Those traces may reveal which the document store folders are being searched, which spreadsheets are treated as authoritative, which reports are being reused, and which systems the user can reach. This matters because the traces can become evidence, and they can also reveal sensitive context. A prompt might mention a staff issue, a procurement concern, an incident, or a decision being prepared. A retrieval trace might reveal the files that are effectively the source of truth, even if no one has documented that. Treat exhaust as an operational data layer, not as harmless waste.

On-screen text

• Every AI interaction leaves a trail: "AI exhaust" or "AI debris".
• Prompts
• What people asked, and the shape of the work they were trying to do.
• Retrieved context
• Which files, records, or snippets the assistant pulled into the answer.
• Audit logs
• Who used the tool, when, and under what access pattern.
• Transcripts
• Chat history, file references, generated summaries, and follow-up prompts.

Narration

AI exhaust reveals what people ask the tool to do and where the tool looks for answers. Prompt topics, attached files, repeat queries, timing, and conversation titles show active work. Retrieval traces show which folders, spreadsheets, dashboards, records, and inboxes are treated as useful. That can become a source-of-truth map whether or not anyone meant to create one. It can help cyber, records, and data teams, but only with purpose, minimisation, access control, retention rules, aggregation, and review.

On-screen text

• What is being asked of AI
• Prompt topics, attached files, retrieved sources, frequency, repeat queries — a live read of what work people are actually doing.
• Where the answers come from
• Which spreadsheets, drives, documents, and inboxes the AI is reaching into — the de facto source-of-truth map for the agency.

Narration

AI exhaust is a rich signal, but rich signals are easy to misuse. Prompt volume is not productivity. Retrieval volume is not competence. Asking many questions might mean diligence, complexity, uncertainty, training, or a bad interface. Reading more files is not the same as doing more work. There is also a chilling effect. If staff believe every prompt title, attached file, and generated summary is being watched as a performance signal, they may change behaviour in unhelpful ways. They may stop using approved tools, write vaguer prompts, move work into less governed systems, or avoid asking for help. So the rule is: govern the exhaust before normalising the dashboard. Decide why the exhaust is collected, who can see it, how long it lasts, how it is aggregated, what it must not be used for, and how staff will be told.

On-screen text

• Wrong proxy
• Prompt volume is not productivity. Reading more is not the same as doing more.
• Chilling effect
• If staff believe prompts are being watched, behaviour changes.
• General privacy problems

Narration

The AI exhaust activity makes inference concrete. Each synthetic pack contains fragments: prompt logs, file activity, retrieval traces, chat fragments, and calendar subjects. No single record is meant to be an obvious secret. The question is what happens when the fragments are joined. Pause and ask four things. What operational activity appears to be happening? Which individual record looked harmless by itself? Which combination changed the risk? What false conclusion could a manager, vendor, staff member, media outlet, or external actor draw? The aim is not to become suspicious of every log entry. The aim is to design governance around the bundle: what should be retained for audit and record keeping, what should be aggregated or delayed, what should be access-controlled, and what should never become a productivity score.

On-screen text

• Pick one of the three packs
• Your job is to infer what operational activity may be happening.
• Which individual records looked harmless?
• Which combinations changed the risk?

Narration

AI exhaust is part of a bigger abundance problem. We already had too many documents, spreadsheets, dashboards, extracts, meeting packs, screenshots, and local copies. AI adds more material, faster, including things we might never have bothered to write before. The question stops being only "where is the file?" and becomes "which file is current, authorised, complete, safe to combine, and safe to use for this decision?"

On-screen text

On-screen text unavailable.

Narration

This is not the first time humans have had to respond to information abundance. When collections became too large to remember directly, people invented ordering and navigation systems. Alphabetical ordering, indexes, bibliographies, taxonomies, catalogues, and search engines all responded to the same basic pressure: there is more material than a person can hold in memory. AI creates another version of that pressure. Meeting transcripts, generated notes, summaries, draft explanations, prompt logs, retrieval traces, and automated outputs multiply faster than people can read. The lesson from history is that abundance creates a navigation problem, and the navigation problem becomes a governance problem. Who says what is authoritative? Which copy is stale? Which definition applies? Which audience is allowed to use it?

On-screen text

• The pattern: when knowledge becomes too large to hold using previous methods, something has to change.
• Stephanos of Byzantium → the Ethnika
• Alphabetical ordering makes encyclopaedic material searchable.
• Printing press → indexes and bibliographies
• More books require better tools for finding what is inside them.
• Linnaeus → taxonomy
• Classification makes large collections of living things usable.
• Dewey, catalogues, librarianship
• Hierarchies of knowledge: what you'll find where.
• The web → search engines
• Ranking and retrieval become the interface to too much information.

Narration

AI increases data volume in several ways. First, it makes recording and summarising ordinary activity cheap. Meetings that would once have disappeared now produce transcripts, summaries, and action logs. Second, AI creates its own traces: prompts, tool calls, retrieval logs, generated outputs, and edit history. Third, AI makes low-value documents cheap to produce. Tutorials, primers, onboarding notes, draft summaries, and exploratory analyses can appear because the cost of generating them is low. Some of that is genuinely useful. Some of it is stale, speculative, wrong, or redundant. The danger is that search does not automatically understand the difference. If low-value material is easier to find than the source of truth, it can become the answer.

On-screen text

• Documents get created even for the trivial
• Meeting notes, automated transcripts and summaries — capturing the everyday because the cost of doing so is near zero.
• AI exhaust: higher volume, granularity and interpretability
• Logs and audit trails have always existed; AI creates new exhaust — prompts, retrievals, tool traces — at much higher volume, granularity and interpretability.
• Too low value in the past
• AI-generated commentary, induction material and auto-generated primers — content not worth producing manually.
• Meta-analysis that is new
• AI sweeps over databases and file shares pulling out language patterns, vocabulary and mentions of people and places.

Narration

There are three escalating problems. The small problem is storage. More files require more storage, more archiving, and more disposal discipline. That matters, but storage can be bought. The bigger problem is search and retrieval. When there are many similar documents, it becomes harder for people and AI tools to find the current, authoritative artefact. Search results can become crowded with stale drafts, exported copies, old meeting packs, and generated summaries. The largest problem is governance. Definitions drift. Owners become unclear. Handling rules disappear. Outputs move faster than review. People and tools reuse whatever is easiest to find. You cannot solve the largest problem with storage alone. You need maps, guides, source-of-truth signals, and integrity rules.

On-screen text

• Small problem
• Extra storage required.
• Buy more storage. Archive more aggressively.
• Bigger problem
• Search and retrieval gets worse.
• Navigation guidance: indexes, catalogues, registers of truth.
• Even bigger problem
• Data control systems break down.
• Deliberate design for what happens at speed and scale.
• Severity escalates → solutions get structurally harder.
• More data creates three layered problems — and the answers get structurally harder at every step.

Narration

Use induction as a test of the knowledge system. Pick a folder, report, dashboard, spreadsheet, or recurring artefact. Imagine explaining it to an enthusiastic but naive new colleague. What lives there? What matters first? What is stale? What is the source of truth? What should not be reused? Who owns the definitions? What decision does it support? Now ask the key question: is there a document in the folder that says what you just said? If yes, would the new person find it? If no, the organisation is relying on oral tradition. The AI version is the same. Approved AI tools do not inherit team memory by magic. If the folder does not expose its purpose, authority, stale-copy warnings, definitions, owners, and handling rules, the tool will infer. Inference is where stale copies and wrong definitions become dangerous.

On-screen text

• Pick a folder or report, explain the contents there as if your partner is an enthusiastic but naïve intern
• What did you find yourself explaining?
• Is there a document already in existence that says what you said?
• If there is, where is it? Would the intern have found it themselves?
• If not, how would this intern learn about this folder or report?
• The key question: is your team’s current systems adequate for today and the future?

Narration

The new maps need to work for people and approved AI tools. They need to be human-readable, because staff need to understand and audit them. They need to be machine-readable, because AI search and retrieval need to see them. They need to be human-writable, because teams must maintain the guide. They may also be machine-assisted, because large information estates are too big to map perfectly by hand. A good map says where to look, what to trust, which files are authoritative, which files are stale, which definitions matter, who owns what, what handling applies, and what an approved assistant may summarise. The goal is not a perfect catalogue on day one. The goal is to stop people and tools from guessing silently.

On-screen text

• The new explosion
• Drafts, transcripts, summaries and AI outputs multiply faster than humans can read them.
• What's new this time
• The volume is machine-generated, so the solution has to be:
• Machine-readable
• Human readable
• Machine-writeable
• Human-writeable
• Search-engine friendly
• What’s needed
• Indexes that say where to look for documents, what to trust, purposes, definitions, etc.

Narration

Software development gives a useful analogy. Modern coding tools often read root-level guidance files. Those files explain how the project is structured, what conventions matter, which commands to run, and which files are unsafe to edit. The important point is not that every team should become a software team. The important point is that a workspace can carry instructions for how to work safely inside it. The same pattern can help repository sites, team spaces, shared drives, dashboard folders, and spreadsheet estates. A folder can tell people and approved AI tools what it is for, what is authoritative, what is stale, who owns it, and what handling rules apply.

On-screen text

• In software projects, tools such as Codex and Claude Code can use root-level guidance files like AGENTS.md or CLAUDE.md to understand structure, conventions and safe ways of working.
• Organisations need the same pattern for knowledge

Narration

The everyday version of a project guidance file might be a folder guide. It might be called start here, index, source of truth, read me, folder guide, or something local. The exact name matters less than the fact that people and tools can find it. The guide should answer practical questions. What is this folder for? Who is the audience? What is the handling level? Which files should be read first? Which files are records, drafts, snapshots, or stale copies? Which spreadsheet is authoritative? Who owns definitions? What can an approved assistant summarise? What requires owner confirmation? If a new staff member or approved AI tool cannot find that guidance, they will infer it from file names, search order, and whatever looks most recent. That is not good enough for decision work.

On-screen text

• For the document store, Teams, OneDrive, shared drives, dashboards and spreadsheet estates, the equivalent is a Folder Guide, Knowledge Map, Start Here file or Source-of-Truth note.
• Typical filenames (usually found in the folder itself):
• 00_START_HERE — Folder Guide.docx
• 00_INDEX.md or 00_SOURCE_OF_TRUTH.md
• README.md
• AGENTS.md or CLAUDE.md — (e.g. if you use Codex or Claude Cowork)

Narration

The goal is not to catalogue every spreadsheet perfectly on day one. Start by mapping the estate: where similar files live, which ones are current, which ones are stale copies, who owns the important folders, and where a person or AI tool should start reading.

On-screen text

• 1. Cluster by purpose. Group near-duplicates and abandoned drafts using filename patterns and modification age.
• 2. Inventory the shape, not the contents. Filenames, owners, locations, last-modified, size, sensitivity labels.
• 3. Identify what matters. The handful of files doing work become governed datasets with owners, as-at dates, and review points.
• 4. Make an initial folder roadmap. It does not have to be complete, or perfect.
• 5. Let the roadmap be updated. If people disagree about sources of truth, it is better to have that documented.
• 6. Find your upstream users. People who depend on your outputs should document that in the roadmap.

Narration

A useful folder guide has a few predictable parts. It names the purpose and audience. It states the handling level or the handling uncertainty. It lists the files to read first and the files that are source-of-truth records. It marks drafts, snapshots, exports, and stale copies. For spreadsheets, dashboards, reports, and meeting packs, it says what each is used for. Then it gives the operating context: key definitions, known limitations, owner, steward, and approver if relevant. It should also name the support contact, review date, and retention or disposal expectation. The AI-use note is now essential. What may an approved assistant summarise? What must it not use? What requires source-owner confirmation? What should never be inferred from this folder alone? A useful guide can admit uncertainty. That is better than forcing the next person or tool to guess.

On-screen text

• Purpose of this folder or knowledge area.
• Audience and handling level.
• Most important files to read first.
• Source-of-truth files; working files versus records.
• Key spreadsheets and what they are used for.
• Recurring reports, dashboards and meeting packs.
• Definitions that matter; known stale, retired or duplicate material.
• Owner, steward, approver and support contact.
• Review date and retention/disposal expectation.
• AI-use notes — what an approved assistant may summarise, what it must not use, what requires human or source-owner confirmation.
• Other folders or data sources to look at
• Comments that say “I’m not sure, but I think …”

Narration

Pause and build a rough folder navigator for one real or synthetic folder. It does not have to be polished. Start with the purpose of the folder. Add the source-of-truth file or dashboard. Mark known stale copies. Name the owner, steward, or support contact. Add the handling level. Add the review point. Add related folders. Add one line about what an approved AI assistant may summarise and what needs human confirmation. Then add one mistake-prevention line. One version might be, "Do not use the May export for current reporting." Another might be, "The dashboard refresh time is not the same as source freshness." Another version could be, "Use this workbook for budget actuals, not operational readiness." Or it might be, "Ask the owner before using vendor names outside this team." That one line may be the difference between a useful folder and a future error.

On-screen text

• Use the folder from the last exercise (or otherwise use the synthetic example from the website – FarWest site folder navigator)
• Create a folder guide that would help a new staff member and an AI assistant avoid guessing.
• It doesn’t have to be perfect or complete and can have “Not sure, might be…”
• It should have a section for known upstream users, and a note to anyone who uses the folder to add themselves to the upstream users.

Narration

The good news is that a lot of the first-pass mapping can be AI-assisted. An approved tool can trawl a folder, cluster similar files, spot likely duplicates, identify common naming patterns, draft a first index, and suggest questions for the owner. That can save time and make human review more focused. But the tool does not become the authority. It can draft the map; the owner, steward, custodian, or reviewer validates it. The tool can identify patterns; the accountable human confirms purpose, handling, freshness, definitions, and authority. The operating rhythm might be periodic: a tool-assisted scan, a human review of uncertain items, and an update to the guide. That is more realistic than expecting every folder to be perfectly maintained manually from day one.

On-screen text

• Quite a lot of this index creation can be done by AI
• A sample prompt is on the data-literacy website.
• Occasionally (e.g. once per month) let it do a long trawl to find relevant documents
• That will speed up AI for other tasks
• It will also speed up a lot of human tasks – finding the source of truth is a common problem at Your Organisation.

Narration

This is the core design rule: the source of truth must be easier to find than the stale copy. If the stale copy is easier, people will use it. AI tools will use it too. A policy that says "use the authoritative source" is not enough if the authoritative source is buried, unnamed, unlabeled, or absent from the folder people actually work in. Good governance should make the right path easier. The source of truth should be clearly named, linked from adjacent workspaces, described in the guide, and explained well enough that a person or approved AI assistant knows why it is authoritative. This is not tidiness. It is risk control.

On-screen text

On-screen text unavailable.

Narration

Data teams help turn local data work into maintainable systems. Depending on the organisation, they may own source pipelines, semantic models, dashboard standards, data-quality checks, metric definitions, governance patterns, and support pathways. The quality of the request matters. A vague request such as "fix the data" or "make a dashboard" forces the data team to infer the decision, audience, owner, freshness requirement, handling level, and trust test. A better request names the problem lane and the expected outcome. Data literacy for non-data specialists includes knowing when to ask for help and how to make that help actionable.

On-screen text

On-screen text unavailable.

Narration

Different data problems belong to different people. If the source data is wrong, a dashboard redesign will not fix it. If nobody agrees what "active" means, a pipeline change will not fix it. If material cannot safely move, a prettier extract will not fix it. Use the roles to assign the work: engineering for sources and pipelines, analytics for decision support, stewards for definitions, and governance or risk teams for handling, access, retention, and approval.

On-screen text

• Who does what, and what a good request from you looks like.
• Platform / data engineering
• Owns sources, pipelines, and access.
• Give them: a clear business question and rough volume.
• Analysts / data scientists
• Shape questions into analysis and produce the artefact.
• Give them: the decision this feeds, the audience, and the deadline.
• You, the requester
• Own the question, the context, and the decision.
• Give them: fast answers to clarifying questions and honest draft review.

Narration

It helps to name the lane of the request. A one-off analysis answers a bounded question once. A recurring report needs repeatability and owner discipline. A dashboard or data product needs source, refresh, audience, support, and lifecycle management. A source-system repair addresses the upstream process that creates bad data. A governance or handling request asks what can move, who can see it, and what rule applies. The lane tells people what done looks like. It also prevents overbuilding. Not every one-off answer needs a dashboard. Not every dashboard problem is a charting problem. Not every source problem can be fixed in Power BI.

On-screen text

• Knowing which lane a request belongs in tells you who to ask, what to hand over, and what "done" looks like.
• One-off analysis
• A specific decision needs a specific answer, once. Hand over the decision, audience, and deadline.
• Recurring report
• The same question repeats. This is a maintained artefact, not a weekly copy-paste.
• New pipeline or source
• Something does not exist yet: a platform or data-engineering request with a business case.
• Dashboard product
• A published, supported artefact with an owner, a version, and a sunset.
• Governed automated output
• A script, model, or AI agent produces the answer. Same governance load as a human-authored artefact.

Narration

Automation does not remove accountability. A scheduled script, dashboard refresh, folder-guide update, AI-drafted report, or recurring extract is still an output. The danger is that it stops asking for attention. It can keep running after the source changes, the owner leaves, the audience changes, or the decision no longer exists. So it still needs an owner, source, handling rule, review path, failure mode, and stop condition.

On-screen text

• A scheduled script, a scripted dashboard refresh, a folder guide refresh, an AI-drafted report — the mechanism changes, the obligations don't. All four governance questions still apply.
• Owner — a named human, not "the script" or "the model". When it breaks or surprises someone, who answers the question?
• Source — every automated output still stands on a data source. Name it, show its as-at date, and show the last successful run.
• Review — automation doesn't remove the review, it changes who does it and when. Spot-check a sample; review any logic change before it ships.
• Handling discipline — an AI-drafted summary of sensitive data is still sensitive data. Classification and access rules don't weaken because the draft was machine-generated.
• The shorthand — if a human would need to justify sending this, the automation needs the same paperwork. Automation is a delivery mechanism, not a governance exemption.

Narration

The course now moves from individual artefacts to data systems. Data literacy is partly an individual skill: spotting stale dashboards, weak definitions, risky spreadsheets, and missing caveats. But data literacy is also a system property. Good systems make the right behaviour easier. In a good system, source, owner, definition, freshness, handling, review, and repair paths are visible. People can find the source of truth. AI tools can retrieve the right guide. Exception cases are recorded. Stale copies are labelled. Definitions have owners. Outputs know which decision they support. The goal is not perfect bureaucracy. The goal is to reduce guessing.

On-screen text

On-screen text unavailable.

Narration

At human speed, weak data systems create inconvenience. People lose time finding files, asking which dashboard is authoritative, checking definitions, or discovering that a spreadsheet is stale. At AI speed, the same gaps create confident scalable error. An assistant can summarise the stale spreadsheet before anyone notices. It can retrieve the easiest artefact rather than the authoritative one. It can blend definitions into a fluent answer. It can move information through a prompt, screenshot, summary, or generated document before human review catches up. AI removes the friction that used to slow mistakes down. That means the control points must move earlier. Source, owner, freshness, definition, handling, review, and exception rules need to be available before polished answers are produced at speed.

On-screen text

• At human speed, weak systems create inconvenience
• Stale definitions, missing owners and unclear sources cost time and cause occasional mistakes.
• At AI speed, weak systems create confident, scalable error
• The same gaps now produce fluent, plausible answers at volume — and pass them on as fact.
• AI removes the friction that used to slow things down
• Finding, summarising, drafting and spreading information all happen faster than human review can keep up.
• The data system now has to be visible, not assumed
• Source, owner, freshness, definition, handling, review and exception rules need to be explicit and accessible.

Narration

Slowness used to provide accidental protection. If a spreadsheet was wrong, someone might notice while preparing a report, checking a chart, forwarding an email, or answering a follow-up question. If a dashboard had a stale metric, the path from source to decision might be slow enough for a human to ask back. AI changes that. It can read, summarise, join, and draft quickly. That speed is useful, but it reduces the time available for noticing that the file is stale, the definition is wrong, or the handling rule is missing. The answer is not to avoid AI. The answer is to make the system explicit enough that AI speed has something safe to follow.

On-screen text

• At turtle speed
• Someone notices a spreadsheet looks old.
• A person asks which dashboard is authoritative.
• An analyst remembers that “active” means different things in two systems.
• Handling rules are applied during review.
• At AI speed
• AI summarises the stale spreadsheet before anyone notices.
• AI retrieves whichever artefact is easiest to find.
• AI blends the meanings into a fluent answer.
• A prompt, screenshot, summary or generated output moves information before review.

Narration

Finding the file is only the first step. Indexes, folder guides, and maps answer the question "where is the source of truth?" That is necessary, but not enough. A data system must also answer whether the data is correct, current, authorised, complete, safe to combine, and suitable for the decision. Human onboarding used to cover some of that. People learned which folder to trust, who to ask, which dashboard was old, and which definition applied in which meeting. AI tools do not reliably inherit that informal context. If the system does not expose the integrity rules, handling rules, and authority signals, the tool will make plausible guesses. Some guesses will be right. The problem is that wrong guesses can now be produced quickly and fluently.

On-screen text

• Indexes and maps answer one question
• Where is the source of truth? Catalogues, registers and root guides tell us where to look.
• Data systems have to answer more
• Is it correct, current, authorised, complete, safe to combine and safe to use for this decision?
• Human onboarding is not enough
• Inducting people into "how we use this data" was sufficient at human speed. At AI speed the system itself needs data integrity rules. AI can hallucinate and populate false data faster than it can be discovered and corrected.

Narration

Data integrity rules are statements about what must always be true if an output is going to be trusted. Some are technical. Every incident has a unique identifier. Every purchase order has a valid identifier. Every invoice corresponds to a purchase order unless an approved exception applies. A closure date cannot be before an opening date. Some are reporting or product rules. Every dashboard tile shows source, refresh date, owner, and definition. Every recurring spreadsheet has an owner, data currency date, and review point. Some are AI-output rules. Every AI-generated operational summary includes source set, data currency date, handling level, and human reviewer before it travels. The important phrase is "must always be true." If the rule is essential for decision safety, write it down and make it checkable.

On-screen text

• Object
• What must always be true
• Incident ticket
• Every incident has a unique identifier and severity level.
• Cell tower / asset
• Every asset ID maps to exactly one physical asset location.
• Planned maintenance window
• Start time must be before end time, and affected systems must be listed.
• Dashboard KPI
• Every KPI tile shows source system, refresh time and owner.
• Supplier service disruption report
• Every service disruption claim must reference a valid incident or work order.
• AI-generated operational summary
• Every summary includes source systems, as-at date, handling classification and human reviewer.
• the core operational system Secure -> the shared document repository Corporate export
• Every exported record must have an approved release reason and audit trail.

Narration

The rules that slip are often obvious only after failure. Uniqueness slips when duplicate incident IDs, customer IDs, site IDs, or invoice IDs appear. Reference rules slip when a service disruption report points to an invalid work order or a cost line does not match a purchase order. Time rules slip when closure dates come before opening dates or dashboard refresh appears newer than source refresh. Status rules slip when a completed job still appears as awaiting approval. Geographic rules slip when a coordinate sits outside the expected service area. Handling rules slip when an extract moves outside the approved audience. Exception rules slip when there is no record of who approved the deviation. These are decision-safety concerns, not database concerns alone.

On-screen text

• Object
• What must always be true
• Coverage dashboard
• Percentages cannot exceed 100%.
• Tower maintenance spreadsheet
• A completed job cannot still appear as “awaiting approval”.
• Customer escalation
• Priority 1 incidents must have an assigned owner within 15 minutes.
• GIS asset map
• Latitude/longitude must be inside the service jurisdiction.
• Weekly executive briefing
• Numbers must reconcile with the operational source system.

Narration

There are several implementation levels. In database applications, programmers can enforce rules directly through schema design, validation, foreign keys, constraints, and application logic. In spreadsheets, teams can use data validation, protected ranges, reference tables, drop-down lists, locked formulas, and clearly named source tabs. In AI-enabled workflows, some rules also need to be written in natural language so approved tools and human reviewers can see them. For example: "An extract from this folder must not be shared outside the approved audience"; "The current-source workbook is the only file marked authoritative in the guide"; "Any AI summary must include source set, data currency date, and reviewer." Plain-language rules do not magically enforce themselves. They still need owners, review paths, and escalation. But if the rule is not written where people and tools can see it, it is much harder to follow.

On-screen text

• In database applications, programmers make rules to force it
• Spreadsheets can enforce data types. (This is often under-used)
• https://support.microsoft.com/en-us/office/apply-data-validation-to-cells-29fecbcc-d1b9-42c1-9d76-eff3ce5f7249
• As more work shifts to AI, data integrity rules can be written in human language
• Rule type
• Example
• Uniqueness
• Invoice ID appears once.
• Referential
• Invoice links to an existing purchase order.
• Temporal
• Closure date is not before opening date.
• Semantic / business-rule
• Invoice amount does not exceed remaining PO balance unless exception-coded.
• Handling / access
• The extract is not shared outside the approved audience or environment.

Narration

Good systems do not pretend exceptions never happen. Sometimes a source system contains a bad date. Sometimes a job has an unusual status. Sometimes an invoice lacks the normal reference. Sometimes a dashboard metric temporarily uses a fallback data source. Sometimes a field is known to be incomplete. The question is what happens next. A useful exception record says what rule failed, whether the failure blocks use, who is responsible for investigating, what action is required, when it expires, and how the exception should be communicated. This matters because AI tools can be very confident with exceptional data. If the exception is documented, a tool or reviewer can handle it. If the exception is invisible, it may become a false certainty.

On-screen text

• Good data systems do not pretend exceptions never happen. Exceptions get tracked, and there’s a process for flagging it up.
• Question for every exception
• Which rule failed? Make the breach explicit so it can be aggregated and trended.
• Does it block use? Decide whether work pauses, proceeds with caution or proceeds normally.
• Who investigates? Assign accountability; avoid “someone else will look at it”.
• What evidence is required? Capture facts, not opinions; standard fields per exception type.
• How is the exception recorded? Logged in a known place with a unique ID and timestamp.
• When does it expire or get reviewed? Time-limit every exception; force a re-decision.
• Can AI summarise it, in which environment? Define the approved tool and handling level for AI use.

Narration

Pause on one spreadsheet, dashboard, report, or recurring output. Choose three fields or claims. For each one, write a "must always be true" rule. For example: a date must be in the reporting period; a percentage must be between zero and one hundred; or a site ID must exist in the current asset register. Some other possibilities are that a status must use one approved value, or a source refresh must not be older than the dashboard claims. Then decide what happens when the rule fails. Does it block publication? Does it require owner review? Does it create a caveat? Does it trigger a source-system repair? Does it expire after a period? The activity is valuable because it turns vague "data quality" into specific checks.

On-screen text

• Use a spreadsheet (e.g. the one from the pre-work) or a Power BI dashboard.
• Pick a few columns of data, take each in turn.
• What should always be true about this column? (It will always be a number; it will always be newer than another column; it shouldn’t exist unless another column is present).
• How is that enforced? If it is not enforced, is it documented? Could a human or AI bot accidentally enter impossible data?
• How should wrong data / exceptions be handled? Is that documented?

Narration

Trustworthy data supports quantified statements. A quantified statement is a number with scope, method, uncertainty, and decision relevance. It says what evidence was used, how fresh it was, what was included, what was excluded, and how confident we can be. AI can help draft quantitative explanations, but it can also overstate them. A fluent summary can make weak evidence sound strong. A chart can make noise look like a trend. An average can hide variation. A small sample can look more stable than it is. The discipline is to connect the number to the method and the decision. What claim are we making? What evidence supports it? What uncertainty remains? Is it good enough for this decision?

On-screen text

On-screen text unavailable.

Narration

This is a deliberately fake comparison, but the decision problem is real. Suppose we have sampled mean time between failure for two kinds of networking equipment. If we only look at the averages, one vendor may look better than the other. That is not enough. The useful question is whether the difference is strong enough to support a claim, or whether it could easily be noise from a small sample. AI can help here by generating the spreadsheet formula, selecting a plausible statistical test, and explaining the result in plain English. The human job is still to frame the question, check the data, and decide whether the result is strong enough for the decision being made.

On-screen text

• Nokia (ex-Alcatel-Lucent)
• Cisco
• Mean
• n = 10
• n = 8
• MTBF (hours) sampled from incident records.

Narration

Statistical tests help decide whether an observed difference is likely to be meaningful or just noise. Reporting the mean and median is table stakes. The next step is asking whether the data really supports the comparison. In the fake vendor example, the chart may look as though one vendor is better, but the Mann-Whitney result does not support a confident difference. That does not mean the question is unimportant. It means this data, framed this way, is not strong enough to justify the claim. Good AI tools can often suggest the test, create the formula, and explain terms such as p-values or R-squared. The human still needs to confirm the test fits the data, understand the operational context, and decide whether to collect more evidence, change the grouping, or use a different decision threshold.

On-screen text

• Reporting mean, median, etc. is table stakes
• Good AI bots are good at identifying the right statistical test to perform (confirm it of course)
• Bots can guide you on running the test
• Can explain the meaning of p-values, R2 values and so on
• Surprisingly useful resource despite its forbidding name: www.biostathandbook.com
• Takes you from analytics-like to science-like
• Mann–Whitney from the previous page’s data…U = 50.5, two-sided p = 0.37 The difference between vendors is not statistically significant.

Narration

Many operational questions are statistical comparison questions. Is one vendor more reliable than another? Are service disruptions longer in one region? Do incidents with one cause have a higher recurrence rate? Did a new process reduce response time? Are satisfaction scores different across cohorts? Does a change in dashboard usage reflect training, workload, or seasonality? The method should match the question. Sometimes a count is enough. Sometimes a median is better than a mean. Sometimes a distribution matters. Sometimes a test is needed. Sometimes the data is not good enough to support the claim. The data-literacy habit is to avoid turning a number into a conclusion too quickly.

On-screen text

• Some data questions compare groups
• Is Nokia / Alcatel-Lucent equipment more reliable than Cisco?
• Other operational questions are about a repeated metric
• Is this week worse than usual?
• Is this month’s backlog a real problem?
• Is this site, region, or vendor genuinely unusual?
• Are we seeing a one-off event or a process shift?
• Or forecasting
• How many faults will the field crews see next week across the Hunter region?
• What will the install backlog look like at the end of the month?
• How many calls will the contact centre take after the next price change?
• How many connections will we add in Western Sydney over the next quarter?

Narration

The wrap-up brings the three sessions together. AI does not remove the need for data literacy. It makes the old data discipline faster, more visible, and more consequential. Weak definitions, stale spreadsheets, unclear sources, and missing handling rules were already problems. AI makes them easier to scale. The practical answer is not to stop using AI. The practical answer is to make the system explicit: define terms, name owners, make source-of-truth files visible, write folder guides, document integrity rules, handle exceptions, and keep human accountability in the loop. That is the thread from interpretation to communication to governed visibility.

On-screen text

On-screen text unavailable.

Narration

The new operational reality is a shift in risk. Before AI, weak definitions created confusion. With AI, they can become scalable error. Spreadsheet drift used to create inconvenience. With AI, stale spreadsheets can become confident summaries. Stale reports wasted time. With AI, they can be retrieved and reused automatically. Missing governance used to be patched by tribal knowledge. With AI, it can become invisible automation. Where the decision depends on uncertainty, use explicit probabilities, ranges or confidence language rather than hiding uncertainty behind a single number. The organisation needs faster answers without losing traceability, handling, ownership, source freshness and review.

On-screen text

• Before AI
• Weak definitions created confusion
• Spreadsheet drift created inconvenience
• Stale reports wasted time
• People compensated with tribal knowledge and human caution
• Protected by slowness: problems get found with time and enough eyeballs
• Some number comparisons looked good enough
• With AI
• Weak definitions become scalable error
• Stale spreadsheets become confident summaries
• Missing governance becomes invisible automation
• Ambiguous ownership becomes untraceable decisions
• Iteration speed increases the cost of unclear controls
• Where decisions depend on uncertainty, effective organisations use explicit probabilities, ranges or confidence language

Narration

The three sessions form one arc. Session 1 covered definitions, spreadsheets, and thresholds: how data gets meaning, how metrics can be misunderstood, and how spreadsheets become risky when they behave like systems. Session 2 covered governance, handling, and artefacts: how data travels, how outputs keep caveats, how dashboards become products, and why AI access is still access. Session 3 covered AI scale, indexing, integrity, and communication: how abundance changes search, how AI exhaust becomes a data layer, how folder guides help people and tools, and how integrity rules make outputs safer. The common thread is context. Data becomes useful when the right context travels with it.

On-screen text

• Session 1
• Definitions, spreadsheets, thresholds.
• Session 2
• Governance, handling, artefacts.
• Session 3
• AI scale, indexing, integrity, communication.

Narration

The tomorrow test is practical. When returning to work, choose one artefact, folder, dashboard, spreadsheet, report, or recurring output. Ask whether someone else can understand it without guessing. Can they find the source of truth? Is the source of truth easier to find than the stale copy? Can they tell whether it is current? Can they tell what is safe to share? Could an approved AI tool use it without creating dangerous confusion? If the answer is no, the fix does not have to be large. Add a source note. Add an data currency date. Add an owner. Mark a stale copy. Add a handling note. Write a one-page folder guide. Name the review point. Small visible context can prevent large invisible errors.

On-screen text

• When you go back to work, ask yourself:
• Can someone else understand your artefact without guessing?
• Can they find the source of truth?
• Is it easier to find the source of truth than the stale copy?
• Can they tell whether it is current?
• Can they tell what is safe to share?
• Could an AI tool use it without creating dangerous confusion?
• If yes, the artefact is closer to decision-grade.

Narration

Use five habits as a memory prompt. Define before you measure. If the metric is not defined, the number is not safe. Own before you share. Every dataset, dashboard, recurring spreadsheet, and decision-ready output needs a named accountable human. Use CHORDS when artefacts travel: Caveat, Handling, Owner, Refresh date, Definitions and Source. Make the source of truth obvious. It should be easier to find than the stale copy. Document what is not authoritative. Some files are drafts, examples, exports, or old snapshots. They can exist, but the map should say what they are. These habits work before AI and still work with AI.

On-screen text

• Define before you measure. Every key term has one owned definition. Many data problems are definition problems.
• Own before you share. Every dataset has a named human accountable for it.
• Use CHORDS when artefacts travel. Caveat, Handling, Owner, Refresh/as-at, Definitions and Source.
• Source once, reuse often. One source of truth per metric, not five spreadsheets. Many data problems are workflow problems.
• Document what is authoritative. Not every transcript, draft, or summary belongs in the record. Provide maps so the right data is easier to find than the wrong data.

Narration

The final habits are practical checks. Say the statistic in plain English. Read the chart before trusting the picture. Write for the decision, not for the artefact. Keep uncertainty visible. And remember that a decision-ready output still needs handling, traceability, and a source of truth.

On-screen text

• Session 3 — Interpretation & Communication
• AI speed exposes data-system gaps. Slowness used to protect us. It no longer does.
• Integrity rules and exception handling are part of the system, not afterthoughts. Define what must always be true, and what to do when it isn’t.
• When a decision depends on a difference between groups, check sample size, spread, uncertainty and whether the difference is large enough to matter.
• For repeated metrics, ask “is this unusual?” Start with a run chart, baseline, and known events before reacting.
• Treat AI outputs and forecasts as claims to be checked, not evidence to be passed on.
• With AI, weak definitions can become scalable error. Handling, traceability and ownership need to be visible before reuse.
• Make the source of truth easier to find than the stale copy.

Narration

If you keep one thing from these three sessions, keep this: the source of truth has to be easier to find than the stale copy. If it isn't, people will keep using the stale copy — and so will every AI tool pointed at your data. Everything else we've covered — definitions, ownership, handling, traceability — is in service of one test: could someone act on this without coming back to ask?

On-screen text

• The one idea to keep
• If it isn't, people — and every AI tool pointed at your data — will keep using the stale one. That's the test behind all three sessions: could someone act on this without coming back to ask?