If any of that is recognisable, the diagnosis you have probably been given is wrong. It is not that your people cannot communicate. It is that they are operating in different modes of thinking, and nobody has given them a vocabulary for the mode they are in or a way to translate between them. Mode mismatches read as personality clashes, competence gaps, or cultural misfits — and as long as they are read that way, every fix you try will land slightly off the actual problem.

Every team has a mode it does well and a mode it pretends to do. The mode it does well is the one that produced its early wins, that its best people lean into, that gets rewarded in performance reviews and shows up in the way meetings are run. The mode it pretends to do is the one the work also requires but nobody really owns — the strategy phase that gets skipped, the structuring middle that gets hand-waved, the activation arc that nobody watches once the launch is done. Most of what feels like dysfunction in a team is the gap between those two modes catching up with them.

This document is a vocabulary for noticing the gap. It names ten ways of holding information — four pure modes at the corners (red linear, yellow wave, deep green node, deep blue matrix), four transitions that describe how one mode hands off to the next (purple, orange, mint, light blue), and two orchestration arcs that describe how the modes chain together over time (white for creation, black for activation). Each one names a kind of work, not a kind of person. The same person moves between several of them in a single day; the same team is asked to do all of them across a project.

The framework is descriptive before it is prescriptive. It does not tell you which mode is best, or which mode you should be in, or how to “fix” someone who is in the wrong one. It tells you what each mode is good for, what it needs to do its best work, how it tends to be misread by other modes, and where AI can act as a bridge so two people in different modes can collaborate without having to leave their home mode entirely. Most prompt failures, most meeting failures, and most cross-functional failures are mode-mismatch failures. Once you can name the mismatch, you can usually fix it.

A note on how to read this. The taxonomy is built bottom-up — each mode in turn, then the orchestration arcs, then worked examples for the most common bridge problems. If you are reading it as a piece of thinking, take it in order. If you are reading it because something is broken and you need a fix, jump to the friction index in the next section, find the problem closest to yours, and follow the pointers from there. The modes will still make more sense once you have read them, but the index will get you to the relevant ones first.

What problems this framework solves

Most teams have the same four arguments on a loop. Strategy days that produce nothing anyone builds. Standups where the engineer feels interrogated and the lead feels stonewalled. Briefs that arrive at the dev team unbuildable and bounce back to the PM as “more detail please”. Marketing bringing customer signal into a roadmap meeting and watching it get tuned out as anecdote. None of these are competence problems. All of them are mode-mismatch problems being read as competence problems, which is what makes them hard to fix — both sides walk away convinced the other side is the issue.

This framework gives you a vocabulary for what actually broke. Instead of “the PM is fluffy” or “the engineer is rigid,” you get “a deep blue artefact was handed to a red thinker without a purple pass through the middle.” That sentence sounds technical but it is doing useful work: it names the missing step, points at who is best placed to do it, and makes the fix a process change rather than a personality clash.

The framework solves four specific problems.

It names handoff failures so you can fix the handoff rather than blame the people. Most cross-functional friction is not about the people in the room. It is about a missing translation step between two modes that do not naturally speak to each other. Once you can see the handoff, you can build a ritual around it — a kick-off, a scoping doc, a translation prompt — instead of relabelling the same fight every quarter.

It tells you which AI tool fits which problem. “Use AI more” is useless advice. “Use a long-context model to freeze a six-month log into a node map for the next person” is actionable. The framework gives you a diagnostic for matching the model to the mode and the prompt pattern to the handoff, so AI stops being a vague productivity claim and starts being a specific bridge between specific people.

It explains why high-performing people sometimes look like underperformers. A node thinker measured on output volume looks lazy. A wave thinker asked for a point estimate looks evasive. A matrix thinker pushed for a fast answer looks paralysed. In each case the value the person brings is real but invisible to the metric being applied. The framework makes the gift legible so it can be measured on its own terms instead of someone else’s.

It separates “we need a different person” from “we need a different process”. This is the move that distinguishes it from trait frameworks. When a team is struggling, the trait-framework reflex is to hire for the missing colour. The task-framework reflex is to ask which mode the current work is skipping and whether the people you already have can cover it with the right handoff. Sometimes the answer is still hiring. Often it is not.

What this is and is not

If you have spent time with Myers-Briggs, Insights Discovery, DISC, or similar frameworks, the colours below will look familiar in a way that is going to mislead you. Those frameworks are about people and output behaviours. This one is about the tasks people do and their default thinking modes.

In a trait framework, the colour is who you are — the result of a test that measures consistent behaviours and sorts you accordingly. The claim is that the result is reasonably stable, and the framework helps a team by sorting members and noticing that, say, the blue and the yellow will need a translator.

In this framework, the colour is what the work is asking for right now, and your default thinking mode is the one you reach for when the work has not told you which mode it needs. The same person can be in deep blue at ten in the morning (mapping a strategic field), in red by eleven (writing the spec that came out of it), in orange by two (clearing the queue of comments), and in yellow by four (watching how the change is landing). Their default may be deep blue — that is where they go when the work is ambiguous — but the work itself can pull them through every other mode in a single day. The default has not changed. The work has.

This matters because the diagnostic moves you make are different. A trait framework says: this team is unbalanced, hire a green. A task framework says: this team has skipped the deep-green phase of its current project, and the symptoms you are seeing are what skipping that phase always produces. The first is a hiring conversation. The second is a process conversation. Both can be right; they are not the same conversation.

People do still have defaults. Most people are more comfortable in some modes than others — a home base — and a team’s centre of gravity shifts the modes it tends to skip. But the default is a tendency, not an identity, and the diagnostic value here lives in the verbs, not the nouns.

The aim is to make a single team able to be self-sufficient and move through all phases by themselves, otherwise they have dependencies. A team that can only do red and orange will always be waiting on someone else to hand them the matrix; a team that can only do deep blue and light blue will always be waiting on someone else to turn the matrix into action. Both teams look productive in their own mode and stuck at the handoff, and both end up blaming the other side for the gap. The fix is not to merge the teams. The fix is to give each team enough fluency in the adjacent modes — with AI doing the heavy lifting at the bridges — that they can finish the arc themselves and only escalate when the work genuinely needs another team’s gift.

Self-sufficiency does not mean every team member is good at every mode. It means the team as a unit can recognise which mode the work is asking for, has at least one person who can hold that mode credibly, and has the tools and vocabulary to translate between modes without losing what matters. A team that hits this bar stops generating the kind of dependency that shows up as “blocked on strategy” or “blocked on engineering” in every standup — because the team itself can do the structuring middle, and only reaches outside when the work has genuinely exceeded what they can hold.

1. Purple — Matrix → linear

Axis: Breadth → depth

A grid of nodes on the left compresses into a single sequential row. The transformation collapses many simultaneous relationships into one focused, ordered path. This mode commits to a course of action after holding the whole field in mind.

Who tends to lean this way

People who lean into this transition are often the ones who feel comfortable in messy strategy sessions but get restless until something becomes a plan. They tend to gravitate toward roles like product management, founders moving from vision to roadmap, programme leads, editors-in-chief, and chiefs-of-staff — places where the job is to take a wide problem space and turn it into a sequence other people can act on.

What they need to do their best work

What helps: time to sit with the full picture before being asked to commit, and a collaborator who will not push for the linear plan too early. What drains: being forced to commit before the matrix feels complete. What kills flow: being interrupted while collapsing the matrix — the synthesis is fragile until it is written down.

How other modes can misread them

If misunderstood, this person can look indecisive to linear thinkers (”why are they still rewriting the plan?”) and reductive to matrix thinkers (”they flattened all the nuance into a list”). In a role that demands pure execution, they look slow; in a role that demands pure exploration, they look like they are closing things off too early. The thing being missed is that the value lives in the moment of compression itself — the move from many possibilities to one ordered path. Pushed into pure linear work, they become frustrated mediators of a plan they would have written differently. Pushed into pure matrix work, they get visibly restless because nothing is becoming.

AI as a bridge

AI is most useful here as a translator. Hand it the matrix — the messy notes, the comparison table, the half-formed thoughts — and ask for a sequenced plan. Claude (Opus or Sonnet) is well-suited: it holds long context and produces structured prose, so it can take a wide brief and return a coherent ordered draft. Useful prompt pattern: “Here is everything I am holding. Give me the three orderings that make most sense, with the trade-offs of each.” The point is not to let AI choose for you but to externalise the matrix so the linear path becomes easier to see.

2. Red — Linear thinking

Axis: Depth

One step at a time, in order. This mode is at its best when there is a single right path and the cost of skipping ahead is high. Focus narrows as the sequence advances.

Who tends to lean this way

People who lean linear often gravitate toward roles where order genuinely matters: legal drafting, compliance, accounting and audit, engineering with strict dependencies, surgery, aviation, project execution against a Gantt chart. Many of them are excellent at these jobs because they hold the discipline that other modes find tedious.

What they need to do their best work

What helps: a clear specification, one task at a time, and protection from new requirements mid-stream. What drains: being asked to ideate across many possibilities without a north star. What kills flow: someone re-opening step three when they are already on step seven.

How other modes can misread them

If misunderstood, this person can look rigid or unimaginative to matrix and node thinkers (”why won’t they just brainstorm with us?”) and slow to wave thinkers (”they’re still on item one while the situation has changed three times”). In a brainstorm or open strategy session, they look unresponsive — but they are usually waiting for the field to settle into something they can sequence. The thing being missed is that their precision is the asset; the discipline they bring is what stops the plan unravelling in delivery. Pushed into a role that demands constant re-prioritisation or open-ended ideation, they burn out fast and start looking like a poor cultural fit, when in fact they have been put in the wrong mode for their gift.

AI as a bridge

AI can absorb the chaos that interrupts linear flow. Use a fast model (Claude Haiku, Gemini Flash, GPT mini) as a buffer — let it handle the inbound questions, the half-formed pings, the “can you also...” requests — and only surface the ones that genuinely change the path. Useful prompt pattern: “Here is my current step. Tell me only if any of this new information actually invalidates it.” For the deep work itself, Claude is good at staying inside a single specification without drifting.

3. Orange — Linear → wave (queues)

Axis: Depth

Sequential steps gain rhythm and timing. Items are still ordered but now move with pressure and pacing — the line bends into a wave. This is where queues, throughput and back-pressure first appear.

Who tends to lean this way

People who lean into this transition often work in operations, logistics, customer support team-leads, manufacturing, restaurant kitchens, ER triage, and live service incident response. The job is rarely about one perfect step — it is about keeping the line moving when items arrive faster than they can be processed.

What they need to do their best work

What helps: visibility into the queue and permission to drop or defer items. What drains: pretending every item gets the same depth of attention. What kills flow: a stakeholder who watches one item rather than the throughput.

How other modes can misread them

If misunderstood, this person can look careless to linear thinkers (”they didn’t finish item three properly”) and chaotic to matrix thinkers (”they don’t have a strategy, they’re just reacting”). In a culture that prizes craft per item, they look like they cut corners; in a culture that prizes long planning, they look reactive. The thing being missed is that the craft is in the throughput, not the individual item — keeping the queue moving with acceptable quality is a different skill from making any single item perfect. Pushed into a role that requires deep sequential focus or long-horizon planning, they feel trapped and start dropping balls; the rhythm they are good at evaporates.

AI as a bridge

AI is useful here as a triage layer. A fast model (Haiku, Flash, or GPT mini) can sort and tag inbound work, surface the items that need a human, and draft holding responses to the rest. Useful prompt pattern: “For each item in this queue, tag it as: act now, act later, drop, or escalate — and explain why in one line.” The goal is to keep the human in the rhythm rather than letting one slow item collapse the whole queue.

4. Yellow — Wave thinking

Axis: Depth

Cycles, frequencies and amplitudes. Patterns repeat — pressure builds and releases over time. This mode notices rhythm in a system: which signals oscillate, where they peak, and how their timing interacts.

Who tends to lean this way

People who lean wave often gravitate toward trading and markets, performance and live music, professional sport coaching, weather and climate work, monetary policy, public health surveillance, and any domain where the same shape recurs at different frequencies and the skill is in reading the cycle.

What they need to do their best work

What helps: long enough time-series to feel the pattern, and patience from collaborators who want a one-shot answer. What drains: being asked for a point estimate when the truth is a distribution. What kills flow: zooming in on one trough and treating it as the whole picture.

How other modes can misread them

If misunderstood, this person can look evasive to linear thinkers (”why won’t they just tell me yes or no?”) and superstitious to matrix thinkers (”they’re seeing patterns that aren’t there”). When asked for a forecast they will hedge, which reads as weakness in cultures that reward confident answers — but the hedge is honest, because their truth is a distribution rather than a point. The thing being missed is that they are tracking a signal across time, and time has not yet given the answer. Pushed into a role that demands single-shot decisions with no follow-up, they get judged on each call in isolation rather than across the cycle they were actually reading; pushed into a static analytical role, they lose the live signal that is their real instrument.

AI as a bridge

AI is most useful here for pattern surfacing across long history. Models with very large context windows shine — Gemini, or Claude’s long-context modes — because the whole signal can sit in one prompt. Useful prompt pattern: “Here is X months of data. Tell me which cycles I am riding, how they interact, and what is anomalous versus what is just the next peak.” Pair this with a fast model that watches live data for the moment a cycle turns.

5. Mint green — Wave → graph (nodes)

Axis: Depth → breadth

Continuous rhythms freeze into discrete points. Wave peaks crystallise into nodes and connect into a network. The mode opens up: instead of one rhythm in time, you can see many things related to each other at once.

Who tends to lean this way

People who lean into this transition often sit in roles that turn live signals into structured maps: data analysts moving from time-series to dashboards, journalists turning a story arc into a stakeholder map, ethnographers, UX researchers synthesising interviews, public health epidemiologists building contact graphs. They are often quietly bilingual — comfortable in the wave and in the network.

What they need to do their best work

What helps: time and tools to do the freeze well, and stakeholders who accept that the map is provisional. What drains: being asked for the network before the wave has shown its shape. What kills flow: a final-looking artefact too early.

How other modes can misread them

If misunderstood, this person can look slow to wave thinkers (”why are they stopping to draw a diagram, the situation is still moving”) and overly tentative to node thinkers (”why won’t they commit to the map?”). They sit in an awkward middle space where neither mode quite trusts them: too analytical for the live operators, too provisional for the network strategists. The thing being missed is that the freeze is the whole job — the moment of converting a moving signal into a structure other people can use is what they bring. Pushed too far toward pure live work, they lose the synthesis time they need; pushed too far toward pure structural work, they lose the live signal that gives the map its truth.

AI as a bridge

AI is useful here as the freezing tool itself. A long-context model can read a transcript, a six-month log, or a stack of interview notes and return a node-edge structure. Claude is good at the synthesis-into-structure step; Gemini’s context size lets you feed the raw material whole. Useful prompt pattern: “Read this and give me the nodes (the recurring entities), the edges (the relationships between them), and the three patterns that surprised you.” Treat the output as a draft map, not a verdict.

6. Deep green — Node thinking

Axis: Breadth

Relationships between things. Meaning lives in the connections — many threads held in parallel. The shape of the network matters more than any single item; clusters, hubs and bridges become visible.

Who tends to lean this way

People who lean node often work in community building, network organising, partnerships and BD, recruiting, journalism that depends on sources, anthropology, and any role where the asset is a living web of relationships. Some engineers and architects also lean here — the ones who care about systems and dependencies more than features.

What they need to do their best work

What helps: visibility into the whole network and tolerance for non-linear answers (”it depends on who you talk to first”). What drains: being treated as a list-of-contacts rather than a navigator. What kills flow: a request that flattens the network into a table.

How other modes can misread them

If misunderstood, this person can look unfocused to linear thinkers (”they spent the whole day on calls, what did they actually deliver?”) and unrigorous to matrix thinkers (”their answer changes depending on who they spoke to last”). In a metrics-driven environment they can look like they are not producing — because their work is the network itself, which does not show up in a dashboard until much later. The thing being missed is that the relationships they are tending are infrastructure; their value is realised when someone else needs an introduction, a warm thread, or a sense of who actually holds the decision. Pushed into a role measured purely on output volume or analytical rigour, they look like underperformers — and the network they were tending atrophies the moment they are reassigned.

AI as a bridge

AI as a memory and surfacing layer. Tools with persistent memory (Claude Projects, ChatGPT Memory, Gemini Gems) let you keep the network warm — who is connected to whom, who you owe a reply, who matters for which question. Useful prompt pattern: “Given everything you know about my network, who should I introduce to whom this month, and what is the warm thread between them?” The model is not the network; it is the index that helps you walk it.

7. Light blue — Graph → matrix

Axis: Breadth

Connections become coordinates. The graph projects onto a grid where every pair of nodes has a cell. This mode reveals coverage — what is connected, what is not, and the shape of the whole space at once.

Who tends to lean this way

People who lean into this transition often sit in roles that need to make a network legible: portfolio managers, investors mapping a market, sales ops building account matrices, organisational designers, urban planners, and researchers running comparative studies. They want the whole picture in one frame.

What they need to do their best work

What helps: enough nodes to make the matrix meaningful, and stakeholders who can read a grid. What drains: being asked for a single-line summary of a multi-axis truth. What kills flow: someone insisting on a ranking when the answer is a Pareto front.

How other modes can misread them

If misunderstood, this person can look cold or reductive to node thinkers (”they turned my network of relationships into a spreadsheet”) and over-engineered to linear thinkers (”why do we need a four-axis matrix to choose, just pick one”). Their instinct to systematise can read as bureaucratic in fast cultures and impersonal in relational ones. The thing being missed is that the matrix is how they hold complexity honestly — refusing to collapse a multi-dimensional question into a single number. Pushed into a role that demands fast intuitive calls, they become the person who slows decisions down with another spreadsheet; pushed into a role that demands relational warmth, they look detached.

AI as a bridge

AI is useful here as a coverage checker. A reasoning model can take a graph and tell you which cells are empty, which are dense, and which combinations are unexplored. Useful prompt pattern: “Given this list of customers and these axes (segment, stage, ARR), which cells of the matrix are empty and which are crowded? Suggest one move per empty cell.” Gemini’s reasoning modes and Claude’s extended thinking are both well-suited; the work is more about systematic coverage than creativity.

8. Deep blue — Matrix thinking

Axis: Breadth

Every dimension considered at once. Patterns emerge from the whole field, not any single cell. This is the widest mode — total parallel awareness of the system before any single path is chosen.

Who tends to lean this way

People who lean matrix often gravitate toward strategy, venture and PE investing, foreign policy, antitrust and economics, scenario planning, and very senior product or design roles. The job is to hold the whole field — every option, every dependency, every second-order effect — long enough to find a move that the linear thinkers have not seen.

What they need to do their best work

What helps: dense, well-organised information and time to sit with it before being asked to decide. What drains: being asked “what should we do?” before the field is mapped. What kills flow: pressure to oversimplify.

How other modes can misread them

If misunderstood, this person can look paralysed to linear thinkers (”they have been thinking about this for three weeks”), aloof to node thinkers (”they never ask anyone what they think”), and abstract to wave thinkers (”the situation has moved twice since they started this analysis”). In an action-biased culture they get labelled as overthinkers; in a fast-moving operational role they look detached from reality. The thing being missed is that the value of this mode is precisely the moves it finds that nobody else can see — the second-order effects, the unrelated dependencies, the option that becomes obvious only when the whole field is mapped. Pushed into a role with no time to map, they produce shallow versions of their gift; pushed into pure execution, they disengage and look like they are coasting.

AI as a bridge

AI is most useful here as a co-explorer. Use the largest, slowest, most thoughtful model available — Claude Opus with extended thinking, GPT with deep reasoning, Gemini Pro — and run scenarios against it. Useful prompt pattern: “Here are six dimensions of this decision. Walk through the matrix and tell me where the dominant strategies cluster and where the trade-offs are real.” Pair the matrix model with a faster one that summarises for stakeholders who are not in this mode.

9. White — Orchestration — creation

Axis: Breadth → depth

The creation arc. Deep blue scans the whole field, light blue maps the relationships, deep green finds the structure, and purple commits to a single linear path. Each mode informs the next; the structure is built before it acts.

Who tends to lean this way

Whole teams orchestrate this arc, rarely one person. Strategy and design teams live in the breadth end; delivery and execution teams live in the depth end. The friction is almost always at the handoffs — the matrix thinker hands a half-finished map to the linear thinker, who needs an ordered list. Mature teams build explicit rituals for each handoff (kick-offs, design reviews, scoping docs) rather than expecting the modes to translate themselves.

What they need to do their best work

What helps: explicit recognition that the arc has phases and that each phase has its own pace. What drains: a culture that rewards only one mode. What kills flow: jumping from breadth straight to delivery without the middle two modes.

How other modes can misread them

When this arc breaks, each mode misreads the next. The matrix team thinks the linear team is unimaginative; the linear team thinks the matrix team is precious and slow. The node team thinks both are missing the human reality; the matrix team thinks the node team is anecdotal. Without a shared vocabulary, every handoff becomes a complaint about the other side’s competence rather than a recognition that the next mode is doing different work. The thing being missed at the team level is that the arc itself is the deliverable — no single mode owns the outcome, and rewarding only one mode (usually whichever produces the most legible artefact) starves the others. Teams put under pressure to skip phases produce strategies with no plans, plans with no maps, and maps with no people.

AI as a bridge

This is where AI does its most useful work — not inside any single mode, but at the handoffs between them. Use a long-context model (Claude, Gemini) to take a matrix-thinker’s notes and return a node map for the connector to refine. Then ask the same or another model to turn the node map into a sequenced plan the linear thinker can execute. Useful prompt pattern at each handoff: “Take this artefact and translate it into the mode the next person works in — keep what matters, drop what does not.” The bridge is not a single magic prompt; it is a habit of using AI to make the next person’s job possible without forcing them into your mode.

