Narration

Welcome to Decision-Grade for Practitioners One: Foundations. Today we build a shared language for data, information, and decisions; look at where spreadsheets help and where they turn into risk; think clearly about data quality; and learn to turn a vague request into a decision-ready brief.

On-screen text

• Session 1 — Foundations
• Your Organisation × Industrial Linguistics
• Session 1 of 3 140-minute facilitated session Last updated: 2026-07-05

Narration

Course materials, templates and reference cards are available from the Decision-Grade site at `https://decision-grade.industrial-linguistics.com`. Use the downloadable artefacts during the exercises rather than recreating them from screenshots. The practical point is that the Data Artefact Passport, Decision-Ready Brief, Dashboard Trust Cue Checklist and CHORDS reference card should be easy to find while you work and easy to reuse afterwards.

On-screen text

• Course materials, templates and reference cards are available from the Decision-Grade site: https://decision-grade.industrial-linguistics.com
• Use the downloadable artefacts during the exercises rather than recreating them from screenshots.
• Key artefacts: Data Artefact Passport, Decision-Ready Brief, Dashboard Trust Cue Checklist and CHORDS reference card.

Narration

We start with the words, because a lot of data problems are really word problems. What counts as a site? What counts as available? Which spreadsheet is the copy and which one is the source? Once those questions are visible, the rest of the session is about making a request specific enough that someone else, human or AI, does not have to guess.

On-screen text

• Session 1 Roadmap
• Warm-Up
• Definitions
• Spreadsheets
• Data Quality
• Decision-Ready Briefs
• Summary

Narration

I have a few different lives. One is academic: I lecture in data science at Macquarie. Another is commercial: I work as a consulting CTO around data, AI, and the systems people actually have to live with. I have also worked with federal and state organisations around infrastructure and data management, so I will keep the examples close to work like yours. As you go through the course, test each idea against a spreadsheet, dashboard, report, or awkward evidence trail you actually use.

On-screen text

• Image: Greg Baker
• Greg Baker
• Data Science lecturer at Macquarie University / Consulting CTO
• Ex-CTO of Daisee and Pixc; 2 technology business exits.
• Author of 8 books, 1 patent, 3 film scores, and many scientific papers.
• Researches mathematical approaches to make AI explainable and governable.
• Ex-Googler and ex-CSIRO, with affiliations at ANU and Macquarie University.
• Clients include ACT Treasury, AAT, Allianz, Atlassian, Aon, Auckland City Council, Australian Parliament, Fujitsu, Hewlett-Packard, Vodafone, and Woolworths.

Narration

By the end of this session, you should be more confident doing four things. First, explaining core data concepts and everyday artefacts in plain English. Second, writing usable metric definitions with calculation, inclusions, exclusions, freshness, owner, and known limits. Third, recognising spreadsheet and transformation risk, especially when artefacts are reused, forwarded, or likely to become AI context. Fourth, judging whether data is fit for a particular decision using freshness, completeness, consistency, validity, and fitness for use.

On-screen text

• By the end of Session 1, you should be more confident doing four things:
• Explain
• Core data concepts and everyday artefacts in plain English: dashboards, spreadsheets, extracts, reports, and recurring requests.
• Define
• Usable metrics with calculation, inclusions, exclusions, freshness, owner, and known limits.
• Recognise
• Spreadsheet and transformation risk, especially where artefacts are reused, forwarded, or likely to become AI context.
• Judge
• Whether data is fit for a decision using freshness, completeness, consistency, validity, and fitness for use.

Narration

AI makes the old data-literacy habits more consequential. If the definition is not written down, the tool may choose one or blend several. If the source and version are not visible, a stale tab or "final_v3" file may become AI context. If the transformation steps are invisible, the tool may explain a number as if it knows how that number was made.

On-screen text

• AI tools amplify whatever you feed them — including the messy bits.
• Models cannot see context that is not written down — owner, source, as-at date, caveats, and audience.
• Inconsistent definitions become inconsistent answers — an AI assistant may choose one definition, blend them, or answer without exposing the mismatch.
• Ungoverned spreadsheets become AI context — stale tabs, manual overrides, and "final_v3" files may be pasted into prompts, retrieved by assistants, or treated as evidence.
• Transformations you do not log cannot be reviewed — a model can summarise the number, not reconstruct the steps.
• Quality thresholds still matter — AI lowers the cost of producing an answer, not the cost of acting on a wrong one.

