
What if we could leverage how AI interprets language to give us insights into what politicians are talking about in parliament?

Feel free to skip straight to the results if you're short on time, but if you're up for it, I promise to make the journey entertaining and enlightening!

First things first, two things (and an additional bit):

1. This will be an objective exercise of Applied Data/AI to shed light into how industry benchmarks can be exploited. Findings here aren't a "political opinion" — hopefully you'll see as clearly as I do that, for the purpose of this article: politics are completely irrelevant in the face of how cool applied data is!

2. Shoutout to [Ed Donner](https://www.linkedin.com/in/ed-donner) for the inspiration to write this! Ed's course takes you through the entire domain of Large Language Models with highly stimulating explanations and applications — I truly recommend it for anyone serious about going down the AI engineering road.

*Additional bit: I wrote this article a few weeks ago and forgot about it until I saw there was parliamentary activity again, so the Hansard I'm using is from March — I didn't want to just let the analysis go to waste.*

---

## Context

### Talking Machines: from Data Science to Artificial Intelligence

Not so long ago, when people talked about AI, they mostly meant predictive systems. Data scientists, armed with sophisticated data-processing tools, built models to forecast outcomes, make recommendations, or assess risk.

And don't get me wrong — predictive modelling was (and still is) cutting-edge in most industries. But if we're talking nerd-o-meter levels, things didn't get truly sci-fi until machines started predicting the next word in a sentence at a very large scale.

To reiterate, because this is truly the breakthrough: a machine can effectively predict what combination of words best suits the conversation it currently is in. This means that we can now unpack semantic interpretation mathematically, which is exactly what we'll do.

### Organizing Data (slightly technical, but get down w/the lingo)

Just to be aligned, a Large Language Model (LLM) transforms words and sentences into numbers positioned in an N-dimensional (vector) space. Humans are naturally limited to imagining just three dimensions, but mathematics isn't. What does this imply? Simply put, an LLM translates text into numerical representations (vectors), packing deep meaning into these numbers.

Now, you've likely heard the buzzword "Vector Database" (vDB) floating around. A vDB is essentially an engine built specifically to store these meaningful numerical representations (vectors). Here's a quick example to illustrate the concept clearly: when you search for "king - man + woman," the vector engine returns "queen." That's exactly the magic we'll use to compare and analyze parliamentary speeches.

Lastly, remember how we humans can't visualize more than 3 dimensions? Well, 3 dimensions is still clunky — much easier to see it all in 2 dimensions! That's where **t-SNE** enters the party. All you really need to know about t-SNE is that we use it to squeeze high-dimensional numbers onto a 2D space while respecting "who is close to whom." Imagine it as flattening a complicated globe onto an easy-to-read map without losing the relationships between cities.

### Huggingface: a public zoo of free models

To quote Andrej Karpathy, software is evolving! We've gone from:
- **1.0** — Computer code stored in GitHub
- **2.0** — Neural net weights stored in data
- **3.0** — LLMs stored in Hugging Face

For reference, we'll be using a free model from Huggingface to vectorize the Hansard: **all-MiniLM-L6-v2**.

---

## Results

### ~30 lines of code

This is what the pipeline (overall) looks like:

```python
# 1. read XML → grab every <talker> + <p> block
speeches = parse_hansard("House_2025_03_25.xml")

# 2. slice long speeches into 1k-character bites
chunks = splitter.split_documents(speeches)

# 3. turn each chunk into a 384-number vector
emb = HuggingFaceEmbeddings("all-MiniLM-L6-v2")
vectordb = Chroma.from_documents(chunks, emb)

# 4. pull the vectors back out, run t-SNE
vecs = vectordb._collection.get(include=["embeddings"])["embeddings"]
proj = TSNE(metric="cosine").fit_transform(vecs)

# 5. colour by speaker's party, hover shows first 100 characters

# 6. gradio to chat with the vector database if we want to go a step further
```

### The map

Looking at the semantic map, it appears that on this sitting day, the style of talking for:

- **The ALP** seems to have an individual style of talking positioned mostly on the *top half* of the space.
- **The LP** more *bottom left*, though their style of talking meets the ALP on a lot of topics on the upper left.
- **The LNP's** style of talking is on the *bottom center*, where they are met by all parties and even the AG, and center.

Note: It's important to remember that you're looking at vector space (semantic plane) — meaning that left, right, above, or below don't mean anything other than the semantic interpretation map for this particular embedding model.

### Quick visual insights (this sitting day)

On this sitting day, **23,751 total chunks** were analyzed. The topic distribution was:

- **54%** — Climate, Industry and Infrastructure (the most debate)
- **~19%** — Cost-of-living and jobs
- **1.8%** — Migration (the least mentioned topic)

---

## What's next? I can continue down the Hansard road

1. **Seasonality drift** — did parties' language clouds move closer/apart as campaigns came and go?
2. **Budget week pulse** — should I make it spicier, consolidate a year or two of debates and identify fallacies?
3. **What are you interested in?** — Tell me in the comments.

I'm also contemplating abandoning the Hansard and maybe doing some analysis on Annual Reports for publicly listed companies.

Either way, thanks for riding it out with me! Happy to hear your thoughts 🙂


What if we could leverage how AI interprets language to give us insights into what politicians are talking about in parliament?

AI in Action — A Hansard Analysis


Because Learning Nodes focuses on DecisionOps, it would be a great moment to define it as a word and lay out its main strategic pillars.

**DecisionOps** is the operating discipline that turns business questions into defensible decisions by making Assumptions, Interpretations, and Evidence explicit, versioned, and reusable.

DecisionOps tackles:

1. **Question Debt**: The unanswered business questions that pile up silently — until they surface as costly reversals. Not because the data wasn't there, but because the question was never properly framed, tracked, or resolved.

2. **Decision Decay**: The slow rot that happens after a decision is made. The reasoning disappears, the assumptions go unrecorded, and all that survives is a dashboard or a slide. Six months later, no one remembers *why* it was decided — only *what* was decided. And when conditions change, there's nothing to revisit.

---

## Core Idea: Above Tools, Below Decisions

DecisionOps exists **above tools** and **below decisions**.

Organizations already have:
- Data tools (SQL, BI, Excel)
- Governance tools (catalogs, lineage)
- Collaboration tools (Slack, Confluence)

What they do not have is **infrastructure for how decisions are formed from data**.

Learning Nodes fills that gap.

---

## The Biggest Problem: Invisible Reasoning

The biggest failure in modern analytics is not bad data — it is **invisible reasoning**.

Today:
- assumptions are implicit
- interpretations compete silently
- validation is informal or skipped
- context is lost as soon as artifacts are shipped

Learning Nodes is designed to externalize, structure, and preserve reasoning over time.

---

## How this shows up in everyday work

**Making decisions first-class objects:**
- Decisions are treated as first-class objects, not outcomes
- Business questions, assumptions, interpretations, and evidence are explicit and structured
- Tools (Excel, dashboards, notebooks) are framed as *artifacts*, never as the core workflow

**Making assumptions explicit:**
- Assumptions are named, versioned, and challengeable
- Multiple interpretations can coexist and be compared
- Validation is a phase, not a feeling
- Decisions have memory: past context can be revisited, forked, or reused

**Fluid collaboration:**
- DecisionOps is not role-specific software. It is a **shared decision workspace** where different roles appear at different moments — naturally.
- Stakeholders, analysts, SMEs, DEs, DS/ML, and AI agents all engage with the same question, but not in the same way or at the same time.

---

## Common Traps (Don't go down this route)

- Tool comparisons ("better than Excel", "replacement for BI")
- Feature-led explanations
- Workflow diagrams that end at "delivery"
- Treating "confidence" as subjective
- Presenting validation as a checkbox
- Linear "handoff" metaphors
- Org-chart thinking
- Over-indexing on AI novelty

---

## Who this is for

**If you're an analyst**, DecisionOps gives you leverage: it turns your work from reactive delivery into orchestration of understanding.

**If you're a leader**, DecisionOps gives you clarity: it lets you see *why* a decision was made, not just *what* was decided.

**For risk, compliance, and legal teams**, DecisionOps provides something they rarely get today: a clear, auditable trail of assumptions, evidence, and rationale behind critical decisions.

---

## The bottom line

Most organizations don't fail because they lack data, tools, or talent. They fail because **decisions are not treated as a system**.

DecisionOps is an attempt to change that: to give business questions structure, to make reasoning explicit, and to turn decisions into durable assets rather than one-off outcomes.

> Decision-making is becoming the last human advantage. It deserves its own operating model.


I defined DecisionOps, not as a buzzword, but as an operating discipline. Here are its main strategic pillars.

DecisionOps — The Business Layer Above Data


There's an old idea from the British Enlightenment that sounds pessimistic at first, but it's actually brimming with optimism:

> **The problem is inevitable.**
>
> Not *a* problem. *The* problem.

The idea is simple: **progress doesn't eliminate problems. It changes their shape.**

This idea quietly powered the Enlightenment. And today, it explains something most AI conversations miss entirely.

---

## Why this matters right now

We're bombarded with hype that AI is going to:
- Replace analysts
- Replace developers
- Replace designers
- Replace decision-makers

Because it "learns."

But let's get real for a second:

> AI only works in worlds where the problem is already defined.
>
> And the real world doesn't work like that.

---

## Supervised learning reveals the limit

Let's talk about supervised learning, because it's the cleanest example.

Supervised learning assumes:
- A defined objective
- A known label
- A stable feedback loop
- A past that meaningfully represents the future

In other words: **the model doesn't discover the problem. It inherits it.**

*For the tech folks: When "training models" we're always tweaking to avoid "overfitting," which means we're admitting upfront that we're molding the thing to fit what we already have.*

And here's that Enlightenment gem staring us in the face:

> The moment the model gets good at the task, the real problem has already moved.

---

## The "Inevitable Problem Loop"

This is the framework most AI discussions are missing:

1. Humans solve a problem
2. That solution reshapes the environment
3. New constraints, incentives, and failure modes appear
4. A new problem emerges — one that was invisible before
5. Humans must reinterpret reality again

**AI fits neatly into step 2.**

**Humans live in steps 3–5.**

---

## Why this can't be automated away

AI is instrumental. It optimizes *within* a frame. It does not question:
- whether the frame is still valid
- whether the metric still means what it did last year
- whether the old solution created new problems

These are not compute problems. They're not data problems. They're **interpretation problems**.

And interpretation is inherently human.

---

## Why AI feels threatening anyway

AI spooks people because it's killer at the stuff that used to pass for deep thinking.

But honestly, the real juice in any job was never the grunt work. It was in:
- Framing the right question
- Knowing when a metric stopped meaning what it used to mean
- Understanding *why* something worked — so you could adapt when it didn't
- Explaining trade-offs to other humans

AI accelerates execution. It **amplifies the rate at which new problems appear**.

---

## The wall AI keeps hitting

AI doesn't fail because it's weak.

It fails because: **progress creates novelty. Novelty breaks models. Every time.**

This is the epistemological barrier — not a compute problem, not a data problem, but a **knowledge problem**.

---

## A letter of hope (and responsibility)

If you're a professional reading this — analyst, engineer, PM, founder — here's the good news:

> You are not competing with AI.
>
> You are operating **upstream** from it.

Your job is not to be faster at answers. Your job is to:
- Decide which questions are worth asking
- Notice when yesterday's solution became today's problem
- Navigate trade-offs that no dataset can label yet

AI will make this *more* important, not less.

The future doesn't belong to people who "out-compute" machines.

**It belongs to people who can reinterpret reality when the problem inevitably changes.**

And it always will.


There's an old idea from the British Enlightenment that sounds pessimistic at first, but it's actually brimming with optimism: The problem is inevitable.

Start reading

The DecisionOps Guide

The Growth Engine

Applied Growth

AI + DecisionOps

From the blog

AI in Action — A Hansard Analysis

DecisionOps — The Business Layer Above Data

"The Problem Is Inevitable" — and That's Why AI Won't Replace You