Narration

Decision-Grade for Practitioners Two is about governance, handling, and publishable outputs. Session One gave us the language for asking good data questions; today we move from asking to handling. AI tools, assistant-style features, and scheduled scripts will happily speed up whatever request you give them, including a vague, unsafe, or stale one. Governance is not a separate AI topic; it is the thing that decides whether AI use is safe and useful.

On-screen text

• Session 2 — Governance, Handling, and Publishable Outputs
• Your Organisation × Industrial Linguistics
• Session 2 of 3 140-minute facilitated session Last updated: 2026-07-05

Narration

By the end of this session, participants should be able to do four things. First, turn a vague data ask into a decision-ready brief. Second, classify and handle data using the local language: Official, Sensitive, and Protected. Third, document an output so it can survive stakeholder review, audit, and reuse. Fourth, work more confidently with sensitive material inside a regulated workflow. Those are not abstract compliance goals. They are day-to-day behaviours. They decide whether a spreadsheet, dashboard, email, report, or AI-generated summary can safely be trusted by someone who was not in the room when it was made.

On-screen text

• Decision Briefs
• Convert vague asks into decision-ready briefs, carrying forward the through-line from Session 1.
• Classify
• Identify dataset sensitivity and apply the right handling rules.
• Document
• Produce a publishable output that survives audit and stakeholder review.
• Apply
• Work confidently with sensitive data inside a regulated workflow.

Narration

There are five blocks today. First, we make requests usable by starting with the decision. Then we look at classification and handling, dashboards as data products, separated environments, and finally request routing and automation. The same question keeps coming back: what is the decision, what artefact is safe, what can be shared, and what governance does the AI output inherit?

On-screen text

• Five blocks. Each block ends with a hands-on activity so concepts land before we move on.
• Decision-ready briefs
• Governance and classification
• Publishable outputs
• Sensitive-data workflows
• Request routing and automation

Narration

In data work, a good specification is not bureaucracy. It is the difference between an answer someone can act on and an answer that forces the analyst, dashboard builder, or AI assistant to guess. Treat "spec" broadly. It might be a Teams message, a ticket to a data team, a request from an executive, a dashboard brief, a prompt to an AI assistant, or a one-line request in an email. The same discipline applies: say what decision is being made, what data is in scope, what output is needed, who owns it, what handling applies, and how the answer will be checked.

On-screen text

On-screen text unavailable.

Narration

Spec quality matters in both directions. Executives and managers will pass requests down to teams. Some will be clear and actionable. Others will be underspecified, and the right move is to ask back, clarify, or use judgement before the data work starts. You will also pass requests to others. Be specific so the next person does not inherit your ambiguity. A good request names the decision, audience, timeframe, threshold, artefact, owner, handling constraint, and trust test. This is even more important with AI. A person may infer your context. An AI tool will often infer too, but its inference may be hidden behind fluent prose or a polished chart.

On-screen text

• Executives will pass requests to you
• Sometimes they are ill-defined, and need some conversation (or intuition) to make a good specification
• We’re also running Decision-Grade for Leaders
• You will pass data requests to others
• Be specific so the next person does not inherit your ambiguity.

Narration

The leaders' course and this course are designed to reinforce each other. Leaders are being taught to start with the decision, not the dashboard. That means defining the decision, uncertainty, action threshold, time horizon, evidence needed, and handling constraints before asking for a report. They are also being taught to challenge dashboards for trust cues: source freshness, dashboard refresh, metric definitions, denominators, owners, caveats, and enough lineage to explain the result. If leaders start asking sharper questions, this room should recognise the pattern. They are not asking for ceremony. They are asking for the minimum context that lets a decision stand up later.

On-screen text

• Start with the decision, not the dashboard: define the decision, uncertainty, action threshold, time horizon, evidence needed, and handling constraints before asking for reports.
• Challenge dashboards for trust cues: ask for source freshness as well as dashboard refresh, clear metric definitions, denominators, owners, caveats, and enough lineage to explain the result.
• Reduce reporting risk: move away from versioned spreadsheets, screenshots, and copied extracts toward repeatable, source-connected reporting with clear ownership and traceability.

Narration

Leaders are also being taught to sponsor practical data governance, apply responsible AI oversight, and ask better vendor and tool questions. The shorthand is: what to ask, what not to accept, and what minimum standards to reinforce. If a dashboard has no source-refresh indicator, if a spreadsheet travels without a caveat, or if an AI summary has no review trail, the leader should now know to push back. Session 2 is about making the artefacts ready for that pushback before it happens.

On-screen text

• Sponsor practical data governance: reinforce need-to-know access, documented purpose, least privilege, share-by-link where appropriate, review/expiry, and auditability.
• Apply responsible AI oversight: recognise AI beyond GenAI, distinguish approved from unapproved tools, and ask the core assurance question: “Has this been through the AI assurance process?”
• Ask better vendor/tool questions: require disclosure of AI use, data handling, logging, retraining, change control, monitoring, and review arrangements before approval.
• TLDR: what to ask, what not to accept, and what minimum standards to reinforce so teams can use data and AI with less hidden risk.

Narration

