There are a few approaches which come to my mind, thinking out loud.

1. introduce introspection methods and ask estimators and meta-estimators where they send each parameter.

• this has the benefit of not having to fit before inspecting the routing
• it has the downside of having to implement the introspection separately, and may not stay in sync with the other parts of the implementation and may be buggy

2. introduce a mechanism to tell build_method_metadata_params and build_router_metadata_request to record what they get and what they do with it.

• less implementation, and almost reliable as long as every estimator use these methods
• requires a call to fit, and probably a config param in a context, which has its own issue with parallelism

3. introspect using get_metadata_request's code

• doesn't require extra implementation by each estimator, and doesn't require a call to fit
• it may be tricky to get right, and it probably won't be clean and maintainable code

4. hook into methods such as fit and score

• would probably require some config param and it again would have issues with parallelism
• may introduce non-trivial overhead if implemented as a decorator for instance
• keeping track of variables after slicing (in GridSearchCV for instance) is not trivial

Thanks for this @adrinjalali... your comments here seem to be more about what internal APIs will facilitate this inspection, rather than how the user will see the results in a way that is interpretable to them.

I don't think it solves it very well, but I'd wondered about having some kinds of annotations on diagram displays... I'd also been thinking about generating descriptions of composite estimators in natural language!

Sigh. This is a hard part of the puzzle, but for now it's a reason why I'd continue arguing for explicit declarations in code rather than implicit/batteries-included routing.

Since we to move the slep006 to 1.2, I guess it makes sense to move this as well.