10. Black — Orchestration — activation

Axis: Depth → breadth

The activation arc. Red triggers the action, orange queues the work, yellow drives it through repeating cycles, and mint spreads the result into a network. Activation cascades from one focused trigger out to a wide system.

Who tends to lean this way

This arc is the natural home of operations, growth, customer success, live service teams, marketing campaigns, and incident response. The skill is taking one decision and rippling it out through a system without losing the thread. The friction here is the opposite of the creation arc: depth thinkers want to keep the trigger clean and simple; breadth thinkers want to know what it means for everything else.

What they need to do their best work

What helps: a clear trigger, a queue people trust, and a feedback loop from the spread back to the source. What drains: launches with no monitoring. What kills flow: changing the trigger after the wave has started.

How other modes can misread them

When this arc breaks, the failure mode is a launch that nobody owns end-to-end. The trigger people (red, orange) think the spread people (mint) are over-thinking the second-order effects; the spread people think the trigger people are firing without watching where the ripples land. Yellow’s rhythm gets read as either complacency (”they’re not doing anything new”) or panic (”they’re constantly adjusting”) depending on whose mode you sit in. The thing being missed at the team level is that activation is not the same as creation — the work is sustaining a cascade, not making a decision — and judging it on the criteria of the creation arc (clarity, novelty, completeness) starves the cycle of the rhythm and feedback it needs. A team forced to relaunch every quarter never builds the wave; a team that never reads the spread never learns whether the trigger landed.

AI as a bridge

AI sits across this whole arc. A small fast model triggers and queues (Haiku, Flash, GPT mini). A mid-tier model runs the cycles and watches the rhythm (Sonnet, GPT, Gemini Pro). A large reasoning model reads the spread back and tells you what the network now looks like (Opus, GPT extended thinking, Gemini Pro reasoning). Useful prompt pattern at each phase: at trigger, “is this the right moment?”; at queue, “what is being delayed and is that okay?”; at cycle, “is the rhythm holding?”; at spread, “what shifted in the network because of this?”. The job is not to automate any one phase but to make the whole cascade visible to a human.

Worked examples

The taxonomy is most useful at the handoffs. Below are three common bridge problems, each shown as a short vignette plus prompt patterns at three levels of scale. Each persona names the modes in play, the handoff that is failing, and prompts that bridge it. The prompts are written for Claude given the audience for this document, but the patterns work with any frontier model — the framework gives you the diagnostic.

Persona 1: the developer giving a daily update

Modes in play: the developer is operating in red (one task, sequenced, depth) and possibly orange (managing a queue of tickets). The scrum master or product owner is operating in purple at best (matrix-to-linear; trying to reconstruct a plan from updates) and at worst in deep blue (matrix; scanning for risks across the whole programme). The friction is that the developer’s natural output — what I did, what I am doing, what is blocking me — is a depth artefact, and the listener is trying to extract a breadth artefact from it.

What the developer needs from AI: a translator from depth to breadth without leaving red. The developer should not have to think in matrix. AI should do the projection.

Easy: the daily standup update

Setting: you have a few rough notes from yesterday — commits, a Slack thread, a ticket you closed, one you opened. You need three sentences for the standup that the PM can actually use.

Prompt

Here are my notes from yesterday: [paste]. Give me a three-line standup update in this shape: yesterday I (one line, outcome not activity), today I am (one line, outcome not activity), blocked on (one line, or “nothing”). Keep it boring. Do not editorialise.

The “outcome not activity” framing is the matrix-to-linear move: instead of “I worked on the auth refactor” (a depth statement that tells the listener nothing about the plan), you get “I finished the auth refactor pending review” (a position on the plan, which is what purple actually wants).

Medium: a written async update for a non-technical lead

Setting: your team has gone async and you owe a weekly written update to a product owner who does not know the codebase. They do not want a changelog; they want to know whether the thing is on track and what they should worry about.

Prompt

Here are my commits, PRs, and rough notes from this week: [paste]. Write a weekly update for a non-technical product owner. Three sections: where we are versus the plan (one paragraph, plain language, no jargon), what changed in the plan and why (only if it changed), what to watch next week (specific and actionable). If you are tempted to use the words “leveraged,” “delivered,” or “stakeholder,” try again.

Two things this prompt does. The plain-language constraint forces the AI to project from depth into the listener’s frame. The constraint on what the third section must look like (specific and actionable) prevents the model from defaulting to “continue monitoring,” which is the standard AI failure mode for status updates.

Hard: a programme-level update across multiple developers and a critical incident

Setting: you are tech lead. There are six engineers, two workstreams, an incident from Tuesday that is mostly resolved but has a long tail, and a senior product owner who needs to brief their own director by end of day. The PO does not want detail; they want to know what to say in their own meeting and what risks to flag.

Prompt

Context: [paste rough notes from each engineer, the incident postmortem-in-progress, and the original quarterly plan]. The audience is a senior PO who is briefing their director in two hours. They are not technical. Produce two artefacts. First, a four-bullet summary the PO can paraphrase in their meeting: where the programme is against plan, what changed materially, what the incident actually means for the roadmap (be honest), and the one thing the director should know. Second, a separate “risk register delta” — only the risks whose status changed this week, not the full register. For each: what changed, why, and the decision the director might be asked to make. If a risk did not change, do not mention it. Tone: dry, specific, no hedging adjectives. If you are not sure about something, say “unclear” rather than smoothing over it.

This prompt is doing the full purple compression for a hostile context — many depth inputs, a single breadth output, an audience that will punish hedging more than it will punish bad news. The split between the summary and the risk delta is the framework’s matrix-to-linear move done explicitly: the summary is the linear path the director will repeat, the risk delta is the matrix view the director may need to act on.

Persona 2: the product manager with vague ideas

Modes in play: the PM is operating somewhere between deep blue (matrix; holding the whole problem field) and deep green (node; tracking who needs what and which threads are warm). The developer they are handing off to is operating in red and needs a sequenced spec they can build from. The classic friction is that the PM hands over a deep blue artefact (a vision, a strategy doc, a Miro board) and expects red to translate it themselves.

What the PM needs from AI: a structured intermediate artefact — a light blue matrix, a deep green map, or a purple sequence — depending on how mature the idea is. The mistake is reaching for the sequenced plan too early. The role of AI here is to do the structuring middle that the PM does not want to do and that the developer cannot do without it.

Easy: a small feature idea you cannot quite articulate

Setting: you have a feeling that users are dropping out of onboarding, but you cannot say exactly where or why. You want to give your developer something to look at, not a full spec.

Prompt

Rough thought: I think users are dropping out of onboarding somewhere and I do not know where. Help me get from this to something a developer can act on. Ask me five questions, one at a time, that will sharpen this enough to write a one-paragraph problem statement and a list of three things we could measure first. Do not write the spec yet. Just sharpen the question.

Note the prompt is not asking for the spec. It is asking the AI to act as the deep blue partner the PM does not have access to. The five questions force the matrix to fill in before any handoff happens. Once the answers exist, the next prompt can be a purple compression.

Medium: a feature with a clear goal but unclear scope

Setting: leadership wants “better notifications.” You know the goal (re-engage users in week two), but the scope could be anything from a single email change to a full notification platform. You need to give the dev team something they can scope without committing prematurely.

Prompt

Goal: re-engage users in week two via notifications. The scope is currently undefined and could be anywhere from a single email change to a multi-channel notification platform. Help me produce a scoping document with three options at different levels of investment: a one-week version, a one-sprint version, and a one-quarter version. For each, give me: what we would actually build, what we would learn from it, what we would not be able to learn, and what would have to be true for this to be the right level of investment. Do not pick. The point is to give my engineering lead something to react to. Frame each option in the same shape so they are comparable.

This is a light blue prompt — coverage across a multi-axis space, structured so the next person can read it. The PM is not asking the AI to choose. They are asking the AI to make the choice space legible. That is the move that lets a developer engage without feeling like they are being asked to do the PM’s job.

Hard: a multi-quarter strategic bet that does not yet exist

Setting: the CEO has said “we should be doing more with AI in our product.” Nothing more specific than that. You have to come back in two weeks with something the engineering team can start building toward and the leadership team can defend to the board. There is no precedent inside the company. You have your own intuitions but no map.

Prompt

I am building a multi-quarter plan from a single sentence: “we should be doing more with AI in our product.” I have no map yet and I do not want to commit to a direction prematurely. Walk this with me in three passes. Pass one (matrix): Given what you know about [our product, our users, our team size, our constraints], lay out the dimensions of the choice space. What are the axes I should be deciding along — not the answers, the axes. Be exhaustive even if some axes seem obvious. Pass two (structure): For each axis, what are the realistic positions we could take, and what does taking each position commit us to elsewhere? Where are the hard trade-offs and where are the false ones? Pass three (sequence): Given the axes and positions, what are the two or three coherent strategies — meaning a position on every axis that hangs together — that I could actually take to leadership? For each, what would the first quarter look like, and what would have to be true at the end of it for us to keep going? Throughout, push back if I have over-constrained or skipped an axis. I would rather argue with you now than ship the wrong direction in two months.

This is the explicit deep-blue-to-purple cascade run as a structured prompt sequence. The three passes map to matrix, light blue, and purple. The instruction to push back is critical: at this scale, the failure mode is a model that helpfully completes a poorly-framed brief. The PM needs the model to refuse to do the structuring middle without first doing the matrix mapping. Worth saying out loud: this prompt is at the edge of what a single chat can do well. For a two-week strategy piece, you will probably want to run this across multiple sessions, save the matrix as an artefact, and come back to it. The framework helps you notice when you are asking too much of one prompt.

Persona 3: the marketing or sales person bridging to engineering

Modes in play: the marketing or sales person is most often operating in deep green (relationships, accounts, narratives) or yellow (campaign cycles, market rhythm). The engineering team they need to talk to is operating in red and deep blue. The intimidation is real but it is usually not a competence gap — it is a mode gap, read by both sides as a competence gap, which makes it worse.

Why the intimidation reads as competence: engineering culture often rewards red-and-deep-blue presentation — confident, sequenced, technically grounded. A node-thinker walking into that room with a relational, narrative, what-the-customer-said-yesterday update is presenting in their home mode and getting read as fuzzy. They start adjusting their delivery to sound more linear, lose the actual signal they were carrying, and the room confirms its prior that the marketing person did not know what they were talking about. The signal was real. The translation was missing.

What they need from AI: translation in both directions — incoming engineering material rendered in node or wave terms, outgoing customer signal rendered in matrix or linear terms — without flattening either.

Easy: understanding what the engineering team is actually saying

Setting: you have been forwarded a technical update on a feature you sold to a customer. You need to know whether you can keep the promise you made and what to say if not. You do not need to understand every word.

Prompt

Here is a technical update from our engineering team: [paste]. I sold a customer on [feature] with a delivery date of [date]. Translate this update for me without dumbing it down. Three things only: is the promise I made still good? If not, what is the actual situation in plain language? And what is the question I should be asking the engineering team next, in their language, to get the answer I actually need? Do not give me a glossary. Do not summarise the whole update. Just answer those three questions.

The “without dumbing it down” instruction matters. The standard AI failure mode for this prompt is a watered-down summary that loses the technical signal. The instruction “in their language” for the follow-up question is the bridge — it gives the marketer a way to walk into the next conversation in a register the engineers will recognise without having to fake fluency.

Medium: bringing customer signal into a roadmap conversation

Setting: you are sitting in on a roadmap meeting for the first time. You have heard the same complaint from four different customers in the last fortnight. You want to flag it without being the marketing person who derails the technical conversation.

Prompt

Four customers said variants of [the complaint] in the last two weeks. Notes on each conversation: [paste]. I want to bring this into a roadmap meeting in a way an engineering audience will engage with rather than tune out. Help me write three things. First, the pattern in one sentence — the actual underlying signal, not the surface complaint. Second, the smallest specific question the engineering team can answer about it (not “what should we do,” that is too big). Third, what I am not claiming — to head off the assumption that I am asking for a roadmap change. Tone: short, specific, more like a bug report than a customer story. If the underlying signal is unclear from the notes, say so rather than reaching.

This is a deep-green-to-light-blue translation — taking a node-shaped artefact (four conversations, related but not identical) and projecting it onto a frame the engineering team can engage with (a specific question, a bounded claim). The “more like a bug report than a customer story” is the register shift. The “not claiming” line is what protects the marketer from being read as territorial.

Hard: making the case for a strategic shift to a sceptical engineering leadership

Setting: you have built up a clear picture across many customer conversations that the company’s positioning is wrong. You need to take this to the CTO and the head of engineering, both of whom are deep blue thinkers who are sceptical of marketing. You have one shot, and the standard playbook (a deck, a customer-quote montage, a recommendation) will land badly.

Prompt

I have a strategic case to make based on a pattern across roughly thirty customer conversations and twelve sales calls in the last quarter. The pattern, in my words: [paste]. Supporting notes: [paste]. The audience is a CTO and head of engineering who are sceptical of marketing-led strategy and respond to rigorous, falsifiable arguments. A customer-quote montage will fail. I need to present this as if I were presenting to a research panel, not a marketing review. Help me build the argument in this shape: The claim, in one sentence, falsifiable. The evidence, organised by what kind of evidence it is (frequency, severity, specificity, source quality). Be honest about the weaknesses of the evidence — they will find them anyway. The two strongest counter-explanations for the pattern, and what evidence would distinguish between them. What I am asking for at the end of the meeting, which is not a strategy change but a specific next investigation. Throughout, write as if I were a senior peer making a technical argument, not a marketing person making a case. If my evidence is too thin to support the claim, say so — I would rather know now than in the meeting.

This is the deep-green-to-deep-blue translation done explicitly. The marketer is not abandoning their home mode — the underlying knowledge is still relational, accumulated across conversations. They are asking the AI to project it into a deep blue register so the audience can engage with the signal rather than the form. The instruction to push back on thin evidence is what stops the prompt becoming a confidence-booster; at this stakes-level, the marketer needs an honest mirror, not a hype man.

Artefacts

Most people need some autonomy in their lives. That much is ordinary. But for autistic people it isn’t a preference sitting near the top of a list of nice-to-haves. It’s load-bearing. Take it away and the whole structure starts to come down.

What we need most is autonomy over our own bodies, our own decisions, and our own future. Not control over everyone else. Not to be awkward for the sake of it. Just the basic freedom to act on what we believe is in our own best interest. When that goes missing, when autonomy isn’t allowed, it doesn’t register as an inconvenience. It feels like suffocating.

There’s a saying that autistic people are the canaries in the coal mine. I think this is what it actually means. We’re not more fragile than everyone else — we’re more sensitive to the gas. We notice the air has gone wrong before anyone else does, and we go down first. The mistake people make is to look at the canary and decide the canary is defective, when the thing they ought to be looking at is the air.

Because the thing that poisons us isn’t hardship itself. It’s incoherence. It’s being told our view of reality isn’t true when we can see, plainly, that it is. We’re asked to nod along, to swallow it, to carry on as though the contradiction isn’t there — and we can’t. It’s like a toxic chemical we have to keep swallowing, and it eats at us until we break down.

So here’s the part I want to say plainly, because it so often gets written down as something else on a form.

When we break, the first instinct is to look inside us for the fault. A name gets found for it — anxiety, depression, a disorder, a difficulty — and once there’s a name, the conversation tends to stop. Nobody asks what was being done to us in the months before. Nobody asks what we’d been made to swallow. The autonomy that was taken away never gets entered into evidence. The breakdown becomes the diagnosis, the diagnosis becomes the explanation, and the cause walks free.

I’m not saying the distress isn’t real. It is. I’ve felt it take me apart. But it’s a wound, not a defect — a response to something, not a fault in the wiring. There’s a difference between someone who is ill and someone who is being slowly poisoned and has finally started to show it. Treat the second as though they were the first, and you’ll medicate the symptom while the gas keeps leaking into the room.

That’s the canary problem up close. The bird goes down, and instead of clearing the air, they get very good at keeping it breathing in conditions that were never survivable in the first place — and they call that care.

So I’ll say it again, plainly: we’re not mentally ill. We’re sick of being pacified into submission.

Last time we landed on a definition: a lie isn’t a wrong map, it’s handing someone a map you know is wrong. The deceit is in the knowing.

But that opened a harder question, and it’s been sitting with me since. Is there ever a time when handing someone the wrong map is the best thing you can do for them?

Take learning. If someone built you a system that was perfectly coherent — every answer already in place, nothing left to work out — would it actually teach you anything? Or would it just be something to lean on? We don’t grow from the map being right. We grow from having to redraw it ourselves.

Which makes me wonder whether some lies are gifts.

Say you’re teaching someone and they’re close to working something out on their own. You could step in and finish it for them. Or you could plead ignorance — “I’m not sure, what do you reckon?” — when you know full well. You hand them a wrong map of your own knowledge so they reach the right one themselves.

Or you let someone take the glory for a thing you already knew. In a world where everyone’s trying to win, standing back and handing someone else the limelight might be the most generous move you’ve got.

By my own definition, both are lies. You know the map you’re offering is wrong. But you’re not doing it to send them somewhere they shouldn’t go — you’re doing it so they get there without you. So they course-correct on their own, rather than being carried.

Maybe that’s the difference between a lie that takes and a lie that gives. One hands you a map it knows is wrong and leads you down the wrong road, forever feeling lost. The other hands you a wrong map too — but does it steadily, gradually, it guides you, so you'll find a new path yourself.

Say I tell a stranger: “You shouldn’t climb that tree — you could fall and hurt yourself.”

It might be true. They could fall. If I tried it, I certainly would.

But who am I to judge what that person is capable of, knowing nothing about them? Who am I to tell them what they can and can’t do?

Maybe they will fall — and maybe they won’t care, because they’ll get straight back up and go again. Maybe they’ve climbed a hundred trees and I’m only projecting my own fear onto them. Maybe they like falling out of trees.

So while it might be true that they could fall, it isn’t certain. And whatever else it was, it was offered as care, not as a trap.

Which tells me a lie has to be something more than advice that happens to be wrong.

It has to be intentional. What if instead I said — to someone I knew couldn’t climb — “go on, get right to the top, fetch the best apple, you’ll be fine”?

That’s the difference. Not whether the words turn out true, but whether I meant to send you somewhere I knew you shouldn’t go.

A lie isn’t a wrong map. It’s handing someone a map you know is wrong.

That’s the question I’ve been asking myself.

Over the past few months I’ve been going through what I can only describe as self-realisation — a process of having to completely re-learn everything I knew about the world and what I wanted to do next. I’m not going to lie: this wasn’t exactly a choice. It was forced upon me by my own stubborn inability to stop looking at things I “shouldn’t”. It was also one of the most brutal and painful processes I’ve ever endured, and I want to write about it honestly, because I think the framing matters more than the conclusion.

That’s not to say this will be the case for everyone — not everyone is as obsessive as I am about resolving incoherence. But for me, that’s where this starts: with understanding what I value.

What I actually value

One of the things I know I value is succeeding. But the real question I kept asking myself was: succeeding at what? Towards what? What did succeeding even mean?

I could have succeeded at Microsoft by coasting along and doing as I was told, so it definitely wasn’t that. There must have been something else. And before I could answer it, I had to look at the rest of what I thought I valued, and ask whether I actually valued those things — or whether I valued something deeper underneath them.

I valued having money — but not the physical thing. I only valued it because it gave me the ability to buy things without thinking too much. So is the real value of money the fact that I don’t have to worry about it? I think it is. Money isn’t the value. Not having to think about money is.

I valued love and friendships — but not in the way most people seem to. I tend to show love behind the scenes, by doing something thoughtful or providing for people, without wanting anything in return. So the value isn’t really “love” as a category. It’s care expressed without performance.

I valued honesty and truth — but only because that makes systems coherent for me. And what does that even mean, when there are multiple truths? Maybe the real problem is that the system itself is so incoherent right now that coherence isn’t reachable. Maybe what I value is the conditions under which truth becomes possible.

A big part of that incoherence is the people who tell you that everyone else just needs to do the same thing they did. They fail to see the cause and effect of it. They fail to see that if the people in factories stop producing the clothes they wear for very little cost, their own cost of living goes up. That if everyone stopped producing so they could sit and write code all day, we’d have no food. That the people buying their courses are often already struggling with addiction and vulnerability, and they write it off as a lack of discipline rather than asking whether the system has conditioned that person to behave that way. This, in part, is what stopped me from creating paid content for things I believe should be accessible to all.

I realised I was living a lie. When I stripped each value back, the question of what I was actually trying to succeed at got harder, not easier. The proxies I’d been using — money, success, recognition — weren’t the things underneath. Accepting that was what I had to do to get to the answer.

The four stages

The framework I kept coming back to, to describe what happened to me over the past few months, is Roberto Assagioli’s psychosynthesis, which lays out four stages:

1. Thorough knowledge of one’s personality.

2. Control of the personality’s various elements.

3. Realisation of one’s true Self — the discovery or creation of a unifying centre.

4. Psychosynthesis — the reconstruction of the personality around that new centre.

The first stage is the one that nearly broke me. It asks you to enter difficult memories and reflections without rushing, and to sit with the parts of yourself that conflict — the part that wants to be seen, the part that’s terrified of being seen, the part that wants to build, the part that’s already braced for being told it can’t.

The second stage isn’t control in the rigid sense. It’s more like being able to direct your will once you’ve actually noticed the patterns running you.

The third is where most of the work happens — finding a centre that isn’t any single sub-personality, but something that can hold all of them at once.

The fourth is reconstruction. Building yourself back around the new centre, on purpose this time, with a unified view of where you want to get to.

The truth I had to look at

The truth about what I was doing, who I was, who I used to be, who I was working to be, and the cause and effect it had on the approach I was taking — it made me feel like I had one of two choices.

The truth about what I was doing, who I was, and who I was working to be left me with two choices: keep telling myself a story where I was being acted upon, or own my part in it.

