How inlaops maps to the vetiver workflow • inlaops

For tidymodels and other supported models, vetiver gives a standard path from a trained model to a served one:

train → vetiver_model() → vetiver_pin_write() → vetiver_api() → deploy → monitor → call

inlaops puts an inlabru bru fit on that same path. Most steps work exactly as they do for any other model; this article lists where they differ.

Step by step

Step	tidymodels + vetiver	inlaops	Gap
Train	A workflow bundles preprocessing (a recipe) with the model, so new data is prepared the same way automatically.	`inlabru::bru()` with `config = TRUE`, or `bru_reg()` for fixed-effects models.	No preprocessing travels with the model; requests must carry ready-made predictors.
Define the prediction	Implicit: the model’s `predict()` method knows what to return.	Explicit: `pred_formula` in the pin metadata, e.g. `"~ exp(Intercept + field)"`.	An extra required step, which also lets you choose the quantity served (mean, intensity, linear predictor).
`vetiver_model()`	Description, input schema and required packages are filled in automatically.	The same, through inlaops’ methods. The input schema is the predictor columns, or coordinates for spatial point fits.	Only the first observation model is used (#6); polygon / areal fits are rejected (#5).
Pin and version	`vetiver_pin_write()`, `pin_versions()`, metadata.	Identical.	None.
API	`/predict` returns a point estimate; `/ping`, `/metadata` and request checking come with it.	Same endpoints and request checking. `/predict` returns the posterior mean, a 95% credible interval and the posterior SD.	Every request runs INLA’s posterior sampler, so it is slower than a point prediction and needs INLA’s compiled program on the host. The interval level is fixed at 95%.
Deploy in a container	`vetiver_prepare_docker()` writes the Dockerfile, `plumber.R` and lockfile.	Write the Dockerfile by hand; `vignette("docker")` has one that works.	`vetiver_prepare_docker()` fails: its system-requirements lookup rejects INLA, which is not on CRAN.
Deploy on Posit Connect	`vetiver_deploy_rsconnect()`.	Publish a hand-written `plumber.R` that loads inlaops, INLA and sn; see `vignette("connect")`.	vetiver’s generated `plumber.R` does not load inlaops, so the API cannot serve a `bru` fit (#16). The INLA build must also run on the server’s operating system.
Monitor	`vetiver_compute_metrics()`, `vetiver_pin_metrics()`, `vetiver_plot_metrics()` on `.pred`.	The same functions work on `.pred`.	They judge the posterior mean only. Scoring the whole predictive distribution (CRPS, log score) is a separate step with `bru_score()`; see `vignette("scoring")`. WAIC and DIC go into the pin metadata by hand.
Call	`vetiver_endpoint()` and `predict()`, or any HTTP client.	Identical.	None.

In short

The core lifecycle matches. Pinning, versioning, serving, calling and basic monitoring work as they do for tidymodels, and the API returns more: posterior uncertainty, not just a point estimate.
The gaps sit at the two ends. Before pinning, there is no bundled preprocessing and the prediction formula has to be stated. At deployment, vetiver’s one-call helpers don’t work for INLA models, so the Dockerfile or plumber.R is written by hand.
Some differences come from INLA itself: posterior sampling on every request, and a compiled inla program that has to match the host.

For the full walkthrough of the shared steps, see vignette("vetiver").