workflows extract_spec_parsnip() in R: Pull the Parsnip Spec
The workflows extract_spec_parsnip() function in R returns the parsnip model specification stored inside a tidymodels workflow, whether the workflow has been fit or not. It is the supported way to inspect the engine, mode, and finalized arguments of the model without poking at internal slots.
extract_spec_parsnip(wf) # spec from unfit workflow extract_spec_parsnip(wf_fit) # spec from fitted workflow, same object extract_spec_parsnip(wf_fit)$engine # engine name as a string extract_spec_parsnip(wf_fit)$mode # "regression" or "classification" extract_spec_parsnip(wf_fit)$args # quosures for each model argument extract_spec_parsnip(wf_final) |> translate() # translated engine call after finalize extract_fit_parsnip(wf_fit)$spec # also reaches the spec, via the fit object
Need explanation? Read on for examples and pitfalls.
What extract_spec_parsnip() does
extract_spec_parsnip() returns the parsnip model spec object stored inside a workflow. It works on both unfit workflows and fitted workflows, and it returns the same spec in both cases. The function reaches into the workflow, finds the model_spec slot, and hands it back so you can read the engine, the mode, and the model arguments without reaching into internal structures.
The spec is the object you originally created with calls like linear_reg() |> set_engine("lm") or rand_forest(trees = 500) |> set_mode("classification"). Inside a workflow it lives behind several layers of list nesting, and the path can change between releases. extract_spec_parsnip() is the stable, documented door, and it belongs to the same extract_*() family as extract_recipe(), extract_fit_engine(), and extract_fit_parsnip().
extract_spec_parsnip() returns the blueprint that tells parsnip which engine to call and which arguments to pass. To get the trained coefficients or tree splits, reach for extract_fit_engine() or extract_fit_parsnip() instead. Confusing the two is the most common mistake when working with workflows.extract_spec_parsnip() syntax and arguments
extract_spec_parsnip() takes one required argument. The signature is short because the function only does one job.
The x argument must be a workflow() object that has had a parsnip model attached with add_model(). If no model has been attached, the function raises an error pointing you at add_model(). The ... slot is reserved and ignored today, so always call the function with the workflow as the only argument.
The returned object is a parsnip model_spec. You can inspect it, modify it with update(), or attach it to a new workflow.
| Spec slot | What it holds | Typical use |
|---|---|---|
engine |
Engine name as a string | Check which package will fit the model |
mode |
"regression" or "classification" |
Confirm the model task |
args |
Named list of quosures | Read the model arguments like trees or mtry |
eng_args |
Engine-specific arguments | Inspect things passed via set_engine(arg = ...) |
extract_recipe(), extract_fit_engine(), extract_fit_parsnip(), extract_preprocessor(), extract_mold(), and extract_parameter_set_dials(). Each targets a different slot of the workflow.Pull parsnip specs with extract_spec_parsnip(): four examples
Every example below builds a workflow first, then extracts the spec so you can see what extract_spec_parsnip() reports back at each stage of the modeling cycle.
Example 1: Inspect the engine and mode
The most common use is a quick sanity check. When you load a saved workflow or audit a teammate's code, the spec tells you exactly which engine and mode are wired up.
The spec carries the engine name and the mode as plain strings. The class vector confirms it is a rand_forest model spec, the same object you would build by hand with rand_forest(). Pulling these out is the first step in any audit of a fitted workflow.
Example 2: Read finalized arguments after tuning
After tune_grid() and finalize_workflow(), the spec carries the best hyperparameters. extract_spec_parsnip() is the right way to confirm what was finalized.
The args slot shows quosures, one per model argument. After finalize_workflow() replaces the tune() placeholders, the quosures hold the actual chosen values. Reading args$trees and args$learn_rate confirms the workflow is ready to fit.
translate() to see the engine call. Piping the extracted spec into translate() reveals the literal call parsnip will make, including engine-specific defaults. This is the cleanest way to verify a hyperparameter survived the finalize step.Example 3: Reuse a spec in a different workflow
Pulling the spec lets you wire the same model into a new workflow without rebuilding the call from scratch.
Same model spec, new preprocessor. The spec is a pure recipe for the model call, so it does not care which preprocessor attaches to it. This pattern is useful when you have settled on hyperparameters and want to test the same model against several feature pipelines.
Example 4: Compare the spec before and after fit
The spec survives the fit unchanged. extract_spec_parsnip() returns the same object whether you call it on an unfit or fitted workflow.
The returned specs are identical. Fitting does not mutate the spec; it produces a separate fit object that lives in another slot of the workflow. Reach for extract_fit_parsnip(wf_fit) if you want the spec plus the fitted results bundled together.
Common pitfalls
extract_spec_parsnip() is small, but three failure modes catch new users. Each error message points roughly at the fix, and the corrections below remove the ambiguity.
extract_spec_parsnip() returns only the model recipe: engine, mode, arguments. Calling coef(), summary(), or predict() on the spec raises an error because there is nothing fitted inside. Reach for extract_fit_engine() or extract_fit_parsnip() when you need the trained model.Try it yourself
Try it: Build a workflow that fits a decision_tree() on the iris dataset with tree_depth = 4 using the rpart engine in classification mode, then pull the parsnip spec and read its mode and tree depth. Save the extracted spec to ex_spec.
Click to reveal solution
Explanation: extract_spec_parsnip() returns the unchanged parsnip spec from the fitted workflow. The mode slot is the string you set with set_mode(), and args$tree_depth holds the quosure carrying the depth value you passed in.
Related tidymodels functions
extract_spec_parsnip() rarely flies solo. These are the functions you will reach for alongside it.
add_model()attaches the parsnip spec thatextract_spec_parsnip()will later return.extract_fit_parsnip()returns the parsnip fit object, which bundles the spec plus the fitted results.extract_fit_engine()returns the underlying engine fit, such as thelmorrangerobject.extract_recipe()pulls the recipe out of the same workflow, when one is attached.extract_preprocessor()works on any preprocessor type, not only recipes.finalize_workflow()replacestune()placeholders in the spec with concrete values.translate()shows the literal engine call the spec will make once fit.
See the workflows extract reference for the full extract verb family.
FAQ
What is the difference between extract_spec_parsnip() and extract_fit_parsnip()?
extract_spec_parsnip() returns only the unfitted parsnip spec, the blueprint describing engine, mode, and arguments. extract_fit_parsnip() returns the parsnip fit object, which carries both the spec and the trained results, including coefficients or tree splits. Reach for the spec when auditing what was wired up; reach for the fit when you need the trained model behaviour, like calling predict() or tidy() on the results.
Does extract_spec_parsnip() work on a workflow that was never fit?
Yes. The spec is set when you call add_model() and never changes during fit(). extract_spec_parsnip() happily returns the spec from an unfit workflow, and the returned object is identical to the one you would get after fitting. The function only errors when no model has been attached at all, in which case the message tells you to call add_model() first.
Why does my extracted spec still show tune() placeholders?
You extracted before finalizing. After tune_grid() you must call finalize_workflow() (or finalize_model() for a bare spec) with the chosen parameter values before the spec carries them. Without that step, args$trees still holds the tune() quosure rather than the chosen integer. Inspect the spec right after finalize to confirm the values stuck.
Can I edit the extracted spec and put it back into the workflow?
Yes, via update_model(). Extract the spec, change one argument with update() or set_args(), then call update_model(wf, new_spec) to swap the modified spec back into the workflow. Avoid mutating the spec object in place; the workflow holds a copy and will not see your edits until update_model() runs.
How does extract_spec_parsnip() relate to translate()?
extract_spec_parsnip() returns the abstract parsnip spec, the same one across engines. translate() takes that spec and shows the literal engine call, like ranger::ranger(num.trees = 500). Pipe one into the other when you want to confirm an argument survived the tidymodels-to-engine translation, especially after finalize_workflow() replaces tune placeholders.