# V11: the network simulation executes its plan through APIs V10 added a standalone transaction demonstration. V11 connects the network planner itself to the mock APIs. A power interruption, maintenance period, access failure, backhaul outage or demand change affects the allocation plan. The selected policy's proposed paths then become API requests, using their actual operator groups, resources, quantities and two-hour windows. ## Decision and execution are separate steps 1. The browser solver proposes a feasible allocation for each window. Its five-policy comparison remains a planning experiment. 2. The client decomposes the chosen allocation into demand-group → RAN-host → backhaul paths. It preserves both flow matrices and the amount of demand. The aggregate solver does not uniquely pair each buyer with a backhaul route. A deterministic decomposition supplies that pairing and execution order; under scarce budgets or credit, those choices can affect which purchases succeed. 3. For a path that uses another operator's resource, the client discovers offerings and agreement terms, requests a quote, accepts it, submits a product order and requests service fulfilment. The server decides whether demand, capacity, budget and credit allow the order. 4. Only mock fulfilment verification adds the path's Mbps to delivered service. Rejected orders and failed or unknown fulfilment do not count as delivery. The map animates these verified paths, rather than assuming the proposed allocation happened. 5. Fulfilment evidence feeds the proposed IODSP commitment and statement APIs. Charges use the actual owner of each purchased component. A path using two sellers produces separate bilateral statements. An own-network path calls the shared admission service but creates no inter-operator quote, purchase or charge. Own fulfilment is assumed after those availability and capacity checks; the external success/failure/unknown injector applies only to purchased paths. It still consumes its share of RAN and transport capacity, so the external purchases cannot use that capacity again. ## Sim and Demo modes The top switch controls execution pace. **Sim** processes the selected plan as quickly as the APIs respond. **Demo** gives each two-hour network window a minimum of two seconds, so one simulated hour corresponds to one second. The map follows the active window. API delays or unresolved outcomes can hold the clock; they never create unverified traffic. The right-hand log sits beside the network animation and scrolls independently. It retains call metadata for the current run, with expandable request/response JSON. Large state responses are explicitly summarised in the trace; the exported latest server state remains complete. Pausing Demo retains in-flight outcomes and prevents further requests from starting until resumed. Changing modes starts a fresh execution against the same proposed plan. ## One shared run, not independent toy transactions A Durable Object represents one synthetic network run. It owns the three operator groups' spending and directional credit accounts, all 24 time windows, and the reservations for RAN, backhaul and demand. Successful service retains its capacity booking for that historical window. Unknown activation retains reservations and blocks later reuse of the affected resource until resolved. Each mutation carries an idempotency key. The server derives demand and availability from the validated scenario, including outages, backup endurance, permissions and reachability. It does not run the optimiser or accept the browser's claim that a path was delivered. The browser supplies a proposed path; the mock network admits and verifies it. This shared authority is a demonstration boundary. Real competing operators would retain their own inventory, accounts and permissions. Cross-operator admission, authentication and compensation would require further work. ## What changes when the APIs refuse a plan An allocation can fit the engineering constraints and still fail a commercial or fulfilment gate. The execution view reports the resulting verified Mbps and shortfall. Unknown responses pause execution for explicit resolution or retry. Changing inputs or selecting another policy invalidates the prior execution; cached playback and timeline inspection do not create more purchases. This version executes the selected plan. It does not automatically search for another supplier after a rejected purchase. That is a next decision-policy experiment, with the current API outcomes providing the inputs. ## Read the two ledgers separately The original cost comparison estimates energy, retained facilities, transport, switching and coordination under each proposed policy. The API ledger records buyer spending and seller receivables for the selected execution. A payment between operators redistributes money; it is not an additional combined resource saving. Failed execution does not validate the plan's cost advantage. The planning estimates are labelled separately from delivered service. Prices, spending limits and credit limits are editable demonstration assumptions. They are not extracted from operator contracts. No live LLM, network equipment or payment rail is used. ## API boundaries - TMF620 / TMF651: offerings and agreement context. - TMF648 / TMF622: quote and commercial order. - TMF641 / TMF638: service order and inventory. - Proposed IODSP profile: delivery-linked commitments, charges and bilateral statements. - Explicit mock controls: synthetic network fulfilment and resolution of uncertainty. See the [network execution contract](../../cloudflare/network-api/CONTRACT.md) for supported requests. The existing [standards profile](MOCK_API_STANDARDS.md) identifies the pinned fullCIRCLE and TM Forum references. These are bounded implementation subsets, not conformance claims.