This section answers the following questions:

• Which dimensions to define or notfeatures should be dimensions?
• Where In which space to situate the criteria?
• How to define aggregating computations?

...

Choose Dimensions in Spaces

Main idea: dimensions are non-contingent features to the space required  required to situate a variable or a criterion in the problem. For instance if there are the following features: color, length, width, surface; then only color, length and width should be dimensions, but not surface, as it can be inferred from two of the other features (length and width).

A critical step of problem modeling is the definition of the dimensions and of the spaces they form.

...

If you make a Brand dimension, you will end up with a "holey cheese" space that is difficult to navigate and the system will be way larger than needednecessary. Instead, the Brand feature should be used to define a scope within the Category x Assortment x Packaging space.

A ground-rule could be: dimensions are non-contingent features required to the space required to situate a variable or a criterion in the problem.

The Granularity of Levers and Criteria

Main idea: when possible, situate levers and criteria in the same space, in other words, place them at the same level of granularity.

...

Levers are often imposed by the customer (typically some kind of prices and discounts): if the customer wants discounts at a product x customer family level, then so be it. Criteria, however, are often more vaguely described. It is up to optimization engine Optimization Engine configuration to translate the customer needs and requirements into actual criteria. A good practice is to seek to simplify the work at the future agents' local level, i.e. at the level of the lever. What is simple for a Value Finder? It is when it has few neighbors (ideally just one) and when these neighbors are shared with as few other Value Finders as possible (ideally zero).

The best way to achieve this is to situate levers and criteria in the same space, in other words, place them at the same level of granularity. For instance, one of our typical cases is turnover stability when a customer wants to streamline its pricing: the customer wants to change list prices (situated in a product space) and discounts (situated in a product family x customer group space) but wants its global turnover to stay the same. Where should we situate the constraint of equality between current and historical turnovers?

...

Of course, in some cases, these three propositions may not be exactly the same from a domain point of view and there are often other considerations to weigh in when making this choice. This is the whole question of understanding the customer's needs.

Intermediate Variables

Main idea: large aggregating computations with lots of inputs and parameters should be avoided.

...

Once levers and criteria are situated, we often realize that there is a computed variable that aggregates a large amount of lower granularity values. Large aggregating computations with lots of inputs and parameters should be avoided. Decomposing these computations into intermediate variables at intermediate granularity levels should be preferred to gain clarity, flexibility, and maintainability. If the system runs on multiple threads, this also improves performance as agents run in parallel while a Computation Agent has lots of processing to do on its inputs which do not scale well. The trade-off is that the resulting multi-agent system will be larger, which could cause some memory issues.

...

In this sense, the simple case shown as an example in the Graphical Norm and Description File sectionsfor Optimization Problems is bad practice, sorry about that.