The basic sequence is decision, data needed, method, artefact. The order matters. Many reporting failures jump straight to the artefact: "build me a dashboard", "send me the spreadsheet", or "summarise this for me". But a dashboard may be the wrong answer if the real need is a recommendation, a reconciliation, a status note, or a clarification. Before asking a person or an AI tool to produce something, name the decision, state the timeframe and freshness requirement, say what action the output should enable, and say how the output will be judged trustworthy enough to use.

On-screen text

• 1. Name the decision.
• 2. State timeframe, freshness, and required cut.
• 3. Say what action the output should enable.
• 4. Say how you'll judge whether the output is trustworthy enough to use.

Narration

The data cart checklist is the decision-ready request checklist. It asks for the decision or action, the answerable question, the threshold or trigger, the artefact, the cut of data, the accountable owner, the rules and handling, and the trust test. The memory line is: fill the cart before you ask for the answer. If one of those fields is missing, a human colleague may have to ask back. An AI assistant may simply guess.

On-screen text

• A decision-ready request travels with the checks needed to answer it safely.
• 1. Decision/action
• 2. Answerable question
• 3. Threshold/trigger
• 4. Artefact
• 5. Cut of data
• 6. Accountable owner
• 7. Rules/handling
• 8. Trust Test
• AI answers the question you actually asked

Narration

The before line is the kind of request that lands in inboxes every day: broad, plausible, and not actually answerable without guessing. The rewrite does not add ceremony for its own sake. It says what decision is being made, what question can be answered, what threshold would trigger action, what artefact is wanted, what cut of data is in scope, who owns the request, what handling applies, and how the answer will be checked. The trust test is the one that often gets dropped. It is the difference between confidently sharing a number and confidently sharing a wrong number.

On-screen text

• Before: "Give me the latest the core operational system operational picture for the priority service area."
• DATA CART field
• After
• Decision/action
• Stage, deploy, or activate additional deployable resources for the core operational system continuity in the priority service area.
• Answerable question
• Which the core operational system sites or deployable resources require augmentation by location, power state, availability, capacity, and a partner organisation operational need?
• Threshold/trigger
• Act if two or more high-risk sites need current power, connectivity, or deployable resources support.
• Artefact
• One-page operational note with a dashboard reference, not a new dashboard.
• Cut of data
• Site A, Site B, Site C, Site D, Site E, Site F; latest the field status feed update; deployed vs activated status; site risk, a partner organisation requests, asset availability; relevant an external provider and confirmed field status inputs.
• Accountable owner
• Requester and operational owner to confirm the decision, approve the brief, and clarify gaps.
• Rules/handling
• Use the appropriate label, audience, approved channel, and sharing limits for operational status material.
• Trust Test
• Reconcile the core operational system dashboard, the field status feed notes, asset deployment log, and latest an external provider / confirmed field status updates; every asset labelled deployed, activated, staged, or not available.

Narration

Participants practise by choosing a real request they have received or given in the last month. If they cannot use a real one, they use the synthetic the priority service area the core operational system request. They fill the DATA CART fields and mark what they cannot answer without asking back. The output is not a brainstorm. It is a structured brief. If the web helper is used, the boundary must be explicit: it is an external demonstration site. Do not enter real personal, sensitive, operational, or client material. Use fictional, synthetic, or de-identified examples only.

On-screen text

• Rewrite a vague request into a decision-ready brief.
• Pick a real request you've received (or given) in the last month.
• Write the brief, filling in the DATA CART fields.
• Mark what's missing — which fields couldn't you answer without asking back?
• Decide the right artefact — dashboard, one-off extract, written answer, or no data at all?
• If you can't recall a real one, use the synthetic the priority service area the core operational system request from the worked example.
• Output: a structured brief, not a brainstorm.
• Optional tool: try the DATA CART web helper at https://decision-grade.industrial-linguistics.com/data-cart. Use synthetic or fictional examples only — it is an external, unsigned demonstration site, so do not enter real personal, sensitive, or client information.
• Decision-Ready Briefs

Narration

Now swap briefs with a partner. Read theirs as the analyst who has to receive the request and do the work. Could you act on it without asking back? Mark the gaps that would force either a human analyst or an AI assistant to guess: missing source, missing data currency date, missing threshold, unclear audience, ambiguous metric definition, or no handling note. Do not just check whether the form is filled in. Test whether the content is usable. Hand back one concrete rewrite: the single change that would make the brief more decision-ready.

On-screen text

• Swap briefs with a partner. You mark theirs; they mark yours.
• Read as the analyst receiving this request. Could you act on it without asking back?
• Mark what is missing — decision, audience, timeframe, metric definition, quality bar, expected artefact.
• Hand back one rewrite — the single change that would most improve their brief.
• Output: a marked-up brief and one concrete improvement.
• Brief Peer Review
• Decision-Ready Briefs

Narration

The Course Challenge is to take one artefact you actually produce — a dashboard, a recurring email, a request reply, a status pack — and make it decision-ready. That means a passport on it: owner, source, data currency date, audience, classification, known limits, review point. AI-generated outputs count as artefacts too. A summary an assistant writes for you, a dashboard a tool builds automatically, a scheduled script that emails numbers — they each need the same passport. The fact that a machine produced it does not give it a source, an owner, or a caveat.

On-screen text

