TM1 feeders are often presented as one of the awkward parts of modelling: essential but difficult, powerful but suspect. That reputation is understandable. Feeders demand deliberate design, and poor feeder design can produce missing values, excessive memory use, and confusing rules. But feeders are not an accidental defect in TM1’s calculation engine. They are a central part of how a HyperSparse planning model remains both detailed and practical.
The starting point is sparsity. A serious planning model may combine products, customers, organisational units, cost centres, periods, scenarios, currencies, measures, and other dimensions. A model with 10,000 products, 5,000 customers, 120 months, 10 scenarios, and 20 measures has 1.2 trillion possible cells. Yet only a small proportion will contain business data. Most customers do not buy most products in most months. Most planning scenarios do not need values at every detailed intersection.
Treating every theoretical cell as occupied would be wasteful beyond reason. TM1’s HyperSparse architecture addresses that problem by concentrating storage and processing on the comparatively small set of cells that matter. Empty cells remain possible addresses without requiring the system to store them merely because the dimensions make them possible.
A Rule Can Be Valid Where No Business Value Exists
Rules introduce a second form of the same problem. Consider a simple calculation:
Margin = Revenue − CostThe rule may be valid everywhere in the cube. It can theoretically apply to every product, customer, month, scenario, and version. But theoretical validity is not business relevance. Margin is meaningful only where Revenue or Cost exists.
If TM1 treated every possible Margin intersection as active simply because the rule applied there, the rule would begin to erase the advantage of sparse design. The active calculation space would expand toward the size of the theoretical cube.
Feeders prevent that expansion. They tell TM1 where a rule-calculated cell may be relevant. Revenue and Cost can feed Margin. A feeder does not instruct TM1 to calculate and store every possible Margin value in advance. The rule still defines the calculation. The feeder identifies the targets that must be treated as potentially non-empty.
Feeders Are a Selective Map of Rule Dependencies
When a source value exists at a detailed intersection, the corresponding feeder marker allows TM1 to consider the relevant Margin cell in its sparse calculation path. In the common case, this makes a leaf-level rule cell available to appear in sparse views, contribute to consolidations, and serve as an input to further calculations.
That distinction is the key to understanding feeders. They are not primarily a way to force calculations to happen. They identify the rule targets that need to participate in the model. TM1 can then calculate a value when it is requested rather than fill the entire cube with precomputed results.
The model therefore carries a deliberately selective map of its own active logic. It retains sparse inputs and does not materialize every potential rule result, but it preserves enough dependency information to know which calculated cells may matter.
The Middle Ground Between Precalculation and Endless Search
The alternatives make the design choice clearer.
One approach is to calculate and store every potential result in advance. This is the logic of materialized views, summary tables, and prebuilt aggregates. It can make retrieval fast when reporting paths are predictable, but every source-data change may require many stored results to be refreshed. In a planning environment, where assumptions, versions, allocations, and forecasts change continuously, that can mean maintaining a large body of values that are zero, irrelevant, or never viewed.
Another approach is to evaluate every applicable rule dynamically whenever a user requests a result. That avoids maintaining precomputed values, but it risks asking the calculation engine to search a huge, mostly empty potential space. In a large cube, that is not a realistic basis for responsive interactive planning.
TM1’s feeder model occupies the useful middle ground. It does not materialize every possible rule result, but it preserves enough dependency information to identify calculated cells that might matter. The result is a dynamic calculation engine that does not need to treat every theoretical intersection as live.
Precision Is Both a Performance and a Correctness Question
Feeders resemble a dependency graph: a structure recording how an input affects downstream calculations. Their specific role in TM1 is tied to sparsity. They indicate not only that one value depends on another, but that a rule-driven target belongs in the set of cells that may be non-empty.
That is why feeder design affects both performance and correctness. An underfed model may omit a legitimate calculated value from a sparse view or consolidation because TM1 has not been told to consider the target cell. An overfed model may activate too much of the cube, consuming additional memory and calculation effort.
Neither outcome changes the principle. The feeder map should match the business logic it represents. A precise feeder activates the places where a source value can genuinely lead to a relevant result. It leaves inactive the much larger set of cells where a rule is theoretically valid but commercially meaningless.
The Feature Is Selectivity
Other analytical technologies solve related problems differently. Columnar databases are designed for efficient scanning and aggregation of stored facts. Traditional OLAP systems may rely on prebuilt aggregate levels when expected questions are known in advance. Sparse matrix systems store meaningful coordinates and values for numerical computation.
TM1’s distinctive planning problem includes hierarchies, writeback, versions, consolidations, and business rules. Feeders help the engine preserve selectivity in that setting. They identify the leaf-level, rule-calculated cells that may need to participate in the model while allowing TM1 to ignore the vast majority of a theoretical cube.
That is not a compromise imposed on TM1 developers. It is one of the architecture’s defining modelling features. The aim is neither to feed everything nor to avoid feeders. It is to represent the real dependencies of the business accurately enough that the model can remain detailed, correct, and responsive.