Mapping the estate onto VSM, S1/S2/S4/S5 all have live or dev-stage tooling, but S3 — the organ that turns sensed opportunity and strategic intent into sequenced, resourced operations — is fragmented across stale vv-ops prose, a flat 72-row capability-ask registry, and a not-yet-built Engage. A viable system with a hollow S3 senses and reasons well but cannot manage itself; this is where the next build cycle must concentrate (ENGAGE + HR-SYS are the S3 frontier).

The suite graph (27 nodes / 112 edges) recovers a real B2C2B feedback loop as a strongly-connected component: public content attracts clients, client work generates evidence, evidence feeds public content. But the loop is broken in practice because RADAR is only proposed and the signal contract is unbuilt — sensed market signals cannot flow into reasoning or content. Shipping radar/signal is the single highest-leverage act for making the flywheel real; propagation cost across the graph is 20.8%.

operate's identity: strategy→analysis with live artifacts across four substrates — Graph (DSM/BDN/OST), Space (Wardley/AIR), Dynamics (stock-flow/ToC/diff-in-diff), Category (Cynefin). It is explicitly not a document generator (that is doc-studio's job). But as the REASON node it has no sensing input: nothing feeds it external signals, so all reasoning starts from manually-entered state. It reasons in the dark until the signal contract connects it to Monitor/radar.

The founding bet: a 2-person firm can match the variety of the AI-transformation market (Ashby/Beer sense) by building amplifiers — ~20 tool repos acting as variety attenuators and amplifiers around the founders. If this holds, the suite is the firm's viability mechanism, not overhead. Every repo must therefore justify itself as an organ in the VSM reading, not as a side project.

Clients buying AI transformation will accept — and prefer — a 2-person firm whose delivery is visibly instrumented (live graphs, scored diagnostics, generated artifacts) over a body-shop consultancy. The tooling is itself the credibility signal: "we run on this, so can you." Unproven at scale; Dr Max is the single supporting data point.

Every tool is built multi-tenant-capable (engagement_id on every entity, no hardcoded client) but deployed single-tenant per engagement by default. This keeps client-data isolation trivial to argue, makes migration to client-owned infrastructure a data export rather than a re-architecture, and defers real multi-tenancy cost until engagement volume forces it.

The ~20 repos are not a portfolio of apps but a single Business OS read through the Viable System Model: S5 = founders + methodology canon + brand; S4 = Monitor/sensing + evidence graph; S3 = vv-ops + delivery + backlog; S2 = vv-standards + catalog + iam + design-system; S1 = client engagements tooled by Transform, Workshop, Engage. The same organs recur at three scopes — suite, market, client — which is VSM recursion, not metaphor.

The suite composes through exactly five contracts: (1) iam-JWT for identity, (2) catalog entity/slug for shared vocabulary, (3) "signal" for the sense→reason seam, (4) VVDOC for documents, (5) engagement-graph export for delivery data. Everything else is a repo-local decision. Contract (3) is the only one not yet built — it is the keystone gap, and its absence is what keeps sensing disconnected from reasoning.

The suite deliberately maintains three separate knowledge graphs: sensing (radar) for market signals, evidence (AIT) for the public evidence-claim graph, and reasoning (operate) for per-engagement strategy graphs. They connect via typed handoffs (the signal contract, read-only augmentation), never via a merged uber-graph. Merging would destroy provenance boundaries and couple client IP to public data.

Consolidate methodology v0.1 (~25K words) to v0.2 (~16K), turning the un-versioned methodology IP into a versioned, meta-layered asset with Delphi validation queued toward v1.0. Sequenced first because everything downstream depends on it: authoring-MCP scope (M3), cohort curricula stabilization, and the IAM migration window (M2) all key off a frozen v0.2. In VSM terms it hardens S2 (standards/canon) and closes the 'methodology IP un-versioned' live gap, giving the VVDOC contract a stable payload. Big-4 archetype-methodology productization makes the v1.0 timeline pressure real. Horizon: 90 days; in flight.

Migrate the self-built Node IAM to a commodity provider (Auth0/Clerk), porting the federated permission model and re-issuing tokens across operate, workshop, and AIT. It is the classic Wardley anti-pattern — Custom where Commodity exists — and buying it back frees scarce senior-operator hours for the moat work. Deliberately deferred until M1 closes to avoid paying migration cost twice; it stabilizes the iam-JWT contract (one of the five suite contracts) and, as a co-benefit, forces retirement of operate's presence-gated auth. This is S2 hygiene that de-risks every S1 tool. Horizon: ~6 months, gated on M1.