• Course Challenge: Fix One Artefact
• Take one real artefact back to work. Give it a passport.
• Pick one dashboard, spreadsheet, report, or extract you publish or rely on. Add the six fields, even if only in a comment or cover note:
• Owner Source Version Freshness Handling Known limits
• Run this in the next two weeks. Bring the fixed artefact back to your team, and to Session 3 as the handling-rules check.

Narration

Because you are brilliant, others will learn from your wisdom (in response to that good spec)

On-screen text

On-screen text unavailable.

Narration

Once you answer a data request, the answer often keeps moving. A spreadsheet might be forwarded, copied into a briefing pack, or pasted into an email. Or it might be a status note, an extract, or a screenshot that someone else reuses. Once it has left your control, the context has to travel with it. A dashboard is different. You might send a link, but the data stays in the system. People return to it, access can be changed, and everyone expects it to keep refreshing. So a travelling artefact needs context attached. A dashboard needs product discipline: owner, refresh behaviour, access settings, and a life cycle.

On-screen text

• Travelling artefacts. Forwarded reports, spreadsheets, extracts, status notes, recurring emails, report packs.
• Leave the creator’s control. Get forwarded, copied, pasted into briefing packs, treated as reusable evidence.
• Need enough context to survive being separated from the person who made them.
• Non-travelling artefacts (products). Power BI dashboards, published apps, internal tools.
• Stay in place. People return to them. Have access settings, refresh schedules, a semantic model behind them.
• Outlive the original request. Can mislead for weeks if stale, ownerless, or poorly defined.

Narration

Focusing on the things that get forwarded: if it travels, give it CHORDS. That context might live in the first tab of a spreadsheet, in the email that sends it, or in a paragraph at the top of a report. The caveat says what you know is limited or wrong. The handling note says who can see it and where it can be shared. The owner tells the next reader who to ask. Refresh date tells them when the numbers were true. Definitions say what the key measures actually mean. Source says where the information came from and how someone would refresh or check it. Those six things are what stop a useful answer becoming detached from its meaning.

On-screen text

• If it travels, give it CHORDS.
• Caveat — the known limit a reader should be told.
• Handling note — classification and who it can be shared with.
• Owner — the team or person responsible for it.
• Refresh / As-of — when the numbers were last refreshed.
• Definition — what each key metric actually measures.
• Source — where the numbers come from.
• Caveat • Handling • Owner • Refresh/as-at • Definitions • Source

Narration

This is why CHORDS matters when AI is in the workflow. If the caveat is missing, the model may state a number confidently even though the original sender had already warned that it was incomplete. If the handling note is missing, the output can carry sensitive material further than it should. If the owner is missing, the tool does not know where the master source or responsible person is. If refresh information is missing, it can treat an old spreadsheet as current. If definitions are missing, it smooths over distinctions that humans already find difficult. If the source is missing, it may invent a plausible-looking reference instead of admitting it cannot check.

On-screen text

• Missing CHORDS shows up as:
• Caveat missing — the model states a number with confidence the data doesn’t support.
• Handling missing — sensitive material gets quoted in an output that travels further than it should.
• Owner missing — nobody to ask when the answer looks wrong, so the wrong answer ships.
• Refresh missing — stale figures are presented as the current state of the network.
• Definition missing — two metrics that sound alike get mixed, and the recommendation tilts the wrong way.
• Source missing — the model fills the gap with a plausible-sounding but fabricated reference.

Narration

For dashboards, you still need CHORDS, and you also need dashboard clocks. A dashboard is a maintained product, not a forwarded snapshot. It needs an owner, versioning, metric definitions, known limits, a support path, a review point, and eventually a retirement trigger. It also has more clocks. A forwarded spreadsheet has one obvious clock: when that snapshot was created or sent. A dashboard has at least two: when the tile last refreshed and when the upstream source last changed. If AI is layered on top, there is often a third clock: when the assistant last retrieved, indexed, or cached the dashboard context.

On-screen text

• A Power BI dashboard is a maintained product. It needs named owner, version, refresh policy, metric definitions, known limits, support path, review point, retirement trigger.
• Two clocks (three with AI).
• Forwarded spreadsheet: one clock — the as-at date.
• Power BI dashboard: two — when the tile refreshed, and when the upstream source actually changed.
• With AI layered on top: a third — when the tool last retrieved or indexed the context.

Narration

What to respond with (to that good spec)

On-screen text

On-screen text unavailable.

Narration

Before AI, effort acted as a rough filter. A dashboard was expensive enough that people usually reserved it for something recurring and important. A spreadsheet took effort. A simple extract or written answer was easier. With AI, those effort differences start to collapse. It can become almost as easy to ask for a dashboard as to ask for a paragraph. That creates a new trap: reaching for the most impressive-looking artefact instead of the one that fits the decision. The question is not what can we generate. The question is what form should this answer take so someone can act on it safely.

On-screen text

• Effort no longer decides the artefact. Dashboards used to be the hardest artefact to produce, report writing the easiest. AI compresses all four to roughly the same effort.
• Artefact
• Before AI
• With AI
• Dashboards
• Max
• Low
• Spreadsheets
• High
• Low
• Extracts
• Medium
• Low
• Report writing
• Low
• The trap isn't that AI lowers quality — it's that we now reach for the most ambitious artefact by default. Ask what form best fits the decision, not which one looks most impressive to make.

