The VISM technical book treats product strategy as a set of falsifiable hypotheses. A compelling control-plane design does not by itself prove that a customer will place it on a production write path or pay for it.
MVP proposal
The proposed MVP demonstrates one Kubernetes service onboarding path: restore-test baseline, human-sealed Checkpoint 1, agent scale/image proposal through REST/CLI/MCP, inspector report, deterministic policy, signed plan approval, staged execution, independent verification and tamper-evident audit export.
| Included early | Explicitly not included early |
|---|---|
| One cluster/service; stateless scale and image actions; three authority modes; typed adapters; checkpoint/audit; REST/CLI/MCP thin clients. | Generic shell; universal multi-cloud topology discovery; destructive database automation; blanket controller disablement; unverified enterprise certification. |
Roadmap gates
The source roadmap proposes an MVP in 0–12 weeks, then a 3-month read-only/shadow pilot, a 6-month v1 with more services and ownership adapters, and later selective platform domains. Expansion depends on staging safety scenarios, customer willingness to place the control in the write path, paid pilot evidence, recovery/drift/concurrency drills and repeatable onboarding—not calendar passage alone.
Customer and commercial hypotheses
The initial ideal profile is a software organization with Kubernetes production, a platform/SRE team, usable telemetry and interest in automation. The hypothesized buyer is Head of Platform or VP Engineering with security as co-buyer and senior platform engineers as champions. These are hypotheses to interview, not market survey findings.
The source proposes a protected-environment and protected-service pricing metric rather than per-server or per-tool-call billing. Pilot, managed and enterprise prices are explicitly hypotheses and should not be represented as validated public pricing.
What could become a moat—and what cannot
A gateway, reasoning prompt, hash chain or approval button is not a moat on its own. A defensible advantage would require accumulated, high-quality transition evidence; dependency provenance; reusable verified templates; policy history; recovery outcomes; adapter conformance and integrations that reduce real customer replacement cost without locking in data.
Validation questions
- Will customers permit the control boundary in a real write path?
- Can all agent bypasses be closed for a narrow scope?
- Is the dependency graph sufficient to avoid harmful false confidence?
- Do humans understand plan scope instead of rubber-stamping?
- Is restore testing economical and repeatable?
- Can the product deliver measurable value and repeatable onboarding before support cost overwhelms it?