← Workspace·visionvolve-internal

VisionVolve — Internal

Greenfield install · GroupWide
Greenfield

Strategic notes

Assumptions, hypotheses, analyses, observations, claims, risks, decisions. The reasoning trail behind the engagement — the thing the brief and concept docs draw from.

Assumption·active·confidence: medium·source: memory:vv-business-os-vision
Requisite variety is engineered with tools, not headcount

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.

vsmvisionrequisite-varietystrategy
Assumption·active·confidence: medium·source: inference
The AI-transformation market rewards a heavily-tooled boutique

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.

marketpositioningvision
Assumption·active·confidence: high·source: doc:2026-07-09-ecosystem-and-suite-citizenship
Single-tenant deployments, multi-tenant-capable code

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.

architecturemulti-tenancydeployment
Add note
Markdown supported
Where did this come from? interview:Peter Varga, doc:concept-v0.3, inference
Comma-separated