Execution begins only after a typed final plan is sealed, policy has made a decision and the required human authority is current. The design treats a production effect as a separate boundary from the control database transaction.
Dependency graph and blast radius
The graph is operational context with provenance, not only a network drawing. A service can share a database, queue, cache, NAT, quota or failure domain with another service that does not call it directly. Each edge carries source, freshness, confidence and status; conflicting sources stay visible rather than being resolved optimistically.
Illustrative capacity ceiling
| Constraint | Illustrative ceiling | Interpretation |
|---|---|---|
| Database connections | 240 replicas | 4,800 available connections ÷ 20 per replica after headroom/allocation. |
| External API | 350 replicas | Remaining request budget at target workload. |
| Cluster capacity | 1,200 replicas | CPU/memory after surge reserve. |
| Network/NAT | 800 replicas | Benchmark-derived equivalent capacity. |
| Cost | 500 replicas | Approved budget horizon. |
The conditional upper bound is the minimum: 240. This is not a safety certificate. Missing capacity is not infinite capacity; CPU/IO, cache, queues, load balancer health, storage and unknown dependencies may lower the actual safe envelope.
Dispatch and permit
- Claim the workflow, establish fencing and reserve dependency/cost budget.
- Refresh critical state and recheck policy, approval, graph and checkpoint eligibility.
- Persist dispatch intent and wait for durable audit acknowledgement.
- Issue a single-use permit bound to plan, step, payload, targets, adapter and epoch.
- Validate permit and conditional write at the broker/admission boundary.
- Send the typed provider API call and retain the provider operation identity.
- Poll/read with a verifier identity, then enter verification.
Idempotency, drift and reconcile
A lost response after a write is normal distributed-systems behavior. VISM enters RECONCILING, reads provider receipts/state and determines attribution before any retry. A target that changes UID, a duplicate key with different payload, an unsupported non-idempotent action or a changed graph can invalidate the plan rather than produce a best-effort action.
Staged execution
Stages are part of the approved plan. Each has warmup, readiness, soak, technical/application/dependency/cost checks and recovery rules. PASS advances; FAIL aborts; UNKNOWN remains blocking until deadline then freezes or hands off. No stage may exceed a policy bound merely because an illustrative visual showed a larger jump.