Run one hybrid ML and rules simulation step

Optional hybrid engine configuration overrides

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.

Metrics snapshot for this step. throughput is successful throughput (goodput). The normal simulation engine emits offeredRps on the final top-level step result as the aggregate original-client offered load for the same step/window. Legacy persisted histories may omit it; it is never derived from retry/path/per-resource figures.

One per-step hybrid referee decision.

Resource/behavior and base-rate coverage summary for this hybrid step — what CWM could model deterministically, what it estimated, and what it could not see at all. level never means complete economic or invoice coverage; inspect billingPolicyCoverage separately. Shares are of SIMULATED cost, never a real bill; known gaps are listed by name with a zero share. Also persisted on each decision in the cumulative hybrid result.

Share distribution: shareOfSimulatedCost values do NOT necessarily sum to 1.0. When an unrecognized SKU is present its share is deliberately forced to 0. Use modeledCostShareOfTotal as the authoritative denominator.

Cumulative hybrid decision history and summary statistics for a simulation.

Present only on x402 (wallet-paying) calls. Describes the wallet that owns this simulation and when that ownership expires.