HOW IT WORKS
Every effect must earn the next state.
VISM turns a typed AI proposal into a controlled transition with pinned state, policy, authority, staged execution and independently evaluated evidence.
THE CONTROLLED LIFECYCLE
Eight steps, one transition record.
The exact modules may evolve, but the sequence preserves a key distinction: an agent recommendation is not authority, and an effect receipt is not verification.
- Capture current stateCollect scoped observations, dependency context and recovery evidence with freshness and provenance.
- Receive a typed proposalAccept a schema-bound action with target UIDs and an idempotency context—not free-form shell.
- Inspect the changeIdentify missing evidence, dependencies, contradictions, blast radius and possible recovery paths.
- Evaluate policyApply deterministic scope, capacity, cost, risk, incident and recovery constraints.
- Bind approvalSeal the final plan; human authority attaches to its exact hash when required.
- Execute progressivelyIssue a constrained permit per step after live preflight and durable intent recording.
- Verify resultEvaluate technical, application, dependency, business and cost evidence.
- Commit or recoverOnly PASS advances the verified state. FAIL or UNKNOWN stops progression and invokes recovery/handoff.
STATE MACHINE
Unknown is a control outcome, not a cosmetic warning.
A transition moves through validation, approval, execution and verification. Drift, expired authority and uncertain effects have explicit states rather than being silently retried.
DETAILED SCALE EXAMPLE
A 3 → 1,000 request is evaluated as a dependency problem.
A source-backed illustrative model has a database ceiling of 240 replicas, an external API ceiling of 350, network 800, cluster 1,200 and cost 500. The minimum ceiling is conditional—not a guarantee.
LIVE DEPENDENCY CHECKS
- Database capacity 240 ceiling
- Cache and queues
- Network and load balancer
- External API quota
- Cloud quota and cost
- Recovery readiness
Illustrative only: the smallest evidenced constraint bounds the plan. Missing capacity is not treated as infinite capacity.
WHAT HAPPENS AT EACH STAGE
Staging prevents a large desired change from becoming an unobserved large effect.
A plan defines its stages before it is approved. Each stage has warmup, verification rules, recovery behavior and a bounded next step.
| Stage | What VISM checks | What can stop progress |
|---|---|---|
| 3 → 10 | Target identity, live preconditions, first permit and readiness. | Drift, invalid approval, missing evidence. |
| 10 → 50 | Dependency health, workload response, observed cost and soak window. | FAIL or UNKNOWN from required rules. |
| 50 → 200 | Reserved shared capacity, policy bounds and verified prior step. | Exceeded per-step limit or changed graph context. |
| Beyond 240 | A new plan could be proposed only after the binding dependency changes with its own evidence. | Current dependency ceiling blocks the requested state. |
RECOVERY IS A TRANSITION
Rollback is not a magic undo button.
Recovery considers compatibility, data loss, blast radius and authority. A failed stage does not authorize arbitrary reversion; it selects a preapproved branch or waits for an appropriately scoped human decision.
Restart only when it is compatible and bounded.
Roll back an image or configuration only with verified compatibility.
Use infrastructure or database recovery only with data-loss and authority gates.
SEE THE FULL SPECIFICATION