Narration

Reporting confusion often starts before anyone opens a spreadsheet or dashboard. It starts when words, categories, labels, and assumptions mean different things to different people. There was also a strong theme around assumptions and instructions. Clear instructions produce better data. If the input instructions are unclear, or if they change along the way without being recorded, then downstream reporting becomes harder to trust. People begin to ask: who put these numbers here? Which columns were needed? What assumptions were made? What does this field actually mean? Who knows how the formulas work? What happens when the person who understands the spreadsheet is away? These are normal problems in large organisations. That is why shared language matters.

On-screen text

• Decision-Grade Foundations
• Welcome & Warm-Up
• Definitions That Hold Up
• Spreadsheets
• then Data Quality
• Data, Information, Decisions
• Decision-Ready Briefs
• Summary & Takeaways

Narration

Most operational data problems are not just bad numbers. They usually start earlier, with a workflow that only makes sense to the people already inside it, or a definition that everyone thinks they share but nobody has written down. At human speed, people compensate for that with memory and context. They ask the person who made the file, or they know which version is normally used. Once AI can search, retrieve, summarise, and act quickly, that friction disappears. So the ownership, definition, freshness, and workflow around the artefact become part of the control system.

On-screen text

• At human speed, people compensate for weak systems with memory, context, and tribal knowledge.AI removes the need for human friction — so definitions, workflows, and ownership suddenly matter much more.

Narration

Use the cold-reader test. If a colleague outside the immediate area could not understand the dashboard, spreadsheet, report, extract, or briefing note without you standing beside them, an AI assistant probably cannot either. It may still produce a fluent answer, but it will be guessing about the missing business context. Before an artefact becomes AI context, the basic discipline has to be visible: what it is, where it came from, what decision it supports, how fresh it is, who owns it, and what limits travel with it.

On-screen text

• AI context
• Before a dashboard, spreadsheet, report, extract, or briefing note can safely become AI context , it needs enough data discipline that a human can understand it without guessing .
• If the business knowledge is only in someone's head, it will not travel with the artefact.

Narration

Walk the core operational system example end to end. Data is status-report entries, site incident and service disruption records, dashboard values for availability, capacity, service level, utilisation, power status. Information is interpretation — "two high-risk sites are on augmented power, one resource pool is activated, one planned service disruption should be deferred." Decision is the action — stage or activate deployable resources, deploy backup power or deployable resources, apply a planned-service disruption embargo.

On-screen text

• Data, Information, and Decisions. Three different things — they are different, but they are all just input context to AI.
• Data — weekly the core operational system status-report entries, site incident and service disruption records, priority, resolution notes, planned maintenance, and dashboard values for site availability, channel capacity, service level, utilisation, and power status.
• Information — "Two high-risk the core operational system sites in the service area are operating with power or connectivity augmentation; one deployable resources Asset is activated; one planned service disruption should be deferred."
• Decision — stage or activate an additional deployable resources Asset, deploy backup power or deployable resources, or apply a planned-service disruption embargo for the affected response period.
• A status-report entry is data. A dashboard tile is information. Neither is a decision.

Narration

When I say data here, I do not only mean the official database. The dashboard is data for decision purposes. Weekly status reports are data. Field-status tools, asset logs, program trackers, briefing notes, and recurring requests for the numbers all shape decisions. That is why they need common standards. If people rely on an artefact to decide what to do next, it needs shared definitions, a source, a named owner, and a freshness indicator. Otherwise the decision is being made from private context rather than from the artefact itself.

On-screen text

• What Counts as Data Here?
• core operational network (the core operational system) dashboard
• Weekly status reports and monthly performance reports
• the field status feed field status tool (JIMS)
• Asset deployment logs
• the major capital program trackers
• Briefing notes and recurring requests for "the numbers"
• All of these shape shared decisions — so all of them need common shared standards.

Narration

A metric is only useful if every reader can answer: calculation, inclusions, exclusions, owner, freshness, known limits. These are not bureaucracy — they are what stops two teams citing the same number and meaning different things. The spoken example should be operational availability for the core operational system, channel capacity, and service level.

On-screen text

• What a Useful Metric Definition Must Include. A metric is only useful if everyone reading it (including AI) can answer:
• Calculation — the exact formula or logic
• Inclusions — what's counted
• Exclusions — what's deliberately left out
• Owner — who maintains it
• Frequency / freshness — how often it updates
• Known limitations — what it can't tell you

