amortized-workflow

Name: amortized-workflow
Author: Learning-Bayesian-Statistics

153stars15forks

How to install amortized-workflow?

learning-bayesian-statistics/baygent-skills/amortized-workflow

$npx -y skills add Learning-Bayesian-Statistics/baygent-skills --skill amortized-workflow

Installs into the current project.

Summary

Opinionated amortized Bayesian workflow with BayesFlow for simulation-based inference (SBI). Contains critical guardrails that agents will usually not apply unprompted — always consult before writing BayesFlow code. Trigger on: simulation-based inference, amortized inference, app

Files · 1

View on GitHub

SKILL.md

1	# Amortized Bayesian Workflow
2
3	## Workflow overview
4
5	Every amortized Bayesian analysis follows this sequence. Do not skip steps — especially simulator validation and model criticism.
6
7	1. Formulate — Define the generative story. What latent variables or parameters generated the observations?
8	2. Specify the simulator regime — The first iteration always uses offline training for fast turnaround, regardless of simulator speed. The simulator regime only determines the simulation budget for the pilot run:
9	- Fast simulator (< 0.05 s per draw): pre-simulate 20 000 datasets, train for 100 epochs
10	- Slow simulator (> 1 s – minutes per draw): pre-simulate 3 000–5 000 datasets, train for 100 epochs
11	- No simulator / pre-existing bank: use whatever is available; switch to disk training if it does not fit in memory
12	Online training is a refinement step — use it only after the first offline pass shows healthy diagnostics and you want to squeeze out more performance.
13	3. Define prior + observation model or simulation bank
14	- Implement prior and observation model and wrap them in a simulator
15	- Pre-simulate the pilot budget into a dict (using `workflow.simulate(N)`) for offline training
16	- If the simulator is external or proprietary, ensure simulations are already generated from the intended prior and data-generating process
17	4. Choose the architecture — this step is critical; getting it wrong ruins inference. See `references/conditioning.md` for the full conditioning logic and decision table.
18	- "Simple vector" means the observation is a single fixed-length feature vector whose element order is meaningful (e.g., 5 named sensor readings, a pre-computed summary statistic). Only then: route through `inference_conditions` with no summary network.
19	- Set-based / exchangeable data — If the simulator produces N observations that are exchangeable, the data is a set, not a vector. This includes: N i.i.d. draws, regression datasets with (x, y) pairs, repeated measurements, trial-level data, cross-sectional samples. Route through `summary_variables` with a `SetTransformer`. Never put this in `inference_conditions`.
20	- Time series — ordered sequences: route through `summary_variables` with `TimeSeriesTransformer` or `TimeSeriesNetwork`.
21	- Images as conditions / observations for parameter inference — route through `summary_variables` with `ConvolutionalNetwork`.
22	- Images as inferential targets — conditional image generation, spatial field generation, denoising, and other image-valued outputs require an image-capable diffusion inference network. Use `bf.networks.DiffusionModel(subnet=...)` with `UNet`, `UViT`, or `ResidualUViT`; see `references/image-generation.md`.
23	- A workflow can use both slots simultaneously. Fixed-length metadata (e.g., sample size N, scalar design variables) can go in `inference_conditions` while structured observations go in `summary_variables`.
24	- When in doubt, use a summary network. It is always safer to include one than to omit one; a summary network will always be needed if the data has more than one axis.
25	5. Build the workflow — Prefer `bf.BasicWorkflow(...)`
26	- Decide on which variables to auto-standardize. Prefer `standardize="all"` unless you have verfied that the simulator outputs are already in a good range for the networks.
27	6. Run simulation sanity checks — Before training, verify that simulated data look plausible and span the relevant range of real observations. Again, pay attention to what needs to be standardized.
28	7. Train the amortizer — First iteration always uses offline training for fast feedback:
29	- `workflow.fit_offline(...)` with the pre-simulated pilot budget (default first pass)
30	- `workflow.fit_online(...)` only as a refinement step after offline diagnostics look healthy, or when the user explicitly requests it
31	- `workflow.fit_disk(...)` if streaming simulations from disk
32	**Always offer to run training in

