5.2. Using Modules in Configuration

💡 First Principle: Calling a module is calling a function — you supply arguments that satisfy its input variables and read back its outputs — so the module's variable and output declarations are its public contract, and nothing else crosses the boundary.

Why care: Variable scope and the output boundary are tested directly and are the source of real confusion: people try to reach into a child module's internals or expect the child to see parent variables. The function model resolves all of it.

The mental model: A module call is a phone call to a specialist. You tell them only what they need (inputs); they tell you back only their conclusions (outputs). You don't get to rummage through their notes, and they don't see your other calls.

⚠️ Common Misconception: "A child module can read the root module's variables." It cannot. Each module has its own scope. Data flows into a child only through arguments you pass to its variables, and out only through its declared outputs.