PyMC in the Browser: Why Deployment Architecture Isn't a Causal Validity Signal
On this page
Thomas Wiecki's PyMC Labs demonstration, dated May 16, 2022, describes Bayesian modeling in a browser using PyScript and Pyodide. It illustrates an execution option, not proof that a model estimates a causal effect. Procurement needs evidence both for the method and for the runtime's practical constraints.
What changed to make browser-native modeling possible?
Pyodide runs Python through WebAssembly in the browser. The PyMC Labs page describes a Python execution mode for its tensor backend and lists PyMC, PyTensor and Bokeh in its example. It does not pin a complete tested package/runtime set, so treat the example as illustrative and verify compatibility, numerical behavior, convergence, memory and sampling time for the proposed versions.
The three-step pattern behind the demo
The demonstration follows a package, model, and page-loading pattern; it is not a verified current installation recipe:
- Choose compatible packages. The browser runtime needs appropriate builds. Pyodide's package documentation distinguishes its supported package environment; an arbitrary native Python package is not automatically browser-compatible.
- Embed a model. The source illustrates a beta-binomial coin-flip model: a uniform Beta(1,1) prior and a Binomial likelihood, with ten flips and five heads as example inputs. This estimates a probability under its assumptions. It is not an intervention experiment merely because it uses Bayesian sampling.
- Load and verify the page. Check package loading, the actual sampler and numerical configuration, diagnostics, and output against known expected results in the chosen runtime. Static hosting, package downloads and application data handling still need their own operating plan.
Browser execution can reduce setup friction for a suitable demonstration. It does not establish that the chosen likelihood, population, comparison or identification assumptions answer the customer's decision.
Where can browser execution be useful?
Potential uses include teaching notebooks, interactive assessments and small models fitted to locally supplied data. Compare client and server execution on supported dependencies, device memory, runtime, accessibility, data handling and maintenance. These are operational choices; verify the actual application before claiming data never leaves a device or that operating cost is zero.
None of them is a substitute for asking what the model is estimating and how that estimate was validated. A workshop notebook that lowers the bar to trying Bayesian modeling is not the same claim as a procurement-ready causal estimate.
The evaluation checklist this replaces
When a deployment-architecture claim shows up in a vendor evaluation, three questions separate it from an evaluation of the underlying method:
- What is estimated, from which source and design, and does the comparison identify a causal effect?
- What independent validation, numerical checks and sampling diagnostics support the intended use?
- Can the chosen runtime meet device, memory, latency, data-handling, reproducibility and operating-cost requirements?
For a Subconscious study, request the design, response source, analysis, uncertainty assumptions and relevant validation as part of the study scope. Aggregate method evidence is separate from evidence about deployment architecture.
Limitations
The PyMC Labs demonstration concerns its own browser example. It does not document Subconscious's runtime or establish unconditional architecture or capability exclusions. Confirm the proposed product configuration and measure the method and operating constraints separately.
What to check before you sign off
Ask for the experiment's source, assignment, endpoint and validation, plus reproducible runtime and package versions, numerical results, sampling diagnostics and measured resource use. A working browser demo proves the exercised execution path; it does not by itself prove causal validity or that the buyer's operating constraints are met.