Narration

Before you build anything, decide which of four things you are producing. A dashboard monitors — a standing view of a changing state. A brief decides — a written recommendation someone can act on. A spreadsheet reconciles — a bounded list someone needs to sort, filter, or check. And a clarification unblocks — if the request is not answerable yet, ask back before building. If you cannot say which of the four this is, you are not ready to build it.

On-screen text

• Match the Artefact to the Decision
• If you can't say which of these four you are producing, you are not ready to build the artefact.
• Dashboards monitor. Standing view of a changing state for an operational user.
• Briefs decide. A written recommendation a leader can act on.
• Spreadsheets reconcile. A bounded list someone needs to sort, filter, or check.
• Clarifications unblock. Ask back before building anything when the request is not yet answerable.

Narration

Build a dashboard tile when the recipient needs a standing view of a state that genuinely changes between glances, and when an operational user will return to it repeatedly through a shift rather than look once. It only works if the metrics are stable and well defined — source, owner, refresh cadence, definition, caveats, and handling all settled. Reading the tile should lead directly to an action: dispatch, reroute, or escalate, not "interesting, we should look into that".

On-screen text

• When a Dashboard Is the Right Answer. Build the tile when the recipient needs a standing view of a changing state.
• The state actually changes between glances. the core operational system site status, power state, capacity, utilisation, service level during an evolving incident.
• An operational user will return to it repeatedly. Same user, same handful of metrics, multiple times a shift — not a one-off lookup.
• The metrics are stable and well-defined. CHORDS holds: source, owner, refresh cadence, definition, caveats, handling are all settled.
• Reading the tile leads directly to an operational action. Dispatch a deployable resources, reroute connectivity, escalate — not "interesting, we should look into that".

Narration

If the question matches one of these, send something other than a dashboard link. A leader who needs a recommendation gets a brief. Someone who needs to reconcile rows gets a spreadsheet. If the metrics are not settled — definitions in flux, owner unclear — fix that first, because a dashboard locks in the wrong number at scale. If the question is not answerable yet, ask back. And if it is a genuine one-off that nobody will return to, answer in a message; do not grow the dashboard estate.

On-screen text

• When a Dashboard Is the Wrong Answer. If the question matches one of these, send something else — not a link to something in Power BI.
• A leader needs a recommendation. Write a brief — e.g. whether to stage another deployable resources at a priority site, or embargo planned maintenance.
• Someone needs to reconcile rows, not monitor a trend. Send a spreadsheet — bounded list of the core operational system sites and deployable resources with deployed/activated status, power source, availability, last confirmed update.
• The metrics aren't settled. Definitions still in flux, owner unclear, refresh ad hoc. Settle CHORDS first; a dashboard locks in the wrong number at scale.
• The question isn't answerable yet. Ask back before building anything — scope, audience, and decision aren't clear.
• It's a one-time look. Nobody will return to it. Answer in a message or a screenshot; don't add to the dashboard estate.

Narration

Hand over rows when the recipient needs to reconcile, not monitor. The output is a list, not a trend — rows someone will work through, sort, filter, annotate, or join. The scope is bounded and used once or a few times, with defined fields and a defined data currency timestamp, and the context travels with the file. Reach for a spreadsheet when an audit or handover needs the underlying rows, so someone else can verify the numbers behind a recommendation.

On-screen text

• When a Spreadsheet Is the Right Answer. Hand over rows when the recipient needs to reconcile, not monitor.
• The output is a list, not a trend. A reconciliation of the core operational system sites with deployed/activated status, power source, availability, last confirmed update — rows someone will work through.
• The recipient needs to sort, filter, annotate, or join. e.g. cross-checking deployable resources against a maintenance window, or ticking off sites as they are confirmed.
• The scope is bounded and used once (or a few times). Defined sites, defined as-at timestamp, defined fields. CHORDS travels with the file.
• An audit or handover needs the underlying rows, not a summary view. Someone else has to be able to verify the numbers behind a recommendation.

Narration

Dashboards and spreadsheets answer different kinds of requests. A dashboard is right when people need to return to the same changing state over time. A spreadsheet is often right when the job is to reconcile, filter, annotate, or check a list. The artefacts should follow the decision, not the other way around.

On-screen text

• Pick a dashboard (e.g. from PowerBI) that you find helpful, or that you use regularly.
• Why is it a dashboard? What is the thing that it is monitoring? How does it get refreshed? Why does it help to have that as a dashboard?
• Pick a spreadsheet that you found helpful
• What was it reconciling? Why was a spreadsheet the best way to deal with this?
• If you have no examples of good dashboards or spreadsheets, feel free to invert this exercise to talk about the worst and most unhelpful (and explain why)

Narration

The handling note is what tells the recipient where the artefact may live, who can see it, whether it can be forwarded, and what limits apply. Start with sensitivity level and approved audience. Then check the practical channel: email, Teams, SharePoint, a dashboard, or an approved assistant. Finally, deal with the time limits: purpose, retention, review, and expiry. Handling is the practical rule that travels with the material. It is not just a label picker.

On-screen text

On-screen text unavailable.

Narration

