A guide for building a personal strategy system that combines two complementary ideas:
- Stafford Beer's Viable System Model (VSM) — organizes your strategic thinking by function and rate of change
- LLM-maintained wiki — the knowledge infrastructure that keeps the system alive without manual bookkeeping
The VSM gives you the architecture. The LLM wiki gives you the maintenance flywheel. Together they solve the two reasons personal strategy fails: structural confusion (mixing purpose with status) and maintenance burden (nobody updates cross-references).
Strategy documents rot because they mix things that change at different rates. Your purpose rarely changes. Your environmental reads change monthly. Your operational workstreams change weekly. Mixing them in one document means everything feels stale, and you stop updating it.
The VSM identifies five functions any viable system must perform. We repurpose it for personal strategy:
| Function | What It Holds | Update Frequency |
|---|---|---|
| S5 — Identity | Purpose, decision rules, endgame | Rarely (quarterly review) |
| S4 — Intelligence | Environmental scanning, landscape assessment, scenario analysis | Monthly or when signals arrive |
| S3 — Control | Credibility tracking, influence map, sequencing, attention allocation | Weekly |
| S2 — Coordination | Resource arbitration between plays, shared stakeholder rules, interference detection | Weekly (or when plays collide) |
| S1 — Operations (one per play) | Workstreams, milestones, checkboxes, tactical state | Continuously |
S2 can be folded into S5 as a section if you're running only 1-2 plays with minimal resource conflict. Once you have 3+ plays genuinely competing for the same scarce resources (your time, stakeholder bandwidth, credibility budget), S2 warrants its own file — it becomes the referee between plays rather than a footnote in the constitution.
The maintenance burden is what kills human-maintained wikis — updating cross-references, keeping summaries current, tracking contradictions. Human-maintained wikis decay because nobody wants to be the one updating 15 pages when one fact changes.
The LLM wiki inverts this. Rather than re-deriving answers from raw sources each time (RAG), the LLM incrementally builds and maintains a persistent, compounding knowledge base. Cross-references pre-exist. Contradictions are already flagged. You never write the wiki yourself — the LLM does all bookkeeping.
Human role: Curate sources, direct analysis, ask good questions, make decisions. LLM role: Everything else — ingest, cross-reference, update, lint, synthesize.
The VSM is your strategy layer — it organizes what you're trying to do and why. The LLM wiki is your knowledge layer — it organizes what you know about the world you're operating in.
graph TB
subgraph Strategy ["Strategy (VSM)"]
S5["S5 — Identity"]
S4["S4 — Intelligence"]
S3["S3 — Control"]
S2["S2 — Coordination"]
S1a["S1 — Play A"]
S1b["S1 — Play B"]
S1c["S1 — Play N"]
S5 --> S4
S4 --> S3
S3 --> S2
S2 --> S1a
S2 --> S1b
S2 --> S1c
end
subgraph Wiki ["Knowledge Base (LLM Wiki)"]
People
Systems
Organizations
Concepts
Logs["Daily Logs"]
Threads
Index["index.md"]
end
S4 <-.->|"reads from"| Wiki
S3 <-.->|"links to"| Wiki
S1a -.->|"produces"| Logs
Logs -.->|"LLM ingests"| Wiki
The feedback loop:
- Daily logs (raw observations) feed the wiki (entity knowledge, interaction history)
- Wiki feeds S4 (who are the actors? what do they want? what changed?)
- S4 informs S3 (is my pressure map still accurate? do I need to adjust?)
- S3 directs S1 (what should I work on this week?)
- S1 outcomes become tomorrow's daily log entries
The LLM maintains the wiki layer automatically. You maintain the strategy layer with the LLM's help. Neither system requires you to manually update cross-references, chase stale entries, or remember to file observations.
| Layer | Description | Example |
|---|---|---|
| Raw sources | Immutable inputs — never modified by LLM | Daily logs, Slack exports, meeting notes, documents |
| Wiki | LLM-generated markdown: entity pages, summaries, concept pages | People/, Systems/, Organizations/, index.md |
| Schema | Conventions, workflows, structure — the configuration that makes the LLM a disciplined maintainer | CLAUDE.md, templates, frontmatter schemas |
The schema is the key configuration file. It's what makes the LLM a disciplined wiki maintainer rather than a freeform text generator. It defines: what entity categories exist, what frontmatter fields they carry, how pages are structured, what update operations look like. The taxonomy should fit your domain naturally — an SRE might split Systems into Services, Infrastructure, and Environments; a product manager might use Products, Features, and Competitors; a researcher might use Papers, Methods, and Datasets. Start with People, Systems, Organizations, and Concepts, then subdivide as your wiki grows.
Ingest. Drop a source (daily log, meeting notes, Slack export) and the LLM reads it, extracts entities, updates relevant wiki pages, appends to the log, refreshes the index. One source may touch 10-15 wiki pages.
Query. Ask a question and the LLM reads relevant pages, synthesizes an answer with citations. Good answers get filed back into the wiki — explorations compound.
Lint. Periodic health check: find contradictions, stale claims, orphan pages, missing cross-references, data gaps. The LLM suggests new sources and questions.
index.md— Content-oriented catalog. Every page, one-line summary. The LLM reads this first when answering queries or deciding what to update. Think of it as the table of contents the LLM navigates by.log.md— Append-only chronological record of operations. When did ingest last run? What was updated? This provides an audit trail and helps detect staleness.
The LLM doesn't get bored, doesn't forget to update a cross-reference, and can touch 15 files in one pass. The compounding effect is real: after a few weeks of daily ingestion, the wiki knows more about your professional context than you can hold in working memory. Entity pages accumulate interaction history. Concept pages track how your understanding evolved. The index makes everything navigable.
The historical parallel is Vannevar Bush's Memex (1945) — a personal knowledge store with associative trails. Bush's unsolved problem was maintenance cost. The LLM handles that.
A "play" is an autonomous bet — it has its own thesis, stakeholders, timeline, and success criteria. Two plays can share resources (your time, credibility) but should be independently viable.
Ask yourself:
- What are the distinct bets I'm making on my career/position?
- Could one succeed if the other fails?
- Do they have different stakeholders and different timelines?
If yes to all three, they're separate plays and each gets an S1 file.
The hardest to write and the most stable once written. It answers:
- Why does this strategy exist? What personal outcome are you optimizing for? Be honest — this is private.
- What are the decision rules? When plays compete for your time, what wins? When organizational interest and personal interest diverge, which takes priority?
- What does the endgame look like? Not a single outcome — a set of possible outcomes with the conditions that determine which materializes. Design so every near-term action increases value across all outcomes.
- How do plays coordinate? Allocation rules, shared stakeholders, interference detection.
- What discipline governs this system? Operational security, framing rules, circle of trust.
S5 should be readable in 5 minutes and revisited quarterly. If you're updating it weekly, you've put S3 content in S5.
Your environmental scanning function. It answers: "What's happening around me that I don't control but need to track?"
- Key actors — People and teams whose decisions shape your environment. Motivations, constraints, trajectories.
- Landscape assessments — Date-stamped reads on the state of play. Stack chronologically — most recent is current; older entries provide trajectory.
- Scenario analysis — Named scenarios (risk and opportunity) with trigger conditions and personal impact.
- Signal tracking — External forcing functions that affect your timeline.
S4 draws heavily from the wiki layer. Entity pages (people, orgs) feed your actor assessments. Interaction history feeds your relationship reads. The wiki does the bookkeeping; S4 does the synthesis.
If you're not adding to S4 at least monthly, you're flying blind.
Your management dashboard. It answers: "Is the strategy working? Where do I need to intervene?"
- Credibility ledger — Attributable wins and artifacts. Track visibility and attribution deliberately.
- Pressure/influence map — Who needs to be influenced, on what, why, and what lever? Link to wiki entity pages for each person.
- Sequencing tracker — RFCs, proposals, pitches that need ordering. Track sequence and blockers.
- Compensating controls — Each risk from S5 mapped to concrete countermeasures.
- Attention allocation — Are all plays advancing? Is S4 scanning being starved by execution?
S3 should be glanceable in 2 minutes and updated weekly. If a table has gone 2+ weeks without update, something is wrong.
S2 arbitrates when plays compete for the same scarce resource. It answers: "Play A and Play B both need my time/attention/stakeholder bandwidth this week — who wins and why?"
Structure it as:
- Allocation rules — Default time splits, minimum allocations per play, what overrides the default (deadline proximity, closing windows, external forcing functions).
- Shared stakeholder rules — If the same person is relevant to multiple plays, how do you sequence conversations? Do you bundle or separate? What's the framing for each?
- Interference detection — Triggers that surface when a play is being starved. "If Play B has not advanced in N weeks, escalate to yourself." Explicit thresholds prevent slow starvation from going unnoticed.
- Reinforcement patterns — How success in one play creates credibility or leverage for another. This is how plays compound rather than merely coexist.
S2 is the lightest file in the system. If you're agonizing over its content, your plays probably don't conflict enough to need it — fold the rules into S5 and revisit when you add a third play or notice one consistently starving.
Each play gets its own file:
- Thesis — One paragraph. What's the bet?
- Strategic phasing — Near/medium/long-term arc.
- Workstreams — Grouped by phase. Checkboxes for tasks.
- Current status — What's in-flight?
- Dependencies and blockers — What's waiting on someone else?
S1 files change the most frequently. This is the operational heartbeat.
A thin S1 (for a play mostly specified elsewhere) should contain: thesis, status, next actions, coordination flags, and links.
vault/
├── Strategy/ ← VSM layer
│ ├── S5-Identity.md — Constitution (quarterly)
│ ├── S4-Intelligence.md — Landscape (monthly)
│ ├── S3-Control.md — Dashboard (weekly)
│ ├── S2-Coordination.md — Play arbitration (weekly, or fold into S5)
│ ├── S1-[Play Name].md — Operations (continuous)
│ └── [Supporting analysis].md — Deep-dives referenced by S4/S1
│
├── Daily Log/ ← Raw sources (immutable inputs)
│ └── YYYY-MM/YYYY-MM-DD.md
│
├── Wiki/ ← LLM-maintained knowledge layer
│ ├── index.md — Navigation catalog
│ ├── People/ — Person entities
│ ├── Systems/ — Tools, platforms, products (your domain)
│ ├── Organizations/ — Teams, orgs, companies
│ └── Concepts/ — Cross-cutting ideas
│
├── Threads/ ← Ongoing efforts (open/close lifecycle)
│ └── [workstream or effort].md
│
├── Templates/ ← Document templates
├── log.md ← Append-only operation log
└── CLAUDE.md ← Schema (LLM conventions)
The system compounds over time. Here's the cycle:
- You work. Meetings, Slack, code, decisions. This is the raw signal.
- LLM ingests. Daily log entries trigger wiki updates — entity pages, interaction history, change logs. 10-15 pages touched per day.
- Wiki accumulates. After a few weeks, the wiki knows your professional context better than you can hold in memory. Cross-references pre-exist. Patterns emerge.
- S4 draws from the wiki. Your landscape assessment is grounded in accumulated observations, not one-time impressions. "I've interacted with this person 12 times over 6 weeks — here's the pattern."
- S3 acts on S4. Your pressure map and credibility ledger are informed by real data. Decisions about where to invest attention are evidence-based.
- S1 executes. Work happens. Produces new observations. Cycle repeats.
Each cycle deposits knowledge. The wiki gets richer. The strategy gets sharper. The maintenance burden stays on the LLM.
The compounding effect: After 30 days, you have 30 daily logs, hundreds of wiki updates, and an entity knowledge base that makes your S4 intelligence function genuinely informed rather than impressionistic. After 90 days, you have trajectory data — you can see how stakeholder positions shifted, which plays accelerated, which stalled.
-
Organize by rate of change. The primary failure mode is mixing stable purpose with volatile status. VSM prevents this.
-
Each S1 is recursively viable. A play should stand on its own — its own intelligence, control, and operations.
-
S3-S4 imbalance is the most common failure. Execution naturally dominates scanning. Protect S4 time — it's where you detect your plays are aimed at the wrong target.
-
The pressure map is the strategy made actionable. A strategy without a stakeholder influence map is a wish list.
-
Credibility compounds; track it. The ledger is the evidence base for whatever conversation you eventually need to have.
-
Private means private. Honest strategy requires honest self-assessment. Every action should have a legitimate overt justification, but the reasoning can be frank.
-
Thin S1 files prevent duplication. If a play has its own thread, S1 is just a pointer with coordination flags.
-
The LLM does the bookkeeping. You curate sources, direct analysis, and make decisions. The LLM ingests, cross-references, updates, and lints. Never fight the maintenance burden yourself.
-
Raw sources are immutable. Daily logs, meeting notes, documents — once written, never modified. The wiki is the synthesis layer that evolves.
-
The index is the LLM's navigation.
index.mdis how the LLM finds what to read. Keep it current and content-oriented (not just a file list). -
The log is the audit trail.
log.mdtracks what was ingested, when, and what it touched. Detect staleness by checking when the last operation ran. -
Good queries become wiki content. If you ask a question and the LLM synthesizes a useful answer, file it back. Explorations compound.
-
Lint regularly. Periodic health checks surface contradictions, orphan pages, missing cross-references, and stale claims before they mislead you.
-
The schema makes the LLM disciplined. Without conventions (CLAUDE.md, frontmatter schemas, templates), the LLM produces inconsistent output. The schema is the configuration that turns a text generator into a wiki maintainer.
Use this prompt to generate your initial structure. Replace bracketed sections with your own content.
I want to build a personal strategy and knowledge system combining Stafford
Beer's Viable System Model with an LLM-maintained wiki.
My situation:
- [Your role, level, team, org]
- [What you're trying to achieve in 1-2 sentences]
- [The 1-3 independent bets you're making]
For each play, briefly describe:
- [Play name]: [thesis in one sentence] — [key stakeholders] — [timeline]
Key environmental factors:
- [What's happening around you that you don't control but matters]
- [Key people whose decisions shape your path]
- [Any forcing functions or deadlines]
Generate:
1. CLAUDE.md — schema for the LLM wiki (entity categories, frontmatter,
conventions, update operations, templates)
2. S5-Identity.md — purpose, decision rules, endgame scenarios
3. S4-Intelligence.md — landscape assessment of key actors and environment
4. S3-Control.md — empty credibility ledger, influence map seeded with my
stakeholders, attention allocation tracker
5. S2-Coordination.md — allocation rules, shared stakeholder rules, interference
detection (or fold into S5 if only 1-2 plays)
6. S1-[Play].md for each play — thesis, phasing, initial workstreams
7. Wiki/index.md — initial navigation catalog
8. A daily log template — what gets ingested each day
Design principles:
- Separate strategy by rate of change (S5 quarterly, S4 monthly, S3 weekly,
S1 continuous)
- Each S1 is recursively viable
- Pressure map should be concrete: who, what, why, lever
- LLM maintains all wiki pages — human never edits entity pages directly
- Raw sources (daily logs) are immutable; wiki is the synthesis layer
- Be frank — the strategy is private
| Cadence | Strategy (VSM) | Knowledge (Wiki) |
|---|---|---|
| Daily | Update S1 checkboxes | Ingest daily log → LLM updates entity pages |
| Weekly | Glance at S3: ledger growing? Plays fed? Pressure map stale? | Review wiki for surprising patterns |
| Monthly | Update S4: new signals? Scenarios still hold? | Lint: contradictions, orphans, stale claims |
| Quarterly | Revisit S5: decision rules still reflect reality? | Prune dead entities, archive closed threads |
If S5 is changing monthly, you haven't converged on your goals — name it. If S4 hasn't been touched in 2+ months, you're executing on stale intelligence. If the wiki hasn't been ingested in a week, the flywheel has stopped.
The VSM + wiki structure is a starting point. Once you've run the system for a few weeks and have a feel for where your analysis is thin or your S4 lacks structure, consider layering in additional frameworks. These are not required — they're analytical methods that sharpen specific VSM functions when prose alone isn't cutting it.
Simon Wardley's mapping method gives S4 an evolution axis and a vocabulary for movement. Without it, S4 landscape assessments are prose opinions. With it, you can plot where components sit on the genesis→custom→product→commodity spectrum and identify where movement is happening.
| Wardley Concept | VSM Function | What It Adds |
|---|---|---|
| Value chain + evolution axis | S4 | Shows where your plays sit relative to component evolution — are you building on something that's commoditizing beneath you? |
| Climatic patterns | S4 | Structural forces that happen regardless of your actions (commoditization pressure, co-evolution of practice with technology). The "weather" your strategy operates in |
| Inertia | S4 + S3 pressure map | Explains why stakeholders resist. "Their value is tied to a component evolving past them" is sharper than "they resist change" |
| Doctrine | S3 | Universal good practices for operating — maps to compensating controls and execution discipline |
| Gameplay | S1 | Named strategic moves (open-source a competitor's differentiator, exploit an inertia gap, land-and-expand). Gives plays deliberate structure beyond "do the work" |
When to add: If your S4 feels like a list of opinions rather than a structured read of movement. If you're struggling to explain why a stakeholder will or won't act. If you need to communicate positioning to someone else visually.
Start with: Map the value chain for your primary play. Place components on the evolution axis. Identify where inertia exists in the people around you. You don't need a full Wardley Map — even a rough positioning gives S4 analytical teeth.
John Boyd's Observe-Orient-Decide-Act loop maps directly to the S4→S3→S1 cycle but adds emphasis on tempo — the speed at which you cycle through observation and action relative to your environment. The insight: if you cycle faster than the people around you, you shape the environment rather than reacting to it.
When to add: If you notice your S4 entries are always post-hoc ("I learned this happened last month") rather than anticipatory. If your strategy feels reactive. If you're in a competitive dynamic where someone else is also maneuvering.
How it maps:
- Observe = S4 scanning (what's happening?)
- Orient = S4 synthesis + S5 decision rules (what does it mean given who I am?)
- Decide = S3 allocation (where do I invest attention?)
- Act = S1 execution (do the work)
The key discipline: complete the loop. Most people observe and act without the orient step (they react without contextualizing). The VSM forces orientation because S4 synthesis has its own file — you can't skip it.
Clayton Christensen's JTBD framework is useful when your plays involve other people adopting something — a tool, a process, a product, an idea. Instead of asking "what does this stakeholder want?" ask "what job are they hiring a solution to do?"
When to add: If your pressure map has entries where the lever is "convince them" but you can't articulate why they'd care. If you're building something that needs adoption (a platform, an RFC, a process) and struggling with positioning.
How it maps: Each pressure map entry in S3 gets sharper: "VP Engineering needs to adopt X" becomes "VP Engineering is hiring for 'make my platform team credible and productive' — adopting X is evidence of architectural decisiveness, which is his job."
Dave Snowden's Cynefin framework distinguishes between simple, complicated, complex, and chaotic domains. Useful for deciding how to approach work in different S1 workstreams — not all problems respond to the same method.
When to add: If you notice some workstreams respond well to planning (milestones, timelines, dependencies) and others resist it (the plan breaks on contact with reality every week). Cynefin gives you permission to use different approaches for different types of problems.
How it maps:
- Complicated workstreams (a platform migration, compliance milestones) → plan and execute, expertise matters
- Complex workstreams (organizational positioning, culture shifts, adoption campaigns) → probe-sense-respond, safe-to-fail experiments
- Your S1 file can note which domain each workstream operates in, which prevents applying the wrong management style
Goldratt's TOC identifies the single constraint limiting throughput and focuses all effort there. Useful when your S3 attention allocation is diffuse — you're spreading effort across 8 workstreams when only one is actually on the critical path.
When to add: If your S1 has many open workstreams but progress feels slow everywhere. If you can't answer "what's the one thing that, if unblocked, would accelerate everything else?"
How it maps: S3's sequencing tracker should identify the current constraint. All other workstreams are subordinated to it. Constraint shifts → sequencing shifts. This prevents the common failure of "working hard on everything, progressing on nothing."
Shell/Schwartz-style scenario planning constructs multiple plausible futures and stress-tests strategy against each. More structured than the "endgame scenarios" in S5 — formal scenarios have named axes of uncertainty and 2x2 quadrants.
When to add: If your S5 endgame section feels like a list of possibilities rather than a structured analysis of what drives the fork. If you want to pressure-test "does my near-term action portfolio actually increase value across all scenarios?"
How it maps: Pick the two most consequential uncertainties (e.g., "does the org restructure or hold steady?" x "does the market window open or close?"). Build the 2x2. Check each S1 action against all four quadrants. Actions that only work in one quadrant are fragile; actions that work in all four are robust.
The system is tool-agnostic but works well with:
- Obsidian — Local markdown editor with graph view (visualize hub pages vs. orphans), wikilinks, and Dataview plugin for dynamic queries against YAML frontmatter
- Obsidian Web Clipper — Convert web articles to markdown for raw source ingestion
- Git — The whole system is just a repo. Version history, branching, diffs included for free
- Claude Code / similar LLM agents — The agent that maintains the wiki. Runs ingest, lint, and query operations. The schema (CLAUDE.md) configures its behavior
- Marp — Markdown slide decks if you need to present from wiki content
Everything is plain markdown. No lock-in. The LLM is the only moving part that isn't a text file.