forecasting-ch18-hierarchylisted

# Chapter 18: The Hierarchy ## Scope and intake Use when forecasts across stores, regions or products must add to consistent totals. Do not use for assuming coherent totals automatically improve accuracy or preserve nonnegativity. Ask only for unresolved material inputs: What are the bottom-level quantities and summing relationships? Do nodes overlap? Are base forecasts for the same origin/horizon? Are historical forecast errors available to estimate covariance? ## Input contract and additional evidence Long format, one row per node and period: `node,timestamp,target`, with every node on an identical calendar and historical values that already add up within `history_tolerance`. The hierarchy is declared in config as `edges`, a list of `[child, parent]` pairs; the tool builds the summing matrix itself (aggregates first, leaves last). The older `node,forecast` input with a supplied `S` is still accepted for a one-shot reconciliation of forecasts you already hold. Minimal **format illustration**, not sufficient training data: ```csv node,timestamp,target Total,2010-01-01,100.7 A,2010-01-01,60.4 B,2010-01-01,40.3 Total,2010-02-01,105.9 A,2010-02-01,63.1 B,2010-02-01,42.8 ``` ## Executable interface Exact CLI columns: `node,timestamp,target | node,forecast`. Supported method controls: `S, as_of, coherent_quantiles, edges, frequency, history_tolerance, horizon, nodes, origins, past_errors, pool, season, seed, shrinkage, transform`. The tool builds S from `edges`, forecast