# Model Runtime Acceptance Runbook ## Before Changes - Record the target deployment and identity mode. - Confirm administrator identity with `/api/v1/me`. - Save current provider, base model, pricing rule set, policy set, platform, and platform-model JSON without secrets. - Confirm whether real upstream calls are allowed; otherwise use simulation. - Confirm upstream endpoint, auth, model name, capabilities, limits, pricing, and sync/async behavior from documentation. - Record which existing pricing rule and runtime policy were reused, or the exact semantic mismatch that required a new one. - For billing changes, save the current effective rule bindings, discounts, user-group policy, wallet balance, and one representative estimate response as described in `model-billing-configuration-and-estimation.md`. - Record the protocol compatibility decision and why the selected existing `specType` is sufficient, or the concrete gap that requires `universal`. - When one base model has different upstream names across platforms, confirm each binding resolves the expected `providerModelName`. ## After Configuration Read back: - `/api/admin/catalog/providers` - `/api/admin/catalog/base-models` - `/api/admin/pricing/rule-sets` - `/api/admin/runtime/policy-sets` - `/api/admin/runtime/runner-policy` - `/api/admin/platforms` - `/api/admin/models` Verify that IDs and bindings resolve as intended and no unrelated record was removed or reset. ## Catalog Verification Use an authorized user JWT: ```bash curl --fail-with-body \ -H "Authorization: Bearer " \ "$GATEWAY_BASE_URL/api/v1/model-catalog" ``` Confirm model alias, model types, provider source, effective capabilities, pricing summary, rate limits, permissions, and enabled state. For pricing, verify the effective rule source and discount source rather than checking IDs only. Confirm whether the platform-model discount overrides the platform default, and compare the estimated or simulated amount with the intended price. Use `/api/v1/pricing/estimate` for the first read-only calculation. A simulation request is a task execution path and may reserve and settle wallet billing; do not treat it as a read-only replacement for the estimate endpoint. ## Execution Verification Start with simulation: ```bash curl --fail-with-body \ -H "Authorization: Bearer " \ -H 'Content-Type: application/json' \ -d '{ "model": "", "messages": [{"role":"user","content":"Reply with OK"}], "runMode": "simulation", "simulation": true, "stream": false }' \ "$GATEWAY_BASE_URL/v1/chat/completions" ``` Simulation verifies Gateway routing, permissions, parameter normalization, pricing, and task behavior, but it does not execute the real universal submit or poll scripts. Validate universal scripts separately against a local mock or approved provider test environment before enabling production traffic. For media or universal scripts, inspect: - `/api/workspace/tasks/{taskID}` - `/api/workspace/tasks/{taskID}/events` - `/api/workspace/tasks/{taskID}/param-preprocessing` - `/api/admin/runtime/model-rate-limits` - `/api/admin/runtime/rate-limit-windows` With explicit approval, run one real minimal request and verify upstream request ID, normalized output, task completion, `billings`, `billingSummary.totalAmount`, `finalChargeAmount`, and the wallet `task_billing` transaction. Explain any expected estimate difference caused by actual token usage, cached input, generated media duration/audio, preprocessing, or failover to another platform. ## Rollback - Restore the prior complete resource body with PATCH. - Restore an individual platform-model binding through POST. - Use full platform-model PUT only when the saved list is complete and replacement is intentional. - Remove newly created resources in reverse dependency order only after explicit confirmation. - Use runtime restore only after the upstream problem is resolved. ## Final Report Report resource IDs, before/after behavior, requests used for verification, simulation or real mode, billing evidence, remaining risks, rollback readiness, and whether `/api-docs-json` was used. Never include credentials or raw secret-bearing payloads.