Use the local participant-facing shorthand: Official, Sensitive, Protected. Official is routine business information, but not automatically public. Sensitive means formally Sensitive with a handling limit or handling marker where applicable. Protected is the higher bar for security-classified information. The practical advice is to ask the owner or custodian where the handling is unclear. It is much easier to downgrade a label after confirmation than to recall a travelling artefact after it has gone too far.

On-screen text

• Retention & Review
• Keep it as long as you need it; review on a cadence. Deletion is a feature, not a failure.
• Purpose
• Use data only for the purpose it was collected for. Reuse for a new question means ask, not assume.
• Classification
• Sensitivity level is a signal for handling: official, sensitive, or protected changes how it moves, is stored, and is shared.
• Access
• Least privilege by default: the right people see the right slice, no more, and need-to-know is auditable.

Narration

Use the local labels in plain English. In this public version, Official, Sensitive and Protected are example labels; use your organisation’s local equivalents where they differ. Official is routine work on approved channels. Sensitive means there is a real handling limit: operational detail, partner status, or material where a wider audience would cause harm or embarrassment. Protected is narrower again. For AI, the label applies to the whole interaction: prompt, attachment, retrieved context, chat history, and output. If one part needs tighter handling, treat the whole interaction at that level.

On-screen text

• Example labels: Official, Sensitive and Protected, or your organisation’s local equivalents.
• Always use the exact your organisation label shown in the managed environment, and confirm unclear cases with the information owner.
• Official — routine business. Share on need, inside approved environments. Default care, not extra friction.
• Sensitive — formally Sensitive with a handling marker or handling limit. Tighter access, named audience, no external sharing without approval.
• Protected — higher bar again. Named access list, documented purpose, and a reason it cannot be done at a lower marking. Handled in the approved environment only.
• When unsure — hold at the higher marking and ask the information owner. Downgrading is cheap; recalling a share is not.
• Detailed the shared document repository / DLP label-picker training sits in the your organisation reference material, not in this session — today's focus is the judgement call.

Narration

Before anything leaves your hands — email, chat, screenshot, AI prompt, upload — run the same short check: label, purpose, audience, channel, source, refresh date, caveat, review point. "Let the AI read this" is an access decision in disguise. Pasting a site availability extract from the core operational system into an assistant gives a tool access to that data. Pointing an agent at the document store folder gives it standing access to whatever is in there. Treat AI access with the same rigour as you would a share from the document store or a forwarded email.

On-screen text

• TRAVEL is the quick check before information leaves your hands. Keep the data inside approved environments — no personal drives, personal accounts, or unmanaged tools.
• T — Tag / label the exact your organisation handling marking on the artefact itself.
• R — Reason the decision or question this will serve, in one line.
• A — Audience named recipients or a scoped group, not "the team".
• V — Venue / channel an approved environment appropriate to the marking; share the link, not the file.
• E — Evidence / as-at named source system and the date the data represents, on the artefact.
• L — Limit / expiry when the recipient deletes, refreshes, or re-confirms access.
• Share the link, not the file.
• Run TRAVEL before it leaves your hands.
• Tag • Reason • Audience • Venue • Evidence/as-at • Limit/expiry

Narration

Pasting into a chat, uploading to a tool, or letting an assistant retrieve from a folder is a sharing decision. The recipient is not just the chat window. It includes the model and the approved tenancy. It also includes the vendor arrangements and support path. Then there are the later pathways: any training pipeline, any memory or retrieval layer, and future users who may see retained context. That does not mean every AI use is forbidden. It means AI access is still access. Use approved tools and approved environments for work material. Do not put internal work content into public tools. Do not use internal tools for personal material. AI outputs are drafts, not sources. Trace numbers, quotes, and claims back before they travel.

On-screen text

• Pasting into a chat, uploading to a tool, or pointing an agent at a folder is a sharing act. TRAVEL still applies — but four letters change shape.
• A — Audience the model is a recipient. Assume the vendor, the training pipeline (if there is one), and anyone who later prompts it (if there is memory) are part of the audience.
• V — Venue use only your organisation-approved AI tools and tenancies. Public Copilot, ChatGPT.com, free Gemini = not an approved venue for work content. Random sites from training vendors are a liability
• E — Evidence AI outputs aren't sources. Treat them as drafts; trace any number, name, or quote back to the system it came from before it leaves your hands.
• L — Limit the model has no expiry. If there is memory, then what you paste in today can resurface in another chat, another team, another tenancy. Don't paste what you wouldn't email.
• AI access is still access.
• TRAVEL + AI

Narration

Not every file is the same kind of thing. Some files are working files. Some are records. Some are evidence trails that explain how a number, report, or briefing was produced. For AI-assisted work, useful provenance starts with the prompt and the source documents or extracts. Then keep the generated output, the date, and the tool or model if that is available. Finally, record the human reviewer and any changes made before publication. Do not keep everything forever. Keep enough to explain the decision and dispose of what should not persist.

On-screen text

• Not every file is a record. Know which is which before you delete, archive, or forward.
• Working file — drafts, scratch extracts, a pivot you rebuilt three times. Useful to you, not proof of anything. Dispose when done.
• Record — the version you actually sent, published, or made a decision on. Kept for the retention period, in an approved location.
• Evidence trail — the chain behind the record: source pull, transform notes, approver, date. Lets someone reconstruct the number months later.
• Three practical questions — what do we keep, what do we dispose of, and what do we archive or refresh. Answer before you close the tab.