People who liked this also viewed

6 picks

Type

amortized-workflow

153stars15forks

View on GitHub

How to install amortized-workflow?

learning-bayesian-statistics/baygent-skills/amortized-workflow

$npx -y skills add Learning-Bayesian-Statistics/baygent-skills --skill amortized-workflow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Amortized Bayesian Workflow
2
3	## Workflow overview
4
5	Every amortized Bayesian analysis follows this sequence. Do not skip steps — especially simulator validation and model criticism.
6
7	1. Formulate — Define the generative story. What latent variables or parameters generated the observations?
8	2. Specify the simulator regime — The first iteration always uses offline training for fast turnaround, regardless of simulator speed. The simulator regime only determines the simulation budget for the pilot run:
9	- Fast simulator (< 0.05 s per draw): pre-simulate 20 000 datasets, train for 100 epochs
10	- Slow simulator (> 1 s – minutes per draw): pre-simulate 3 000–5 000 datasets, train for 100 epochs
11	- No simulator / pre-existing bank: use whatever is available; switch to disk training if it does not fit in memory
12	Online training is a refinement step — use it only after the first offline pass shows healthy diagnostics and you want to squeeze out more performance.
13	3. Define prior + observation model or simulation bank
14	- Implement prior and observation model and wrap them in a simulator
15	- Pre-simulate the pilot budget into a dict (using `workflow.simulate(N)`) for offline training
16	- If the simulator is external or proprietary, ensure simulations are already generated from the intended prior and data-generating process
17	4. Choose the architecture — this step is critical; getting it wrong ruins inference. See `references/conditioning.md` for the full conditioning logic and decision table.
18	- "Simple vector" means the observation is a single fixed-length feature vector whose element order is meaningful (e.g., 5 named sensor readings, a pre-computed summary statistic). Only then: route through `inference_conditions` with no summary network.
19	- Set-based / exchangeable data — If the simulator produces N observations that are exchangeable, the data is a set, not a vector. This includes: N i.i.d. draws, regression datasets with (x, y) pairs, repeated measurements, trial-level data, cross-sectional samples. Route through `summary_variables` with a `SetTransformer`. Never put this in `inference_conditions`.
20	- Time series — ordered sequences: route through `summary_variables` with `TimeSeriesTransformer` or `TimeSeriesNetwork`.
21	- Images as conditions / observations for parameter inference — route through `summary_variables` with `ConvolutionalNetwork`.
22	- Images as inferential targets — conditional image generation, spatial field generation, denoising, and other image-valued outputs require an image-capable diffusion inference network. Use `bf.networks.DiffusionModel(subnet=...)` with `UNet`, `UViT`, or `ResidualUViT`; see `references/image-generation.md`.
23	- A workflow can use both slots simultaneously. Fixed-length metadata (e.g., sample size N, scalar design variables) can go in `inference_conditions` while structured observations go in `summary_variables`.
24	- When in doubt, use a summary network. It is always safer to include one than to omit one; a summary network will always be needed if the data has more than one axis.
25	5. Build the workflow — Prefer `bf.BasicWorkflow(...)`
26	- Decide on which variables to auto-standardize. Prefer `standardize="all"` unless you have verfied that the simulator outputs are already in a good range for the networks.
27	6. Run simulation sanity checks — Before training, verify that simulated data look plausible and span the relevant range of real observations. Again, pay attention to what needs to be standardized.
28	7. Train the amortizer — First iteration always uses offline training for fast feedback:
29	- `workflow.fit_offline(...)` with the pre-simulated pilot budget (default first pass)
30	- `workflow.fit_online(...)` only as a refinement step after offline diagnostics look healthy, or when the user explicitly requests it
31	- `workflow.fit_disk(...)` if streaming simulations from disk
32	**Always offer to run training in

People who liked this also viewed

6 picks

Type