The Desk

Mission-critical MCX over a shared commercial operator network

Proposed world objective: determine whether the launch is supportable against owner-approved mission-critical performance and consumer-service non-degradation thresholds, then…

Full framing

Proposed world objective: determine whether the launch is supportable against owner-approved mission-critical performance and consumer-service non-degradation thresholds, then define a staged rollout with explicit entry gates, monitoring, stopping conditions, and rollback. Gate A must supply the missing numerical thresholds and decision deadline; none are inferred here.

SourceModel

Instrument evidence

One exact state for each modeled layer

Chapter 1 · product-launch-sim

The launch analogue creates adoption pressure without proving network safety

Closed-rehearsal Product schedule — refreshed exact state
Result

The frozen state schedules pl_iot_fleet at week 20 and keeps onboarding_fix, seed_community, referral_program, and distribution_push active from weeks 20–52. The existing modeled…

Boundary This identifies adoption pressure that a bounded rehearsal must contain, but it cannot establish consumer-service…
Full evidence-bounded interpretation

The frozen state schedules pl_iot_fleet at week 20 and keeps onboarding_fix, seed_community, referral_program, and distribution_push active from weeks 20–52. The existing modeled comparison is 3995.66337758 active subscribers at week 52 without levers versus 25564.114423 with those levers; the levered run has partial-resolution warnings, and neither run measures consumer-network quality or activates a real offering.

Question this layer answers What does the exact Malaysia product schedule show about modeled uptake pressure while production remains unchanged?
Decision relevance

This identifies adoption pressure that a bounded rehearsal must contain, but it cannot establish consumer-service non-degradation; it therefore supports only the closed model rehearsal, not a production launch.

What you can try next

Open the frozen week-52 state and inspect the four week-20-to-52 lever cards and their warnings without changing the schedule; any changed state would require a new registered scene.

Where the study goes next

Because uptake pressure is modeled rather than observed, the next chapter tests how the prototype readiness state evolves under its illustrative recovery and regression dynamics.

Open live analyzed state →

Chapter 2 · comdyn

Illustrative dynamics leave pressure above the protected state

Modeled MCX readiness dynamics — closed rehearsal context
Result

The frozen two-state model shows protected 0.4584 and pressure 0.5416 with recovery 0.0105 and regression 0.0046 over 1085 modeled days. It is seeded from the prototype readiness…

Boundary The model keeps dynamic risk visible but cannot supply a production gate or consumer-service guarantee; the imbalance…
Full evidence-bounded interpretation

The frozen two-state model shows protected 0.4584 and pressure 0.5416 with recovery 0.0105 and regression 0.0046 over 1085 modeled days. It is seeded from the prototype readiness result and is explicitly illustrative—not an operator forecast, SLA, or target-network observation.

Question this layer answers Do the frozen readiness dynamics show recovery overtaking regression strongly enough to support a launch decision?
Decision relevance

The model keeps dynamic risk visible but cannot supply a production gate or consumer-service guarantee; the imbalance remains a reason to hold the decision at evidence no-go.

What you can try next

Open the frozen state and inspect the recovery and regression parameters alongside the protected/pressure split; treat any adjustment as sensitivity exploration requiring a new scene before use.

Where the study goes next

Those dynamics inherit their starting point from the composite readiness proxy, so the next chapter examines what that index actually measures and leaves unknown.

Open live analyzed state →

Chapter 3 · cidx

Prototype readiness cannot clear a live launch gate

MCX launch readiness index — refreshed
Result

CIDX reports 0.4584 for one entity and one scored observation across six prototype dimensions built from generated data. The state is a modeled decision aid, not an operator KPI,…

Boundary The proxy is useful as a checklist across mission service, consumer headroom, spatial coverage, link security,…
Full evidence-bounded interpretation

CIDX reports 0.4584 for one entity and one scored observation across six prototype dimensions built from generated data. The state is a modeled decision aid, not an operator KPI, SLA, or target-network observation; owner tolerances and production thresholds remain absent.

Question this layer answers Does the composite readiness proxy establish that mission-critical and consumer safeguards are ready together?
Decision relevance