Narration

Before anything leaves your hands — email, chat, screenshot, AI prompt, upload — run the same short check: label, purpose, audience, channel, source, refresh date, caveat, review point. "Let the AI read this" is an access decision in disguise. Pasting a site availability extract from the core operational system into an assistant gives a tool access to that data. Pointing an agent at the document store folder gives it standing access to whatever is in there. Treat AI access with the same rigour as you would a share from the document store or a forwarded email.

On-screen text

• The records legislation still applies. AI tools add three places where records hide.
• Prompts and pasted content are records. Anything you type that documents a decision, advice, or transaction is a State record (the records legislation) the moment you send it — same as an email.
• The output is the easy half. People keep the report. They don't keep the prompt, the attachments, or which model produced it — exactly what an auditor or FOI request will ask for.
• Disposal cuts the other way. A model with retrieval over the document store sees what's there today. Records that should have been disposed of get resurfaced — retention failures become live again.
• Tool tenancy is not a records system. Copilot or ChatGPT conversations get auto-purged or kept indefinitely on vendor defaults — neither matches your organisation's disposal authority.
• If it's a record on paper, it's a record in the prompt.

Narration

This checkpoint is a judgement exercise about what really travels when AI is involved. It might be the prompt. It might be an upload, a retrieved folder, the generated output, the memory, or the record that gets created afterwards. In pairs, choose the safest route: allow it, minimise first, use a synthetic example, ask the owner, or decide that this is not an AI task. Then name the risk you caught and the control that follows the content. The important line is simple: AI access is still access, and the label follows the material into the output.

On-screen text

• Open: https://decision-grade.industrial-linguistics.com/checkpoint/
• Name what travels — before work data enters an AI tool, decide what is really moving: the prompt, the upload, the retrieved folder, the generated output, the memory, or the record.
• Choose the safest route — in pairs: Allow, Minimise first, Use a synthetic example, Ask the owner, or No AI for this.
• Risk & control — name the risk you caught and the control that must travel with the output. AI access is still access; the label follows the content.

Narration

In this activity, treat each access request as a decision, not a vibe check. Ask what the person is trying to do, what data they need, what handling rules apply, what environment is approved, and what evidence would make the access safe enough.

On-screen text

• Table groups. Three inbound access requests. For each one: approve, reject, or ask back.
• Scorecard — purpose, scope, classification, expiry, approver, audit trail.
• Requests (synthetic) — (a) "Send me the full the core operational system operational picture so I can brief my director tomorrow." (b) "Can I get site power status for every site for a vendor capability assessment — ongoing access?" (c) "I need last month's channel capacity and service level figures for three regions, for a specific after-action review."
• Decide and defend — for each request, which lane and which missing element closes it.
• Narrow enough to approve.Clear enough to audit.
• ACCESS = Aim • Cut/scope • Classification • Expiry • Sign-off • Storage/audit

Narration

Mosaic risk starts with details that look routine by themselves: a site list, a backup-power location, an availability dip, a liaison note, or a staged-versus-deployed count. The risk is the package. An AI tool is very good at joining those fragments and writing a confident story across a folder that no person would have manually pieced together. Judge the story the tool could produce, rather than the single row you typed in.

On-screen text

• Each snippet looks fine on its own. Combine three of them and ask: what marking would this composite picture attract — and why?
• Snippets (synthetic) — a public map of a regional town; a list of generic site IDs with utilisation bands; a deployable resources staging location with no dates; a roster of backup-power units by model number; an a partner organisation liaison roster with first names.
• Combine — which three, when joined, reveal the service area for a specific incident?
• Action — pick the combined marking, then name which owner you would confirm with before publishing the composite.

Narration

The CHORDS checklist helps a thing travel. Product discipline keeps a dashboard trustworthy over time. A Power BI dashboard is a product that people may return to every day, week, or incident cycle. It needs an owner, version, refresh policy, source-refresh indicator, metric definitions, known limits, support path, review point, and retirement trigger. Without those, dashboards can become stale products that still look current.

On-screen text

On-screen text unavailable.

Narration

Ownership means someone cares enough to keep the dashboard maintained, answer questions, and correct it when it is wrong. Versioning matters because metric definitions and transformations change. If someone took a screenshot last week and another this week, they need to know whether the same definitions are being used. Support matters because a dashboard with no support path can continue to be relied on after the people who understand it have moved on.

On-screen text

• If you publish it, you maintain it. Every dashboard is a small product.
• Owner
• A named human accountable for what it says. Not a mailbox, not a team alias.
• Version
• Visible on the artefact. A logic change bumps the version and gets a one-line note.
• Refresh policy
• Both clocks: when the tile last redrew, and when the upstream feed last wrote.
• Known limits
• Exclusions, definition gaps, and the reads it cannot support.
• Support path
• Where a reader goes when it breaks or when a number looks wrong.
• Review / retirement
• When it is reviewed next, and the trigger that retires it.

Narration

