Create a cloud simulation

Versioned provenance of prediction basis, not a claim simulated outputs were observed. CPU is mean serving app-host CPU (not aggregate cpuUsage); no apps means appCpu=null and an empty per-resource array. latencyP99Basis independently identifies the P99 basis: owned in-VPC internal-ALB fit, scaled from that fit (not directly measured), or uncalibrated generic P99. predictionEvidence.latencyP99, when present, carries P99's evidenceLevel and low/central/high assumption interval; it is prediction provenance, not observed simulated output, and not a statistical confidence interval. When latencyPercentileStatus is unavailable, public latency percentiles are null; a serving resource without a modeled latency distribution does not support P50/P95/P99. Fargate allocation/billing/capacity facts alone do not establish workload latency. Resilience timeoutMs is a per-edge, per-attempt deadline over local service time, target base latency, injected latency, and queued wait, not a deadline against aggregate chain percentiles. Historical evidence may omit or null this optional quantity. latencyBasis names the general modeled latency path; use latencyP99Basis for P99. Ranges are assumption intervals, not confidence intervals. Measured lean uses 0.65–1.35 times the center; lean proportional AWS M5 scaling uses CPU 0.40–1.60 and latency 0.50–1.50 times the final reported P50/P95 centers (after applicable penalties). The lean scaled baseline uses offered application RPS T: P50 = max(1.45, 2.4833 - 0.0010466T) ms, P95 = max(P50, 3.10, 4.3697 - 0.0012973T) ms (full-precision fit). On the exact healthy lean owned ALB → 2× m5.large → MySQL db.r5.large graph at 10–1,000 offered target RPS, P99 uses max(final P95, 7.021919127633514 + 0.00027013891327780484*T) ms, fitted by ordinary least squares on the owned campaign's 10/100/500 RPS P99 measurements. The 1,000-RPS point is a holdout, not a fit point. The owned fit is a prediction, not a new observed sample or a provider measurement. Exact eligible P99 uses 0.65–1.35× assumption bounds; analogous lean M5 sizes use the fit as scaling (0.50–1.50× within range), not direct measurement. Beyond 1,000 RPS scaling/extrapolation uses 0.25–2.00×. Generic typical/heavy and ineligible paths retain the generic, unverified P99 formula, with 0.50–2.00× bounds in-range and 0.25–3.00× beyond. Active failures disqualify a healthy measured P99 claim. The exact owned typical Node CRUD path instead fits P99 from 20/100/200 RPS measurements; this is a prediction, not an observed output or a general typical-app reference. Its 300 RPS holdout is not fitted. Matching one- and three-app-server topologies are explicitly labeled owned-scaled and derive app CPU/latency/goodput from equivalent two-server fit load (2 × total RPS ÷ app-server count); their server counts were not measured. Database CPU and connection demand still use total offered traffic. One server at 300 total RPS requires a 600 RPS equivalent fit extrapolation beyond the holdout, with P50 held at its 300 RPS projection. Pool-capacity comparisons are warnings only and do not independently imply errors or throughput loss. The final P99 is floored at final P95; P99 is not scored in Accuracy. No generic 5 ms floor applies to scaled lean latency; 0.05 ms is only a physical/non-finite safety floor. Reference estimates use 0.50–2. Beyond 1000 offered RPS, scaled uses 0.25–2 and reference 0.25–3. Unknown-vCPU legacy fallback uses the widest reference range and has no external reference. legacyGeneric explicitly labels use of that unverified generic branch: true at the top level if any reported app CPU or latency quantity used it, and true on each affected appCpuByResource item. The evidence note names each affected resource's shape and reason (missing vCPU, flexible shape without resource.characteristics.ocpus, or unknown/ unrecognized shape). CPU ranges are physically capped at 100%. Prediction-only capacity metadata covers GCP E2 standard e2-standard-2/4/8/16/32, N1 standard n1-standard-1/2/4/8/16/32/64/96, and N2 standard n2-standard-2/4/8/16/32/48/64/80/96/128. Google-published vCPU and memory specifications establish hardware dimensions only, not CWM performance, throughput, or price. Historical rows missing evidence are returned non-mutating as unavailable/legacy with null weight/load/quantities and empty IDs; they are never relabeled measured by today's model.

Trusted server-side attribution copied from the live scenario catalog; absent for explicit resource-graph creates.

Read-only introspection of what CWM actually modelled from the creation payload. Returned on POST /api/simulations (201) and GET /api/simulations/{simulationId} so a consumer can verify the resolved billing and capacity values per resource — e.g. why two payloads that look identical produce different costs (different resolved size, GPU SKU, or cost multiplier). Every value is derived with the same resolution functions the billing/autoscale engine uses.

Immutable, versioned receipt stored at creation and returned unchanged by create, get, and step responses. It records each material assumption's source: human/API input, MCP/agent input, platform default, catalog resolution, engine inference, or unsupported fallback. It makes normalized Kubernetes inputs comparable without requiring equivalent natural-language prompts.

Dependency-resilience model for a simulation. When attached (via simulation.resilienceConfig), the step engine traverses declared dependency edges, applies retry policies and circuit-breaker state, and emits retryAmplificationFactor + full resilience telemetry in every step response.

Limits (shared with the engine to prevent unbounded work):

• dependencies: max 64 edges
• scheduledFaults: max 32 faults
• maxRetries per dependency: max 8
• maxCascadeDepth: max 8
• maxGeneratedRps: max 500,000 RPS
• maxStepWork: max 2,048 work units per step

Version: only version: 1 is accepted.