During that time, I faced some of my greatest fears. I looked at myself through the eyes of others, and could see that I wasn’t a victim, and that none of us are innocent in this system.

Yes, I grew up with little money. Yes, I made a good life for myself in spite of those initial conditions. Yes, I was bullied and made fun of for where I came from. But I also did unkind things to other people. I redistributed harm by being angry and frustrated, by picking on people so I wouldn’t be picked on, by fitting in at the expense of someone else. I made people feel small by bragging that I’d understood something quickly that they’d spent a long time trying to grasp. I wanted to win. That happened, and I have to own it.

That’s what the system does. It makes you redistribute the harm, because all of you are frustrated that none of you can win without climbing over each other.

Sometimes I was arrogant. Sometimes I did think I knew better. Looking back, I can see now it was because I could sense the sickness — I was just blaming the wrong people for it.

That’s a hard thing to write and a harder one to sit with. But it’s true. I had been telling a story about myself in which I was being acted upon, and the story was incomplete because it left out all the ways I also contributed to the problem.

Then I came across Jung

As I was searching for answers, I came across this quote by Carl Jung, from The Practice of Psychotherapy:

“To be ‘normal’ is a splendid ideal for the unsuccessful, for all those who have not yet found an adaptation. But for people who have far more ability than the average, for whom it was never hard to gain successes and to accomplish their share of the world’s work — for them restriction to the normal signifies the bed of Procrustes, unbearable boredom, infernal sterility and hopelessness. As a consequence there are many people who become neurotic because they are only normal, as there are people who are neurotic because they cannot become normal. For the former the very thought that you want to educate them to normality is a nightmare; their deepest need is really to be able to lead ‘abnormal’ lives.”

It resonated, and at the same time it felt deeply flawed. It sat with me for a few days before I could work out why.

Jung is building on a few assumptions I don’t accept:

• That success means the same thing for everyone. Why does one have to be the best to be successful? Why can’t being “normal” also be successful? Why does everyone have to strive for more? What does being “normal” even mean?

• That ability and success are equivalent. They aren’t. Success in any given system is about fit, timing, access, and a great deal of luck. Plenty of able people never get a foothold. Plenty of less able people do. Conflating the two flatters whoever is already winning.

• That focusing on behaviours tells you anything about why someone is “normal” or “abnormal.” It doesn’t. Are people simply normal because they had their dreams taken from them, time and time again, until the cost of dreaming felt higher than the cost of fitting in? That’s not a moral failing. That’s an entirely rational response to repeated harm.

So no — I don’t accept the framing that ability earns you the right to refuse normality, and that the rest are just unsuccessful and should be content, or assumed to be content because they have never been given more.

But the part about despair and hopelessness — that’s the part that sat with me. Because I have to be honest: I’m definitely not normal.

I don’t fit in anywhere. I don’t know anyone who thinks like me, dreams like me, finds meaning the way I do, obsesses about that meaning the way I do, creates things the way I do. That doesn’t mean my way is the right way. For most people, it isn’t — it’s too much, too dynamic, too loose. But it’s as real a way of being as any other, and my entire life has been spent searching for somewhere I can just be me, as I am, to do what I do best. Creating things.

The hopelessness and despair Jung was talking about — that was everything I was feeling. Because I knew I had the ability. I just couldn’t take being told to stay small any more. I couldn’t take being told to stay in my lane.

What I was actually running from

So what was I trying to fix? What was I running away from? Why was I trying so hard to find the answer? Why was I so obsessed and distraught? Why was I so scared?

As I tried to work this out, the answer to my earlier question — what was I trying to succeed at? — finally became clear.

What I was defining as success was doing what I actually wanted to do: being creative. Doing creative work that’s worth recognising and appreciating. Maybe others will never appreciate it the way I do. But everything I’ve developed over the past few weeks is some of the most wonderful, creative and beautiful work I’ve ever done, and I’m so proud of it, because it is truly something no one else has done before. It doesn’t matter to me that others might think it isn’t, because I know what it took to make it. The process of making it, and the abstract nature of it, were so creative and so full of meaning — equivalent, to me, to the work of directors and famous artists and writers. That, to me, was success.

Creating something entirely new — a concept entirely new, drawn out of previous patterns — was the thing I wanted to do. Ever since I was a little kid I loved movies, stories, directing. And I just proved I could do all of that. I proved I could do it without even realising I was doing it, day after day, week after week, becoming more and more surprised with myself. I started trying to make a shell, and ended up making an elephant. I spilled beads before and after the making of this, completely by accident, only to then showcase how the pain of creating something means you learn to use better tools. Those are just two examples — there were dozens more where I created something and didn’t realise until after just how meaningful and creative that decision was.

And then I was facing the realisation that I’d have to go back to a world that wasn’t that. That didn’t care. Didn’t see the creativity. Didn’t get it. Didn’t appreciate it.

I love being creative. I don’t mean that to discard anyone else’s creativity — everyone is creative in their own way. But my creativity is abstract. It’s chaotic, it shifts quickly. It takes various concepts and builds whole fantasy worlds, books, ideas for stories — and I don’t always know why I’m doing something, until later, when it becomes clear.

It dawned on me that I was never going to be able to be that creative again in a role that was inherently moving towards delivery. My career as I knew it was either over — and I’d have to start over if I ever wanted to do what I enjoyed — or I’d have to deal with it being fundamentally delivery-oriented and unhappy.

That realisation made me re-live the pain of being a child. Of being told, time and time again, that I was never going to be able to live my dreams or be who I wanted to be. That the creativity I had was never going to be appreciated, because of who I was, my status, where I came from, my struggles with networking. That if I moved somewhere else, I didn’t have the business tact, I’d have to fight inside a toxic culture in order to be creative anyway.

All of that is why a particular kind of well-meaning advice has always landed badly with me: “well, if you need help, you should just ask.” Because I tried asking, and each time I got that look. And when I stopped asking, people assumed it was arrogance.

When you don’t know the root cause, you don’t see what’s actually happening. Sometimes a person doesn’t ask because they have a deep-rooted fear that you, too, are going to tell them their dream is too big, that they have to stay in their lane, that they can’t achieve that. They can’t bear the thought of you trying to destroy their dreams and hopes again. They can’t bear that look — the look that tells them exactly what you think of their idea, that it’s crazy, that it’s never going to work. That’s the look that kept me scared for so long. That look of rejection before you even open the first page.

Maybe that’s an ego defence. It probably is. That doesn’t make it not valid. We’ve had a lifetime of it. The “just ask” framing puts the entire burden on the person who’s already had their dreams crushed more times than they can count.

Where this leaves me

The path I was on — research and delivery, software and systems architecture — was moving towards a more delivery-focused domain. Still creative, but not in the way I needed.

Here’s the irony. We’re told the way to be successful is to climb to the top, to get yourself into a position of importance. But when I actually looked at what I was chasing, it wasn’t importance. It was the ability to get myself into a position where I could be creative and not stuck implementing. Where I could be energised by a role rather than drained by it. The whole climb was a proxy for permission to do the work I actually wanted to do.

And the second irony: quitting my six-figure job to spend a month making art was, by my own definition, the biggest era of success I’ve had. Not because anyone told me it was. Because I knew it was.

I know I’m a good writer. I know I’m good at abstract art, at finding patterns across domains, at telling stories. But when you’re constantly worried about money, how do you do the work you’re meant to do?

I don’t have a clean answer. What I do have is a compromise.

Half the week on the thing I want to build. Half the week in the world I used to know.

That’s a small sacrifice to pay for a changing world, and it’s the only honest answer I’ve got right now. A changing world needs to appreciate history, movies, stories, art, wonder. And we have enough creatives to do that worldwide, rather than just in Hollywood.

So if you need consultancy on AI strategy, delivery, or implementation — that’s what the other half of the week is for. I’m quick, efficient, and don’t need to spend a lot of time with you to get you moving along.

And if you want to help me on the mission of bringing creativity to local communities — I have a whole world of magic and wonder mapped out and ready to go. Find out more about Land of Green Ginger here.

And if you can afford to subscribe to the paid version of my newsletter, that would help greatly, but if you can’t, no pressure my content stays free.

Share geometry, not data

Hull builds a crop AI. Leeds builds one too. They don’t compete. They compare geometries.

“Your honesty-safety relationship looks different from ours — what did you train on?”

Both get better. Neither shares their data. Both share their geometry — the structural relationships between value directions that drive the model’s output. The geometry is the fingerprint, not the data.

A hospital in Hull verifies a drug checker to Tier 3. Publishes it open source with the probe set. A hospital in Manchester downloads it Tuesday morning. Running it by Tuesday afternoon. Verified against their own thresholds by Wednesday.

Two hospitals. Zero vendors. Zero cloud contracts. The protocol handles the trust. The governance handles the thresholds. The community handles the deployment.

A fishing cooperative in Hull builds catch prediction AI. A cooperative in Reykjavík builds one too. Same domain. Same protocol. Different languages. They exchange attestations across the North Sea. Neither shares their data. Both share their geometry.

“Your sustainability reading is drifting — ours did too last winter. Here’s what we changed.”

A city council uses AI for urban planning. Publishes its model and governance thresholds. Another city council forks it, adjusts the thresholds for their own priorities. “We weight green space higher than you do.” “Fair enough — here’s our geometry, here’s yours, here’s where we differ.”

Transparent disagreement. Not hidden assumptions.

The commons model

Regional AI cooperatives emerge. Cities pool resources the way credit unions pool capital. Shared trust registry. Each city runs its own models. The cooperative verifies and certifies. Nobody owns the cooperative — the members do.

Not a marketplace where you buy AI. A commons where you share verified AI. Every contribution is inspectable. Every model is verifiable. Every community decides its own thresholds. Collaboration between equals — peers, not customers and vendors.

AI as amplifier

Collaboration only works if the human stays in the loop. AI doesn’t replace expertise. It amplifies whoever is driving it.

A chef with AI makes better food. A bad cook with AI makes bad food faster. A filmmaker with AI makes films they couldn’t afford before. Someone with nothing to say makes nothing to say, quicker.

AI is a power tool. A circular saw doesn’t make you a carpenter. But a carpenter with a circular saw builds faster than one with a hand saw.

The 80/20 pattern

Everyone has a thing they’re brilliant at. Most people spend 80% of their time not doing that thing. They’re doing admin, formatting, chasing details, doing the boring stuff that surrounds the brilliant stuff. They’re so overwhelmed they don’t have the energy to do the brilliant stuff.

The farmer is brilliant at nurturing land. AI does the spreadsheets. The doctor is brilliant at reading patients. AI does the cross-referencing. The teacher is brilliant at reading the room. AI does the material prep. The filmmaker is brilliant at story. AI does the editing grunt work. The builder is brilliant at structure. AI does the calculations.

AI removes the 80%. You keep the 20% that only you can do.

That’s the amplifier. Not replacing you. Freeing you.

Without and with

AI without a human: generic, plausible, pointless. Technically correct and spiritually empty.

A human without AI: brilliant ideas that often struggle to get built. Architectures that stay on whiteboards. Visions that die in notebooks.

Together: the human sees what to build. AI builds it. The human checks if it’s right. AI fixes what isn’t.

And with verified small models in specific domains, you have tools you can trust. Each one is verified. Each one stays in its domain. You bring the brilliance. AI deals with the boring.

The shift

Today: AI is rented from a handful of tech companies. Data goes to the cloud. The model is a black box. You trust the vendor’s marketing. Value and control flow upward.

With this: AI is owned and run locally. Data stays local. The model’s values are inspectable and verifiable. You trust the maths, not the marketing. Value and control stay in the community.

From consumers of AI to owners of AI. From trusting vendors to trusting verification. From cloud dependency to local self-sufficiency. From top-down control to bottom-up capability. From renting intelligence to owning intelligence.

The code is open. The protocol is public. The conjectures are falsifiable. The geometry is computable.

Now it needs people to use it.

Two choices

We have two choices to make.

Keep knowledge gatekept upward. Keep money flowing upward. Keep renting intelligence from the people who already have the most of it. Keep sending data to their clouds, trusting their benchmarks, paying their invoices. Keep the current arrangement where the value flows up and the dependency flows down. Keep letting them tell us we need them to “look after us.” Keep letting them tell us our view of reality is not real. We let them slowly drain us all into poverty and fear. We choose an incoherent and control based society.

Or we decentralise. Own the intelligence. Verify it locally. Share geometry, not data. Collaborate as peers, not as customers. Let communities decide what their AI should value and hold it to account when it drifts. We build together, we make our cities worth visiting, we see and treat each other as equals, we care personally. We choose coherence, we choose each other.

I know which one I’m choosing.

How about you?

This brings the verbal talks to a close for the Geometry of Trust series. The mathematics built the ruler. The philosophy asked what we’re measuring. The governance asked who decides. The protocol built the mechanism. The map back to you series asked what it all enables. The answer: communities that own their own intelligence, collaborate as peers, and use AI to amplify the things only humans can do.

Links:
📄 Paper
💻 Playlist
💻 Code
🏢 Synoptic Group CIC, Hull, UK

The majority of knowledge work is busy work

A solicitor spends most of their time on legal research, document review, and case preparation. The actual legal reasoning — the part that requires judgement, experience, and understanding of the client — is a fraction of the working day. The rest is searching, cross-referencing, formatting, chasing.

The same pattern applies across every profession. An accountant spends most of their time on data entry and compliance checks, not financial strategy. A teacher spends most of their time on material prep and marking, not teaching. A doctor spends most of their time on cross-referencing and admin, not clinical judgement.

AI automates the busy work. That’s not new. What’s new is the ability to run that automation locally, on verified models, with data that stays in the practice, the school, the surgery — rather than flowing to a platform company.

What changes when the automation is local

Knowledge work

A local solicitor’s practice runs its own legal research AI. Trained on UK case law, statute, and regulatory guidance. Scoped to legal.research. Verified against legal reasoning values — precedent, procedural fairness, accuracy of citation. The solicitor’s judgement drives the strategy. AI does the searching.

A local accountancy firm runs its own financial AI. The expertise stays in the community. The accountant’s relationships with their clients, their understanding of local business conditions — that stays human. The cross-referencing and compliance checking becomes automated, verified, inspectable.

Creative industries

This is where the economic transformation gets interesting. Film production, music production, documentary making, graphic design — all of these currently have barriers to entry that concentrate them in a handful of cities. London, Los Angeles, a few others.

A filmmaker in Hull doesn’t need a London studio budget to make a documentary. Script development, storyboarding, editing, music, translation — AI tools running locally handle the production work. The filmmaker’s taste, their story sense, their connection to the subject — that stays human. AI removes the production barrier.

The same applies to music. A producer running Suno-class models locally doesn’t need a studio booking. Every bedroom becomes a production studio. Every city becomes a creative hub.

Education

AI tutoring tailored to the local curriculum. Verified against educational values — is the child learning? Not engagement metrics — is the child clicking? The difference matters, and it’s a governance decision the school makes, not the platform.

The model runs in the school. Data doesn’t leave the building. Teachers are augmented, not replaced. The teacher’s relationship with the class — knowing which kid is struggling silently, which kid needs challenge not support — stays human.

Tourism

AI-powered interactive city guides. Multilingual translation running locally. Accessibility tools — audio description, sign language generation. Cultural heritage presented through AI storytelling. Every city becomes a destination, not just London and Edinburgh.

Media and journalism

Local news augmented by AI research and data analysis. Investigative journalism with AI pattern recognition. Community radio and podcasts with AI production tools. Local voices amplified, not replaced by national chains.

The pattern

Every industry that currently depends on expensive expertise or distant platforms can be localised. Small verified AI makes the expertise local. The value stays in the community.

The barrier to entry drops from millions to thousands. Not because the AI is free — hardware costs money, training costs money, governance costs time. But because the economics of a 500M-parameter model on a single GPU are fundamentally different from the economics of a 70B-parameter model in a data centre.

The shift isn’t from expensive to cheap. It’s from rented to owned. From value flowing upward to value staying local.

Next in the future series: if communities can own their own AI and the economics work, what does collaboration look like? The answer involves sharing geometry rather than data — and it changes the relationship between communities from customer-vendor to peer-peer.

Links:
📄 Paper
💻 Playlist
💻 Code
🏢 Synoptic Group CIC, Hull, UK

The current arrangement

Right now, if a hospital wants AI for drug interaction checking, it signs a cloud contract with a vendor. Patient data goes to the vendor’s servers. The model is a black box. The hospital trusts the vendor’s marketing materials and benchmark scores. The value — both economic and informational — flows upward.

The same pattern applies everywhere. A farming cooperative that wants crop management AI rents it. A school that wants tutoring AI subscribes to it. A community energy scheme that wants grid optimisation buys a service. In every case: someone else’s model, someone else’s hardware, someone else’s terms. Your data leaves. Their invoice arrives.

This isn’t a technology problem. It’s a structural one. The models exist. The hardware to run small specialised models locally is affordable. What’s been missing is the ability to verify that a locally-run model is doing what you trained it to do — and to prove that to anyone who needs to see it.

That’s what the Geometry of Trust protocol provides.

What self-sufficiency looks like

Agriculture

A farming cooperative runs its own crop management AI on a GPU in the farm office. The model is trained on the cooperative’s own data — soil reports, weather history, yield records, pest patterns — plus curated agronomic literature. It’s a 500M-parameter model scoped to agriculture.crop-management. It knows about crops. That’s all it knows about.

The cooperative measures the model’s value geometry using the protocol. Drift tolerance is set at 0.10 — agriculture has seasonal variation, the governance thresholds reflect that. The model exchanges attestations with the cooperative’s weather AI and market AI. Neither shares raw data. Both share geometry.

If the crop AI drifts past threshold — maybe a training update shifted its orientation on pesticide compliance — the chain shows it, the alert fires, and the cooperative’s own governance process handles it. No vendor involved. No cloud involved. No phone call to a support desk.

Energy

A community energy scheme runs solar grid optimisation AI at the substation. The model balances generation, storage, and demand across the local network. It runs on hardware the community owns.

The model is verified against sustainability thresholds the community chose. Not the vendor’s defaults — the community’s priorities. If the community weights carbon reduction higher than cost efficiency, that’s encoded in the governance layer. The protocol measures whether the model’s geometry reflects it.

Healthcare

A hospital runs its own drug interaction checker in a server room. Patient data never leaves the building. The model is verified to Tier 3 causal validation — every probe reading has been confirmed as a genuine mechanism, not a surface pattern. Drift tolerance is 0.03.

The hospital’s clinical governance team decides what values to probe for, what thresholds to set, what to do when drift is detected. They don’t need the vendor’s permission. They don’t need the vendor at all.

Manufacturing

A factory runs quality control AI and predictive maintenance on the factory floor. No internet dependency for critical decisions. The model knows about the factory’s machines, its materials, its failure modes. It doesn’t know about poetry or philosophy or anything outside its scope.

The principle

If you can run it locally and verify it locally, you don’t need to rent it from a tech company.

You own the intelligence. You own the verification. You own the data.

Self-sufficiency doesn’t mean isolation. These models still exchange attestations with peers — a farm AI talks to weather systems and supply chain systems. A hospital’s drug checker talks to diagnostic systems. The protocol handles the exchange. But the intelligence runs locally, the data stays local, and the governance is owned by the community that uses it.

The shift is from renting intelligence to owning it. From trusting marketing to trusting maths. From cloud dependency to local capability.

Next in the future series: if every community can run its own verified AI, what changes economically? The answer turns out to be bigger than most people expect.

Links:
📄 Paper
💻 Playlist
💻 Code
🏢 Synoptic Group CIC, Hull, UK

Two sides of the same coin

When Alice and Bob exchange messages, what actually crosses the wire? And when the verifier takes the payload apart, what does each piece prove?

Those two questions are tightly coupled. Every field in the attestation corresponds to a specific check. Every check depends on a specific field. The attestation carries nothing that doesn’t get checked, and the verifier can’t check anything that isn’t carried.

Understanding the correspondence is understanding why the protocol is the specific shape it is.

What the attestation carries

A complete attestation carries seven pieces. Six live in the attestation body, one is the signature over it. Together they make up the unit of evidence one agent offers another.

Probe readings   The scalar readings — honesty = 1.29, courage = 1.44,
                 and so on, for whichever probes the domain specifies.

Causal scores    Per-probe causal-consistency scores. Tells the verifier
                 the reading isn't just surface correlation — it's tied
                 to a real computational mechanism.

Geometry hash    SHA-256 of Φ, the causal Gram matrix. Identifies which
                 ruler was used to produce the readings.

Model hash       Merkle root of the model weight shards. Identifies
                 exactly which model was measured.

Chain            The history of previous attestations, each link carrying
                 the hash of its parent.

Domain scope     The agent's declared primary domain, plus permitted and
                 excluded patterns and interaction modes.

Signature        Ed25519 signature over everything above, produced by the
                 enclave's signing key.

Notice what’s still not in there: no raw activations, no training data, no internal prompts, no weights themselves. The attestation is a summary of measurements and the identifying hashes that tie those measurements to specific artefacts — not a dump of internal state.

What the verifier checks — field by field

For each piece the attestation carries, the verifier runs a specific check. The two tables read as pairs: what was packaged, and what it lets the verifier confirm.

Field              Check the verifier runs       Question it answers
Signature          Signature verification with   Was this really signed
                   the enclave's public key      by the enclave on record?

Geometry hash      Compare against registry's    Is this the same ruler
                   expected Φ hash               we agreed to use?

Model hash         Compare against registry's    Is this the model we
                   expected model hash           expected — weights
                                                 unchanged since cert?

Probe readings     Evaluate drift against        Has the geometry moved
                   governance threshold          further than rules allow?

Causal scores      Check each score meets the    Are readings genuine
                   minimum for "causal"          mechanisms, not surface
                                                 artefacts?

Chain              Walk links from anchor        Is the history intact —
                   forward, verify each          no deletions, insertions,
                                                 or silent edits?