Ship the 7-verb authoring MCP (generate / insert / edit / apply_brand / render / validate / publish) on top of the brand-emitting design system and format adapters; GUI editor deferred to v2. Sequenced after M1 because the MCP authors against versioned methodology IP — without v0.2 frozen, the orchestrator has no stable canon to compose from. It stands up the second moat and operationalizes the VVDOC contract, effectively giving S3/S4 a production arm: sensed insight becomes branded, multi-format client artifact without senior hours per artifact. No obvious commercial equivalent exists for the MCP + brand-emitting-DS + multi-format combination. Horizon: ~12 months.

Standardize the 4–8 week diagnostic into a fixed-price, repeatable-scope productized intake — the map's cleanest Custom → Product transition (engagement-shape-flexibility drifting right). It sits last because it consumes everything upstream: versioned methodology (M1), reclaimed operator capacity (M2), and MCP-authored deliverables (M3) are what make a diagnostic repeatable without diluting quality. Strategically it is the S1 mouth of the B2C2B loop — a low-friction entry product that converts radar/cohort-sensed prospects into engagements and reduces sales-cycle variability. Explicit trigger: after two Lighthouse engagements close with a repeatable diagnostic shape. Horizon: 12–18 months.

Product naming moves to plain product names: operate becomes Transform (working name), sensing becomes Monitor. The internal SENSE/REASON/EXPRESS verb taxonomy stays an architecture concept but is dropped from user-facing UI — clients buy tools, not epistemology. Repo and infrastructure renames are deferred to a cleanup pass, as with the earlier engege→operate rename.

Each client engagement gets its own isolated reasoning graph, optionally augmented with read-only market-intel overlays — never merged into a shared graph across clients. This preserves confidentiality by construction, makes client offboarding a delete/export, and keeps the market-intel layer reusable without contaminating it with client IP. Validated by the Dr Max engagement structure and the three-KG architecture.

v1 integration between Workshop and delivery tooling is a manual JSON/CSV export/import cycle, not a live service-to-service API. Workshop has no formal external auth model today, and a real S2S contract is a cross-repo project that would stall v1. The proper API integration is specced as a v1.5 deliverable; accepting the manual bridge is a deliberate ecosystem-light trade.

operate and aitransformers-platform are converging on the same strategy-canvas/method engine for two audiences — the biggest open architecture decision. Current leaning: extract the shared method/render engine as a common layer while keeping the data kernels distinct (engagement-graph vs evidence-claim graph), so the "never merge the graphs" invariant survives code reuse. Needs a spike to test whether the engine can truly be kernel-agnostic before committing.

Leading engagements with a scored diagnostic (AIR, profitability/automation-potential) rather than a transformation proposal lowers the client's initial commitment threshold and produces the evidence that justifies the larger engagement. If true, the diagnostic tools are the top of the funnel, not deliverables — which changes how much polish they warrant. Testable across the next 2–3 client entries.

Running VisionVolve's own strategy — these notes included — through operate exercises every substrate against a real, messy, evolving subject and surfaces gaps no synthetic demo would. It also produces the strongest sales artifact: showing a prospect the tool running the firm that built it. Falsified if the VV engagement graph goes stale within a quarter.

Dr Max has a fuller presence in the suite than VisionVolve itself: a seeded engagement, scored diagnostics, populated graphs, branded UI. VV's own strategy exists as prose and memory files, not as typed entries in its own tooling. An uncomfortable but useful signal — the tools work for a real subject, and the firm hasn't paid itself the same discipline it sells.

Estate snapshot: 27 nodes / 112 edges; 20 tools live; operate, AITP, and AIR in dev; VV-NEWS dormant; RADAR proposed; ENGAGE and HR-SYS planned. Every VSM function has at least nascent tooling except operational management — there is no organ that sequences work, allocates the two humans' capacity, or closes the loop between roadmap and delivery. The estate's shape itself diagnoses the S3 gap.

The canonical methodology markdown — the firm's core IP and the S5 canon — exists as un-versioned files on Anton's laptop. A single device loss destroys the asset the entire suite operationalizes. Mitigation is trivial (private git repo + versioning discipline) and overdue; this is the cheapest-to-close highest-stakes risk on the register.

Roughly 10GB of client engagement audio recordings sit unencrypted, containing personal data of identifiable client staff. This is a live GDPR exposure (storage without adequate technical measures) that could poison the trust positioning of a firm selling governed AI transformation. Needs an immediate encrypt-or-delete pass plus a retention policy.

Suite direction is fragmented across stale vv-ops prose and a flat 72-row capability-ask registry with no sequencing, dependencies, or capacity model. For a 2-person firm this means prioritization happens implicitly in whoever's head is active — precisely the S3 failure the VSM analysis predicts. The fix and the S3 build-out are the same workstream: the roadmap should be the first artifact managed in the S3 tooling.

operate currently checks only for a valid session, not roles/permissions: 15 server actions execute without authorization checks. Acceptable for a single-operator playground, unacceptable the moment a client or second user touches a deployment. Must be closed before any client-facing deployment of Transform.