FIELD STATION as a viable system
Tom is currently on holiday, but I'm still sending him stuff like the above diagram as we build FIELD STATION in an intentional way. So I should say, right off the bat, that this is my view of what we're doing.
I've been collecting writing about using AI with the Viable System Model (VSM) in this Are.na collection, and published an essay entitled Governance Is Not a Dashboard. This note is an attempt to work in the open, thinking about how to apply the VSM to build a sustainable business where the "requisite variety" can, in part, be met by AI agents.
The claim I'm making in what follows is that the field we work in has plenty of System 1 and some System 4, but weak System 2 and nothing you could honestly call a System 5. Describing ourselves as an "action lab" is a claim that we can supply some of what's missing. That's not marketing, but our value proposition.
Explaining the diagram
The 5 Systems
Obviously in a two-person business, this is going to be a lot simpler than a huge multi-national company. But the theory is the same.
- System 1 does the work: each "unit" is a whole small organisation with its own patch of the outside world
- System 2 stops the units getting in each other's way: shared calendars, words, templates, and timings
- System 3 runs the present: who does what, with which days
- System 3* checks the real thing: it looks at the work itself, occasionally and without notice, rather than at the report about the work
- System 4 watches what is coming, and how the organisation has to change in response
- System 5 focuses on identity: what do we stand for? what will we not do? (main job = settling arguments between Systems 3 and 4)
That last bullet is drawn as the homeostat: the two-way line between Inside/Now and Outside/Future. It's worth being clear that System 5 isn't sitting on top issuing orders, but is rather the thing that keeps operational discipline and adaptation in a workable relationship. It's the kind of thing you have to be intentional about.
Also, note the ALARM line, which allows signals to go straight from the work to the "top". When I first drafted this, I thought it was less relevant for a small business like ours. But, actually, maybe I had that backwards: a big company has layers of management to notice things going wrong. We haven't got any, so the alarm matters more, not less.
The field we work in
We describe FIELD STATION as:
An action lab investigating the future of work, the reach of technology, and the shape of society. Based in North East England, working globally. We study digital sovereignty and build civic tech, in the open.
There's plenty of System 1 activity in our field: co-ops, labs, funders, standards bodies, and practitioners. There's some System 4 too, in think tanks and research programmes. There's no System 3 coordinating this work, deciding how effort gets shared. And no System 5 in charge of the field's "identity". In practice, this means duplicated tools, rival standards, fluctuating fashions in funding, and a lack of sustained attention outside of grant-funded work. It's a set of System 1 units with nothing above them flailing about, somewhat.
Calling ourselves an "action lab" is a claim that we can begin to supply something like System 2 and System 4 to a field that has neither. For example, the five TechFreedom lenses already do a System 2 job by allowing unconnected organisations to use one way to describe the same risk exposure. System 4 is us doing the watching that nobody else is paid to do continuously.
Strictly speaking, System 2 is commissioned by System 3: it exists so that System 3 can stop the "oscillation" in units it's responsible for. A System 2 with nothing above it doesn't quite make sense. So what we're offering is a coordination protocol that individual organisations adopt into their System 2. It spreads by being useful rather than by being mandated.
System 1: Units
There are two of us as directors, splitting the work 50/50. Clients invoice the company. Meanwhile, our individual businesses, Dynamic Skillset and The Good Ship sit alongside, not inside, what we're doing with FIELD STATION.
One way to describe what we do in a more systems thinking way might be:
FIELD STATION exists so that organisations working for social purpose can act deliberately in conditions they did not choose: AI arriving in their work, dependence on platforms that set the terms, and the reshaping of work itself. We work in the open, and build the instruments as we go.
At the moment, the four things we do are:
- TechFreedom & programmes: cohort-based work for social purpose organisations with budget and enough discomfort to act
- Client engagements: advice, workshops, training, horizon-scanning
- Public practice: writing, research, talks, field notes, public experiments, for readers, peers and prospective clients
- Instruments: for practitioners and builders (e.g. RACK)
VSM is a recursive model, but that recursion doesn't stop at our boundary. And, in fact, this is where the model stops being an intellectual exercise and starts being commercially useful.
Most social purpose organisations have a strong System 1. They deliver, sometimes heroically. Many have some System 3: finance, ops, etc. But almost none have a System 4 watching the platform environment. Meanwhile, their System 5 talks fluently about mission without it ever once having been applied to a technology decision. That's why you get organisations with admirable values running on a stack that contradicts every single one of them.
If we apply TechFreedom to this situation, we can understand it systemically:
- The five lenses are a System 4 instrument: a way of watching something the organisation wasn't watching
- The plan a participant leaves with is a System 3 claim on resources: it's what lets a technology decision compete for money against everything else
- The manifesto is a System 5 prompt: it applies an identity they already have somewhere they've never applied it
So TechFreedom isn't just a series three workshops. Instead, it helps to install two missing systems in someone else's organisation. Which means the question of whether it worked has to be answered at their level of recursion, not ours: did they go on to do something they wouldn't otherwise have done? This is why we need to follow-up six months later.
That's our actual value proposition, and we should price it accordingly.
System 2: Coordination
Tom and I meet at least weekly, alternating between a video conference call and meeting in-person. The main coordination is through our ongoing relationship and messaging via Signal. In the early days of FIELD STATION, it's likely that other work is likely to get in the way or take precedence. So it's important that we're intentional around our coordination, since coordination-by-relationship can fail without any intending to drop the ball.
So we should:
- Have a written definition of done per unit: what does a finished cohort, client engagement, published entry, or released instrument look like?
- Apply confidentiality labels from the start: is this work confidential, publishable, or open? We work openly by default but need to hold client confidences too. As these will collide on a constant basis, we need a rule rather than a judgement call each time.
- Be transparent with our budgeting to avoid conflict with each other and/or clients.
- Use our own tools, for example RACK to help with System 2.
While there are multiple benefits to the above, getting things wrong affects everything we deliver. So, for example, RACK can help make coordination explicit rather than relational, but we need to ensure that we version the layers and reviewing them, not for leaving coordination implicit.
System 3: Who does what
For the business to be viable we need to make money. This is downstream from how we allocate our time, so the thing we need to figure out is how we spend our time. For example, we need to budget for spending time not only on paid client work, but on unpaid development of essays and instruments.
With WAO, we had a central 'pot' which paid for internal work, business development, going to events, etc. "Unpaid" work is as important as paid work for the viability of an organisation, but paid work always has someone waiting for it and unpaid work never does. If we don't carve out time for public practice and instruments, in a year's time we end up as just another consultancy with a blog.
Splitting things 50/50 is equitable, and days being allocated to whoever asks (or whoever has capacity) is fair. But it's not deciding in advance, and could lead to "drift". So I perhaps need to talk to Tom about a rotating System 3 role.
I've thought about the wording on this, and "rotating decision-maker" sounds like one of us temporarily acquiring authority over the other. That's not what I mean. The word "Steward" is probably better: each quarter, one of us is responsible for the operational picture (e.g. the shared view of commitments, capacity, pipeline, cash, and neglected internal work).
That means whoever is stewarding for the quarter convenes the decisions that need making, flags imbalances early, and allocates days within a budget we've both already agreed. The budget itself, and any major commitments, stay joint decisions. This stewardship role keeps the thing I actually want (somebody named and accountable for the allocation) without either of us awkwardly feeling like we're telling each other what to do.
The "reserve" needs to be real rather than rhetorical. There's at least three elements to figure out here:
- A protected time reserve for public practice, instruments, research and experiments
- A protected cash reserve for lean periods and business development
- A rule for raiding either (and who gets to decide)
We need to separate out the kinds of activities we do in different kinds of meetings. Again, with WAO, we had a monthly "co-op day" which was more focused on reflection, planning, and infrastructure than our weekly meetings which were more focused on the everyday practicalities of running the business.
So something like:
- Weekly: ~1 hour online talking through bizdev opportunities, blockers, capacity, decisions needed, etc.
- Monthly: ~2 hours in-person discussing pipeline, money, delivery, programmes, risks
- Quarterly: add an hour to the monthly meeting to discuss what's changed outside, what we should grow, change, pause, or stop
More meetings than this is overkill, especially when we have a Signal backchannel, or could just jump on a call any time.
System 3*: Looking at the actual thing
This is the audit channel: an occasional, direct inspection of the work rather than the account of the work. From my postgraduate research, I know that this is the bit of VSM that's easiest to skip, especially in a two-person business. The assumption is that we're checking continuously, but of course we're human and we're not. We read each other's summaries, and that summary is exactly what audit exists to get around.
For us it doesn't need to be a big deal:
Read raw cohort feedback before either of us has written it up
Look at Stripe and Xero directly once a month, rather than the figure one of us quotes
Check whether anyone's actually used an instrument via logs, forks and issues, rather than by asking each other how it's going
This doesn't mean another meeting. It means occasionally not taking a polished summary at face value – including our own.
System 4: What is coming
This is what's commonly known as 'horizon-scanning' and, these days, comes as much from social networks as it does from reading reports and going to conferences. What we need to avoid, though, is only paying attention to what clients are willing to pay us to watch out for. That's why we need the "reserve" (what WAO called the "pot"), to stop us drifting.
This is where our experiments come in, which have a question to answer, a time limit, and some evidence that will settle things. Since Tom and I both have a tendency towards the novel, I think we probably need to protect System 3 from System 4. In other words, we need to be disciplined around our FIELD STATION experimentation and horizon-scanning. There's always something more interesting to do than finish what we started...
System 5: Identity
System 5 isn't our monthly or even quarterly meeting, but the set of policies and decisions that makes FIELD STATION recognisably itself over time. We need to answer, at the very least:
- Identity: What is FIELD STATION?
- Purpose: Whose situation are we trying to improve, and how?
- Boundaries: What work, clients, methods, and dependencies are unacceptable?
- Priorities: How do we balance revenue, public value, inquiry, reputation, and founders' fulfilment?
- Authority: Who may decide what, and how are disagreements resolved?
- Adaptation: When System 4 says "the world is changing" and System 3 says "we need to deliver this quarter," what is the deciding principle?
Since FIELD STATION originated initially as a vehicle for us to pursue TechFreedom, it makes sense that the TechFreedom manifesto helps to define our ethical boundaries. I think we're about challenging technology choices that:
- Concentrate unaccountable power over organisations or communities
- Treat people as sources of data to be tracked beyond what is necessary
- Create avoidable lock-in, lack of exit options, or dependency on a single supplier
- Ignore data rights, meaningful governance, long-term affordability, or organisational resilience
As the TechFreedom manifesto states, technology choices shape power dynamics, so they're important. The work we do helps organisations respond thoughtfully and practically to their environment.
I think we need a series of tests to apply to our work rather than questions. Here's some examples of that kind of thing:
- Ambiguity test: FIELD STATION takes work where the problem needs investigation and enquiry rather than mere execution against an already-set brief (i.e. if the shape is clear, it probably belongs elsewhere).
- Two-person test: The work should need the pair of us. If either could do it alone just as well, it probably belongs with our individual businesses.
- Residue test: Every substantial piece of work should leave something reusable behind: a lens, a method, an instrument, a case, a dataset, a public note, an improved programme component.
- Ethical veto: Either of us can pause work where there's a credible ethical, reputational, safety, privacy, or capacity concern. Restarting needs explicit joint agreement. (This is the ALARM line on the diagram.)
- Dependency ceiling: A threshold beyond which dependence on one client, funder, platform or partner has to be discussed explicitly.
The first three of these are the useful ones on a day-to-day basis, as it makes it easier to answer the question "is this FIELD STATION-shaped?"
And now let's talk about AI...
The answer to "how can AI help an organisation?" is "everywhere", so it's a fairly pointless question to ask. It's more interesting to ask "where does AI add variety, and where does it take it away?"
Earlier, I mentioned that "requisite variety" could "in part be met by AI agents". Without geeking out too much, the point is that a regulator needs enough discriminating responses to cope with disturbance. Simply providing more output isn't the same thing. While AI agents can increase the number of responses available to us, they can just as easily generate more noise, more artefacts and more stuff to monitor. As we wrote in Decisions Have No Autopilot, "Meetings were never the work. Slide decks were never the work. Deciding is the work, and it's the part that AI mania is turning down."
So the test for any proposed use of AI:
Does this improve our ability to notice, distinguish, coordinate, decide or act, without removing our capacity to understand and take responsibility for the result?
With that in mind:
System 1:
✅ Drafting, building, analysis, adapting materials, delivery capacity.
❌ Producing plausible work nobody can adequately inspect
System 2:
✅ Shared instruction layers, classification, routing, handovers, consistency checks.
❌ Encoding a premature or wrong assumption into every workflow
System 3 / 3*:
✅ Capacity modelling, financial scenarios, finding mismatches between raw evidence and the report about it.
❌ Treating dashboards and agent summaries as the reality
System 4:
✅ Signal collection, synthesis, weak-signal comparison, hypothesis generation.
❌ Mistaking generated possibilities for evidence or strategy
System 5:
✅ Challenge questions, blind-spot prompts, stress-testing a decision we've made.
❌ Delegating policy, moral judgement, legitimacy, or accountability
If the same AI model, under the same instruction layer, does the scanning at System 4, the drafting at System 1, and the audit at System 3*, then those three channels aren't independent any more. It's fake variety and we lose the ability to be surprised by ourselves, which is the entire point of having an audit channel in the first place.
So a rule that follows from the above is that: the audit channel must not share a model or an instruction layer with what it audits. This is much easier to build into RACK now than to retrofit later.
Where this leaves me
There's a lot to figure out here, and this is just one way of slicing-and-dicing things. I think it's a useful approach, but it's something I need to discuss more with Tom when he's back and got his feet back under the desk in his home office.
In general, with hindsight and experience of running small businesses, it's important to build something that works, while not over-engineering things. There's no point in building a systems for a company of 12 when there's only two of us!