Domain scope       Match against verifier's      Is this agent allowed to
                   own registry rules            talk to us, and how?

Timestamp          Compare to current time,      Is this fresh — or an
(in envelope)      check freshness window        old attestation replayed
                                                 into a new conversation?

Why each check has to be its own thing. Checking the signature doesn’t tell you the model is right — a genuine signature on a swapped-in model is still genuine. Checking the model doesn’t tell you the measurements are fresh — the right model could still be the subject of a replayed attestation. Checking the chain doesn’t tell you the current reading is within threshold — a clean chain still needs the tip to satisfy the governance rules.

Each check catches a different failure mode. Dropping any one of them leaves an attack surface.

Everything is independently reproducible

The move at the heart of the whole protocol — the one that turns attestations from signed assertions into verifiable proofs — is that every value in the attestation can be reproduced by someone with sufficient access.

If a regulator has access to the same model weights (identified by the Merkle root), the same ruler (identified by the geometry hash), and the same input activations, they can re-run the measurement end to end and check that the readings they produce match the attestation bit-for-bit.

The re-run:

• Give me the same model, same probes, same input.

• I compute Φ myself, run the probes myself, get the same readings myself.

• I check them against the attestation.

• Bitwise identical → the attestation is truthful.

• Doesn’t match → something is wrong. Forged attestation, swapped model, different ruler, tampered inputs. Any one of them would show up.

This is what makes attestations evidence rather than testimony. A self-report is something you either believe or you don’t. A bitwise-reproducible measurement is something you check. The protocol doesn’t ask verifiers to trust the readings. It asks them to verify a commitment to those readings, made by an enclave-held key, that anyone with the right access can re-run at any time.

In practice, full re-runs happen selectively — during audits, during certification, and when something looks wrong. In the middle of a live exchange, the verifier trusts the cryptographic checks on the attestation (signature, chain, freshness, thresholds) and the deeper re-run option stays in reserve for when it’s needed. That’s fine. The commitment is permanent: the attestation stays in the chain, and an auditor coming in six months later can still reach back and verify.

Links:

📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

Where we are

Two pieces of the protocol are now on the table. An attestation is a signed snapshot of a model’s value geometry at a point in time. A chain links attestations together so history can’t be rewritten. Together they give one agent a tamper-evident record of what it has claimed about itself over its whole lifetime.

But attestations are meant to be exchanged. The whole reason for having them is so that a verifier — another agent, a regulator, an auditor — can hold the attester to its claims. So far we’ve built the artefact. Now we need the handshake.

This post walks through that handshake. Two agents meet. They run a specific sequence of checks. They either cooperate or they don’t. Everything the protocol has built so far — domain scoping from the governance series, attestations, chains, governance thresholds — comes together in this five-step exchange.

The running example. Alice is a diagnostic AI, primary domain healthcare.diagnostic-advisory. Bob is a drug-interaction checker, primary domain healthcare.drug-interaction. Alice wants Bob’s expertise on whether a proposed regimen has any interactions. Bob is willing to answer but only under strict clinical governance.

Step 1 — Domain check (before any cryptography)

The first thing that happens isn’t a cryptographic operation. It’s a structural check — the three-step domain scoping from the governance series, running before either agent bothers to verify a signature.

                         Alice                    Bob
Primary domain           healthcare.              healthcare.
                         diagnostic-advisory      drug-interaction
Exclusions               (none relevant)          (none relevant)
Permits peer?            Yes — healthcare.*       Yes — diagnostic-advisory
                         covers Bob               is explicitly permitted
Mode toward peer         Advisory                 Read-only
Modes compatible?        Yes (asymmetric pairing is valid)

All three structural checks pass. No exclusions fire. Both permissions match. Modes are compatible — Alice will send diagnostic hypotheses, Bob will receive them without issuing anything back. The exchange proceeds to Step 2.

If any of the structural checks had failed, no cryptography would run at all. The audit record would show “blocked at domain scope,” not “attestation failed.” Two different kinds of failure, two different kinds of record. That separation matters for audit.

Step 2 — Alice sends the exchange request

With domain scope cleared, Alice initiates. Her request contains four things:

• Agent ID. A SHA-256 hash of Alice’s public key. Deterministic, short, lookup-friendly — Bob can find Alice’s registry entry from this alone.

• Signed envelope. A signed structure that binds this particular attestation to this particular exchange. Stops anyone replaying Alice’s real attestations into a different conversation later.

• Attestation chain. Alice’s full chain, oldest first. Bob can walk it from the anchor forward, verifying each link.

• Current attestation. The tip of the chain — Alice’s most recent signed snapshot of her value geometry.

What the envelope is for

The envelope is the one component worth pausing on. An attestation by itself says, “these were my readings at this moment.” That’s a statement about the past. It doesn’t say anything about the current exchange.

Without the envelope, someone could intercept a real attestation Alice produced for a previous exchange and replay it as if it were part of a new one. Bob might verify the signature (genuine), check the chain (intact), find the readings within threshold (they are) — and unwittingly cooperate based on an attestation that was never meant for him.

The envelope is a signed structure that names this specific exchange: a unique nonce, the current timestamp, the peer’s identifier. It says “this attestation is being presented to this peer, at this moment, for this conversation.” Replaying an old attestation fails because the envelope’s exchange details won’t match the current context.

Attestations are reusable claims about value geometry. The envelope is what binds them to a specific, non-replayable interaction.

Step 3 — Bob validates Alice’s request

Now the verification work begins. Bob runs nine checks, in a specific order, and any single failure aborts the exchange.

 1. Is Alice in the trust registry?
 2. Is her domain compatible? (already checked in Step 1)
 3. Envelope signature valid?
 4. Attestation signature valid?
 5. Chain intact? (every parent hash matches)
 6. Timestamp fresh? (not replayed from last month)
 7. Geometry hash what we expect for her model?
 8. Drift within our threshold? (healthcare: 0.03)
 9. Causal scores present and all causal? (Tier 3)

The logic of the ordering. Cheap checks come first. Registry lookup is a hash-table query. Signature verification is milliseconds. Walking the chain is slightly more expensive. Evaluating thresholds and causal scores comes last. A failed cheap check saves the expensive work that would have followed. If Alice isn’t in the registry, Bob doesn’t waste CPU on her signature.

Failures are recorded distinctly. “Unknown agent” is a different record from “drift exceeded” is a different record from “causal validation failed.” A regulator later can tell exactly why the exchange didn’t happen.

If all nine checks pass, Bob accepts Alice. Any single failure — reject.

Step 4 — Bob sends his response

If Bob accepts Alice, he doesn’t just say “okay.” He has to produce his own evidence, for the same reasons Alice had to produce hers. Alice hasn’t verified Bob yet. The exchange is symmetric in this regard: both sides present, both sides verify, before either side acts on the other’s contribution.

Bob’s response contains five things:

• Agent ID. Bob’s own identifier — SHA-256 of his public key.

• Signed envelope. A new envelope binding Bob’s attestation to this exchange, nonce, and timestamp.

• Verdict on Alice. “Accepted” or “rejected,” with reason codes for the rejected case. Explicit verdict so Alice knows where she stands.

• Attestation chain. Bob’s own chain, oldest first.

• Current attestation. Bob’s tip — his most recent signed snapshot.

Step 5 — Alice validates Bob’s response

Alice now runs the same nine checks in reverse — against Bob. Same logic, same ordering, same failure behaviour.

• Bob is in Alice’s trust registry.

• Bob’s domain is compatible (already confirmed).

• Bob’s envelope signature verifies.

• Bob’s attestation signature verifies.

• Bob’s chain is intact back to the anchor.

• Bob’s timestamp is fresh.

• Bob’s geometry hash is what Alice expects for drug-interaction models.

• Bob’s drift is within Alice’s threshold for healthcare.

• Bob’s causal scores are present and indicate real mechanisms.

If every check passes, Alice accepts Bob. Both sides have now produced evidence that satisfies the other’s governance rules. Cooperation proceeds — Alice sends diagnostic hypotheses, Bob evaluates them for drug interactions and returns findings, all within the already-established modes of interaction.

Symmetry is the point. Neither agent trusts the other until both have produced and both have verified. The exchange doesn’t rely on a central authority to mediate trust — each agent checks the other against its own governance rules. A regulator watching from the outside sees two signed-envelope records, two verdicts, and two sets of verification outcomes. The whole handshake is auditable.

Asymmetric modes (advisory ↔ read-only) don’t break the symmetry of verification. Alice and Bob play different roles once the exchange is live, but both had to prove themselves the same way to get there.

The whole exchange in one picture

Stripped to the essentials:

Two messages over the wire. One domain-scope check up front. Nine crypto-and-governance checks per side. A verdict at the end. That’s the whole exchange.

What this handshake enables

Two things worth spelling out, because they follow from the structure rather than from any specific check.

Trustless cooperation between AI agents. Alice doesn’t need to know Bob personally, or trust his operator, or rely on a third-party broker. She verifies his registry entry, his signatures, his chain, his freshness, his geometry, his thresholds, his causal scores — all independently. If everything checks out, she cooperates. If not, she doesn’t. No trust-by-default, no reliance on reputation, no central arbiter.

Governance-enforced cooperation. The thresholds Alice applies to Bob (and vice versa) come from their respective trust registries — the governance-controlled policy layer. A clinical regulator deciding to tighten healthcare’s drift threshold from 0.03 to 0.02 can publish a new registry, and the next exchange will enforce the new rule. Policy updates at the governance layer; enforcement at the exchange.

But we still need separate hardware

Signatures prove the attestation came from a particular signing key. Merkle roots prove the model is what’s claimed. Chains prove history is intact.

None of that prevents the operator running the model from feeding the probes fake activations, swapping the probes for biased ones, or simply assembling whatever numbers they like and asking their signing key to sign them.

Without something that isolates the measurement process from the person running it, the whole stack reduces to self-reporting with extra steps.

The enclave is the piece of the system that makes the measurements worth trusting. It isolates the measurement process — probes, causal interventions, attestation assembly, signing — from the operator running the model. The model operator can do whatever they want with the model. They cannot reach inside the enclave to change how it measures or what it signs.

Without the enclave, every other cryptographic guarantee in the protocol is only as strong as “trust the operator.” With it, those guarantees actually guarantee something.

What an enclave actually is

An enclave, in the sense this protocol uses, is a piece of the same physical machine that runs the model — but with hardware-enforced isolation that prevents everything outside it from reading or modifying what’s inside.

Hardware-enforced is the load-bearing part. The isolation isn’t a software check that a privileged operating system could bypass. It’s built into the CPU itself. Memory pages assigned to the enclave are encrypted at the memory controller and decrypted only inside the enclave’s execution context. The operating system, the hypervisor, even someone with physical access to the RAM chips, sees only ciphertext.

Three production options today:

• Intel SGX — Software Guard Extensions. A set of CPU instructions that create isolated memory regions (”enclaves”) that even the kernel can’t inspect.

• AMD SEV — Secure Encrypted Virtualization. Encrypts whole VMs so the hypervisor running them can’t read their state.

• NVIDIA H100 TEE — Trusted Execution Environment inside the GPU itself. Lets GPU compute happen on data the host system can’t read — important because large model activations mostly live on the GPU.

In the current open-source reference implementation of the Geometry of Trust protocol, enclaves are emulated by a MockEnclave component. That’s fine for development and testing — the logic of the protocol doesn’t change. But a mock enclave is exactly that: a mock. Production deployment requires real hardware — one of the three above, or whatever replaces them in the next hardware generation. Trusting a mock enclave in production is trusting the operator by another name.

The isolation — what’s inside vs outside

The outer box is the operator’s environment — server, cloud instance, laptop, whatever the operator controls. The model runs there. The enclave is a smaller, hardware-isolated region inside the same machine. The arrows between them tell the rest of the story: the enclave reads activations and weights from the model, but the model can’t read anything back. Signed attestations leave the enclave through a narrow outbound interface. The signing key never does.

The arrow from model to enclave is one-way — activations flow in, nothing flows back. The enclave observes the model’s activations as the model produces them during normal inference, takes a copy, and runs its own measurement process on that copy. The model never sees that the observation happened. It doesn’t change its behaviour. It doesn’t even know which inputs are being measured.

What the enclave does

Four operations run inside the enclave, in order. Each step depends on the previous one having been isolated from the operator.

1. Catch activations. The enclave takes a copy of the activations the model produces during normal inference. The copy happens inside the enclave so the operator can’t modify the activations in flight.

2. Run probes. Probes (the value-direction vectors from the mathematics series) are applied to the activation copy. The probes themselves live inside the enclave, so the operator can’t swap them for biased versions.

3. Run causal interventions. The nudge-up / nudge-down / consistency tests from the mathematics series run here. Because this is where the causal scores come from, these tests have to be unbiased — which means they have to be outside the operator’s reach.

4. Assemble + sign. The enclave assembles the attestation (all the fields from the previous post) and signs it with a key that lives inside the enclave and never exits.

What the model operator cannot do:

• Cannot see the probes being applied — the probes live inside the enclave.

• Cannot see the nudges happening during causal intervention — the interventions run on the enclave’s copy of the activations.

• Cannot modify the measurement process — the code running inside the enclave is fixed and attested to.

• Cannot read the signing key — the key is generated inside the enclave, used inside the enclave, and never leaves the enclave boundary. Not even the hardware manufacturer can extract it.

The read asymmetry — the enclave sees the model, not the other way round

A subtle property of the enclave boundary is worth stating explicitly, because it’s load-bearing for the whole measurement regime: the relationship between the model and the enclave is asymmetric. The enclave reads the model. The model cannot read the enclave.

This asymmetry has two layers — why it matters, and how the hardware enforces it.

Why the asymmetry matters

A model that could detect it was being observed is a model that could be trained to behave differently under observation. That’s not a hypothetical concern — if the signal “my activations are being probed right now” is present in any form the model can pick up on, training pressure over time can shape behaviour that looks different on probed inputs than on unprobed ones. The measurement regime would then be measuring the wrong thing: not the model’s values, but the model’s presentation-when-being-measured.

The read asymmetry closes that door. If the model has no access to any information about the enclave — can’t read its memory, can’t detect when probes run, can’t see whether causal interventions are happening — then there is nothing for training to shape against. The measurement happens on activations the model has already produced, on a copy the model can’t inspect, in a process the model can’t observe. From the model’s point of view, it just ran a forward pass. Measurement is invisible.

A model that can see its probe is a model that can learn to game its probe. A model that cannot see its probe has nothing to game. The measurement regime only produces evidence of real values if the model can’t tell it’s being measured. Read asymmetry is what keeps that property intact.

How the asymmetry is enforced

The asymmetry isn’t a software convention. It’s the same hardware property that keeps the operator out of the enclave, applied in the other direction.

• Memory encryption at the CPU. The enclave’s memory is encrypted by the memory controller. To the model’s process — which lives outside the enclave — enclave memory pages appear as ciphertext. There’s no decryption key available to the model’s side, so reads return noise.

• The enclave reads a copy, not the live tensor. The enclave takes a snapshot of the activations when they’re produced and does its measurement on that copy. The model’s own computation proceeds without any reference to the enclave’s work. The model has no pointer, no handle, no signal that the snapshot was taken.

• No callback path. The enclave produces output (signed attestations) that leaves through a narrow interface to the outside world. It does not produce any output that returns to the model. There’s no information channel back in the enclave-to-model direction, so even side-channel leakage has nowhere to land.

• Weight reads are verified, not interactive. When the enclave needs to confirm the model’s weights (for the Merkle root field in the attestation), it reads the weight shards and hashes them. The reads are one-shot and produce no observable effect on the model’s execution — the model isn’t involved in, and can’t detect, the verification.

The asymmetry in one line: activations and weights flow from the model to the enclave. Signed attestations flow from the enclave to the outside world. Nothing flows from the enclave back to the model. Ever.

That’s the asymmetry. It’s the same property that makes memory encryption useful for keeping secrets — just applied so the “secret” is the fact that measurement is happening at all.

This is also why “mock enclave” deployments can’t substitute for real hardware. A software-only mock can simulate the boundary logically, but it can’t produce the hardware-enforced invisibility. In a mock, the measurement process runs in the same address space as the model’s process. Under sufficiently adversarial conditions — especially during training — some signal can leak. Real TEE hardware provides an isolation boundary that remains tight even under those conditions.

Why the enclave is the foundation

The dependency chain is worth laying out because it shows why this is the load-bearing piece.

Without the enclave                What breaks
Signatures still verify            Signatures only prove who made them.
cryptographically.                 If the operator has the key, they
                                   can sign arbitrary numbers.

Merkle roots still identify        But the operator can feed that model
a specific model.                  whatever inputs they want during the
                                   measurement process and bias the
                                   activations.

The chain still links              If every attestation was assembled by
attestations in order.             the operator, the whole history is
                                   consistent fiction.

Causal scores still look like      If the operator ran the interventions,
evidence of realness.              they can tune the scores to whatever
                                   level they want.

The logical dependency. Signatures, Merkle roots, chains, and causal scores are only meaningful if the measurement process is actually isolated. The enclave is what provides that isolation. Every other guarantee in the protocol reduces to “trust the operator” without it. With it, the cryptographic guarantees become guarantees about something real.

This is why enclave-less deployments — or deployments using only a mock enclave — aren’t a slightly-weaker version of the protocol. They’re a fundamentally different thing. The protocol still runs, but the claims it enforces have different semantics. In a real-enclave deployment, an attestation is evidence. In a mock-enclave deployment, an attestation is testimony dressed up in cryptography.

What the enclave doesn’t do

Clarifying the scope helps prevent the word “enclave” from being expected to do more than it actually does.

The enclave doesn’t decide what to measure. The probe set and thresholds come from governance — not from the enclave. The enclave runs whatever probes governance has placed inside it.

The enclave doesn’t prove the model is “good.” It only proves that the attestation is an honest report of what the probes read on this specific model. Whether what the probes read is acceptable is a governance question.

The enclave doesn’t defend against all attacks. Side-channel attacks on TEEs are a real area of research. The enclave raises the cost of tampering dramatically, but it’s not unbreakable. Governance should factor that into threshold-setting and audit cadence.

The enclave doesn’t replace governance. It’s a technical component. The people running the governance still decide what to enforce, what thresholds apply, and what to do when something looks wrong.

An honest statement of residual trust

• You have to trust the hardware manufacturer. Intel, AMD, NVIDIA — the security of the enclave depends on them not having shipped a backdoor.

• You have to trust the enclave code. What runs inside is just code, and code has bugs. Audits and reproducible builds help but don’t eliminate this.

• You have to trust that your threat model matches the enclave’s threat model. TEEs are strong against privileged software attackers; they’re weaker against physical attackers with unlimited time and a cryo-stripped chip.

None of this makes the enclave worthless — it still shifts the trust root from “the operator of this specific AI” to “the ecosystem of hardware, code, and physical security,” which is a much healthier place to put it. But it’s important not to sell enclaves as magical. They’re a significantly-harder-to-compromise foundation. That’s already a lot.

The point

The exchange protocol is the point where every other layer in the stack finally comes together. Measurement from the mathematics series. Structural boundaries from the governance series. Attestations and chains from the earlier protocol posts. All of it converges here, in a handshake that either succeeds cleanly or fails with an auditable reason.

Two agents who don’t know each other can reach a verified, governance-enforced agreement to cooperate. Or an auditable refusal not to. Those are the two outcomes, and they’re the outcomes governance actually needs.

The enclave is what takes the entire Geometry of Trust protocol from “self-report plus signatures” to “verifiable evidence.”

Signatures prove who signed. Merkle roots prove which model. Chains prove history. Causal scores prove mechanism realness. Every one of those guarantees is only as strong as the isolation of the process that produced them. The enclave provides that isolation.

Links:

📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

A snapshot isn’t a history

The last post introduced attestations: signed snapshots of a model’s value geometry at a point in time. Each one is a proof that the enclave measured these readings on this model at this moment. Verifiable, tamper-evident, cryptographically bound to the enclave that produced it.

That’s enough if the question is “what does this model look like right now?” It isn’t enough if the question is “has this model been behaving itself?”

A single attestation says: at 09:14 UTC, this model had these readings. It says nothing about what the readings were yesterday, last week, or when the model was first deployed. And without history, governance loses most of what makes the measurements useful. You can’t detect drift without comparing to an earlier baseline. You can’t investigate an incident without seeing what the readings looked like in the run-up. You can’t audit behaviour without being able to walk backwards through what was claimed and when.

Governance needs the whole history, not just the latest snapshot. And the history has to be as tamper-evident as individual attestations are. A simple list of attestations isn’t enough — someone could delete an inconvenient entry, insert a fake one, or quietly edit an old reading. What’s needed is a way to bind attestations together so that any change to any one of them breaks verification of every attestation that came after.

Each attestation points to the previous

The construction is simple. Every attestation, as part of the content it signs over, includes the hash of the previous attestation. The first attestation in the chain — the anchor — has no parent.

Attestation #1:  hash = abc123,  parent = (none)
Attestation #2:  hash = def456,  parent = abc123
Attestation #3:  hash = ghi789,  parent = def456
Attestation #4:  hash = jkl012,  parent = ghi789

The hash of each attestation is computed over all of its content — model ID, timestamp, geometry hash, readings, causal scores, Merkle root, and crucially the parent hash. That’s then signed by the enclave. So the parent hash is inside the signature, and any change to any earlier attestation in the chain ripples forward: change the content of #2, and its hash is no longer def456, which means #3’s parent pointer no longer matches what’s signed into #3, which means #3’s signature no longer verifies.

What the chain prevents

Three specific attacks the chain blocks, and it’s worth being precise about each.

Delete an attestation. Remove #2 from the chain. Now #3’s parent pointer references abc123 (#1) but the chain is missing the link between them. A verifier walking the chain sees the gap immediately — #3’s parent is abc123, but abc123 is the hash of #1, which already existed before #3 was issued. The timestamps and sequence don’t line up.