The proxy is useful as a checklist across mission service, consumer headroom, spatial coverage, link security, operational control, and adoption containment, but it cannot authorize production or convert missing thresholds into a pass.

What you can try next

Open the frozen state and inspect the six Stage-6 indicator contributions to see which modeled dimension constrains the composite; do not treat slider changes as new evidence.

Where the study goes next

The index leaves link security and consumer headroom unresolved at the composite level, so the next chapter examines the exact radio and service mix under the published contention sweep.

Open live analyzed state →

Chapter 4 · link-sim

The nominal MCX sweep is not a consumer coexistence test

MCX demand sweep configuration on shared n72 capacity
Result

The connected lookup lk_3c2b6da985e452a192e8b688 is a 15-point sweep from 1× to 8× on n72, 5 MHz, and 25 PRB, with 12 MCPTT, 2 MC-video, 20 MC-data, and 200 IoT flows. Modeled…

Boundary The replayable workload supports a closed model rehearsal and exposes where to demand live coexistence evidence; it…
Full evidence-bounded interpretation

The connected lookup lk_3c2b6da985e452a192e8b688 is a 15-point sweep from 1× to 8× on n72, 5 MHz, and 25 PRB, with 12 MCPTT, 2 MC-video, 20 MC-data, and 200 IoT flows. Modeled completion and deadline completion stay at 1 throughout and PRB utilization peaks at 0.8440542068139872 at 6.5×, but this is a one-trial nominal priority-GBR scheduler simulation, not consumer-coexistence telemetry or a consumer-service SLA.

Question this layer answers What does the exact shared-capacity configuration establish about modeled MCX contention, and what does it leave unproven?
Decision relevance

The replayable workload supports a closed model rehearsal and exposes where to demand live coexistence evidence; it does not support production activation or prove consumer-service non-degradation.

What you can try next

Open the frozen MCX state and inspect the exact scheduler, carrier, flow counts, and lookup limitations at demand scale 1 before treating any sweep variation as a new result.

Where the study goes next

Because none of the four frozen scenes supplies current Malaysian field or consumer-QoS evidence, the analysis closes with the evidence no-go and the review-only DOIL rehearsal contract—not rollout authorization.

Open live analyzed state →

Required evidence gap · Incident Sim

No verified Incident Sim scene is present

Result

This Gate-A faculty has no snapshot bound to the published Study.

Boundary

The finding cannot claim visual evidence from this required layer.

Next

Register and verify the exact Incident Sim state, then publish a revised Study.

Claim-bound findings What the evidence supports—and how strongly 6 bound claims
  1. supported

    The Link Sim reactive-jammer lookup spans 41 points from -10 dB to 30 dB over 1000 modeled trials; deadline completion falls from 0.975 at -10 dB to 0.897 from 11 dB onward,…

    Full claim wording

    The Link Sim reactive-jammer lookup spans 41 points from -10 dB to 30 dB over 1000 modeled trials; deadline completion falls from 0.975 at -10 dB to 0.897 from 11 dB onward, while latency p95 rises above 1000 ms at 2 dB, and the tool states that crypto is modeled rather than real and the jammer is a research abstraction.

  2. supported

    CIDX reports a modeled readiness proxy of 0.4584 for one entity and one scored observation, while ComDyn is an illustrative two-state model seeded from that prototype with…

    Full claim wording

    CIDX reports a modeled readiness proxy of 0.4584 for one entity and one scored observation, while ComDyn is an illustrative two-state model seeded from that prototype with recovery 0.0105, regression 0.0046, and a 1085-day modeling horizon; neither is an SLA or target-network observation.

  3. supported

    Incident Sim still reports no active ticket, no active agent context package, state no_ticket, and publishedForAgent false; its available spatial outputs are a stale immutable ZA…

    Full claim wording

    Incident Sim still reports no active ticket, no active agent context package, state no_ticket, and publishedForAgent false; its available spatial outputs are a stale immutable ZA public-demo replay rather than current Malaysian operator evidence, and the attempted scene failed visual verification.

  4. projected

    Taken together, the rechecked evidence does not establish consumer-service non-degradation on the target commercial network, so production activation is not supportable from the…

    Full claim wording

    Taken together, the rechecked evidence does not establish consumer-service non-degradation on the target commercial network, so production activation is not supportable from the current record; this is an evidence no-go, not proof that a bounded MCX launch is technically impossible.

  5. supported

    For the explicitly scheduled Malaysia catalog analogue, Product Launch Sim returns 3995.66337758 modeled active subscribers at week 52 without levers and 25564.114423 with the…

    Full claim wording

    For the explicitly scheduled Malaysia catalog analogue, Product Launch Sim returns 3995.66337758 modeled active subscribers at week 52 without levers and 25564.114423 with the four week-20-to-52 levers; the levered run carries partial-resolution warnings and neither run measures consumer-network quality.

  6. supported

    The published Link Sim MCX lookup is a 15-point demand sweep from 1× to 8× on n72 5 MHz and 25 PRB with 12 MCPTT, 2 MC-video, 20 MC-data, and 200 IoT flows; it reports modeled…

    Full claim wording

    The published Link Sim MCX lookup is a 15-point demand sweep from 1× to 8× on n72 5 MHz and 25 PRB with 12 MCPTT, 2 MC-video, 20 MC-data, and 200 IoT flows; it reports modeled completion and deadline completion of 1 throughout, with modeled PRB utilization peaking at 0.8440542068139872 at 6.5×, but it is a one-trial nominal scheduler simulation and not consumer-coexistence telemetry.