Narration

Here is a metric that looks simple until you ask what it means. Site availability depends on the response window, which sites count, whether deployed resources are in or out, which provider outages are excluded, who owns the update, and how fresh the status is. Do not memorise this metric. Notice how many decisions are hiding inside one ordinary-looking percentage.

On-screen text

• Worked Example: A Metric Definition That Holds Up
• Metric: the core operational system Site Availability — the priority service area
• Calculation: % of time selected the core operational system fixed sites and deployed deployable resources were operational during the reporting window, cut by location and asset type.
• Inclusions: fixed the core operational system sites; deployed deployable resources; temporary and backup-powered sites; locations within the priority service area.
• Exclusions: third-party provider disruptions (tracked separately via the field status feed); unrelated services; non-the core operational system services.
• Owner: your organisation operations (the field status feed); operational reporting via the delivery partner. Exact internal owner to be confirmed.
• Freshness: as-at operational update during an event; cadenced weekly and monthly status reports; the core operational system dashboard for partner organisations.
• Known limits: average availability hides local site, capacity, power, and service-level issues; deployable resources must be explicitly included or excluded.

Narration

Every word on this list (staged, deployed, activated, unavailable, partially available) sounds simple — and every one of them has broken a report or a decision somewhere. The only way to pressure-test a definition is to throw an edge case at it and see whether your rule holds.

On-screen text

• Pin down one metric so two teams (or a human and an AI) compute the same number.
• Pick one metric from your work — "active site", "deployed system", "customer", "open ticket", etc. or use one of the pre-supplied ones
• Write the definition in a few sentences: what counts, what doesn't, and the as-at moment. Make sure you include the following words. Rule, Inclusions, Exclusions, Owner, Freshness
• Ask the AI — it will ask pedantic and annoying questions about your definition and consider weird corner cases
• Rewrite if it broke — adjust the sentence until the AI bot is no longer able to find confusing cases .
• Output: a metric definition you'd be comfortable handing to a colleague or an AI prompt.
• Definitions
• https://decision-grade.industrial-linguistics.com/duel/

Narration

Now we turn to spreadsheets. The question is not whether spreadsheets are good or bad; the question is what job the spreadsheet is doing, how long it will live, who depends on it, and whether an AI tool could safely understand it.

On-screen text

• Last updated: 2026

Narration

AI bots love spreadsheets. One reason is search: a spreadsheet file name often says exactly what the file contains, so search finds it quickly. Another reason is tooling. Some assistants have Excel tools, and other AI systems can often use Python libraries such as pandas to inspect sheet names, column headers, row counts, and formulas. They do not always need to paste the whole workbook into the prompt. They can ask the spreadsheet what shape it has, read the headers, and query it more like a small database.

On-screen text

• Usually named something that is clear and promising
• Searching Sharepoint finds it quickly
• Copilot has Excel tools; bots that can run Python usually have access to a library (pandas) that lets them read spreadsheets by treating them as a database
• Spreadsheets don’t take up much of the context window compared to other document formats
• Tool use outputs vs injecting a document
• The headers on each tab get read (usually)

Narration

Spreadsheets are not bad. They are often the right tool. They are useful for ad hoc exploration, one-off checks, personal working files, small team trackers, temporary analysis, and low-stakes calculations. If one person uses a spreadsheet once to add up expenses or sense-check a list, there is usually no need for heavy governance. The risk rises when the spreadsheet changes job without anyone naming that change.

On-screen text

• When spreadsheets are fine
• Ad-hoc exploration, one-off analysis, personal working files.
• Small, low-stakes, short-lived datasets.
• When they turn into shadow systems of record
• Same file is reused for recurring reports or decisions.
• Logic, overrides, or adjustments live only in the sheet.
• Warning signs
• Multiple versions in circulation; manual merges between files.
• Hidden logic in cells or macros; uncontrolled extracts from source systems.

Narration

Risk rises with reuse, audience, and dependence. Low risk — one person, single use, temporary. Medium — small team, reused weekly, internal. High — sent to leaders, hidden formulas, owner unclear, decisions leaning on it. The more a file is treated as a source of truth, the more it needs the discipline of Session Two's governance material.

On-screen text