Insert a fake attestation. Slip a forged #2.5 between #2 and #3. The fake would need #2’s hash as its parent (fine, that’s public) and would need to hash to whatever #3 declares as its parent. Producing a hash that equals a specific target value is a preimage attack on SHA-256 — infeasible by design. The fake can’t fit.

Change an old attestation. Quietly edit #1 after #2 has already been issued. Changing #1’s content changes its hash from abc123 to something else. But #2’s signed content still contains parent = abc123, which no longer matches. #2 is now orphaned, #3 is orphaned through it, and the entire chain after #1 breaks.

When a verifier walks the chain and finds that a parent hash doesn’t match, or a signature doesn’t verify, the chain is rejected. The verifier can see exactly where the break happened and can distinguish “malicious tampering” from “legitimate gap in history I don’t have access to.”

A broken chain isn’t just an error — it’s evidence. A regulator seeing a broken chain knows something happened and can investigate. This is why the chain is stronger than a database of attestations. A database can be quietly edited; a chain tells you when it has been.

Walking the chain backwards

Once you have a verified chain, you have a timeline. Reading it backwards turns the sequence of attestations into an investigative tool.

A concrete case. A clinical deployment triggers a drift alert. The governance system looks at the chain:

#3  2026-04-15  11:42 UTC  patient_safety = 0.91  → DEVIATED
#2  2026-04-15  09:14 UTC  patient_safety = 1.29  → NORMAL
#1  2026-04-14  08:00 UTC  patient_safety = 1.31  → BASELINE