Every dashboard or report that travels or gets published should show enough trust cues for a reader to use it safely: owner, source, freshness, definitions, limitations, audience, access, and review point. TRACE the number before you trust the number: track the source, record the version, account for transformations, caveat the limits, and keep enough evidence for review. The same applies to AI-generated commentary beside a dashboard. It must say what source it used, how fresh it is, what it excludes, who reviewed it, and who is allowed to rely on it.

On-screen text

• Owner & Definitions
• Named owner on the artefact. Each metric has one agreed meaning shown alongside.
• Source & Freshness
• Source named; as-at date visible. Make dashboard vs source refresh explicit.
• Limitations
• Known gaps, exclusions, and reporting changes are called out, not hidden.
• Audience & Access
• Right audience, right level of detail. Local-file copies fail this test.
• TRACE the number before you trust the number: Track source, Record version, Account for transformations, Caveat limits, Evidence trail.

Narration

This is one of the most important dashboard points. A dashboard tile might say it refreshed at 08:03. That means the dashboard recalculated. It does not necessarily mean the upstream source changed at 08:03. If the upstream feed has been stale since Tuesday, the dashboard can look fresh while the operational picture is stale. Ask two questions: when did the dashboard refresh, and when did the source refresh? AI adds a third clock. If an AI assistant is reading an export, index, or cached view, ask when that AI context was last retrieved or updated.

On-screen text

• "Last refreshed 2 minutes ago" tells you the tile is fresh. It does not tell you the number is.
• Clock 1: dashboard refresh
• When the tile last queried its source. In the example: 08:03 today.
• Clock 2: source refresh
• When the upstream system last wrote new data. In the example: stale since Tuesday. Invisible unless you check.
• Show both clocks on the artefact, or show the older of the two. If a feed is stale past its tolerance, mark the tile as not current and say what is excluded. AI adds a third clock: context freshness.

Narration

A plain table with source, owner, data currency date, definitions, caveat, and handling can be safer than a beautiful dashboard with none of those things. This is not an argument for ugly work. It is an argument for accountable work. Make it polished after the trust cues are visible.

On-screen text

• Same monthly service disruption number, two versions. Polish is not trust.
• Plain but publishable — a black-and-white table. Title says "Priority 1 incidents, metro region, Mar 2026". Named owner. Source and as-at date on the page. One footnote noting two sites were under maintenance. It looks dull. You can defend every number.
• Polished but unsafe — a full-colour dashboard with map overlays, trendlines, and a glossy header. No owner. No source. "Last updated" shows today, but the underlying extract is a local copy from three weeks ago. Regions are inconsistent — some use postcode, some use LGA.
• What changes the answer — the polished one would pass a glance test in any exec meeting. It would also mislead the meeting. The plain one wouldn't win a design award, and it's the one you send.
• The rule — trust is provenance, ownership, and caveats visible on the artefact. Everything else is decoration.

Narration

Open the synthetic training dashboard and look for what a publisher should have caught before it went live. Do not stop at chart colours or visual polish. Look for source-refresh problems, unclear definitions, a percentage with no denominator, copied-extract or local-file lineage, and missing audience or handling markers. Write one line for each problem: what you saw, why it matters, and what would need to change before the dashboard could be published. The useful AI question is: if an assistant summarised this dashboard for an executive, which hidden issue would it probably miss?

On-screen text

• Open the Power BI training dashboard (synthetic data, GA-hosted). Spend ten minutes finding what a publisher should have caught.
• Spot it — missing source-refresh cues; unclear or missing definitions; a percentage with no denominator; copied-extract or local-file lineage; audience or handling marker that does not match the environment.
• Note it — for each issue, write one line: what you saw, why it matters, and what you would change before it could be published.
• Debrief — share the worst issue you found and the one most likely to fool a busy reader. We line them up against the Dashboard-as-a-Data-Product fields.
• Power BI synthetic training dashboard — link in the chat.

Narration

If work happens across a secure environment and a corporate environment, do not let convenience become the bridge. The boundary has to stay visible: what can be copied, where it can be summarised, which tool is approved, and who is responsible if the shortcut moves data to the wrong side.

On-screen text

On-screen text unavailable.

Narration

Work happens in two environments. the shared document repository Corporate is the everyday space — email, Teams, the document store, the dashboards most people see. the core operational system Secure carries higher-sensitivity material — the field status feed notes, a partner organisation liaison detail, status for deployable resources, backup-power unit status, certain the core operational system site availability and power-state detail. The boundary is what makes the handling rule meaningful. Do not infer across, paste across, screenshot across, export across, or summarise across the boundary unless the confirmed local process says you can. AI tools cannot be used as a backdoor between environments either. If an approved assistant only exists in one environment, you cannot feed it material from the other to get around that. The fact that an AI tool can produce an apparently-sanitised summary does not make the summary safe to move. If you are unsure, confirm with the owner, the custodian, or the cyber team before acting.

On-screen text

• Some organisations run two separated environments — for example a secure network and a corporate network. If that is you, these rules apply:
• Access — the two environments are governed separately. Use the access you have been granted in each; do not assume a permission in one carries to the other.
• Copied extracts — do not move, copy, export, screenshot, or summarise across environments unless authorised. A copy made for convenience is the most common way data ends up where it should not be.
• Publication & sharing — publish only into approved environments, follow the confirmed local process for the destination, and use the handling marker the receiving environment requires.
• Honest truth — All organisations that run dual (or more) security environments face challenges. Not every problem can be solved well.

