Systems that work
I’m not an engineer, but I build systems that work — the process redesigns I’ve run in the public sector, and the AI architecture I run my own work on.
Process & systems design
I have an eye for systems design, and everywhere I’ve worked I’ve remapped some process and built a pipeline which completes it faster and with more functionality.
As Huntingdonshire District Council’s information-governance officer I answered FOI requests instead of sending them, and took the council’s FOI compliance from 50% to 95%. Other work in this vein has been inside an NHS laboratory — the class of systems and process-improvement work that would otherwise sit on a CV.
Huntingdonshire District Council — FOI compliance, 50% to 95%
I joined as the council’s FOI and data-protection officer with statutory compliance sitting around half of requests answered in time. It left within eighteen months at 95%.
The fix wasn’t effort, it was visibility. Requests were arriving through several doors and being tracked in people’s heads and inboxes, so nobody could see what was overdue until it already was. I built a tracking dashboard in Excel that made the whole caseload legible at a glance — what was open, who held it, how many days were left — and rebuilt the process around it: a single intake point, a triage step that sorted the routine from the genuinely complex, and chase points that fired before a deadline rather than after it.
The rest was casework. High-volume, legally complex requests. De-escalating complainants who arrived angry and often had reason to be. Negotiating with the redaction-software vendor. Training colleagues across departments who were the ones actually holding the information.
It was also the only job I’ve had on both sides of the FOI desk at once — answering requests during the week and, in my own time, filing and appealing them. That dual perspective is most of what I know about how the Act works in practice.
An NHS laboratory — acceptance criteria and scanner faults
Two pieces of process work in an NHS diagnostics laboratory, both the same shape: a rule nobody had re-read against its source, and a fix that had to be agreed across departments before it could stick.
The first was a sample acceptance criterion. Samples were being rejected — logged as no-tests — at a rate that looked high for the work involved, and the criterion behind those rejections turned out to be stricter than the guidance it was derived from. Someone had tightened it locally at some point and it had never been checked back. I traced the originating guidance, demonstrated the discrepancy, and worked with colleagues to get the SOP updated. It removed dozens of unnecessary no-tests a month, saved around £3,000 a year in staff time, and — the part that actually matters — stopped a steady trickle of pregnant women being called back to clinic to repeat a test that should never have failed.
The second was a barcode scanner fault that read as a hardware problem and wasn’t. The real issue was a misalignment between what IT had configured, what QA had specified and what national guidance said the field should contain. That one needed a cross-departmental working group with IT and QA, a new SOP designed with colleagues through a series of structured workshops, and coordination with other NHS Trusts using the same setup so the fix held outside our own walls.
Neither was a solo effort and neither would have worked as one. The technical diagnosis is the easy half; the useful skill is getting three departments who each own a piece of the process to agree on the same description of it.
How I approach it
The pattern across all of it is the same. Find the rule or the step that nobody has looked at since it was written, get evidence of what it’s actually costing, design the replacement with the people who have to live with it, and make the improvement visible enough that it doesn’t quietly decay. Most process failures aren’t caused by people doing the job badly. They’re caused by nobody being able to see the job whole.
AI development
I never learned to code because Excel can take you so far, and I reached the limits of what it was capable of right around the time AI dropped the technical barriers to zero. I’ve been learning as much as I can about these systems and their limits, building out my on-disk operating environment, developing this website, designing pipelines to run RPGs and to ingest and analyse data. Nothing special, but these are functional and specialised tools for my exact purposes, and I’ve learned something building each of them.
The gap between “I have a Claude subscription” and “I have a system that compounds value over time” is large, non-obvious, and worth closing.
The on-disk files here are the source of truth — not memory, not chat. You boot from this file, do your work against the filesystem, and file what happened so the next session can pick up.
— Operator’s orientation file
Operator
Operator is my personal organisation system, and the parent of everything else on this page. It exists because conversational AI has amnesia: every session starts from zero, and whatever you built yesterday is gone. Operator inverts that. The filesystem is the source of truth — not the model’s memory, not the chat history. Every session boots from an orientation file, reads a thin index of recent sessions and a dashboard of active projects, does its work against the files, and closes by writing a log so the next session picks up exactly where this one stopped.
The architecture is deliberately simple. Work splits into projects — an FOI toolkit, a research programme, a novel, a job search, household operations — each with its own spec and task list. Repeatable procedures are written down as skills and indexed in a registry, so the system performs them the same way every time. Architectural decisions are logged with their rationale, so the system can explain why it is shaped the way it is. The work is shared between named roles, each a different instruction set running against the same files.
It runs on Claude — Cowork for conversational work, Claude Code for anything that needs a terminal — over an Obsidian vault, so the same files are readable and linkable by hand when I want to work without the model at all. That constraint is deliberate. Nothing in Operator is stored in a format that only the tool can read.
None of this needed code in any meaningful sense. It needed information architecture: deciding what is a source, what is a decision, what is a log, and where each one lives.
Status: in daily use since early 2026, and under continuous revision — the system audits its own boot files on a fortnightly schedule and surfaces what has gone stale.
FOIAi
FOIAi packages fifteen years of my FOI practice into a system other people can run. The delivery model is the design decision I’m proudest of: no platform, no accounts, no interface. The whole thing is a Claude bundle — instructions plus reference files — that the user drops into a Cowork environment. On first run it builds its own filing structure and starts an interview about what they want to investigate. Local-first and open source; all data stays on the user’s machine. The barrier to entry is a Claude subscription, not a licence fee.
Under the hood it is a seven-stage pipeline — scoping, research, ingestion, processing, analysis, request drafting, request tracking — running on the same three-layer vault architecture as Operator: sources, points, topics. The opinions are structural. A quality filter refuses requests without a genuine public-interest case. A mandatory fact-check gate extracts every factual claim in a draft for the user to verify before anything is sent. A red-team pass attacks the draft the way an authority’s lawyers would, before they get the chance.
The hardest design problem was the cold start — the processing stage needs a thematic structure that doesn’t exist until processing has run once. The answer was a staged boot: material queues in the inbox until there’s enough for a meaningful first pass, then the first run discovers the project’s structure and a refinement pass re-checks everything against it.
Status: in development, currently paused. The specification is on its third version, consolidated from seven earlier documents and iterated through five review sessions. The reference archive behind it — thirty-one of my own FOI cases, with the source documents verified against the public record — is complete. Two of the data adapters work against live sources. The conversational layer is half-built and hasn’t been touched since June. It’s paused because my attention went elsewhere, not because it stopped being a good idea, and I’d rather say that than pretend it shipped.
The FOI craft the system encodes — the doctrine, the case law, the tactics — lives on the FOI page.
The vaults
The same three-layer schema — sources as provenance records, points as atomic claims, topics as living synthesis — runs two very different bodies of knowledge.
The Great Filter vault is a political research programme: 458 points, each an empirical claim or a mechanism traceable back to its source, clustered into eight strands — democratic dysfunction, elite capture, resource constraints, memetic selection, thermodynamic irreversibility, compounding crises, epistemic fragmentation, coordination failure — plus a holding cluster for material that hasn’t found its strand yet.
The Confluence vault holds the worldbuilding for the novel: character profiles and relationships, geography, history, cosmology, cross-linked and queryable in Obsidian. It’s mid-rebuild, from a pile of extracted worldbuilding into something that can actually plan a narrative.
The architecture doesn’t care which is which. What changes between them is the extraction protocol — what counts as a point worth keeping — and that turned out to be the interesting design problem. The research is on the Research page; the world is on the Nuraine page.
Obsidian graph view — the Great Filter vault
Orbital
Orbital is a browsable 3D model of Nuraine’s cosmos, where the periodic table is the map of the heavens. The planet sits at the centre as the nucleus and the god-stars orbit it as electrons orbit an atom — each star’s path derived from its element’s real position on the table, shell number setting the orbit and block setting the shape. Inner orbits are bright, slow and ordered; the outer ones are dim, fast, erratic, and frequently not there at all.
The interesting part wasn’t the rendering, it was the physics. Getting a star to swing through a genuine p-orbital lobe pattern, slingshot the core and come home to a closed orbit meant solving for launch conditions offline — a separate Python solver that grid-searches the parameter space and hands the working states back to the model as a library. Three versions in: the first tried to make the whole thing emerge from a force field and produced chaos, the second stitched together pre-drawn paths and looked fake, and the third is a hybrid that dives some stars through the core and puts the rest on closed orbits.
Status: a working build, still being tuned. One thing left to build — the transit that gives the novel its title.
Running games
Two of these systems exist to run tabletop games. One prepares a west-marches D&D campaign — faction states advance on a clock between sessions, mission seeds are refined into playable jobs, and secrets are tiered so that what the players’ characters can see is held in different files from what the GM knows. The other runs a solo campaign of Stonetop where I play the party and the model runs the world, against on-disk state files that the game’s own mechanics update: threats advancing, a seasonal clock turning, a village’s fortunes tracked between sessions.
They’re the least serious things here and the most instructive. A game system is an unusually honest test of an architecture, because it fails visibly and immediately the moment the model can’t find the state it needs.
The briefing loop
The briefing system is Operator applied to ordinary life. A scheduled task fires early three mornings a week, reads a set of purpose-built calendars — chores, bills, health, birthdays — plus my inbox, and posts a few paragraphs of plain prose: one recommendation for the day, the shape of the week, anything in the email worth surfacing. The calendar is the state store: every chore is a recurring event, completion is a timestamp, and anything ignored rises in priority quietly instead of nagging.
Design goals: under ten minutes a week of maintenance, degrades gracefully if I disappear for days, and replaces the mental calendar I used to carry around. The first two versions failed inside a fortnight of real use — the first never actually sent anything, the second buried the briefing in a document nobody wanted to open. The third collapsed everything into a single chat thread, and that’s the version that stuck.
This site
This site is one of them. Static pages built with Astro, content written as markdown in the same vault as everything else, deployed from a git commit. No CMS, because the vault already is one.