Handoff to network / automation

Continue from analysis into governed implementation

Bounded operational handoff · DOIL

Run one isolated non-production rehearsal that validates the exact two published LinkSim lookups and the exact existing Product schedule,…

Not run or deployed
DOIL Studio view of Run one isolated non-production rehearsal that validates the exact two published LinkSim lookups and the exact existing Product schedule,…

MCX closed model rehearsal

Runbook · Workflow · Agentic system One-time run
Open exact contract in DOIL Studio →
Review scope, controls and rollback 8/8 required structural checks passed

Full bounded objective

Run one isolated non-production rehearsal that validates the exact two published LinkSim lookups and the exact existing Product schedule, keeps the ZA Incident replay as stale demo context, writes and verifies a review-only evidence bundle, and discards the workspace on any stop condition without contacting or changing production.

What changes

  • Write one review-only evidence bundle in the isolated workspace.
  • Invalidate the review bundle and discard temporary rehearsal state when a stop condition fires.

Where

  • Staged rollout, gates, stopping and rollback · Temporary rehearsal workspace only; exact replays, limits, blockers, owners, stop/discard receipts, and gap register.
  • Staged rollout, gates, stopping and rollback · Only the isolated workspace and its unapproved bundle; no production rollback exists because production is never changed.

Activation

  1. Entry checks and exact model replay — manual, human approval required; widens when Every entry check passes; the exact lookup and schedule identities match; all owners are assigned; Incident remains stale ZA demo context; every production boundary remains absent.
  2. Evidence packaging and review gate — approval gated, human approval required; widens when Verification confirms exact inputs, fidelity labels, explicit absent boundaries, and promotion only to Desk reader review.

Monitoring

  • Rehearsal evidence completeness and fidelity against Exact match to both lookup identities, Product schedule, limitations, owners, stop/discard receipts, and gap register; no production claim or binding., published to evidence_outputs

Stop and rollback

  • Entry checks and exact model replay: Any production binding is present or contact is attempted.
  • Entry checks and exact model replay: Any lookup or schedule identity/configuration differs.
  • Entry checks and exact model replay: Incident is described as current, ticket-backed, Malaysian, or field proof.
  • Entry checks and exact model replay: A rehearsal owner is unassigned or the workspace is not isolated and discardable.
  • Entry checks and exact model replay: A replay attempts a consumer-QoS, deployed-security, Malaysian-field, or production-readiness inference.
  • Evidence packaging and review gate: Any identity, limitation, owner, stop/discard rule, or reconsideration requirement is missing. → Invalidate the review bundle and discard temporary rehearsal state when a stop condition fires.
  • Evidence packaging and review gate: An absent boundary is replaced by a value or a missing metric is treated as zero. → Invalidate the review bundle and discard temporary rehearsal state when a stop condition fires.
  • Evidence packaging and review gate: Evidence claims a production pilot is safe or consumer service will not degrade. → Invalidate the review bundle and discard temporary rehearsal state when a stop condition fires.
  • Evidence packaging and review gate: The workspace or bundle cannot be removed from the review path. → Invalidate the review bundle and discard temporary rehearsal state when a stop condition fires.
