Fuzzy CoCoSo

Four things change. The five-step skeleton and the decision logic do not.

Cells. In crisp CoCoSo every cell is a single number. Here every cell is a triangular fuzzy number, made up of a lowest, a most likely and a highest value, and is used for criteria that are unmeasured and rest on judgement or estimation. Criterion weights can also be entered as triangles. But DecisionMind reduces the weight triple to its centre value at the very start of the calculation. This value is the average of the three numbers: (lowest + most likely + highest) / 3. It then normalises this value, so the weight becomes a single crisp number. This is an important limitation of the extension: the uncertainty in the cells is preserved, the uncertainty in the weights is not.

Scale equalisation. Crisp CoCoSo pulls every column into the 0–1 range relative to its own best and worst value. Here too the method applies the same min–max logic separately to each of the three corners: for a benefit criterion it scales all three corners against the column's smallest lower value, while for a cost criterion it first inverts the three corners and then scales them against the column's largest upper value. This inversion is essential; otherwise the order of the corners (lowest ≤ most likely ≤ highest) breaks down for the cost criterion.

Additive and multiplicative measures. The crisp method computes S and P directly from the normalised numbers. Here an extra step is inserted: the method first reduces every scaled triangle to its centre value (the average of the three corners), and only then computes S and P from this single number. In other words, the uncertainty is carried only as far as the scale-equalisation step. S, P and the three compromise strategies derived from them (proportional, worst-relative, balanced) proceed from that point on entirely with crisp numbers. This differs from Fuzzy TOPSIS's (Chen, 2000) practice of carrying vertex distance all the way to the last step. Defuzzification happens much earlier here.

Result and defuzzification. The output is a single crisp K score, not a fuzzy interval. Defuzzification takes place BEFORE S and P are computed, on the normalisation output alone. K itself is already a combination of crisp numbers. Nothing is left to defuzzify afterwards.

DecisionMind fixes three things in this extension: it uses the centre value (the centroid, the average of the three corners) as the defuzzification method; it takes the balance coefficient in the third compromise strategy as λ=0.5; and it reduces the weight triple to its centre value at the start of the calculation. Weights come from outside. The method itself does not generate weights.

As with crisp CoCoSo, the K score is only a ranking within this set of alternatives. It can exceed 1, and it is neither a percentage nor a probability. The three compromise strategies (proportional, worst-relative, balanced) each produce a ranking of their own; how close these rankings are to one another shows how robust the result is.

The difference is this: the width of the input triangle does not flow DIRECTLY into the K score. The uncertainty leaves only an indirect trace, by shifting the corners during the normalisation step. From S and P onward, everything is a crisp number. It is therefore wrong to say "the input was fuzzy, so the score also carries the uncertainty". The score itself is a single number. A user who wants to see the effect of the width must run a separate sensitivity test: change one corner or one weight and check whether the ranking shifts.

Thus instead of writing:

"Because the inputs are fuzzy, the K score also carries the uncertainty"

the report should read:

"The width of the input triangle is used only in the normalisation step; the K score itself is a crisp number, and the robustness of the result must be tested separately by changing a corner or a weight"

Use Fuzzy CoCoSo when criteria come from expert judgement or estimation and reducing that judgement to a single number would create an artificial precision. Expanding a measured criterion, such as price or duration, into a triangle is not modelling uncertainty but manufacturing it. A measured value of this kind is written into the matrix as a triangle whose three components are identical.

Choose deliberately: in this extension uncertainty is carried only in the cells, not in the weights, and is reduced to the centre value before the S/P calculation. If you want the uncertainty in the weights to also flow into the result, you need to know that your chosen extension does not do this, and say so in the report. The base method's exit condition applies exactly here too: a single data type is required across the matrix, and the cost/benefit direction must be marked correctly.

Not noticing that the weight triple is reduced at the outset. Even if you enter a criterion weight as a triangle such as (0.35; 0.40; 0.45), the engine reduces it to 0.40 immediately. Reporting that "weight uncertainty was also factored into the model" is wrong.

Reducing to the centre value first and then running crisp CoCoSo. In the illustrative example below, this path does not change the ranking (A2, A3, A1). But it shifts the K scores from 1.68 / 2.88 / 2.21 to 1.22 / 4.71 / 2.94. A2's margin appears larger than it is, because normalisation over crisp centre values produces a different range.

Entering values without the order l ≤ m ≤ u. If you skip the inversion for a cost criterion, the order of the corners breaks down and normalisation becomes undefined.

Reading the K score as a percentage or a probability. This is a mistake inherited from crisp CoCoSo. Because a fuzzy input looks "more thorough", it is easier to fall into this misreading here.

The governing principle is this:

In Fuzzy CoCoSo, uncertainty is carried only as far as normalisation; S, P and the final K score are crisp numbers. A fuzzy input does not mean the output carries uncertainty.