• Spreadsheet Risk Spectrum. Risk rises with reuse, audience, and dependence on the file for decisions.
• Low risk — working file: one person, single use, throwaway. E.g. scratchpad for a call.
• Medium risk — shared working file: small team, reused weekly, still internal. E.g. team tracker with a few manual joins.
• High risk — quasi-report: emailed to leaders, hidden formulas, owner unclear. Decisions are starting to lean on it.
• Unsafe — shadow system: recurring decision use, multiple versions, no owner, no audit. The org runs on it; nobody governs it.
• Signals that shift a file right: reuse, hidden logic, growing audience, recurring decision use.

Narration

AI magnifies spreadsheet risk because it can treat the most findable file as the most authoritative file. A private working file is lower risk because search may never find it unless you deliberately upload it. A shared working file is riskier, but the team may still understand its quirks. The danger rises when a quasi-report has been copied into important places, or when an old version is referenced by lots of other material. To an AI tool, that can look like importance. At the unsafe end, a shadow-system spreadsheet may be both operationally important and poorly protected, so a bad read or a bad write can become a real incident.

On-screen text

• Low risk — working file: won't even be found by the document store search, unless you deliberately load it as a file for input, it won’t get used
• Medium risk — shared working file: if it has last week's version in conversation history, it will still be roughly right (usually)
• High risk — quasi-report: lots of copies in important places, that version from last year must be very important
• Unsafe — shadow system: "I apologise, I shouldn't have deleted that file. You were right to call me out on that."

Narration

Two spreadsheets, same the major capital program, different answers. View A tracks the major capital program delivery costs only: build, commissioning, and your organisation-managed overheads. View B is broader. It includes a partner organisation migration. It also includes decommissioning of legacy assets and consequential costs borne by agencies. Both can be technically defensible; they answer different questions. Neither puts the scope boundary on the front page. Teaching line: a spreadsheet can be technically accurate and still be decision-dangerous when the scope boundary, owner, or inclusion rules are unclear.

On-screen text

• Same Program, Different Cost Boundary. Two spreadsheets, same the major capital program program, different answers.
• View A: tracks your organisation the major capital program delivery costs only — build, commissioning, and your organisation-managed overheads.
• View B: includes a partner organisation migration, decommissioning of legacy assets, and consequential costs borne by agencies.
• Both can be technically defensible — they answer different questions, and neither file labels its scope boundary on the front page.
• A spreadsheet can be technically accurate and still be decision-dangerous when the scope boundary, owner, or inclusion rules are unclear. If humans don’t realise the difference, how will an AI know?

Narration

Walk the checklist: reuse, decision dependence, calculation visibility, version control, ownership, refresh schedule, and whether a new person could run it next week.

On-screen text

• Spreadsheet Risk Checklist. Run through this before you email a spreadsheet that will drive a decision.
• Is this file reused, or single-use?
• Does a decision depend on it? By whom, how often?
• Is the calculation logic visible, or buried in formulas?
• How many versions exist? Which is the source of truth?
• Is there a named owner? A refresh schedule?
• Could a new person run it next week without tribal knowledge?
• Would you still trust it if three people touched it between refreshes?

Narration

A spreadsheet becomes a shadow system when it stops being a temporary working file and starts carrying an operational process. If people rely on it, update it, forward it, and make decisions from it, then it needs the same source, owner, handling, and review discipline as any other system.

On-screen text

• Pick one of the spreadsheets you use or rely on. Decide where it needs to go next.
• Name the sheet — what decision or report does it feed? Who else uses it?
• Show it cold — show it to your pair partner and explain nothing. What do they think it is about?
• AI risk — if AI were to read that spreadsheet with no other context about Your Organisation or what you do, what is the most mistaken view it could make of it?
• Pick its next step — keep as-is, add information, or replace it with something else?
• Justify it in one sentence — what makes that the right level of rigour for the decisions it drives?
• Name the next owner or action — who you'll talk to back at work, and by when.
• If you don't have a spreadsheet to hand, randomly pick one from Sharepoint or from your email.
• Spreadsheets

Narration

Before trusting a spreadsheet, read its shape. Look for sheet names, hidden rows, merged cells, formulas, dates, filters, copied tabs, and colour that carries meaning. Those are the places where a spreadsheet tells you how it was made, as well as the numbers it contains.

On-screen text

• Last updated: 2026

Narration