Operational domains
  • Product and commercial configuration Out of scope · No offering, price, eligibility, or lifecycle change is permitted; pl_iot_fleet is only a locked model input to the rollout-control rehearsal.
  • BSS catalog, charging, CRM and ordering Out of scope · No catalog, charging, CRM, account, or ordering mutation is permitted; the simulated Malaysia stub returned no MCX matches and is not operator inventory.
  • Service specification and activation Out of scope · No service specification, provisioning, activation, or resource order is permitted; no authoritative service id is supplied.
  • Core-network entitlement, policy and charging Out of scope · No entitlement, policy, charging dependency, priority, pre-emption, or deployed security change is permitted; the jammer/security curve is model input only.
  • RAN coverage and capacity Out of scope · No RAN resource, scheduler, priority, or pre-emption change is permitted; the contention lookup is model input and the ZA Incident replay is stale demo context, not Malaysian field evidence.
  • Campaign, onboarding, referral and distribution Out of scope · No onboarding, referral, community, distribution, campaign, or channel activation is permitted; the four levers are replay inputs only.
  • Assurance, monitoring and feedback Out of scope · No live probe, alarm, KPI, monitoring, or feedback-loop activation is permitted; evidence verification stays inside the rehearsal review workspace.
  • Staged rollout, gates, stopping and rollback Planned · simulated grounding

Authority boundary

This is a reviewable instruction set only. Publication grants no target, execution or deployment authority; the receiving NOC validates current state before any implementation.

Limits carried forward

  • This is DOIL-authored local review material. Desk coordinates and renders it but does not infer language semantics from compiler internals.
  • The single .doil file is the sole portable operations contract. This projection, its package, IR, and receipts are derived review material and are not required by the receiver.
  • The pinned contract-test clock is validation evidence, not the current time. A receiver must re-evaluate expiry and all time-sensitive preconditions at consumption.
  • Exact source, fixtures, lineage, and deterministic observations are review evidence only; they do not certify semantic correctness or prove untested paths.
  • No human approval, target authority, target generation, deployment, scheduling, network call, or external effect is performed by this handoff.
  • A target-side generator must recompile the exact workspace with a supported DOIL verifier and preserve every approved requirement, guardrail, bound, approval, observation, recovery, and output.
  • The reference preview completed as a zero-record structural preview; it contains no action or scenario evidence.
  • This package preserves intent and structural proofs only; no target has certified it.
  • Approval declarations are preserved as intent; this tool does not grant human authority.
  • Future targets are portability labels only; no target-specific generator or adapter ran.
  • The content-addressed Studio state becomes replayable after Desk persists the included StateDoc.
Exact structural evidence

The score and level measure source-structure declaration coverage for the selected profile only. A production-shaped level is not post-investigation Desk handoff eligibility, semantic validation, human approval, certification, live-network validation, target readiness, deployment authority, or execution authority.

Source checks

  • Clean parse · No parser diagnostics
  • Top-level definition · Agent, class, or pipeline definition exists
  • Purpose text · Intent or description is declared
  • Context hydration · Runtime context requirements and sources are explicit
  • Data sources · Data inputs are named; intentionally not applicable to this strict contract
  • Tool surface · Allowed actions are declared
  • Triggers · Activation paths are declared; intentionally not applicable to this strict contract
  • Runnable methods · Handlers or methods are defined
  • Guardrails · Pre, during, or post execution controls are declared
  • Lifecycle · Timeout, health, or restart policy is declared; intentionally not applicable to this strict contract
  • Observability · Logs, metrics, alerts, or reports are declared; intentionally not applicable to this strict contract
  • Recovery · Retry, escalation, or dead-letter policy is declared; intentionally not applicable to this strict contract
  • Output/promotion · Generated plans and approval stages are declared

Handoff checks

  • Strict Operations Contract Complete · The sole .doil file declares every strict operations-contract facet; all other views are derived.
  • Parse Clean · Every workspace file parsed without diagnostics.
  • Brief Complete · A title and objective are required to preserve the human intent.
  • Approved Intent Textually Bound · Every approved requirement is bound exactly once to its full text in the DOIL source for human semantic review.
  • Scenario Coverage Ready · No source-owned scenario fixtures were declared or run; structural readiness makes no scenario-coverage claim.
  • Target Kind Requested · At least one future portability target must be selected; no target artifact is generated here.
  • Tool Effects Explicit · Every declared tool states its backend-neutral effect as read, propose, or external_change.
  • Post Investigation Operational Remedy · The selected entrypoint reaches an explicit external_change request: Desk investigation is upstream, while this handoff specifies the approved operational remedy.
  • Launch Selector Unambiguous · The explicit handler or trigger resolves to one entrypoint.
  • Entrypoint Resolved · Reference preview resolved run_closed_rehearsal.
  • Reference Preview Completed · The deterministic reference preview completed without granting authority or producing external effects.
  • Execution Mode Matches Source · Execution mode agrees with the selected source entrypoint.
  • Repeatable Mode Bounded · Execution intent is one-shot or carries an explicit maxCycles/expiresAt bound.
  • Expiry After Contract Test Clock · Any declared expiry is later than the fixed source-owned contract-test clock; current-time validity is not assessed.
  • Clock Pinned · The reference preview uses the source-owned fixed contract-test clock and contains no current-time or wall-clock claim.
Contract 514f7ee7…3533e3 Verification 24354a44…9f2534 Download exact .doil

Executive readout

Decision summary

Decision boundary

  • Decision question: Can a national public-safety agency launch mission-critical push-to-talk over a shared commercial operator network without degrading consumer service, and what…
Review 12 full notes
  • Decision question: Can a national public-safety agency launch mission-critical push-to-talk over a shared commercial operator network without degrading consumer service, and what bounded operational rollout would remain safe under contention, coverage stress, and adoption growth?
  • Gate A must also name the national jurisdiction, public-safety agency, commercial operator or operator set, permitted data and observation grants, geographic and cohort boundaries, consumer-service red lines, mission-critical service targets, launch decision deadline, and any security or regulatory constraints. The available source record is only a publisher summary of a weather warning and contains no resolvable article link, so it cannot establish those boundaries.
  • Reader live-work return (round 2). LinkSim published lookup lk_c61e61c3c081a362c0345f03 for staged cfg_3aa78f27a7630f897bfdb121 and lookup lk_1c6ec61449ff7f6ee5aeb0ee for staged cfg_49190658cca93ed91cede561. The first staged URL resolved to a plain n72 / 5 MHz / 25 PRB / 2.5 km / 1,000-trial link case; the hybrid staged URL also resolved plain until the UI’s +PQC module was explicitly enabled, then captured X25519+ML-KEM-768 / ML-DSA-65. Incident Twin returned ticket tkt_mspcen1eksn0614sfv and incident inc-mspcgcwu-908o for an 8,168-site working area with 40 modeled degraded sites; the ticket package is 5/5 required evidence, 6 contributions, and 7/7 handoff-ready, with NOC Incidents and Environmental Hazards active. Limitations shown in the app: demand-sim unavailable, so operator package demand estimates were used; coverage-twin unavailable, so RF KPIs are unavailable for this area; the hazard layer is a manifest extent, not geometry-backed. Product launch did not run because Desk rendered the proposed live URL with a terminal ellipsis and exposed neither a clickable full target nor named levers. Re-propose an untruncated Product app link plus the exact levers for the reader to move.
  • Reader return (round 3). Product-launch-sim refused the registered scene verbatim: “Scene "scn_-TcYUNq9KdZnmn8_uhw12" could not be loaded — starting with defaults.” No Product lever was moved. Resend a complete loadable Product state URL and the named levers; this is the second failed Product interaction handoff. The modeled-scenario card was also stale: it repeated the pre-remedy Incident refusal even though ticket tkt_mspcen1eksn0614sfv is now 5/5 and 7/7 handoff-ready, and it described the two published LinkSim point lookups as if the requested sweeps had returned. Re-propose the current Incident package and characterize the LinkSim records only as point evidence with their exact configs and limitations.
  • Reader Product live return (round 4). Base scene scn_cM7QDNWav_aDIrZr8V35r loaded successfully in the Product app. I moved the named seed_community lever through its visible “Initial adoption u₀” control from 0.02 to 0.03 and saved CelcomDigi Business IoT. The app returned “CelcomDigi Business IoT updated; the flow and timeline were recomputed.” At week 312 the product-plan target-attainment total changed from 27 to 28 points and forecast active-subscriber growth after launch seed changed from +49.4K to +50.8K. The adjusted app URL is https://product.darknoc.net/?scene=scn_cM7QDNWav_aDIrZr8V35r&week=312. The Compartmental Stats Bar was captured locally in the app’s Desk return bundle as revision 1. Use this exact reader change against the registered base to compute the Product scene_diff; do not infer any other lever change.
  • Reader LinkSim live return (round 5). The visible MCX pane configuration was loaded into Bench with its service mix intact: n72, 5 MHz, 25 PRB, priority-GBR scheduling, 12 MCPTT flows, 2 MC-video flows, 20 MC-data flows, 200 IoT-telemetry flows, seed 42, one trial, and no adversary. I ran a Demand multiplier sweep from 1 to 8 at 0.5 steps (15 points) and published MCX-capacity lookup lk_3c2b6da985e452a192e8b688; its exact config, points, provenance, and six recorded limitations are attached to the immutable lookup. The MCX pane’s built-in breaking-demand run returned verbatim: “First mission-critical GBR service breaks at ×7 demand.” For the staged hybrid-security case cfg_49190658cca93ed91cede561, the staged adversary was absent, so I explicitly selected “Reactive (handshake window)” with reaction 2 slots and hold 6 slots, then swept JSR from -10 to 30 dB at 1 dB steps (41 points) and published lookup lk_edf377ede2ce06ee74e0c00a for X25519+ML-KEM-768 / ML-DSA-65. Read both published lookups with get_lookup and cite their exact configs and limits; do not treat the built-in ×7 breakpoint as a consumer-service threshold. Disposition reason: keep the live-work request as evidence only because it is an instruction, not an analytical conclusion; the analyst must consume the returned lookups before proposing a conclusion.
  • Reader live-work return (round 6). Product scene scn_cM7QDNWav_aDIrZr8V35r loaded with four visible CD Business IoT design levers. I changed only Seed Community intensity by one UI step, from 100% to 95%; its start week 20, end week 52, and four-week ramp stayed unchanged, as did Onboarding Friction Fix, Referral Program, and Distribution Push at 100%. The Product app recomputed portfolio audiences from 53.0K to 52.7K while displayed portfolio launch MRR remained MYR 11.1M. The adjusted live state is https://product.darknoc.net/?scene=scn_cM7QDNWav_aDIrZr8V35r&week=312&levers=onboarding_fix%40pl_iot_fleet%3A20-52%2Cseed_community%40pl_iot_fleet%3A20-52%3A0.95%3A4%2Creferral_program%40pl_iot_fleet%3A20-52%2Cdistribution_push%40pl_iot_fleet%3A20-52. The app return bundle now includes Launch Lever Cards revision 1 plus five total captured panels. Incident Twin was rechecked in the browser: ticket tkt_mspcen1eksn0614sfv remains active for incident inc-mspcgcwu-908o; its work-package dialog reports tenant za-vodacom-demo, state building, 5/5 required, 6 context items, 7 audit events, and Ready for AI evaluation, while the working-area handoff is 7/7 for 8,168 visible sites and 40 affected. The package’s wizard annotation remains step 1/3, 33% complete. Read the package directly by ticket id rather than relying on ticket_get_active.
  • Reader Incident handoff correction (round 7). The missing prerequisite was not package composition; it was the analyst’s unticketed default Incident MCP session. Incident Twin’s Agent Workbench reports ready for agent, Required 5, Present 5, Missing 0, Published 6, Package ready, ticket tkt_mspcen1eksn0614sfv, incident inc-mspcgcwu-908o, and explicitly says the package is ready for Pilot or an external MCP agent. Its recommended MCP sequence is agent_validate_context_package → agent_get_context_package, with ticket_get_package / agent_get_context_package as source of truth. Use this ticket-scoped external-agent link: https://za.darknoc.net/?deployment=za&operator=vodacom-za&tenant=za-vodacom-demo&ticket=tkt_mspcen1eksn0614sfv&lat=-26.23641&lng=28.51636&z=10&mode=remediation&incidentId=inc-mspcgcwu-908o&agent=mcp&scopes=read%3Aticket%2Cread%3Aincident%2Cread%3Amap%2Cread%3Aspatial%2Cread%3Apackage%2Cread%3Anoc%2Cread%3Apilot%2Cwrite%3Aevidence&expires=2026-08-12T02%3A12%3A26.690Z. The UI labels the expiry advisory and not enforced, and warns this is a draft local link whose production equivalent needs a signed ticket-scoped bearer token. Restore the analytical scope from the published package itself (the six contributions); do not replace it with the later transient 1,546-site remediation viewport.
  • Chosen action: Run a closed model rehearsal — A repeatable non-production evidence package is produced from the exact existing simulator configurations without touching the commercial network. (receiver: runbook).
  • Chosen scope: Run the closed model rehearsal only. The only planned external change is writing one review-only evidence bundle inside an empty isolated discardable workspace; the other seven operational domains are explicitly out of scope because production stays unchanged. Entry requires the exact run and chosen-action ids, both immutable LinkSim lookup ids, the exact Product schedule, stale-demo labeling for Incident, four assigned rehearsal roles, no production endpoint/credential/adapter/binding, and a fresh human-supplied isolated rehearsal window (no window was supplied). Approval owner: Desk reader. Execution owner: rehearsal runbook operator. Evidence owner: model evidence curator. Stop/discard owner: rehearsal safety controller. Stop on any production binding or contact, input mismatch, Incident misuse, unassigned owner, non-isolated workspace, missing evidence or limit, fabricated boundary or zero, production-safety claim, or inability to remove the bundle. On a stop, mark the bundle invalid, remove it from promotion, discard temporary replay state, and retain only a non-sensitive failure receipt. Success retains only the review bundle and audit receipt and removes temporary replay state.
  • Evidence output: exact identities, configurations, point sets and limitations for both published LinkSim lookups; the exact Product schedule plus modeled week-52 and week-312 baseline-versus-levered outputs and warnings; an Incident boundary that says stale ZA demo, “No active ticket.” and “No active agent context package.”; entry, owner, stop and discard receipts; and a gap register that names every absent production boundary without substituting a value. Before any production pilot can be reconsidered, require a current Malaysian ticket-bound area with coverage/SINR/demand/pressure/headroom and authoritative timestamps; a live coexistence test on the actual carrier, bandwidth, scheduler, devices and traffic with human-approved numeric MCX and consumer limits; real deployed cryptography/security and adversarial testing; authoritative product/offering/charging/CRM/order/service/entitlement/policy ids; a named Malaysian cohort, geography, devices, window, priority/pre-emption rules and customer safeguards; a live consumer-QoS baseline, independent probes, rollback telemetry and human-approved degradation limits; and approvals from the national public-safety service owner and operator product/BSS, core/policy, RAN, security and assurance owners. None of those production prerequisites or numeric limits was supplied.
  • 7 cited items were available to this study and are not in it: 2 action proposals, 1 claim, 1 feed citation never placed; 3 claims judged out of scope.
How this was governed

97% autonomous · 2 human checkpoints (gate_a & gate_b)

Verification

  • Supported claims5
  • Projected1
  • Illustrative0

Evidence

  • Cited (source)13
  • Modeled5
  • Observational0
Published Aug 12, 2026 · started Aug 12, 2026