Reliability

Validation.

A generated sampler is only useful if it is correct. AI4BayesCode validates in two stages. Before any code is written it confirms the model is the one you meant. After, it checks that the sampler compiles, reads correctly, and recovers the right posterior.

No automated check catches every bug. Validation raises the floor, and because AI4BayesCode runs inside a coding agent, you can keep digging after the sampler is generated.

Stage 1

Before generation: get the model right.

Most errors start in the model, not the code. Before generating anything, AI4BayesCode makes the parsed model explicit and asks you to confirm it.

Prior completion.

If a prior is missing, the system offers clear options: fixed values, default weakly-informative priors, or literature-informed priors found through an LLM-assisted search. Nothing is left implicit.

You confirm the model.

It shows three views to review: the model formulas (the parsed likelihood and priors), a DAG of the dependencies, and a summary table. When something is ambiguous, such as two parameterizations of the same distribution, it asks before continuing.

Stage 2

After generation: check the sampler.

Once the sampler is written, it runs a three-layer pipeline, cheapest first. If a layer fails, the system revises the code from the accumulated feedback and tries again, up to a set limit.

1 · Syntax

The generated C++ has to compile. The compiler does this for free. If it does not build, the system fixes the code and retries.

2 · Semantic

Twenty-five static checks for bugs that compile and run but still give a wrong posterior: distribution parameterization, dimension mismatch, Jacobian handling, dependency consistency, update logic, gradient correctness, and more.

3 · Runtime

The sampler is run on data simulated under the target model. A quick smoke test, then two-chain R-hat and ESS to ask whether it converges, then posterior checks with Bayesian p-values and PSIS-LOO to ask whether it converges to the right posterior.

Show the 25 semantic checks
  1. Distribution parameterization. Every distribution is annotated with its exact parameterization and mean.
  2. Parallel vs sequential update. Vector Gibbs updates use the correct sequential order.
  3. Dead parameters. No parameter is sampled but never used.
  4. Missing intercept or offset. The regression mean includes the intercept and any offset.
  5. Jacobian handling. Constrained NUTS parameters carry the correct change-of-variable Jacobian.
  6. DAG consistency. The code’s dependency graph matches the model.
  7. Dependency declaration. Each block declares the inputs it reads.
  8. Binding correctness. The R and Python bindings are used correctly.
  9. Numerical stability. Log-sum-exp, clamping, and overflow guards are in place.
  10. State mutation in prediction. Posterior prediction does not alter the chain’s state.
  11. Joint-NUTS audit. Extra checks when a joint NUTS block is used.
  12. Gradient verification. Hand-written gradients are checked against automatic differentiation.
  13. RNG separation. Sampling and prediction draw from separate random streams.
  14. Bijection sanity. Custom trans-dimensional maps round-trip and stay invertible.
  15. Library parity. Gibbs and specialized blocks match a reference implementation.
  16. Gibbs-exception justification. Every closed-form Gibbs step is justified inline.
  17. No ad-hoc Gibbs. No hand-written Gibbs outside the approved set.
  18. Dense-metric justification. A dense NUTS metric is justified and pilot-scaled.
  19. Vectorized gradients. Gradients use BLAS-friendly matrix operations.
  20. No per-step warmup. The sampler never re-warms inside a recording step.
  21. VI block contract. Variational blocks conform to the required interface.
  22. VI optimizer. Variational blocks use the RAABBVI optimizer.
  23. Re-adaptation safety. Re-tuning NUTS preserves chain state and RNG separation.
  24. Joint-NUTS pre-flight. Funnel reparameterization, constraints, and callbacks are complete.
  25. Trans-dimensional models use RJMCMC. Dirac spikes and varying dimension go through reversible-jump.

The two stages work together: the first makes sure the right model is being fit, and the second makes sure the sampler fits it correctly.

Even so, no validation catches every bug. That is why AI4BayesCode runs inside a coding agent: when the sampler is generated, the conversation does not end. You can keep going and ask the agent to probe edge cases, read through the code with you, and hunt down anything the automated checks missed.