Spreadsheets do not always love AI back. AI does well when the sheet is already behaving like data: tables with headers, one record per row, and consistent types in each column. It can usually follow straightforward formulas, data dictionaries, and pivot tables. It struggles when the sheet is really a picture, a notebook, a dashboard, or an application. Removed rows are invisible. Merged cells, colour, font, blank spacer rows, and layout conventions often carry meaning for humans but not for the tool. If colour or layout matters, say that explicitly, or move the meaning into data the tool can read.

On-screen text

• Easy for AI to understand
• Tables with headers, one record per row, consistent data types (all dates in one column, all integers…)
• SUM, MIN, MAX, IF
• Data dictionary that says what the columns mean
• Pivot tables
• Hard for AI to understand
• What rows you removed
• Merged cells
• Colour and fonts
• Layout conventions: top-left area is assumptions; middle area is calculations; bottom area is outputs
• Blank spacer rows
• AI is good at reading spreadsheets when the spreadsheet is already behaving like data. It is much less reliable when the spreadsheet is behaving like a picture, a notebook, a dashboard, or an application.

Narration

Not all spreadsheets are equal for humans or AI. A clean extract or a simple tracker is usually easy to inspect because it has rows, columns, owners, dates, and definitions. A risk register or executive report needs more care because the meaning depends on ratings, caveats, and layout. Dashboard exports and financial models are harder again because freshness, assumptions, and formulas matter. Operational workbooks and spreadsheet apps are the hardest, because the spreadsheet is no longer just data. It is also workflow, interface, and institutional memory.

On-screen text

• Spreadsheet type
• Human use
• AI difficulty
• Clean data extract
• Analyse, filter, summarise
• Easy
• Simple project tracker
• Track status, owners, dates
• Usually easy
• Risk register
• Track risks, ratings, actions
• Moderate; definitions matter
• Executive report
• Present selected numbers
• Moderate to hard; layout and caveats matter
• Dashboard export
• Share a dashboard snapshot
• Moderate; refresh and filters matter
• Financial model
• Forecast scenarios
• Hard; formulas and assumptions matter
• Operational workbook
• Run a process
• Hard; workflow context matters
• Spreadsheet “app”
• Tool with inputs, rules, outputs
• Very hard
• Messy shared team sheet
• Ad hoc collaboration
• Very hard
• Old spreadsheet with hidden tabs/macros
• Institutional archaeology
• Very hard

Narration

The danger level is not about whether the spreadsheet looks tidy. It depends on what decision it supports, who can see it, whether it is the source of truth or a copy, how often it changes, and whether someone can explain the definitions and refresh path.

On-screen text

• Score a spreadsheet you already use. Decide what context would make it safer.
• Score it — open the spreadsheet risk scoring artefact at https://decision-grade.industrial-linguistics.com and run it against the spreadsheet you had open earlier. What's the score?
• Sense-check the score — if it's high, is that because the sheet is also hard for humans to understand?
• Add context — what could you write alongside the file to make it safer for humans and AI to use?
• "Rows 2–140 are raw incidents; rows 141–150 are summary totals, so exclude them from incident counts."
• "Red cells mean manually escalated, not necessarily overdue."
• "The pivot is filtered to May only and was refreshed yesterday."
• "Treat Acme, ACME Pty Ltd, Acme Corp as the same supplier unless checking exact records."
• "Sensitive — do not paste personal details into a public AI tool."
• Spreadsheets

Narration

If you clean or reshape data once, write down what you did. If you clean or reshape it more than once, make the steps repeatable. AI can help with the mechanics, but the transformation still needs a source, a reason, a review path, and enough evidence that someone else can reproduce it.

On-screen text

• Last updated: 2026

Narration

Definitions need roles around them. The owner has ultimate accountability for the data or artefact. The custodian makes final decisions about classification, access approval, and access requirements. The steward or subject-matter expert understands the data in detail: definitions, KPI logic, refresh cycles, quality expectations, and practical limits. The author produces the artefact. The approver signs off that the artefact can be shared or published with the stated marking. These are different responsibilities. One slide in the first run combined author and approver visually, but they should be separate. The person who creates an artefact is not always the person who approves its release or reuse.

On-screen text

• 1. Owner
• Ultimate authority for the data or artefact; accountable for major use and reuse decisions.
• 2. Custodian
• Makes final decisions about classification, access approval, and access requirements.
• 3. Data Steward / SME
• SME for definitions, KPI logic, and data-quality expectations; recommends but does not approve access.
• 4. Author
• Produces the artefact or runs the workflow that generates it.
• 5. Approver
• Signs off that it can be shared or published at the stated marking.
• Access decision path: steward recommends or helps draft -> custodian approves -> steward or administrator may execute the change. AI tools sit downstream: they inherit whatever access and approval decisions you make here.

Narration

A transformation is any step that changes what the reader sees. Filtering is a transformation. Joining two files is a transformation. Recoding categories is a transformation. Grouping rows is a transformation. Calculating a derived field is a transformation. Replacing blanks is a transformation. Excluding records is a transformation. Renaming categories can be a transformation if it changes meaning. The habit is not to panic about transformations. Transformations are necessary. The habit is to write them down.

On-screen text

• If it changes what the reader sees, it is a transformation — and it needs to be written down.
• Filters — kept only the core operational system-metro sites; excluded test and decommissioned entries; dropped records before go-live. Every exclusion is a choice.
• Joins — merged partner status with site register on site_id. Joins can inflate, shrink, or silently drop rows.
• Recodes — mapped eight site-power statuses into three buckets (green / degraded / off). Tell the reader which bucket theirs ended up in.
• Derived fields — utilisation = active_channels / total_channels; service level derived from blocked-call rate. The formula is part of the number.
• Manual fixes — overrode an obvious typo in a site name; re-tagged a backup-power unit logged to the wrong asset. Riskiest kind — log every one.
• AI summaries are transformations too — log the prompt, the model, and what you kept or edited.

Narration

The next bridge is evidence, sources, versions, and transformations. "I cleaned it up a bit" is not enough. A reviewer should be able to see where the number came from, which version was used, what changed, what output was produced, who owns it, and what limits remain. That evidence should live beside the artefact rather than being stuck in someone's inbox.

On-screen text

• "I cleaned it up a bit" is not enough. A reviewer should be able to reproduce your number from the artefact alone.
• Source: named system of record, when you pulled it, who owns it. "the delivery partner weekly status report, 14 Apr 2026 extract" — not "the usual export".
• Version: which snapshot, what changed since last. Ship one version; never two files called "final".
• Transformations: filters, joins, recodes, derived fields, manual fixes — in plain language a reviewer can follow.
• Where it lives: change logs beside the output, data-dictionary tab, or notebook comments — the trail sits with the artefact, not in someone's inbox.
• Same rule for AI-assisted work: the prompt is part of the source, the model and version are part of the transformation.

Narration

A transformation log does not need to be a giant compliance register. It can be a simple record of source, version, change, owner, and known limits. If the transformation is in code, keep the code version. If it is in a spreadsheet, document it in the spreadsheet. If it is in Power BI, make the applied steps inspectable. Another person should be able to inspect the chain from source to output without relying on memory or private email context.

On-screen text

• Five fields, one row per change. Lives beside the artefact: a sheet, a report page, or a notebook comment.
• Field
• Example entry
• Source
• the delivery partner weekly status report, 14 Apr 2026 extract.
• Version
• v3, dated 15 Apr 2026. Supersedes v2.
• Change
• Filtered to the core operational system metro subset; recoded eight power statuses into three buckets; cross-checked against the core operational system dashboard tile and the field status feed operational note.
• Owner
• Named author of the extract, and named approver for publication at the stated marking.
• Known limits
• Two sites under scheduled maintenance window excluded; one upstream feed stale since Tuesday; manual override flagged on one record.
• If a teammate pastes this extract into an AI assistant, the same five lines need to travel with it.

Narration

Power BI shows the same pattern. When a transformation is stored as an applied step, the process can be rerun and reviewed. The source can change, but the same transformation logic can be applied again. That does not automatically make the logic correct, but it does make it more repeatable than a manual copy-paste-clean-up process living only in someone's memory. This is the same literacy habit in different tools. Whether the work is happening in Excel, Power BI, SAP, ServiceNow, a script, a notebook, or a formal data pipeline, the question is the same: what changed between source and output, and can another person inspect it?

On-screen text

On-screen text unavailable.

Narration

Data-driven decision making does not mean accepting the nearest number. It means knowing what decision is being made, what evidence would change the answer, what uncertainty remains, and whether the data is good enough for the action being considered.

On-screen text