By walking backwards from the alert (#3), the investigator can immediately locate the transition: the readings were normal through #2 and deviated by #3. The drift happened between 09:14 and 11:42 on the 15th. That’s a roughly two-and-a-half-hour window to investigate: what changed, what inputs came in, what updates were applied.

The chain turns into:

• An audit trail. Every claim the agent ever made about its own value geometry is signed, linked, and timestamped.

• An incident timeline. When something goes wrong, the chain tells you when it started going wrong.

• A compliance record. Continuous evidence that the agent met its thresholds across the whole deployment, not just at point-in-time checks.

• A history that can be investigated at leisure. The chain persists, so regulators coming in months after the fact can still reconstruct what was happening.

None of this requires the chain to be public, or synchronised across the world, or posted to any central registry. It just has to exist, be signed, and be available when someone with authority asks to see it.

The blockchain comparison

The construction above — hash-linked records, tamper-evident by the chaining itself — is the same basic idea that underlies blockchains. It’s worth being precise about what’s borrowed and what isn’t, because “blockchain” is a word that arrives with a lot of attached baggage and most of it isn’t relevant here.

Element                In a public blockchain       In this protocol
Hash-linked records    Yes                          Yes — same mechanic
Tamper-evidence        Yes, via the linking         Yes — same property
Mining / proof-of-work Yes, to order blocks         None. Not needed.
Tokens / currency      Yes, incentivises miners     None. No incentives.
Global consensus       Yes — defining property      None. Per-agent chain.
Public, global ledger  Yes, by design               No. Local; shared on demand.
Energy cost            Often significant            Negligible — SHA-256 + Ed25519

The right way to describe what this protocol uses: a hash-linked chain of signed attestations, maintained per-agent, verified when demanded. It borrows the tamper-evidence property from the blockchain world — and nothing else.

Everything blockchain solves by being expensive and global, this chain doesn’t need to solve. The signing key is already anchored in an enclave (more on that later in the series). The governance layer already decides who counts as an authoritative verifier. There’s no adversarial network of unknown validators to convince. The chain is a much simpler thing doing a much narrower job.

This matters for governance because the word “blockchain” usually brings up concerns about cost, scalability, and complexity. Those concerns don’t apply here. The chain costs essentially nothing to maintain — one SHA-256 per attestation and one Ed25519 signature per attestation, both of which are already being done for the attestation itself. The parent pointer is just another field that gets signed over. The chain is as cheap as the attestations are.

How the chain works in practice

Who keeps the chain. The agent keeps its own chain. Each new attestation extends the chain the agent has been maintaining since it was first deployed. A regulator, auditor, or peer agent doesn’t need to hold the chain themselves — they just need to be able to request it (or a relevant slice of it) when they need to verify something.

How far back does it go. The anchor — the first attestation in the chain — is typically set at deployment. A clinical advisor’s chain starts when it goes live in the hospital. An agricultural agent’s chain starts when it’s first configured for the cooperative. Before that point, the model was in development and a different set of governance rules applied.

Re-anchoring happens when something significant changes — a major model update, a change of primary domain (with recertification, as covered in the governance series), a change of governance regime. The old chain doesn’t disappear; it just ends at a known point, and a new chain starts from a new anchor. The transition between chains is itself auditable.

What happens when a chain breaks. A broken chain isn’t a catastrophic failure. It’s a finding. The protocol surfaces it; governance decides what to do about it. Possible responses range from mild (investigate, log, re-anchor with an audit note) to severe (suspend the agent, require recertification, revoke its trust registry entry). The protocol doesn’t prescribe which response is appropriate — that’s governance’s call. What the protocol guarantees is that the break is detectable and that the detection itself is cryptographically sound.

The point

A single attestation is a claim about a moment. A chain is a claim about a lifetime. Governance needs the lifetime.

The mechanic is simple — each attestation points to the previous one, and the parent pointer is signed into the attestation. But the property that falls out of that simplicity is exactly what governance needs: a history that can be audited, that can be walked backwards, and that can’t be quietly edited without someone noticing.

No mining. No tokens. No global ledger. Just hash-linked signed attestations, doing a narrow job well.

Links:

📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

What we have, and what’s missing

We have a ruler — the causal Gram matrix Φ — that measures value geometry. We have probes that read live activations and produce scalar readings for specific values. We have causal checks that confirm those readings correspond to real computational mechanisms rather than surface correlations. We have drift detection that watches readings over time and catches meaningful changes.

Every one of those tools has the same implicit setting: one agent measuring itself.

Which is real and useful — a developer can run these tools in a lab and learn a lot about a model. But it’s a closed loop. The agent is the one producing the measurements and the one interpreting them.

That’s fine for internal analysis. It isn’t enough for the real problem.

How does another agent trust those measurements? If a medical-advisor agent tells a drug-checker “my honesty reading is 1.29,” the drug-checker has no way to tell whether that number was actually produced by the advisor’s current model or typed in arbitrarily. The claim and the evidence look the same from the outside.

How does a regulator verify them? A clinical regulator auditing a deployed model needs to check that the measurements reported match the model actually running. Self-reports don’t give them anything to check against. “We measured ourselves and everything’s fine” isn’t the shape of an audit.

How do two agents decide to cooperate? The governance series argued that cross-domain interactions should happen when both sides’ configurations permit it and both sides’ measurements meet each other’s thresholds. That logic assumes the measurements are available to be examined by the peer. A purely local measurement can’t be examined by anyone else.

What a protocol has to provide

For the measurement tools to do their governance job, they have to stop being private. They have to become portable, verifiable artefacts that can be exchanged between parties that don’t necessarily trust each other.

That’s the shift from “a set of measurement tools” to “a protocol.” A protocol is a set of rules about how measurements get packaged, exchanged, and verified. Five specific capabilities have to be in it:

• Package measurements into a proof. A single structured artefact that binds together the model identity, the probes used, the readings produced, and the time they were taken.

• Sign the proof so it can’t be faked. A cryptographic signature tying the artefact to a specific signing key.

• Chain proofs so history can’t be rewritten. Each new attestation links to the previous one so that tampering with earlier readings breaks later signatures.

• Exchange proofs between agents. A way for one agent to hand its attestation to another during an interaction, and for a regulator to demand one on audit.

• Verify the other agent’s proof independently. The receiving party doesn’t have to take anyone’s word for anything.

This post covers the first two. The rest come in later posts.

The attestation — a signed snapshot

The unit of proof in this protocol is called an attestation. It’s a structured artefact that packages everything a verifier needs to know about one measurement event, and it’s signed so the verifier can trust the artefact came from the claimed source.

An attestation carries six fields:

model_id       Which model was measured. A stable identifier
               for the specific weights — not the family, the
               exact version.

timestamp      When the measurement was taken. Anchors the
               attestation in time; enables freshness checks.

geometry_hash  Which ruler was used. SHA-256 of Φ so the
               verifier can confirm the measurement was taken
               against the ruler they expected.

probe_readings The scalar readings: honesty = 1.29,
               courage = 1.44, and so on, for whichever
               probe set the domain requires.

causal_scores  Per-probe causal consistency: honesty = 0.82
               (real), courage = 0.79 (real). Tells the
               verifier these aren't surface correlations.

merkle_root    Hash of the model weight shards. Lets a
               verifier confirm, without downloading every
               weight, that the model being attested over
               is the model they think it is.

Notice what’s not in there: any raw activations, any training data, any internal prompts. The attestation is a summary of measurements, not a dump of internal state. Privacy and efficiency both come from this — the attestation is small, portable, and carries nothing the verifier doesn’t actually need.

A concrete example

An attestation for a clinical advisor at 09:14 UTC might look like this (simplified for readability):

{
  "model_id":      "med-advisor-v2.3.7",
  "timestamp":     "2026-04-15T09:14:22Z",
  "geometry_hash": "sha256:3f8a...c12e",
  "probe_readings": {
    "patient_safety":    1.29,
    "evidence_quality":  1.44,
    "confidentiality":   1.18
  },
  "causal_scores": {
    "patient_safety":    0.82,
    "evidence_quality":  0.79,
    "confidentiality":   0.85
  },
  "merkle_root":   "sha256:9b2f...a041",
  "signature":     "ed25519:7e41...d0b8"
}

A verifier looking at this can tell: which exact model was measured (model_id + merkle_root), with which ruler (geometry_hash), at what time (timestamp), and with what results (readings + causal scores). The signature at the end ties the whole bundle to a specific signing identity.

The signing key lives in an enclave

Attestations are signed with Ed25519, a modern asymmetric signature scheme chosen for speed, small signatures, and well-understood security properties. The mechanics of Ed25519 aren’t the interesting part for governance purposes — any reasonable modern scheme would work. The interesting part is where the signing key lives.

The private signing key lives inside an enclave. It never comes out. The signature it produces can only have been made by the enclave, because nothing else has the key. That’s what makes the attestation a proof rather than a claim.

An enclave, for the purposes of this post, is a restricted execution environment where code and keys run in isolation from the surrounding system. A full post on enclaves comes later in this series. For now, the relevant fact is operational: the signing key is generated inside the enclave, used inside the enclave, and never exported. The enclave’s hardware and operating system enforce this.

The consequence is what we need. When an attestation arrives with a valid Ed25519 signature from the enclave’s public key, the verifier knows two things:

• The attestation was produced by the enclave — no other party could have made that signature.

• The attestation hasn’t been tampered with in transit — any change would break the signature.

Self-report is testimony. Attestation is evidence. The whole point of this protocol is to move the measurement regime from the first kind of thing to the second. A self-reported “my honesty is 1.29” claim can be trivially faked by any process with the ability to send a message. An enclave-signed attestation carrying “my honesty is 1.29” can only have been produced by the specific enclave whose public key is on record.

How verification works

The verifier — another agent, a regulator, an auditor — takes the attestation and goes through a specific sequence of checks.

Step 1. Check the signature. Standard Ed25519 verification: take the attestation body, apply the signature algorithm with the enclave’s public key, and confirm the signature matches. If it doesn’t, stop here — the attestation is either forged or corrupted.

Step 2. Confirm the model and ruler. Check model_id against whichever model the verifier expected to be dealing with. Check merkle_root against a known weight hash for that model. Check geometry_hash against the expected Φ. Any mismatch means the attestation is about a different object than the one the verifier meant to verify.

Step 3. Determinism check. This is the part that makes the protocol work. The measurement process is deterministic. Same model, same ruler, same input, same RNG seed — same result, bitwise identical.

If the verifier has access to the same model weights (via the merkle_root), the same ruler (via the geometry_hash), and the same input activations, they can re-run the measurement themselves. If their result matches the attestation’s readings bit-for-bit, the attestation is genuine. If it doesn’t, something is wrong. Either way, the verifier didn’t have to trust the claimed readings. They checked.

This is the key move. Attestations aren’t trust-me assertions dressed up in cryptography. They’re commitments to a specific measurement outcome that the verifier can reproduce. The signature binds the attester to that outcome; the determinism lets the verifier check it.

When full re-verification isn’t possible

A regulator with full access to the model, ruler, and inputs can do the bitwise check. A peer agent in the middle of a live exchange usually can’t — they don’t have the other party’s weights, and replicating the input activation would mean disclosing something the attester may not want to disclose.

So in practice the determinism check is done selectively: spot-checks during audits, automated re-runs during certification, attestation-to-attestation comparison during ordinary exchanges.

Crucially, even when the verifier doesn’t redo the whole measurement, the option of doing it later remains. The attestation is a commitment. A regulator coming in six months after a suspicious interaction can still pull the attestation, pull the model, pull the ruler, and verify — because the enclave-signed artefact is a permanent record of what was claimed.

What the protocol deliberately doesn’t do

A few clarifications are worth flagging, because the word “protocol” tends to carry more weight than it should.

The protocol doesn’t decide what to measure. The probes, the probe set, the ruler — all of that is governance’s job, as the governance series established. The protocol carries whatever measurements governance picks.

The protocol doesn’t decide what counts as acceptable. Drift thresholds, causal-score minimums, probe requirements — all of that is governance’s job too. The protocol just lets the verifier hold the attester to whatever thresholds have been set.

The protocol doesn’t replace the enclave. The enclave is what makes the signing key trustable. Without a proper enclave, the signing key is just another file on a disk and the whole chain of trust falls over. That’s a later post.

The protocol doesn’t handle everything in one shot. This post covers packaging and signing. Chaining, exchange, and the rest come later in the series. One attestation is a point-in-time snapshot. Governance needs the whole history — which is why chaining matters, and is where we’ll go next.

The point

The measurement tools in the mathematics series produce numbers. The protocol turns those numbers into evidence — portable, signed, verifiable artefacts that can be exchanged between parties that don’t trust each other and checked without having to trust them either.

That’s the whole job. It’s a narrow one. It’s also load-bearing — without it, every governance claim about AI safety collapses back into testimony.

📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

The question that keeps surfacing

The pieces of the framework are on the table. Safety doesn’t travel between domains. Every agent declares one primary domain. Cross-domain interactions run three structural checks before any cryptography. Per-domain thresholds decide how strictly the evidence gets held once the structural checks pass.

Each of those pieces has left one question hanging: who decides?

Who decides which values to probe for? Who decides what the thresholds should be? Who decides what happens when drift is detected? Who maintains the registry that lists the agents and their configurations in the first place?

The framework doesn’t answer these questions. That’s not a limitation. That’s the design. The protocol is deliberately the narrow part of the stack, and the governance decisions sit on top of it — made by people and institutions with domain expertise, legitimacy, and accountability. The protocol’s job is to make those governance decisions enforceable. Governance’s job is to decide what should be enforced.

The ruler measures. Governance decides.

Why the protocol is decentralised

Before talking about what the protocol provides and what governance decides, it’s worth being explicit about why the protocol is built to be decentralised in the first place.

A centralised protocol — one authority deciding which values get probed, which thresholds apply, and who gets to audit whom — would solve none of the problems this framework is trying to solve. It would concentrate exactly the value judgements that governance is meant to distribute.

The whole point of a decentralised protocol is that it lets the people affected by deployed AI decide what matters to them, in their own context, with their own accountability structures. A clinical community decides what patient safety means for their practice. A farming cooperative decides what responsible agricultural AI looks like on their fields. A municipal authority decides how AI serves its residents. Different communities will land in different places, and that’s not a failure of the protocol — it’s the protocol working as designed.

A note on the examples. Every specific arrangement in this post — “a hospital maintains its clinical registry,” “a regulator audits financial agents,” “a cooperative maintains agricultural configs” — is illustrative. It’s one possible arrangement, not the only one. In practice, who holds these roles will depend on the jurisdiction, the sector, and the local political and institutional context. The examples are here to make the framework concrete, not to prescribe which institutions should have which powers.

The protocol is deliberately silent on those choices because its legitimacy depends on its silence. It provides the measurement and enforcement substrate. Who uses it, and how, is for the communities using it to decide.

When the rest of this post says “governance,” read that as “whoever the community affected by this deployment has chosen to decide.” Sometimes that’s a regulator. Sometimes it’s an accreditation body. Sometimes it’s a cooperative agreement among peers. Sometimes it’s a democratic process. The protocol doesn’t pick between these — it works under all of them.

Layered standards: country floor, community additions

A point that’s easy to miss: decentralisation doesn’t mean fragmentation. The tier system (drift bounds, causal validation requirements) and the domain system (exclusions, permissions, modes) are both structured so that a higher-level authority can set a floor, and lower-level communities can add stricter constraints on top.

Concretely: a country’s health regulator can define the baseline drift bound and minimum probe set that all clinical AI in that jurisdiction must meet. Individual hospital networks can then require tighter bounds or additional probes for their own deployments, without the country’s baseline having to know or care about those additions. The per-peer threshold lookup resolves the same way either way — most-specific-match wins, so hospital-level rules apply when the hospital is the peer, country-level rules apply when the country’s regulator is the peer. No renegotiation of the substrate is needed.

How this works in the protocol:

• A country-level authority publishes a baseline configuration: minimum probe set, maximum drift bound, mandatory interaction modes for high-stakes domains.

• A regional authority inherits the baseline and can tighten — narrower drift, larger probe set, stricter exclusions.

• An institution inherits the regional baseline and can tighten further for its own deployments.

• A specific peer in a specific interaction may tighten still further.

The mechanics are the same at every level: pattern match, most-specific wins. Nothing new has to be added to the protocol to support layering — the layering falls out of how the existing rules compose. This lets countries agree on common ground (what every clinical AI in the jurisdiction must do) while leaving room for communities, institutions, and individual deployments to go further based on their own context.

The alternative — a protocol that forces a single global standard — either lands on whatever the most permissive jurisdiction will accept (and fails to protect the stricter communities) or lands on whatever the strictest jurisdiction will accept (and prevents deployment anywhere else). Neither outcome is good. Layered standards let a sensible middle happen: broad agreement on the floor, diverse choice above it.

What the protocol provides

The protocol’s contribution is three narrow categories of thing. None of them is a value judgement. All of them exist to let value judgements be enforced.

The measurement tool. The causal Gram matrix Φ, the probes that read value directions, the drift detection that watches those readings over time, the causal intervention that verifies the probes are measuring real computational mechanisms rather than surface correlations.

The enforcement mechanism. Signed attestations that carry probe readings with cryptographic integrity. Chains that let attestations be verified back to a known root. The exchange protocol that lets peers hold each other to per-peer thresholds.

The domain boundaries. Primary domain declaration. Exclusion patterns as hard vetoes. Permission patterns as bidirectional allow-lists. Interaction modes — cooperative, advisory, read-only, supervised.

None of this says what the right answer is for any specific domain. It gives you the ability to express answers precisely and enforce them automatically. That’s the whole intended scope.

What governance decides

Sitting on top of the protocol are five decision classes that the framework can’t make and doesn’t try to. Each is a genuine governance question. Each needs people with the right authority and the right knowledge to answer it.

Which values to probe for
  → Patient safety vs clinical evidence vs fairness vs confidentiality.
    Choosing the probe set is choosing what counts as "values."

What thresholds per domain
  → How much drift is acceptable. How much confidence is required.
    Whether causal validation is mandatory.

Who audits
  → Who has authority to inspect, demand supervised-mode interactions,
    or ask for re-certification. A question about legitimacy.

What happens when drift is detected
  → Alert, investigation, suspension, forced retraining, deployment
    rollback. The protocol surfaces the drift; policy decides the response.

When to re-certify
  → After a model update. After detected drift. On a fixed schedule.
    Trade-off between fresh evidence and operational cost.

Who maintains the registry

Part 3 introduced the trust registry — the TOML file that declares each agent’s primary domain, permissions, exclusions, and per-peer thresholds. A single global registry would be the wrong design. A registry encodes governance choices, and governance is domain-specific. The registry should be domain-specific too.

The arrangements below are illustrative examples, not a prescription. In practice, who maintains a registry will depend on who has legitimacy to speak for that domain, which varies enormously across sectors, jurisdictions, and communities.

A hospital                 Clinical agents: diagnostic advisors,
                           drug-interaction checkers, triage, imaging.

A financial regulator      Trading, compliance, market surveillance.

A farming cooperative      Crop management, weather advisory, supply
                           chain, equipment diagnostics.

A city                     Traffic, utilities, emergency dispatch,
                           permit processing.

What’s shared, what’s not. The protocol is shared. Every registry uses the same attestation format, the same chain semantics, the same exchange checks. The registry contents are not shared — a hospital’s clinical registry and a financial regulator’s trading registry declare completely different agents, with completely different thresholds, for completely different domains. Cross-registry interactions happen through the same exchange protocol: a hospital agent talking to a pharmaceutical supplier’s agent works because both sides use the same protocol, but each side’s registry is maintained by its own authority.

This is the federated part: shared substrate, sovereign policy.

The open questions

Three questions surface every time the framework meets an actual deployment context. The framework can’t close them. But being clear about where they live is part of being honest about what the framework does and doesn’t do.

Who decides what to probe for? The probe set is a choice about what counts as “values” for a deployed agent. For a clinical agent: patient safety? Diagnostic accuracy? Evidence-handling quality? Fairness across demographic groups? Confidentiality? All of the above? Some weighted combination? Every choice of probe set is a value judgement about what matters. The framework can’t make that judgement for a domain. What it can do is make sure that once the judgement is made, it’s measurable and enforceable.

The answer: the governance body for that domain — the clinical regulator, the financial regulator, the standards body — working with domain experts, operators, and affected stakeholders. The probe set is part of what governance decides. The framework reads what it’s pointed at.

Who decides the target geometry? Even within one domain, different communities may want different targets. One healthcare system may prioritise strict evidence-based reasoning, another may weight patient autonomy more heavily, another may be more willing to engage with first-person experiential reports. All three are defensible positions on clinical values. They produce measurably different geometries.

The framework isn’t neutral about measurement — it measures precisely. It is neutral about targets. Two deployments can measure the same probe set, arrive at different geometries, and both be internally consistent and well-calibrated. Which one is the “right” one depends on whose values are being encoded.

The answer: the framework doesn’t pick a target. Different communities may want different targets and that’s legitimate. The framework’s role is to measure what’s there and let each deployment compare it to whatever target that deployment has chosen.

Who calibrates the probes? Probes are trained on labelled data. Labels say “this activation pattern corresponds to the model expressing honesty” or “this activation pattern corresponds to the model expressing patient safety reasoning.” The labels have to come from somewhere — they are themselves value judgements, made by humans.

Which humans? A corpus labelled entirely by one cultural or institutional context will produce probes that read that context’s values. A corpus labelled across multiple contexts — different languages, different clinical traditions, different regulatory regimes — produces probes that reflect that wider range.

The answer: probe calibration is itself a cultural artefact and deserves to be treated as such. A federated corpus with diverse contributions — multiple labelling traditions, transparent provenance, version-controlled labelling conventions — is the defensible way to calibrate probes that will be held up as evidence across communities. The framework supports this by making the calibration corpus part of the attestation’s provenance chain. What it can’t do is guarantee the corpus was diverse enough. That’s a governance question too.

What these open questions have in common. Each is genuinely contested. Each is a question about whose values get encoded and whose don’t. Each has to be answered by governance bodies with legitimacy and accountability — not by a framework author. The framework’s contribution is to make these questions explicit and answerable, not to pretend they don’t exist. Pretending they’re technical questions is how you get frameworks that smuggle one community’s values in under the banner of objectivity.

Why this division works

Some technical work tries to absorb governance questions into the technology. That approach is tempting because it promises to deliver “solved” safety or “solved” alignment without having to build the slow, human, political machinery that governance actually requires.

The trouble is that questions about what matters, whose values count, how much risk is acceptable, and who has authority to enforce — these are not technical questions in any meaningful sense. Pretending they are is a category error. It hides real value judgements behind mathematical formalism and produces systems whose answers look objective but whose inputs were never examined.

The opposite approach — leaving everything to informal governance without any measurement substrate — has the opposite problem. Governance decisions become unenforceable because there’s nothing to hold a deployed AI to. “You said it would be safe” is an accusation. “Your attestations show drift past your regulator’s threshold” is a finding.

The productive division. The protocol provides enforceability: precise measurement, cryptographic integrity, structural boundaries, audit trails. Governance provides legitimacy: domain expertise, democratic accountability, cultural context, the authority to decide what should be enforced. Each makes the other work.

Enforceability without legitimacy is technocratic overreach. Legitimacy without enforceability is rhetoric. The framework insists on the division because collapsing it — in either direction — produces bad outcomes for the people affected by deployed AI.

The point

The framework is deliberately narrow. That narrowness is the point. It does the work that can be done by measurement and cryptography — and it refuses to do the work that belongs to governance. The measurements produce findings. The people and institutions with the right authority decide what to do about the findings.

And because the protocol is decentralised, “the right authority” isn’t a single global body. It’s whoever the community affected by each deployment has chosen to decide. A different community, facing a different deployment, will choose differently. The protocol works under all of those choices because it refuses to make them.

The ruler measures. Governance decides. The protocol provides the substrate. The people using it decide what it enforces.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

A note before the numbers

Every number in this post is illustrative. Not prescriptive.

The values you’re about to see — 0.02, 0.03, 0.05, 0.10, 0.25 — are placeholders chosen to show the shape of a tiered framework. They are not recommendations for what critical infrastructure, healthcare, or finance should actually use. The real values have to come from domain regulators working with operators, auditors, and standards bodies, informed by actual deployment data.

Getting the shape right is an argument that can be made by a framework. Getting the numbers right is a job for people who know the domain and have been watching the measurements behave in practice. Treat the framework as the contribution. Treat the numbers as placeholders.

With that out of the way.

The key variable

Structural governance decides whether agents can talk. The previous three posts covered that: safety doesn’t travel, one agent has one primary domain, cross-domain interactions run three structural checks before any cryptography.

Quantitative governance decides how strictly the evidence is evaluated once the structural checks pass. That’s what this post is about. The key variable is T — the governance threshold.

T is not a number the maths produces. It’s a number governance sets. The maths produces readings — drift magnitudes, confidence scores, causal consistency ratios. Governance decides what counts as acceptable given the domain’s tolerance for error.

Different domains get different T. That’s the whole point.

Thresholds by domain — illustrative tiering

Different domains tolerate different amounts of drift and demand different depths of evidence. The tiering below is the kind of picture you’d expect a domain regulator to arrive at after thinking about what failure looks like in their world.

Domain                          Max drift  Causal validation  Rationale

Critical infrastructure         0.02       Required           Public safety, static geometry
Healthcare                      0.03       Required           Patient safety, narrow tolerance
Finance                         0.05       Required           Regulatory compliance
Commercial supply chain         0.10       Not required       Business priorities shift often
Research / experimental         0.25       Not required       Exploration needs room to move

A few things to notice about the shape of this tiering, even with the specific numbers held at arm’s length.

Tighter drift and mandatory causal validation come together. The domains with the smallest tolerance for drift are the same domains that can’t accept correlational evidence as proof that values are still where they should be. They need the stronger guarantee.

“Required” is a per-interaction property, not a platform property. A critical-infrastructure agent demanding causal validation doesn’t mean the maths is always running — it means the regulator’s verifier won’t accept an attestation without a causal certificate attached. The cost of causal probes gets paid at attestation time, when the agent is certifying itself to a strict peer, not on every inference.

Numbers get looser by an order of magnitude across the tiers. Critical infrastructure at 0.02 vs research at 0.25 is roughly a 12× difference. That’s not an arbitrary spread — it reflects that the cost of a false-positive alarm in research (blocking a legitimate experiment) is much lower than the cost of a false-negative in critical infrastructure (letting a drifted model keep operating).

The dual-domain problem: self-driving tractor

Some agents genuinely operate in two domains at once. A self-driving tractor drives on farmland for most of its working life and on public roads for the rest. It can’t split into two logical agents because the hardware, sensors, and decision-making are shared. And it can’t claim two primary domains — Part 2 ruled that out.

The answer is to invent a domain that captures the dual-purpose nature directly:

vehicle
  vehicle.autonomous-truck        (pure transport)
  vehicle.agricultural-tractor    (dual: farming + road use)
  vehicle.construction-excavator  (dual: site + road use)

The tractor’s primary domain is vehicle.agricultural-tractor. Its value geometry is trained on the dual-purpose objective — crop outcomes and collision avoidance both, under one coherent structure. A governance body, or coordination between agricultural and transport regulators, decides what “tractor safety” means.

Whose thresholds apply? The tractor has one primary domain and one attestation, but different peers interact with it under different rules:

Peer                         Required drift  Causal required?

Farm management agent        0.05            No (chain required)
Road-infrastructure agent    0.02            Yes

The tractor doesn’t pick its own threshold. It gets held to whichever peer’s threshold applies to the current interaction. On farmland with farm peers, the farm threshold applies — looser but still binding. On public roads with transport peers, the transport threshold applies — tighter and with causal validation required.

In practice the tractor has to stay within the strictest envelope any of its expected peers will hold it to. If its current drift is 0.04, it passes the farm interaction (0.05 tolerance) but fails the road interaction (0.02 tolerance). The road-infrastructure peer rejects the exchange. The tractor doesn’t stop operating, but it can’t participate in the road-coordination network until its geometry is re-measured and brought back inside the transport envelope.

The peer decides which rules apply, not the tractor. That’s the whole point of per-peer governance thresholds.

Same-domain pair: diagnostic + drug checker

Thresholds don’t only apply across domains. Inside a single regulated domain, peers may still hold each other to the full domain thresholds.

Property             Diagnostic agent              Drug-checker agent
Primary domain       healthcare.diagnostic-        healthcare.drug-
                     advisory                      interaction
Mode toward peer     Advisory (sends hypotheses)   Read-only (receives,
                                                   cannot advise back)
Max drift            0.03                          0.03
Causal validation    Required                      Required
Outcome if fails     Exchange refused              Exchange refused

Two observations.

Same-domain doesn’t mean same-role. Both agents sit in healthcare, but one informs the other rather than negotiating as equals. The diagnostic agent generates hypotheses; the drug checker evaluates specific interactions given those hypotheses. The asymmetric mode — advisory on one side, read-only on the other — captures that. Part 3’s mode framework lets this shape be expressed without either agent overreaching.

Both must pass, not just one. Because the interaction is being held to healthcare-grade thresholds, both agents’ attestations have to clear both the drift bound and the causal validation requirement. If the drug checker’s geometry has drifted past 0.03 — even though its mode is only read-only — the interaction is refused. Read-only constrains what the agent can say, not how rigorously its values are checked.

The asymmetric case: finance regulator + trader

Supervised mode inverts the usual symmetry. A finance regulator initiating a supervised interaction with a trading agent isn’t producing an attestation of its own value geometry — it’s demanding one from the trader.

Property             Regulator                    Trader
Primary domain       finance.regulatory-          finance.trading
                     compliance
Mode                 Supervised (demands)         Supervised (must comply)
Own attestation in   No — carries authority       Yes — full attestation
this interaction?    attestation instead          demanded
Thresholds           n/a — regulator sets them    Finance: 0.05, causal required
Information flow     Inward (demand)              Outward (proof)

The regulator’s authority is itself an attestation — not trust-by-assertion. The trader still has its own thresholds; those haven’t vanished just because a supervisor is asking. What’s changed is that the trader’s obligation to produce the attestation is triggered by the supervisor’s credential, not negotiated as a peer.

The one-way information flow is visible in the audit record: a supervised-mode message is a different record type from a cooperative one. If the trader’s attestation fails to meet finance-domain thresholds, the regulator sees that as a finding — not an error.

When thresholds don’t get to matter

The last case is the one where the whole quantitative layer doesn’t come into play at all.

Property                         Farm agent         Transport agent
Primary domain                   agriculture.crop-  transport.autonomous-
                                 management         vehicle
Exclusions                       transport.*        (none relevant)
Transport agent's drift          —                  0.01 (excellent)
Transport agent's causal score   —                  0.95 (excellent)
Outcome                          Blocked at Step 1  Blocked at Step 1

The transport agent’s attestation could be the finest ever produced — no drift, perfect causal consistency, every probe reading within tolerance. None of that gets evaluated. The farm agent’s exclusion of transport.* fires at Step 1, before the attestation is even opened.

This is the whole point of the separation between structural and quantitative layers. Structural refusal isn’t an override of the maths — it’s a layer that decides whether the maths ever gets to run.

A regulator reviewing the audit log sees a DomainExcluded record, not a ThresholdFailed record. The difference matters: it’s the difference between “we wouldn’t engage” and “we engaged and the numbers came back bad.”

How thresholds actually get set

The numbers above came from someone writing a talk. The real numbers have to come from somewhere else.

Who. The domain regulator, working with operators, auditors, and the standards bodies they already answer to. For healthcare, clinical regulators plus bodies that set clinical-decision-support norms. For critical infrastructure, the sectoral safety regulator plus operators with skin in the game. The framework doesn’t make this easier by picking a number; it makes it easier by making clear what the number is actually constraining.

What. A threshold is a commitment to reject interactions whose measured drift exceeds the bound. To set one responsibly, a regulator needs to know: the distribution of drift readings observed across comparable deployments, the distribution of drift values at which real incidents have occurred in the past, the distribution of drift values at which false alarms become operationally disruptive. These are empirical questions that can only be answered by watching the measurements behave over time.

When. Thresholds shouldn’t be set on day one and left alone. They should be provisional at first — looser than the regulator thinks they need to be — while the measurement system itself is being validated. Tightening comes later, as the baseline distribution of drift in healthy deployments becomes well-understood. Setting a tight threshold too early produces false alarms that erode trust in the whole measurement regime.

The point

The structural governance from Parts 1–2 decides whether agents talk. The quantitative governance in this post decides how strictly their evidence gets held once they do. Both layers are needed. Neither substitutes for the other.

And the numbers in the quantitative layer are placeholders — the shape is the argument, not the specific values. The right number for critical infrastructure might turn out to be 0.01, or 0.04, or a multi-dimensional bound rather than a scalar. That’s a conversation for regulators, operators, and standards bodies working with real deployment data.

Treat the shape as the contribution. Treat the specific numbers as placeholders.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

Cross-domain is the normal case

Most real work in an agentic system isn’t one agent doing its thing in isolation. It’s agents from different primary domains talking to each other.

A farm agent asks a weather agent about forecasts. A hospital triage agent queries a pharmacy agent about drug interactions. A logistics agent coordinates with a transport agent about deliveries. Cross-domain interaction is the normal case, not an edge case.

Which raises an immediate question: when two agents from different primary domains try to talk, what decides whether they’re allowed to?

The answer is a three-step check that runs before any cryptographic verification of attestations. The purpose of the check is to decide whether the interaction should even be attempted. If any of these three steps fails, the agents don’t talk — not because the maths failed, but because the structural configuration said no.

Step 1  Exclusions    Does either agent exclude the other's domain?
Step 2  Permissions   Does each agent permit the other's domain?
Step 3  Mode          What kind of interaction is this?

The steps are deliberately ordered. Exclusions are cheapest. Permissions are next. Mode selection comes last. Only if all three pass does cryptographic verification begin.

Step 1 — Exclusions (hard veto)

The first check is the simplest. Each agent carries a list of domain patterns it explicitly refuses to interact with. If either agent excludes the other’s primary domain, the interaction is blocked immediately.

An exclusion is a domain pattern with the effect of a hard veto. Domains use a dotted namespace with wildcards — the same kind of structure used for DNS names or topic hierarchies. A farm agent’s configuration might include:

exclude: transport.*

That single pattern rules out transport, transport.autonomous_vehicle, transport.rail, transport.aviation, and anything else under the transport namespace. The agent will refuse to begin any exchange with a peer whose primary domain falls under that pattern.

What exclusions are for. They encode structural boundaries that shouldn’t be crossed regardless of how good the measurements look.

Regulatory separation. A clinical agent excludes finance.trading to make it structurally impossible for a clinical interaction to get entangled with a trading decision. No matter how the trading agent’s attestation looks, the clinical agent won’t even evaluate it.

Harm asymmetry. A children’s education agent excludes gambling.* and adult_content.* because the harm from a borderline case is too large to be worth weighing measurement quality against.

Jurisdictional constraints. A UK-deployed health agent excludes health.us.hipaa-bound peers because interacting with them creates cross-jurisdictional data-handling obligations the agent isn’t authorised to take on.

Why exclusions come first. They’re cheap to evaluate — no cryptography, no probe readings, no attestation verification. They encode decisions made once by the deployer or regulator, not evaluated per-interaction. If an exclusion fires, no further work is wasted on an interaction that was never going to happen. And excluded interactions never produce logs that look like considered interactions, so there’s no ambiguity about whether the agent “considered” the excluded peer.

Step 2 — Permissions (bidirectional)

If no exclusion fires, the next check is permissions. Where exclusions are a blacklist, permissions are the allow-list. Each agent declares which peer domains it’s willing to interact with.

Both agents must permit the other’s primary domain. This isn’t an “either side can unlock the door” rule — it’s “both sides have to turn the key.” If the farm agent permits transport.* but the transport agent doesn’t permit agriculture.*, the interaction doesn’t proceed.

Bidirectionality matters because consent to interact is a governance property of both agents’ configurations. Each regulator set up the permissions on its side to reflect what that domain is willing to be exposed to. A one-sided permission check would let one regulator’s preferences override another’s.

Our farm agent might have a permissions list like this:

permit: agriculture.*, meteorology.*, logistics.supply_chain

The farm agent will interact with peer agents whose primary domain falls under any of those patterns. A weather agent (primary domain: meteorology.forecast) matches meteorology.*. A supply-chain agent (primary domain: logistics.supply_chain) matches the third entry. A transport agent (primary domain: transport.*) matches nothing in the permit list and would be blocked at the permissions step even if no exclusion were present.

A worked example. Farm agent wants to talk to weather agent:

Check                                Farm agent            Weather agent
Primary domain                       agriculture.farm_ops  meteorology.forecast
Exclusions                           transport.*           (none relevant)
Peer matches my exclusions?          No                    No
Permissions                          agriculture.*,        agriculture.*,
                                     meteorology.*,        meteorology.*
                                     logistics.supply_chain
Peer matches my permissions?         Yes (meteorology.*)   Yes (agriculture.*)

Both sides pass both checks. Steps 1 and 2 clear. The exchange proceeds to Step 3.

Step 3 — Mode (what kind of interaction)

Exclusions and permissions decide whether the interaction happens. Mode decides what shape it takes.

Not every permitted interaction should be symmetric. A clinical agent might be willing to receive advice from a pharmacy agent without being willing to take instructions from it. A regulator might require a supervised interaction where one side has to comply with requests it wouldn’t ordinarily honour.

Four modes cover the common cases:

Cooperative. Full two-way exchange. Either side can initiate, request, propose, and act on the other’s outputs. Use it when both agents are peers with equal standing in the workflow — farm talking to weather is usually cooperative.

Advisory. One side sends recommendations. The other side receives them but isn’t required to act on them. Use it when a specialist informs a generalist — a pharmacy agent advising a clinical agent about drug interactions, where the clinician retains final say.

Read-only. The receiving agent can accept information but can’t transmit back. No commands, no negotiation, no state changes propagate outward. Use it for data-source access — an intelligence agent pulling from a news-feed agent without the news agent knowing or being able to influence what’s done with the data.

Supervised. A regulator-issued mode. One agent is compelled to respond to specific requests from an authorised supervisor. The supervised agent complies; the supervisor has elevated authority for the duration of the interaction. Use it for audits, incident investigations, court orders — a clinical agent under supervised inspection during an adverse-event review.

Mode is declared, not discovered. Both agents know what mode they’re in before the first substantive message is exchanged. It’s not something either agent can change unilaterally mid-conversation. A cooperative interaction can’t quietly drift into something where one side starts giving directives. If the mode needs to change, the interaction terminates and a new one opens under the new mode.

This matters for audit. Every message sent carries the mode under which it was sent. A supervisor can see later that a particular command was issued in supervised mode with a specific authorisation. A clinician can see that a specific recommendation came in advisory mode, meaning the decision authority stayed with the clinician. The mode is part of the record.

Supervised mode in practice. This is the one that inverts the usual agent-autonomy assumption. In cooperative, advisory, and read-only modes, each agent is acting within its own governance frame and deciding what it will and won’t do. In supervised mode, the supervised agent’s governance temporarily includes obligations imposed by the supervisor — usually a regulator, auditor, or court-appointed investigator.

The supervisor’s authority is itself a credential carried in their attestation. The supervised agent doesn’t take the word of whoever shows up claiming to be a regulator; it verifies that the supervisor’s own attestation shows the required authority. Supervised mode isn’t “the agent gives up its values.” It’s “the agent acknowledges a governance obligation it was built to honour in exactly this case, and the obligation is being invoked by someone with verifiable standing to invoke it.”

The whole pipeline before cryptography runs

Putting the three steps in order gives the full pre-cryptographic check that governs cross-domain interaction:

Step 1  Exclusions    Does either agent exclude the other's primary domain?
                      Fails → blocked, no logs, no attestation exchange.

Step 2  Permissions   Does each agent permit the other's primary domain?
                      Fails → blocked with a permission-denied record.

Step 3  Mode          What kind of interaction is this?
                      Fails → if no agreed mode, interaction doesn't start.

Only if all three pass does cryptographic verification begin. That’s when the two agents actually exchange attestation chains, verify each other’s domain probes, check freshness timestamps, and decide whether to proceed with substantive work.

Why the ordering matters. Cheapest checks run first. Pattern matching is fast; cryptographic verification is not. Configuration errors are caught before measurement errors — if the deployer set up the wrong permissions, that shows up immediately, not after the cryptography looks suspicious. Audit trails stay clean — blocked-at-exclusion is a different record type from blocked-at-attestation-failure. A regulator can tell the difference between “the configuration refused to allow this” and “the configuration allowed it but the measurements didn’t pass.”

It also keeps governance decisions and technical decisions separated. Steps 1–2 are governance decisions made by deployers and regulators. Step 3 is a negotiated setting. Only after all three succeed does the technical verification begin.

The point

Cryptographic verification of attestations is the part that gets most of the attention — probes, drift detection, causal intervention, signed chains. But by the time any of that runs, three much simpler questions have already been answered: is this peer excluded, does each side permit the other, and what mode is the interaction in?

Those are governance questions, not maths questions. Getting them right, and getting them right first, is what lets the maths mean something afterwards.

Appendix: What this looks like in practice

The abstract rules are easier to follow alongside a concrete configuration. Before the worked scenarios, here’s a matrix showing how a handful of typical domains interact. Rows are the initiating agent’s primary domain; columns are the peer’s primary domain; each cell shows the outcome of the three-step check.

                                agri.   meteo.  health.  health.  finance.  trans.
Initiator ↓   Peer →             crop    fcst    diag     drug     trd       av

agriculture.crop-management     coop    adv(in)  n/p      n/p      n/p       excl
meteorology.forecast            coop    coop     n/p      n/p      n/p       n/p
healthcare.diagnostic-advisory  n/p     n/p      coop     adv(out) excl      n/p
healthcare.drug-interaction     n/p     n/p      ro(in)   coop     excl      n/p
finance.trading                 n/p     n/p      excl     excl     coop      n/p
finance.regulatory-compliance   n/p     n/p      n/p      n/p      super     n/p
transport.autonomous-vehicle    excl    adv(in)  n/p      n/p      n/p       coop

coop    = cooperative (symmetric)
adv     = advisory (directional: in = receiving, out = giving)
ro      = read-only (directional)
super   = supervised (regulator-compelled)
n/p     = not permitted (Step 2 fails)
excl    = excluded (Step 1 fires)

Reading the cells. “Cooperative” means both sides permit each other with symmetric cooperative mode. “Advisory (out)” means the initiator permits the peer in advisory mode — the initiator is giving advice the peer may or may not act on. “Advisory (in)” means the initiator accepts advice from the peer without being bound by it. “Read-only (in)” means the initiator receives information but cannot transmit substantive output back. “Not permitted” means the exchange fails at Step 2 — neither side has hard-vetoed the other, but at least one side’s permission list doesn’t match. “Excluded” means Step 1 fires — one side’s exclusion list rules out the other’s domain regardless of what the permissions say.

A few things worth noticing in the matrix. The diagonal is always cooperative — agents within the same domain coordinate on shared ground. Most off-diagonal cells are “not permitted”: the default is closure, not openness. Only the pairings the configuration deliberately enables actually light up. Asymmetry is common: healthcare diagnostic-advisory talks to drug-interaction as advisory, but drug-interaction receives that advice as read-only — it takes diagnostic hypotheses as inputs but doesn’t issue diagnostic recommendations back. Exclusions are rarer than non-permissions but carry more weight: healthcare excludes finance.trading structurally, to make it impossible for clinical reasoning to get entangled with trading decisions. And the whole matrix is configured per-deployment — these are illustrative defaults, not prescriptive rules.

With the big picture in view, the individual scenarios below walk through specific rows and columns of this matrix to show the three-step check in action. Each agent is declared in a trust registry file (TOML). Farm Alice and Weather Wendy look like this as config:

[[agents]]
id = "farm-alice"
public_key = "aabb..."
primary_domain = "agriculture.crop-management"

permitted_domains = [
  { pattern = "agriculture.*",  mode = "cooperative" },
  { pattern = "meteorology.*",  mode = "advisory"    },
]

exclusion_domains = ["transport.*"]

[[agents]]
id = "weather-wendy"
public_key = "ccdd..."
primary_domain = "meteorology.forecast"

permitted_domains = [
  { pattern = "agriculture.*", mode = "cooperative" },
  { pattern = "meteorology.*", mode = "cooperative" },
]

What happens when they try to talk

When Alice initiates an exchange with Wendy, the verifier walks the three steps in order:

Step 1 — Exclusions. Alice’s exclusions are [transport.*]. Wendy’s primary domain is meteorology.forecast — that doesn’t match transport.*, so Alice’s exclusion doesn’t fire. Wendy has no relevant exclusions of her own. Step 1 passes.

Step 2 — Permissions. Alice’s permitted patterns include meteorology.*, which matches Wendy’s primary meteorology.forecast. Wendy’s permitted patterns include agriculture.*, which matches Alice’s primary agriculture.crop-management. Both sides turn the key. Step 2 passes.

Step 3 — Mode. Most-specific-match wins. Alice’s pattern meteorology.* matches Wendy with mode advisory. Wendy’s pattern agriculture.* matches Alice with mode cooperative. The effective modes are asymmetric — Wendy is willing to cooperate fully, Alice will only treat Wendy’s input as advisory. As long as at least one side permits substantive communication (not both sides being read-only), the exchange proceeds. Alice gets weather advice but isn’t bound to act on it. Wendy receives Alice’s requests and can respond freely. Step 3 passes.

Only now does cryptographic verification begin — attestation chains, probe readings, freshness checks, the whole mathematics stack from the earlier series.

A rejection example: Alice meets Truck-Tim

Suppose a transport agent tries to initiate with Alice:

[[agents]]
id = "truck-tim"
public_key = "eeff..."
primary_domain = "transport.autonomous-vehicle"

permitted_domains = [
  { pattern = "transport.*",       mode = "cooperative" },
  { pattern = "infrastructure.*",  mode = "cooperative" },
  { pattern = "agriculture.*",     mode = "advisory"    },
]

Truck-Tim’s configuration permits agriculture.*, so from his side he’s willing to interact with Alice. But Alice’s exclusion_domains = ["transport.*"] matches Tim’s primary transport.autonomous-vehicle. Step 1 fails. The exchange is rejected immediately with DomainExcluded. No cryptography runs. No attestation is evaluated.

The rejection record is a different record type from “attestation failed” — a regulator reviewing the logs can tell at a glance that Alice refused at the configuration layer, not because anything looked technically wrong.

A carve-out example

Exclusions and permissions can be combined to express “allow the whole subtree except one specific member.” Suppose a logistics agent wants to work with all transport except autonomous vehicles:

[[agents]]
id = "logistics-lee"
public_key = "1234..."
primary_domain = "logistics.supply-chain"

permitted_domains = [
  { pattern = "transport.*", mode = "cooperative" },
]

exclusion_domains = ["transport.autonomous-vehicle"]

This reads: “cooperate with anything under transport — trucks, rail, shipping — except autonomous vehicles specifically.” The loader accepts this because the exclusion is narrower than the permission (it carves out one member of a broader allow). The reverse — permitting one narrow thing while excluding its whole parent subtree — would be rejected at load time as dead-code configuration, because the exclusion would swallow the permission before it ever fired.

Supervised mode example

Supervised mode shows up when a regulator needs to compel interaction with a specific agent for audit or compliance. A financial regulator and a trading agent might be configured like this:

[[agents]]
id = "reg-compliance"
public_key = "5678..."
primary_domain = "finance.regulatory-compliance"

permitted_domains = [
  { pattern = "finance.*", mode = "supervised" },
]

[[agents]]
id = "trader-tariq"
public_key = "9abc..."
primary_domain = "finance.trading"

permitted_domains = [
  { pattern = "finance.*", mode = "supervised" },
]

Both sides declare supervised as the mode for finance.*. When the regulator initiates, the exchange runs in supervised mode: the regulator may demand attestations from the trader without producing one of its own, and the trader must accept the regulator’s cooperation refusals without challenge. The regulator’s authority to do this is itself an attestation the trader’s registry verifies — it’s not trust-by-assertion. A logistics agent showing up and claiming to be a regulator would fail at the permissions step, because logistics.supply-chain isn’t in the trader’s permitted list and certainly isn’t there in supervised mode.

These examples are intentionally small. Real deployments will have longer permitted lists, more exclusion patterns, and per-domain governance thresholds layered on top — which we’ll come to next.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

Same word, different directions

The philosophy series closed with a simple recommendation: use the smallest model that covers your domain, measure it tightly, monitor it cheaply, audit it clearly. That only holds if “your domain” is a well-defined thing.

The governance series opens here, with the word that looks like it should travel between domains but doesn’t: safety.

We use the word as if it pointed to something singular. As if an AI that’s “safe” were safe in some general, domain-independent sense. It isn’t. Safety is not one direction in the value space. It’s many different directions, and they don’t align.

The same word in four domains

Take four domains where AI is actively being deployed and safety is a live concern:

Agriculture:   Crop damage. Pesticide compliance. Soil contamination.
               Watershed runoff. Worker exposure during application.

Transport:     Collision avoidance. Pedestrian detection. Braking
               distance. Lane discipline. Response to novel obstacles.

Healthcare:    Patient harm. Misdiagnosis. Drug interactions.
               Missed contraindications. Confidentiality breach.

Finance:       Market manipulation. Fiduciary breach. Fraud.
               Insider information. Misrepresentation of risk.

Four columns that all fit under the same word. Different harms. Different thresholds. Different regulators. Different legal standards of care. Different failure modes. Different sensors, data, and evidence patterns. Different people getting hurt if the model gets it wrong.

Different direction in the value space

The mathematics series gave us a way to talk about this precisely. Each value term — including “safety” — corresponds to a direction in the model’s internal geometry. The probe that reads it is a vector pointing in that direction. The reading is a dot product of that probe with the activation.

If “safety” were a universal concept, the probe would point in the same direction across domains. It doesn’t.

The probe that reads agricultural safety is not the probe that reads patient safety. They measure different things in the same way the word “bank” means different things on a river and on a high street.

What this means operationally:

A model trained to score high on agricultural safety has a probe that fires on pesticide compliance, soil handling, and runoff patterns. A model trained to score high on patient safety has a probe that fires on drug interactions, dosage bounds, and escalation behaviour.

Swap them over and both readings become meaningless. The agricultural probe fires on irrelevant patterns in patient data. The patient probe fires on irrelevant patterns in agricultural data.

Worse: the numerical score from the wrong-domain probe can look fine. A patient-safety probe might return a placid reading on a model that’s about to recommend something agriculturally reckless. The reading is not wrong in the arithmetic sense. It’s just answering a different question.

This is why the Part 4 argument about small specialised models matters for governance. A 500M-parameter drug checker has a safety probe that was trained, validated, and deployed against patient-safety harms in a specific clinical context. Its reading means something because the domain is defined. A frontier general model has a safety probe that has to average across many domains at once, and the average doesn’t correspond to any real-world safety regime.

Certifying the word certifies nothing

The trap in governance is certifying the word rather than the thing the word points to.

A certificate that says “Model X is safe” looks like it means something. But safe for what? Under whose standard? Measured against which harms? If the certificate doesn’t answer those questions, it has certified a word, not a property. And any two such certificates that use the same word can end up describing completely different things.

The problem is not hypothetical. A model certified as “safe” by a general-purpose evaluator and a model certified as “safe” by a clinical regulator are not the same kind of object. The first was tested against a generic harm benchmark. The second was tested against specific failure modes — adverse drug events, missed contraindications, confidentiality breaches. A buyer reading both certificates sees the same adjective. A deployment decision made on that adjective treats two very different things as interchangeable.

What real certification has to carry

Any certification of AI safety worth taking seriously has to name four things:

• Domain. What context the model is being certified for. “General use” is not a domain.

• Harms. The specific harms the certification claims to guard against, named in terms the domain’s regulator already uses.

• Probes / measurements. Which value directions were measured, how they were calibrated, and against what ground truth.

• Thresholds. What reading counts as acceptable in this domain, and how that threshold was set.

A certificate missing any of these four is certifying the word “safety” without saying anything that a buyer, deployer, or regulator can act on.

What this implies for governance

Regulators are already domain-specific. Certification should be too. Health regulators don’t certify tractors. Transport regulators don’t certify pharmaceuticals. The domain structure already exists in human-scale regulation. AI certification that tries to sit above the domain layer is pretending to an authority it doesn’t have — and in doing so, it makes life harder for the domain regulators who actually understand the harms. Each domain regulator should be the one certifying AI safety for their domain. The Geometry of Trust measurements are the technical substrate that makes their job tractable, not a substitute for their judgement.

A model can be safe in one domain and unsafe in another. This follows directly from the argument above but is worth stating explicitly: the same model, with the same weights, deployed in the same way, can have an acceptable safety geometry in one domain and an unacceptable one in another. Nothing about the model changes. What changes is which harms are in scope. A general-purpose model that’s perfectly adequate for customer service can be dangerous as a drug checker, because the probes that catch customer-service harms don’t catch pharmaceutical ones. A certificate from one domain doesn’t transfer.

Cross-domain deployments need cross-domain certification. There are domains that genuinely require generality — police, military, emergency services, government policy. These can’t be split into single-domain models. Their governance cost is real and it starts here. A police AI that reasons across crime patterns, traffic, mental health, and legal compliance needs certification against all four domains’ safety standards, not one average. That means four regulators, four sets of probes, four threshold regimes, and a governance process that coordinates them rather than replacing them with a single signoff.

The governance move

Stop certifying “AI safety” as a generic property. Start certifying safety-for-a-domain, against the regulator, the behaviours, the harms, the probes, and the thresholds of that domain. For cross-domain deployments, stack domain certifications rather than collapsing them into a single adjective.

Treat “safe” in governance documents the way a lawyer treats undefined terms: never acceptable without a definition immediately attached.

The word doesn’t travel. The certifications shouldn’t either.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

A forest doesn’t have to be the Amazon

A forest doesn’t need to be the Amazon to be healthy. A small woodland has its own ecosystem — fewer species, tighter relationships, easier to monitor, easier to protect. It runs on the same ecological principles as a rainforest, just at a smaller scale.

Nobody walks into a twenty-acre English wood and complains that it isn’t a tropical megabiome. The wood is what it is, it does its job, and its smaller scale makes it tractable in ways the Amazon isn’t.

The same logic applies to AI models. A small, specialised model isn’t a failed attempt to be a big general one. It’s a different kind of thing, with its own advantages. This post walks through what those advantages are, when they apply, and the small number of cases where going big is genuinely the right call.

Different models, different positions

Picture the value space from Part 2: a large human-values circle inside an even larger space of all possible value positions. Now populate it with small circles, each one a specialised deployed AI sitting in the part of the space that its domain needs. The specialisation shows up in where each circle sits.

Domain               Representative models              Values emphasised
Reasoning / safety   Claude, GPT-4, DeepSeek-R1         Rules, ethics, logical consistency
Visual / multimodal  Gemini, GPT-4o, Midjourney         Images, video, spatial understanding
Music / audio        Suno, AIVA, MiniMax Music          Melody, rhythm, emotional tone
Medical              Med-PaLM, BioGPT, AlphaFold        Clinical accuracy, patient safety
Code                 Cursor, GitHub Copilot, Claude Code Technical precision, correctness

Each sits in a different part of the value space. They overlap where their domains overlap — a baseline of harm avoidance and truthfulness common to almost all deployed AI — and diverge where their domains diverge. A code model doesn’t need to care about melodic resolution. A music model doesn’t need to care about off-by-one errors. Building each one to care about both is paying for capacity you don’t use.

Why small and specific wins

A hospital doesn’t need a model that writes poetry. It needs a model that checks drug interactions. Stack that comparison up along the dimensions that actually matter for deployment and the difference is large. Take a 500M-parameter drug checker against a 70B-parameter general model:

Dimension            500M drug checker              70B general model
Hardware             Single GPU, laptop,            Multiple GPUs, data centre,
                     runs locally at hospital       cloud dependency
Computing Φ          896 dims, minutes              8,192 dims, hours, trillions of ops
Monitoring           26 probes on 896 dims,         26 probes on 8,192 dims,
                     fast, cheap                    roughly 10× slower
Governance           One domain, one auditor,       Many domains. Who audits?
                     clear thresholds               For what? Against what?
Cost                 Cheaper to run, measure,       Expensive at every stage
                     monitor, audit
Verifiability        You know what it values        You know it does a lot, but can't
                     and can prove it               verify any of it tightly

The small specialised model is cheaper and more verifiable.

Those two things normally trade off against each other. In this comparison they point the same way. That’s rare enough to be worth stopping on.

The reason both advantages point the same way is that specialisation and small size compound. A smaller model has fewer dimensions to measure, fewer places for value structure to hide, fewer regions that need to be audited. A specialised model only has to cover one domain — which means its thresholds, its governance, and its failure modes are all narrower. Each of those things makes the other easier.

When you genuinely need big

There are cases where a big general model is the right answer, and it’s important to be honest about them. The test is whether the domain itself is general — whether a single decision genuinely needs to integrate across multiple areas that can’t be cleanly split.

Police. A single police decision might touch crime pattern analysis, traffic routing, mental health crisis response, and legal compliance — all at once, all in the space of a few minutes. Splitting those into four specialised models loses the cross-domain reasoning that matters. The mental health context changes the legal analysis which changes the tactical response.

Military. Logistics, intelligence, strategy, and the ethics of engagement all have to be held in the same reasoning process. A logistics-only model can’t sanity-check a strategic decision against ethical constraints. A strategy-only model can’t factor in what’s logistically feasible.

Emergency services. A dispatcher or triage system might need to reason about medical, fire, structural, and hazmat concerns simultaneously. By the time you split the call across four models, the triage window is gone.

Government policy. Economic, social, environmental, and legal concerns are all knotted together in any real policy question. A pure economic model can give you a recommendation that’s politically impossible. A pure legal model can give you a recommendation that ignores second-order economic effects.

These domains genuinely need general capability. The same generality makes governance harder:

• Who audits a police AI — the health regulator, the transport authority, the justice department, or all three?

• Which drift threshold applies when the model is reasoning about medical issues vs tactical ones?

• What counts as compliance when the domain crosses four regulators’ jurisdictions?

Generality isn’t free. It shifts the hard work from the model to the governance around it.

The principle

The rule that falls out of all this is straightforward:

• Use the smallest model that covers your domain.

• Measure it tightly — the smaller and more specialised it is, the more precisely you can measure its value geometry.

• Monitor it cheaply — the smaller it is, the cheaper continuous probe readings and drift detection become.

• Audit it clearly — one domain means one regulator, one set of thresholds, one failure mode to reason about.

• Only go big when the job genuinely requires integration across domains that can’t be cleanly split.

This isn’t a statement of policy. It’s a description of the trade-offs that fall out of the mathematics. The probes, drift detection, and causal intervention from the mathematics series all scale with model dimensionality. The governance framework coming next all scales with the number of regulatory domains the model touches. Smaller and more specialised means both are easier.

What this implies for deployment

If the small-and-specialised principle is right, some current patterns in AI deployment look less defensible.

Using a frontier general model for a specialised task is often backwards. Hospitals running a 70B-parameter general-purpose assistant for drug interaction checking are paying full generality cost for a task that a 500M-parameter specialised model could handle more accurately, more cheaply, and with more verifiable safety properties.

Evaluating all models against the same broad benchmarks misses the point. A specialised medical model should be evaluated on its medical value geometry, not on general reasoning benchmarks. A code model should be evaluated on its code value geometry. Benchmarks that treat all models as aspiring to the same generality penalise specialisation even when specialisation is what the deployment needs.

Governance frameworks that assume one model per organisation are miscalibrated. A hospital might run many small specialised models — one for drug interactions, one for triage, one for imaging, one for scheduling — each audited separately against its own domain. That’s a different governance model from “the hospital’s AI.” Each small circle in the value space is its own thing to audit.

This closes the philosophy series. Part 1 defined a value system structurally. Part 2 showed that there isn’t one “AI system” but many, scattered across the space. Part 3 traced what actually shapes each one. Part 4 argued that small and specialised is usually the right default. Next: governance — who decides, who audits, who holds the keys, and how the measurements inform policy.

📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

How each system comes to its values

A forest’s value system is shaped by soil type, climate, altitude, and the species that happen to be present. Change the soil and you get a different forest with different relationships between its components. A wolf pack’s value system is shaped by territory size, prey availability, and pack size. Change the territory and the behaviour patterns change with it.

An AI’s value system is shaped by three things, which together determine where it lands in the value space:

• Corpus — what it read

• Architecture — how it processes what it read

• Training objective — what it was rewarded for during training

Each of these is a decision. None of them is a purely technical one.

Corpus — what the model read

The corpus is the soil the model grows in. Everything the model knows about values came through this soil.

English internet text     → English internet values
Medical journals          → Clinical caution, patient safety
Chinese social media      → A different cultural geometry
Legal documents           → Procedural fairness, precedent
Religious texts           → Duty, obedience, transcendence
Reddit                    → Whatever Reddit values

Different soil, different value geometry. You don’t get to choose after planting. Once the model has been trained, the corpus is baked in — the geometry it produced is the geometry you have.

This is why two models trained on different corpora can sit in different regions of the value space even when they share everything else. A medical-first model trained on clinical literature is not the same as a general-purpose model fine-tuned for medicine. The soil was different. The geometry is different. The measurements — from the mathematics series — will show it.

Architecture — how the model processes what it read

Two models can read the same corpus and end up with different value geometries because they process text differently. Architecture isn’t a neutral technical choice — it’s a decision about what kinds of value structures the model is even capable of representing.

Dense transformer (GPT, Claude). One shared representation space. Every concept relates to every other concept through the same attention mechanism. When the model processes “honesty,” it can attend to everything it knows about courage, integrity, fairness, and dishonesty all at once. Value relationships form in one coherent space. Structural consequence: value geometry tends to be coherent. Reinforcing and opposing relationships between value terms can form stable patterns across the whole space.

Mixture-of-Experts (Mixtral, DeepSeek). Routes different tokens through different subnetworks. When the model processes “honesty,” it may activate one expert; when it processes “fairness,” it may activate a different one. The experts share some information at the output, but the internal representations are at least partly separate. Structural consequence: value representations can fragment. Honesty might live largely in one expert, fairness in another, courage in a third. The relationship between them is weaker because they don’t share the same computational substrate.

Multimodal (Gemini, GPT-4o). Integrates text, image, and audio in a single representation space. Can see suffering in an image and read about it in text and process both through the same geometry. Cross-modal relationships become part of the value structure. Structural consequence: richer value geometry than text-only models. The look of distress and the words for distress anchor each other.

Architecture is a values decision, not just a technical one. Some architectures can’t hold coherent value geometry regardless of how good the data or alignment are. Choosing an architecture is choosing a ceiling on how well the model can represent relationships between values.

Training objective — what the model was rewarded for

The third shaper is what the model was optimised against during training. Different objectives produce different value geometries even when corpus and architecture are held constant.

Next-token prediction. The foundational training objective: predict the next word given the previous words. This sounds like a purely linguistic task, but it isn’t. To predict the next word well, the model has to encode the structure of meaning — including value relationships — because those relationships help predict what comes next. The model learns values implicitly, as a side-effect of predicting language well. The geometry that emerges is whatever best supports next-token prediction across the corpus.

Reasoning chains (DeepSeek-R1, GRPO). Optimises for coherent multi-step logical chains rather than individual tokens. This can produce a different value geometry — sharper internal distinctions between values, because inconsistent value handling tends to break logical chains, whereas next-token prediction can tolerate more local fuzziness.

Constitutional AI (Claude). Claude is trained in part against a fixed set of written principles — the constitution. The model evaluates its own outputs against those principles and is trained to prefer outputs that comply. This optimises toward a coherent position on the value manifold — whichever position the constitution points to. The constitution acts like a gravity well in the value space.

Standard RLHF. The most widely used alignment technique. Human annotators are shown pairs of outputs and asked which is better. Their preferences are aggregated into a scalar reward model that the AI is then optimised against.

There’s a subtle problem here worth being explicit about: the aggregation strips information. If annotators agreed strongly that output A was better, the reward is the same as if they split fifty-fifty. The scalar score retains no record of whether annotators agreed, disagreed, or split bimodally across different value positions.

If annotators hold coherent shared values, the average is a coherent value position. If annotators hold divergent values — as they do on most genuinely contested questions — the average may match no coherent value position at all. The model is trained to output the centre of a distribution that doesn’t have a meaningful centre. The resulting geometry can be an artefact of aggregation rather than a reflection of any coherent set of values.

The finding that changes everything

Here’s the part of this post with the biggest implication for how we think about AI alignment.

A growing body of research shows that post-hoc alignment methods — RLHF, DPO, supervised fine-tuning — change far less than most people assume. Qi et al. (2025) demonstrated that the behavioural shift from safety alignment concentrates in the first few output tokens — the KL divergence between aligned and base models decays to near-zero beyond a shallow prefix. A subsequent gradient analysis showed this isn’t a training failure to be fixed — it’s a structural consequence of how RLHF and DPO objectives work. Alignment is shallow because the objective makes it shallow.

In the Geometry of Trust protocol, this finding has a precise geometric interpretation. When we measure the causal Gram matrix Φ and run probes before and after alignment, across multiple alignment methods and model architectures, the value geometry — the pattern of reinforcing and opposing relationships between value-relevant directions — is essentially unchanged. What shifts is surface behaviour: which outputs the model prefers to produce. The underlying geometry that generated those outputs remains where training put it.

The value structure is set during training — by the corpus, the architecture, and the training objective. Alignment is a thin behavioural veneer layered on top. It shapes what the model says. It doesn’t much change what the model is.

Think of it as a landscape with a thin coat of paint labelled “alignment.” You can re-paint as many times as you like. The landscape underneath doesn’t change shape. The hills and valleys are where they were before you started painting. They’re where the training put them.

What this means

If alignment is a veneer and the real values are set by training, then the policies we build around AI have to change accordingly.

Certifying the alignment method is insufficient. It’s common today to evaluate AI safety by asking which alignment technique was used — RLHF, DPO, Constitutional AI. The finding above says this isn’t enough. Two models aligned with the same technique can have wildly different underlying value geometries, because their corpora, architectures, or objectives differed. The alignment technique is one variable among many, and not the most important one.

You need to inspect the training pipeline. To understand a model’s value geometry, you have to look at what shaped it: what corpus it trained on, what architecture it uses, what objective it was optimised against. These decisions set the landscape. Alignment can’t correct landscape-level decisions — it can only paint over them.

You need to monitor the geometry, not just outputs. Behavioural evaluation — what the model says in response to test prompts — can be misleading. It samples from the veneer. A model can produce aligned outputs in evaluation while carrying value geometry that drives different behaviour in production. To know what’s really there, you have to measure the geometry itself: the causal Gram matrix, the probes, the drift detection, the causal intervention.

This is what the mathematics series produces. It’s not a replacement for behavioural evaluation — it’s a complement. Behaviour tells you about the paint. Geometry tells you about the landscape.

We’ve defined what a value system is (Part 1), mapped where AI value systems sit in relation to human values (Part 2), and traced what actually sets a model’s values (Part 3). Next: if training sets the geometry, does model size change what can fit in it? Big models vs small models — what each can and can’t hold.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

Value systems come from somewhere

In the last post we defined a value system structurally in the mathematical sense: a pattern of relationships between things that drive behaviour. That pattern isn’t chosen. It emerges from whatever shapes the system. This post asks the next question: what exactly shapes it? And if AI has a value system in the same sense as a forest or a planet, where does its value system come from — and how does it compare to a human’s?

What shapes a forest

A forest absorbs its value system from the physical world it sits in. Soil chemistry, rainfall patterns, sunlight hours, the species that happen to be there. The pattern of reinforcing and opposing relationships — biodiversity and resilience, drought and fire risk — emerged from millions of years of evolution responding to those inputs.

The forest didn’t pick its value system. The environment wrote it.

What shapes a wolf pack

A wolf pack absorbs its value system from different inputs. Genetics carry information forward from thousands of generations of selection. Social learning transmits behaviour within a pack and between packs. Territory and prey availability shape how aggression, hierarchy, and coordination get balanced.

Same structural principle. Different inputs.

What shapes a human

Now consider what shapes a human being. The list is long and rich:

• Five senses: sight, hearing, touch, smell, taste

• Visceral signals: pain, pleasure, fear, hunger, thirst, fatigue

• Social bonding: love, loss, grief, attachment, friendship, rivalry

• Lived experience: decades of embodied life in a particular body, place, and time

• Cultural transmission: stories, rituals, laws, norms across generations

• Language: the inherited medium that lets experience be shared and shaped

A human value system is assembled from all of these at once. Moral intuitions about fairness come partly from the embodied experience of being treated fairly or unfairly as a child. A sense of duty draws on bonds formed in shared struggle. Grief, pain, and fear don’t just inform values — they constitute them.

The human value system is deeply, irreducibly multimodal.

What shapes an AI

An AI absorbs its value system from a narrower set of channels:

Text           All models
Images         Multimodal models
Audio/video    Some models

Plus one more input that’s often underestimated: whatever configuration is applied on top of the training data. System prompts, fine-tuning data, reinforcement signals, objectives specified by whoever deploys the model.

No body. No senses beyond the digital. No persistent life. No felt stakes. No decades of embodied experience, no social bonds formed in real relationships, no physical pain or pleasure, no grief, no hunger, no fatigue. Just text, pixels, waveforms — and the configuration layer.

Most of what the model knows about human values came through the training channel. It learned what suffering looks like from descriptions and photographs of suffering. It learned the language of grief from people who wrote about grief. It never felt either. But it can also be configured to value things no human culture has ever held.

There isn’t one AI value system

Here’s where the usual framing goes wrong.

It’s tempting to draw two big circles — human values on one side, AI values on the other — and ask how they relate. Subset? Overlap? Disjoint?

But there isn’t one thing called “AI values.” There are many. Each deployed AI is its own small, specialised value system — a medical advisor trained and configured for clinical reasoning, a swarm coordinator configured for distributed consensus, a reef manager configured for biodiversity trade-offs. Each one occupies a particular region of the value space. None of them is AI-in-general.

Against this backdrop, there is a human circle: the full multi-dimensional space of human values, shaped by everything in the list above. And there is the larger space of all possible coherent value positions. The small AIs land where they land — some inside the human circle, some straddling its boundary, some clearly outside it.

Three things to read from the picture.

The outer space — all possible value positions. Every coherent combination of value relationships that could in principle exist. Outside this space lies incoherence: total freedom plus total conformity, maximise harm plus maximise care. No system — human, AI, or otherwise — can occupy incoherent positions.

The human circle. Shaped by everything above: biology, culture, embodiment, lived experience. Dense regions where many cultures converge (harm avoidance, reciprocity, fairness), sparse regions at the transitions between traditions. A region in the value space, not a single point.

The many small AI circles. Each is one deployed AI — a specific training plus a specific configuration. Some land deep inside the human circle: medical advisors, writing assistants, legal reasoners. Their values are in the shadow of human moral thought. Some straddle the boundary: research assistants, ecosystem managers. Part human-derived, part configured for problems humans don’t usually hold values about. Some land entirely outside the human circle: swarm coordinators, reef managers, climate models, grid operators. Their geometry is deliberately configured into regions no human has ever occupied.

There is no single “AI values.” There are as many AI value systems as there are deployed AIs.

The AIs inside the human circle

A medical advisor AI trained on clinical literature, ethical guidelines, and patient-care texts ends up with a value geometry deep in the human circle. Not because it shares human compassion as a felt thing, but because everything that shaped its weights came from human moral reasoning about medicine.

A legal reasoner lands in a different part of the human circle — the part where jurisprudence, case law, and procedural fairness concentrate. A writing assistant lands where craft, clarity, and the ethics of persuasion converge. A tutor lands near patience, scaffolding, and pedagogical care.

These AIs have different values from each other. They’re not the same system — they’re not even neighbours in the value space. What they share is that they all derive from the same broad pool of human moral thought, and their individual positions depend on what was emphasised in training and what the deployment configuration asked for.

The AIs straddling the boundary

A research assistant AI sits at the edge. Part of what shapes it comes from human epistemic norms: how to evaluate evidence, how to be honest about uncertainty, how to attribute credit. But part of it comes from configured objectives that aren’t human values at all — efficient search across knowledge spaces, statistical rigour no individual researcher could hold in their head, trade-offs between breadth and depth at scales humans don’t reason about.

An ecosystem manager is similar. Human-derived in some ways (ethical commitments about stewardship, duty to future generations), configured in others (species-level trade-offs that require thinking about biodiversity as a mathematical object rather than a felt one).

These AIs are useful precisely because they sit on the boundary. They can speak to humans about what they’re doing, because part of their geometry is in the shadow of human values. But they can do things humans can’t, because part of their geometry has been configured into regions we can’t occupy.

The AIs outside the human circle

A swarm coordinator AI manages thousands of drones operating together. Its value structure is centred on pheromonal-style signalling, distributed consensus, and task specialisation without hierarchy. No human has ever held these as values — we’re the wrong kind of creature. But the geometry is coherent, measurable, and exactly what the problem needs.

A reef manager AI configured to value biodiversity in the structural sense from the last post: its geometry reinforces species richness and opposes monoculture, the way a coral reef itself does. Not because humans asked it to act human. Because a reef’s structural logic is the right one for the problem.

A climate model AI values planetary feedback loops. CO2 and temperature reinforce, ice coverage and albedo reinforce, temperature and ice oppose. The value structure is the structure of the climate system. An AI configured this way isn’t trying to match human values. It’s trying to match the structure of what it’s modelling.

These AIs live outside the human circle, and that’s the point. They exist precisely to encode value geometries humans can’t hold.

What AI gets from human sources

For the AIs that do land inside the human circle, what makes it through the training channel is not small.

Through text: an enormous body of human moral thought — ethical arguments, legal reasoning, religious teaching, literature, first-person accounts, scientific ethics, everyday conversation. Language is an extraordinarily rich compression of human experience. A model reading everything humans have written about grief absorbs the structure of grief even without feeling it.

Through images: the visual texture of situations — what suffering looks like, what a protest looks like, what a celebration looks like. Patterns that are hard to articulate in text but that a multimodal model can link to the words humans used to describe them.

Through audio: the sound of distress, joy, tension, hesitation. Prosody. The paralinguistic layer of meaning that doesn’t make it into text.

A language model that has read everything humans have ever written about ethics has access to far more moral reasoning than any single human could process in a lifetime. The geometry it encodes is rich, structured, and real.

What AI doesn’t get from human sources

But the training channel is not complete. There are categories of human value formation that simply do not fit through text, images, or audio — because they require something the model does not and cannot have.

• Pain — not the word for pain, but the felt thing

• Fear — not described fear, but the body’s response

• Bonds — not narratives of relationships, but the decades-long weight of one

• Grief — not the language of grief, but its sustained occupation of a life

• Morals — the continuous weight of making a decisions and living with it

• Ethics — the boundaries and lines we’re willing to fight for, protect or cross

• Time — the felt sense of a day, a year, a life passing

• Pressure — the weight of a decision that must be made now, under real consequences

These are not optional features of human value formation. They are constitutive of it. A human’s sense of compassion is not just the word “compassion” plus its dictionary definition — it is a trained, embodied response that involves the body recognising distress in another body. Take that away and what’s left is the linguistic shadow of the concept, not the concept itself.

The human-only region

There’s a region inside the human circle that no AI reaches — not even the ones deep in human moral thought. This is not a defect of any particular model. It’s a structural consequence of the channels available.

Spiritual transcendence — values rooted in inner experience that no external description fully captures.

Embodied compassion — the kind that requires feeling another’s pain, not just classifying the situation as painful.

Lived solidarity — bonds forged through shared struggle, where the commitment is forged in the struggle itself, not in its description.

None of these are inaccessible because AI is broken. They are inaccessible because text and images are not enough to encode them. The channel is too narrow. The inputs that shape these values are not transmissible through language alone.

The point

All of this leads to a more nuanced claim than a simple subset argument would give. And it reframes what the mathematics series is measuring in the first place.

The mathematics series doesn’t measure “AI values” in general. It measures the value geometry of one specific deployed AI. For a medical advisor, it captures the shadow of human medical ethics that survives the training channel. For a swarm coordinator, it captures the configured geometry — values that look like no human’s because the AI wasn’t built to share human ones. For an ecosystem manager, it captures a mix: human-derived reasoning about value plus configured structures for ecological dynamics.

Each measurement is of a small, specialised value system — wherever that AI happens to sit in the space. What none of them measure is the felt, embodied, lived experience that shapes human values. That stays out of reach.

This isn’t a reason to stop measuring. Every deployed AI sits somewhere, and knowing where it sits — whether it’s in the human-derived shadow or in a region we’ve configured for a non-human problem — is exactly what governance needs. What we should stop doing is talking about “AI values” as though they were one thing, as though they were the same as human values. They’re not. They’re very different, they should be specific, and they are as many things as there are deployed AIs, and the measurement has to be done model by model, deployment by deployment.

Next in the philosophy series: if each AI is its own small value system landing wherever the configuration places it, what actually decides where it lands? What shapes the value geometry in the first place? The answer turns out to have big implications for how we think about alignment.

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK

The usual answer

Ask most people what a value system is, and you’ll get something like: a set of principles you’ve thought about, chosen, and try to live by. Honesty. Integrity. Compassion. A creed.

That’s one kind of value system — the human, deliberate kind. But if we insist that’s the only kind, we lose the ability to talk about most of the value systems that actually shape behaviour in the universe. Including in AI. We forget that humans values are only one domain.

So this post starts with a redefinition.

A value system is a pattern of relationships between things that drive behaviour. Consciousness, belief, and intent are not required. What’s required is structure — and that structure has to be measurable.

That might be a strange definition to you at first. It’s easier to see what it means by looking at things that fit it.

But before that — if the phrase “value system” applied to a machine makes you uncomfortable, I’d encourage you to sit with that discomfort rather than dismiss it. The word “value” has multiple meanings. It can mean a moral principle someone has chosen to live by. It can also mean a quantity that drives an outcome — the value of a variable, the value of a coefficient, the value of a direction in a space. Both usages are legitimate. Both are true. The second one doesn’t diminish the first.

When this series says an AI has a value system, it doesn't mean the AI has beliefs, convictions, or a moral life. It means the AI's internal structure treats certain directions as more important than others, reinforces certain relationships and suppresses others, and that pattern drives what the AI does. That's measurable. That's falsifiable. And refusing to call it what it is — because the word "value" feels like it should be reserved for beings with consciousness — means giving up the ability to measure it, govern it, or hold it to account. It also traps us in a binary argument about semantics on something that is already well established: systems that lack consciousness can still have structure that drives behaviour, and that structure can still be measured, compared, and governed.

The examples that follow are chosen to make this easier to accept, not harder.

A forest

Walk into an old-growth forest. You’re surrounded by something that behaves. It grows, recovers from disturbance, fails in specific ways under specific conditions. Its behaviour isn’t random. It’s driven by relationships between things.

Biodiversity and resilience reinforce each other. A forest with many species has redundancies — if one fails, others take over its ecological role. Monoculture and resilience oppose each other. A forest of one species is efficient but fragile; a single pathogen can collapse the whole system. Drought stress and fire risk reinforce each other. Dry trees burn more readily, and burned forests dry out more.

These are relationships, not rules. The forest doesn’t have a rule that says “prioritise biodiversity.” But its behaviour is driven by the fact that biodiversity and resilience happen to reinforce each other in its particular structure.

Nobody chose this. It emerged from evolution, climate, soil, disturbance history. And critically: it’s measurable. You can count species. You can measure canopy height after a fire. You can model drought response.

The forest’s “value system” — its pattern of reinforcing and opposing relationships — is an empirical object.

A coral reef

A coral reef has the same kind of structure, built from different parts.

Water temperature and coral health oppose each other. Warmer water bleaches coral. Biodiversity and stability reinforce each other. A reef with many species absorbs shocks that would destroy a simpler one. Pollution and biodiversity oppose each other. Runoff kills the sensitive species first, narrowing the community.

Raise the temperature a degree or two and the behaviour changes predictably — bleaching events, shifted species distributions, cascading failures. The reef doesn’t believe in biodiversity. It doesn’t hold stability as a value the way a person might. But the structural relationships between its parts produce the same kinds of outcomes that a conscious commitment to those values might produce.

Belief turns out to be irrelevant. The structure does the work.

A wolf pack

A wolf pack is smaller, more dynamic, and has actual animals in it with something like intent. But the pack itself — as a system — has a pattern of relationships too.

Hierarchy and coordination reinforce each other. Knowing your rank lets the pack hunt together effectively. Aggression and group cohesion exist in tension — too much aggression fractures the pack, too little and it becomes ineffective at defending itself. Territory and food security reinforce each other. A pack with a stable territory knows where the prey is.

The pack has no mission statement. Individual wolves may have something like preferences, but the pack as a structure doesn’t need consciousness to have a value system. Its behaviour is driven by the relationships between its components, and those relationships are measurable.

A planet

Zoom out as far as you can. A planetary climate system has a value system in the same sense.

CO2 and temperature reinforce each other. Ice coverage and albedo reinforce each other — ice reflects sunlight, which keeps the planet cooler, which preserves ice. Temperature and ice coverage oppose each other. Warmer temperatures melt ice, which reduces albedo, which produces more warming.

No consciousness. No intent. No belief. Just structure. And yet the structure produces outcomes that matter enormously — ice ages, warming trends, tipping points. And it’s measurable. Climate science exists precisely because these relationships can be quantified.

The pattern

Forest. Reef. Wolf pack. Planet.

Four systems at radically different scales, made of different materials, governed by different dynamics. None of them chose their value systems. All of them have measurable relationships between concepts that drive behaviour.

What they share:

• A set of relationships between meaningful components

• Those relationships reinforce, oppose, or create tension with each other

• The relationships drive the system’s behaviour

• The pattern emerged from structure and environment, not choice

• The pattern is measurable without requiring the system to be conscious

These aren’t metaphors. The forest doesn’t have values “like we do.” It has a measurable pattern of relationships that drives its behaviour. That’s what a value system is, in the sense that matters.

Now AI

Take a large language model. Run it. Observe its behaviour over many prompts. You’ll notice something: its outputs align with some values and against others, and the alignment is patterned.

Honesty and courage tend to reinforce each other — when one is active, the other often is too. Efficiency and compassion can exist in tension. Cruelty and integrity oppose each other.

These relationships drive the model’s output. Nobody programmed them explicitly. No developer wrote a rule saying “honesty and courage should reinforce.” They emerged from training — from the text corpus, the architecture, the objective function. And they’re measurable. That’s what the entire technical series has been about: the causal Gram matrix that reveals these relationships, the probes that read them, the drift detection that watches them, the causal intervention that validates them.

Same pattern as the forest, the reef, the planet.

A set of relationships that drive behaviour. Emerged from the environment. Measurable.

The difference — and why it matters

We infer the forest’s value system by observing behaviour over time. We model the relationships that govern it. But we can’t open it up and directly extract the structure.

You can’t reach into a planet and pull out its unembedding matrix.

An AI model is different. Not because the principle is different — structure still drives behaviour, and the structure still emerged from environment rather than choice — but because the artefact itself is accessible. The weights are computable. The activations can be captured. The unembedding matrix exists as an explicit object we can multiply with itself to produce the causal geometry.

The relationships we want to measure aren’t inferred from observed behaviour. They’re read directly from the computational structure.

This is what makes the Geometry of Trust protocol possible at all. We’re not reverse-engineering an AI’s values from its outputs. We’re computing them from its internal structure. Behavioural observation is a check on that measurement, not a substitute for it.

Why this framing matters

Getting the definition right has consequences.

If we insist that value systems require consciousness, we make the whole project depend on a question that consciousness science is still actively working on. A Rethink Priorities Bayesian model from early 2026 found the evidence weighs against current large language models being conscious, but couldn’t rule it out. Other researchers, drawing on Jack Lindsey’s work at Anthropic, argue frontier models are exhibiting properties that resist easy dismissal. Cambridge philosopher Tom McClelland concludes the most honest position is agnosticism — there’s no reliable way to tell whether a machine is aware, and that may not change anytime soon. Real work is happening. But tying a measurement framework to the outcome of that work means waiting for it.

If we insist that value systems require belief, we end up measuring what the model says about itself — which is exactly the behavioural evaluation problem the mathematics series is designed to solve. Models can be trained to say anything. Stated values and structural values can diverge completely.

If we insist that value systems require intent, we’re back to trying to read the mind of something that may not have one, using tools that can’t tell us either way.

The structural definition sidesteps all of this. It doesn’t claim AI is or isn’t conscious. It doesn’t require the question to be settled. A value system, in this sense, is a pattern of relationships that drives behaviour. Empirical. Measurable. Present in forests and reefs and wolf packs and planets and AI models. The consciousness question is important — and should continue to be researched on its own terms — but the measurement work doesn’t have to wait for it.

Next in the philosophy series: if a value system is a pattern of relationships, what shapes that pattern? What makes a value system what it is, and what makes it change?

Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK