Explore and reproduce experiments in the Shiny workbench

Launch locally

Install the optional dependencies once, then launch from an interactive R session:

install.packages(c("shiny", "bslib", "DT", "ggplot2"))
shield_app()

The application opens in a browser or viewer and runs in the local R process. Stop the running app from the R console when finished. Arguments after launch are forwarded to shiny::runApp(); for explicit local access:

shield_app(host = "127.0.0.1", launch.browser = TRUE)

Constructing the application without starting a server is useful for testing or integration with an existing Shiny deployment:

app_packages <- c("shiny", "bslib", "DT", "ggplot2")
if (all(vapply(app_packages, requireNamespace, logical(1), quietly = TRUE))) {
  app <- shield_app(launch = FALSE)
  stopifnot(inherits(app, "shiny.appobj"))
}

Uploaded graphs are processed in the running R session. The app uses local system fonts and does not send inputs to an external analysis service. Hosting it on another machine changes where that processing occurs. Session state is not shared between users. Downloads persist only when you save them.

A first experiment

1. Keep Balanced resources as the teaching graph and Single policy as the comparison design. Inspect the displayed batch size, horizon, replication count and master seed before running.
2. Open Graph. The five-leg node and route labels are fixed; inspect the three numeric input columns. All teaching routes have zero exposure and the initial item condition controls have zero hazard.
3. Select Run experiment. A progress indicator reports simulation and bootstrap stages. Inputs are validated before the model runs.
4. Read Outcomes, then Diagnostics. Inspect the summary tables as well as the plots, especially missing arrival-time counts.
5. Save the Complete experiment RDS and Replay script R from Data and export. They preserve the settings actually used by the completed run.

The balanced teaching example inspects transport mechanics. It does not contain calibrated logistics parameters. Switch to Constrained resources to examine resource scarcity and a shorter suggested horizon without introducing hazards.

Changing the teaching graph replaces its vehicle fractions and suggested horizon; it does not reset other settings you have edited. Review those settings before interpreting the new run.

Configure the graph and assumptions

The Graph table has exactly the seven columns accepted by shield_parameters(): leg, from, to, route, travel_min, exposure_weight and vehicle_fraction. The topology requires 15 unique leg-route rows.

Double-click a numeric cell to edit it. Changing vehicle_fraction updates all three routes within that leg, because the fleet belongs to the leg. The constructor rounds fleet size up and enforces at least two vehicles per leg. A graph CSV can be imported or exported; import requires that same schema and is limited to 64 KB. Invalid edits and uploads produce an explanatory message and preserve the previous valid graph.

You can prepare a compatible neutral CSV from R:

scenario <- example_scenario()
graph_columns <- c("leg", "from", "to", "route", "travel_min",
                   "exposure_weight", "vehicle_fraction")
graph_file <- tempfile("shieldR-graph-", fileext = ".csv")
utils::write.csv(scenario$graph[graph_columns], graph_file, row.names = FALSE)
imported <- utils::read.csv(graph_file, stringsAsFactors = FALSE,
                            check.names = FALSE)
stopifnot(inherits(shield_parameters(imported), "shield_parameters"))

The sidebar groups controls by purpose:

A maximum hold must be a multiple of the dispatch interval. Parameters not exposed by the form retain their documented constructor defaults, including the rounded class mix, and are recorded in the complete experiment bundle. The form sets the two named disruption risk levels to the same entered baseline and selects the low label. Use shield_parameters() in an R script when your design needs separate disruption risk levels or other settings not exposed by the form.

The app does not import previously saved results as a new interactive session. Read experiment RDS files in R and use the replay script for a new run.

Choose the comparison design

For independent arms, the Comparisons view reports Mann-Whitney U, Cliff’s delta and the median difference with percentile bootstrap 95% intervals. Positive effects favor arm_x for the viability endpoint. All displayed pairwise Stage 2 comparisons constitute one explicit Benjamini-Hochberg FDR family. Three or more arms also produce a Kruskal-Wallis H statistic, degrees of freedom and p-value. This interactive family is separate from the comparison families declared in a separate scripted study.

For the paired design, the contrast is no disruptions minus disruptions, expressed as a paired mean difference of batch viability proportions. The interval resamples matched replication indices jointly. The paired design controls disruption enablement itself, regardless of the ordinary disruption checkbox. The neutral graph has zero exposure, so its paired contrast is zero.

All comparison intervals use 10,000 bootstrap resamples. The statistical unit is the batch replication. Small interactive experiments can produce unstable estimates or point intervals on discrete outcomes; more bootstrap resamples do not compensate for an inadequate number of independent replications.

Read each view together with its limitations

The primary endpoint is arrival viable at Stage 2 by the horizon. Physical arrival precedes unloading and ends item-condition hazard. A nonarrival is not necessarily a loss. Conditional arrival-time medians exclude items who never arrived; undefined batch medians remain missing. n_pending counts items still viable without Stage 3 arrival. n_disruption_loss counts destructive disruption events and is not the paired total intervention effect.

After you edit an input, a visible message identifies the results as belonging to the last completed experiment. Run again to apply the new configuration. Experiment downloads retain that last completed run; the graph download is explicitly the current graph. Starting a new run clears the old experiment, so a failed validation cannot silently attach old results to new assumptions.

Export an experiment you can replay

The replay script reproduces simulations and descriptive summaries. The RDS bundle also retains inferential tables and the omnibus result; retain it for a complete audit record. Use the same package source/environment to reproduce results exactly. The PNG/PDF downloads cover the viability figure; diagnostics and batch tables remain available in the bundle for your own plotting.

After saving the experiment to a chosen analysis output directory, inspect it from R:

bundle <- readRDS("shieldR_experiment.rds")
bundle$config$arms
bundle$provenance$shieldR_version
bundle$provenance$session_info
bundle$summary
bundle$comparisons
bundle$omnibus

# Reproduce the first arm from the recorded request.
arm <- bundle$config$arms[1, ]
replayed <- simulate_shield(
  bundle$config$parameters,
  policy = arm$policy, disruption_model = arm$disruption_model,
  n_rep = bundle$config$settings$n_rep, seed = arm$seed,
  disruptions_enabled = arm$disruptions_enabled
)
stopifnot(identical(replayed, bundle$runs[[1]]))

Move a larger experiment into scripts

The workbench accepts 1 to 60 items per batch, 2 to 100 replications per arm and horizons from 1 to 240 minutes. The combined workload is limited to items * horizon * replications * arms <= 250000 as an interactive safeguard. This is a conservative input-size measure, not an exact runtime estimate. These caps apply to the app, not to the underlying package APIs.

Use scripted studies for larger grids, durable checkpoints, parameter uncertainty analyses, custom comparison families or publication exports. The study design tutorial explains batch-level inference and replay. Study integrations require their own versioned validation and interface checks. The interface and its synthetic examples do not establish application-specific validity.

sessionInfo()
#> R version 4.6.2 (2026-10-29)
#> Platform: x86_64-pc-linux-gnu
#> Running under: Ubuntu 26.04.1 LTS
#> 
#> Matrix products: default
#> BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 
#> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.32.so;  LAPACK version 3.12.0
#> 
#> locale:
#>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
#>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
#>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
#>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
#>  [9] LC_ADDRESS=C               LC_TELEPHONE=C            
#> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       
#> 
#> time zone: Etc/UTC
#> tzcode source: system (glibc)
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> other attached packages:
#> [1] shieldR_0.6.0  rmarkdown_2.32
#> 
#> loaded via a namespace (and not attached):
#>  [1] gtable_0.3.6       jsonlite_2.0.0     compiler_4.6.2     promises_1.5.0    
#>  [5] Rcpp_1.1.2         parallel_4.6.2     later_1.4.8        jquerylib_0.1.4   
#>  [9] scales_1.4.0       yaml_2.3.12        fastmap_1.2.0      mime_0.13         
#> [13] ggplot2_4.0.3      R6_2.6.1           knitr_1.52         htmlwidgets_1.6.4 
#> [17] maketools_1.3.2    shiny_1.14.0       RColorBrewer_1.1-3 bslib_0.12.0      
#> [21] rlang_1.3.0        DT_0.34.0          cachem_1.1.0       httpuv_1.6.17     
#> [25] xfun_0.62          S7_0.2.2           sass_0.4.10        sys_3.4.3         
#> [29] otel_0.2.0         memoise_2.0.1      cli_3.6.6          magrittr_2.0.5    
#> [33] crosstalk_1.2.2    digest_0.6.39      grid_4.6.2         fontawesome_0.5.3 
#> [37] xtable_1.8-8       lifecycle_1.0.5    vctrs_0.7.3        evaluate_1.0.5    
#> [41] glue_1.8.1         farver_2.1.2       buildtools_1.0.0   tools_4.6.2       
#> [45] htmltools_0.5.9