• Last updated: 2026

Narration

In a spreadsheet, someone may filter, delete, copy, recode, and paste once, and the trail can disappear. In Power BI, transformation steps can be saved as applied steps. That does not make them automatically right, but it makes them repeatable and easier to review.

On-screen text

• An AI assistant only sees what you paste, or what search turned up. Everything else is invisible.
• Numbers travel; context doesn't — a metric pasted into a prompt loses its owner, source, refresh date, and caveats the moment it leaves the source system.
• Definitions you didn't write down get invented — when "active customer" isn't pinned, the model fills the gap with a plausible-sounding default.
• Stale snapshots feel current — AI won't flag that the figure is three months old; it answers as if you pasted today's number.
• Confident summaries hide missing steps — fluent output doesn't tell you which transformation, filter, or override was skipped.

Narration

A number is not good or bad on its own. It is good enough, or not good enough, for a decision. An internal retrospective may tolerate approximate or slightly stale data. A performance report going to partners or central agencies needs source reconciliation, auditable definitions, traceable lineage, and no unexplained manual merges.

On-screen text

• Good Enough for What Decision? Quality is a threshold, not an absolute. The decision sets the bar.
• Lower-risk: internal team retrospective
• Approximate numbers are fine. 3-day-old data is fine. Directional signal is enough.
• Higher-risk: the core operational system performance report to partner organisations or central agencies
• Numbers must reconcile to the core operational system dashboard and status reports. Definitions auditable. Lineage traceable. No manual merges.
• "Is it good enough?" only makes sense if you've said "good enough for what?"

Narration

The dashboard headline is ninety-nine point nine nine percent. The question on the table is whether to proceed with planned maintenance during a weather event. Three failure modes: freshness (the rollup is from before the overnight power drop), completeness (resources and affected sites aren't in the average), consistency (statewide excludes planned service disruptions; the field status feed notes include them). A statewide average can be valid for annual reporting and still be inadequate for an operational call — affected site availability, service level, utilisation, channel capacity, power status, resource inclusion, and planned-service disruption embargoes all matter.

On-screen text

• Worked Example: Three Different Quality Failures
• Dashboard reads "the core operational system average service availability = 99.99%." The question on the table: are we operationally safe to proceed with planned maintenance during this weather event?
• Freshness fails: the headline is rolled up from last week's status report. A site dropped onto backup power overnight — it isn't reflected yet.
• Completeness fails: deployed deployable resources and deployable resources-supported sites aren't counted in the statewide average. The affected footprint looks healthier than it is.
• Consistency fails: "availability" in the statewide rollup excludes planned service disruptions; the field status feed notes include them. Two teams reconcile to different numbers.
• A statewide average can be valid for annual reporting and still be inadequate for an operational decision — affected-site availability, service level, utilisation, channel capacity, power status, deployable resources inclusion, and planned-service disruption embargoes all matter.

Narration

The same ninety-nine point nine nine percent availability number for the core operational system can be good enough for one decision and dangerously insufficient for another. Quality is always relative to what you are about to do with it.

On-screen text

• The number on the table: the core operational system average service availability = 99.99%, statewide, last refresh 6 days ago.
• Team retrospective
• Good enough? What would fail it?
• Leadership update
• Good enough? What caveat do you add?
• Live incident decision
• Good enough? If not, what do you need before calling it?
• If an AI assistant gave you this number, the threshold question is the same: would you act on its answer for each decision, and what would have to be true to say yes?
• Output one threshold per decision: "good enough because..." or "not yet because..."

Narration

Session 1 was about the foundations. Data, information and decisions are different. Metrics need owned definitions, inclusions, exclusions, freshness and known limits. Spreadsheets are useful, but they become risky when they behave like systems. Data quality is always judged against a decision. A vague request can be turned into a decision-ready brief. The workplace action is simple: choose one recurring spreadsheet, dashboard or request, and add the owner, source, data currency date, definition and caveat.

On-screen text

• Summary & Takeaways
• What we covered today
• Data, information and decisions are different.
• Metrics need owned definitions, inclusions, exclusions, freshness and known limits.
• Spreadsheets are useful, but they become risky when they behave like systems.
• Data quality is always judged against a decision.
• A vague request can be turned into a decision-ready brief.
• Workplace action: choose one recurring spreadsheet, dashboard or request. Add the owner, source, as-at date, definition and caveat.