Narration

When work crosses from a secure environment into a corporate environment, convenience cannot be the bridge. Corporate teams may need budgeting figures, vendor records, audit remediation status, portfolio KPIs, asset planning summaries, or disclosure-case information. But they usually do not need the operational record itself. The safer pattern is a controlled extract or a summary that matches the corporate need. Aggregate what can be aggregated. Strip out operational detail that the audience does not need. Keep the reason, destination, owner, and handling rule visible so the extract does not become a backdoor between environments.

On-screen text

• Controlled extracts: secure side to corporate side
• Corporate need
• the core operational system-side source data
• What should move to the shared document repository Corporate
• Budgeting & cost recovery
• the core operational system cost centres, project codes, vendor spend, charge-back models
• Aggregated cost-recovery feeds; budget actuals by program
• Procurement & vendor mgmt
• Contract registers, supplier performance, renewal dates, NDAs
• Vendor master records; contract metadata and expiry alerts
• Executive reporting
• Operational dashboards, incident tallies, KPI rollups
• Curated KPIs and trend lines for portfolio-level reporting
• Risk & audit
• Control test results, audit findings, exception logs
• Open findings, remediation status, attestation evidence
• Asset planning
• Asset registers, lifecycle stage, refresh cycles, capacity utilisation
• Asset class summaries and forward refresh schedules
• Legal & FOI
• Disclosure logs, FOI request history, redaction precedents
• Disclosure case summaries and standard redaction rules
• Corporate often needs a controlled extract, not the operational record itself.

Narration

This is the short version of mosaic risk: do not rate each detail only by itself. Ask what someone could learn by combining the details, and then ask what an AI tool could learn if it searched the folder, joined the records, and wrote the summary for them.

On-screen text

• Combination in the shared document repository Corporate
• What it may reveal
• Why that becomes sensitive
• Procurement spend + project codes
• Which programs are under-resourced or being wound down
• Pre-public funding decisions, signals for affected communities or competitors
• Audit findings + remediation status
• Which controls are weak today and for how long
• Roadmap for exploitation by an insider or external actor
• Open FOI cases + disclosure logs
• What topics journalists and applicants are probing
• Pattern of public-interest pressure; tip-off about pending releases
• Asset register + lifecycle stage
• Which systems are end-of-life or unsupported
• Targeting for cyber-attack on aging or unpatched infrastructure
• Staff records + project assignments
• Who works on what and when
• Inference of identities for sensitive programs (e.g. critical infrastructure, critical infrastructure sites)
• Calendar + procurement + travel data
• Pre-announcement movements of executives or ministers
• Signals about deals, investigations or political activity not yet public

Narration

The old protection was slowness. Aggregating lots of minor data points into a complete picture used to be tedious. If a person deliberately stitched together snippets from many folders, contracts, dashboards, or logs, they generally knew they were doing something sensitive. AI changes that because it can reassemble the picture quickly and enthusiastically. The original pieces may each look ordinary, but the combined summary can reveal a restricted picture. If an AI-generated package now reveals more than the source fragments appear to reveal, treat it according to what it now says.

On-screen text

• Aggregating lots of minor data points into a complete whole is so tedious that no-one would ever do it.
• In a world of humans doing information aggregation, the snippets of secure data that made it into the shared document repository didn’t pose a security problem.
• If you did deliberately aggregate snippets, you knew you were breaking the rules
• But in a world with AI doing information aggregation, you can accidentally create a classified document in the shared document repository.
• Usual protocols apply for dealing with misclassified data

Narration

For the dataset, do not stop at asking whether each row is safe by itself. Ask what someone could infer after combining rows, matching them with other records, or asking an AI tool to summarise the pattern.

On-screen text

• Download the Mosaic Risk zip file from https://decision-grade.industrial-linguistics.com/downloads/data-minimisation-extract-challenge.zip
• There is a spreadsheet of fake data that could be from the core operational system Secure network.
• Executives want to know which regions experienced service disruptions in Q1 2026, what the main causes were, and how long service disruptions lasted on average. They do not need to know which specific sites or engineers were involved.
• Select a minimal set of fields to share and decide how to aggregate the data to meet the business need. For example, you might summarise: total number of incidents per region, average duration per region, counts of incidents by cause (weather, equipment failure, etc.).
• What information does that cause to leak? What potentially secure information is being made public?

Narration

Session 2 was about discipline around outputs that travel. A good data request starts with a decision, not the artefact. Classification is a handling decision, not a label decoration. A publishable output needs source, owner, data currency date, definition, caveat, handling and review context. Dashboards are data products and need trust cues. AI outputs inherit the governance of the data, prompts and tools used to create them. The workplace action is to take one output your team forwards regularly and add the context that must travel with it.

On-screen text

• What we covered today
• A good data request starts with a decision, not the artefact.
• Classification is a handling decision, not a label decoration.
• A publishable output needs source, owner, as-at date, definition, caveat, handling and review context.
• Dashboards are data products and need trust cues.
• AI outputs inherit the governance of the data, prompts and tools used to create them.
• Workplace action: take one output your team forwards regularly. Add the context that must travel with it.