Generally confused re: estimand vs adjustment vs gcm estimation approaches, and code

I am trying to follow the documentation, but find myself very confused about what seems to be a core issue: what is the difference between the multiple types of estimation functions (by which I do not mean, regression vs matching etc)? In particular:

1. The docs section on Estimating average causal effect using backdoor (with regression, or the other methods with very similar syntax) has an example.

https://www.pywhy.org/dowhy/v0.10.1/user_guide/causal_tasks/estimating_causal_effects/effect_estimation_with_backdoor/regression_based_methods.html

The code requires choosing an estimator, and looks something like this:

estimate = model.estimate_effect(identified_estimand,
       method_name="backdoor.linear_regression",
       test_significance=True
)

1. However, just six pages later under Estimating average causal effect using GCM, there appears to be another approach entirely.

https://www.pywhy.org/dowhy/v0.10.1/user_guide/causal_tasks/estimating_causal_effects/effect_estimation_with_gcm.html

The call here looks like this:

gcm.average_causal_effect(causal_model,
                         'Y',
                         interventions_alternative={'T': lambda x: 1},
                         interventions_reference={'T': lambda x: 0},
                         num_samples_to_draw=1000)

This appears to be able to also estimate an ACE — but without going through the intermediate step of choosing an identification strategy. I tried reading the code itself, but I didn’t see a default call to one of the estimate_effect methods, so this seems to be doing something entirely different. (A potentially non-linear regression, based on the auto-fit mechanisms?)

More critically though, if the gcm.auto.assign_causal_mechanisms function can use splines as well as linear models in its regression, then this approach looks not only easy, but also much more flexible than the estimate_effect approach. Why wouldn’t I just choose this one?

1. Then under Finding optimal adjustment sets, there appears to be a third approach. https://www.pywhy.org/dowhy/v0.10.1/example_notebooks/dowhy_efficient_backdoor_example.html

Here, the call looks like this:

ident_eff = AutoIdentifier(
    estimand_type=EstimandType.NONPARAMETRIC_ATE,
    backdoor_adjustment=BackdoorAdjustment.BACKDOOR_EFFICIENT,
)

Is this object ident_eff then fed into model.estimate_effect, as in 1. ? If so, why is it not just an option that can be given to identify_effect? I’m confused by the two very different function calls to create an estimand (if in fact that’s what this is.) Or is this again an entirely different path / software path to getting an estimate?

Version information:

• DoWhy version 1.4

Additional context

While legitimately and generally confused, I ask because of a specific and somewhat complicated research question:

I am searching a large number of variables to see which ones have causal effects on Y. They are too numerous for PC (which is the algorithm I need to use). So, for each variable, my plan is to: Take a maximal tractable subset of the variables, but always with Y and X Fit a graph Record which variables are either mediators, or potential confounders, to X->Y Repeat this a few times to make sure every variable has been in at least one estimated graph, and ideally several At the end, re-estimate a new graph with all of, and only the discovered potential mediators + confounders (plus X+Y) Then and only then, estimate an effect of X->Y from this final graph, because I am most confident that it has all the relevant variables for a clean estimate.

As long as I ensure that all of these accumulated variables are in the estimated graph (so that the backdoor paths can be seen and dealt with; which I understand will happen automatically?), will average_causal_effect be sufficient for an unbiased estimate here? I don’t want to use model.estimate_effect because not all of my variables have a strongly linear relationship with Y, and I don’t like all of the parameter decisions that go into matching — but it’s just not clear to me that these approaches are even comparable.

But am I missing something, either in the approach, or the software?