Z-number PROMETHEE (Nuriyev, 2020)

An organisation will choose its main vendor among three software vendors. There are two criteria: performance-test result and support-service quality; both are "higher is better" and equally weighted (0.50 and 0.50). Each vendor's claim is given as a value (A) and the reliability of the source of that claim (B).

Vendor 1 is a long-established corporate firm. It claims "high" performance, and this claim rests on a large number of reference projects; reliability is high. Support service is "medium," and this assessment too comes from a reliable source. Vendor 2 is a newly founded start-up. It also claims "high" performance, but this claim rests on only a few pilot deployments; reliability is low. Support service is claimed "high" and there are references for this; reliability is high. Vendor 3 is a mid-sized, long-established firm. It claims "medium" on both criteria, and both come from reliable sources.

The method first takes the centroid of every cell's reliability component and scales the value by the square root of this centroid. T2's performance claim shrinks considerably because of its low reliability (roughly 0.32 once reduced to a single number); T1's identical claim stays almost unchanged because of its high reliability (roughly 0.81). It then makes a pairwise comparison on these shrunk values with the level-criterion preference function and computes the incoming, outgoing and net flows.

The result reads as follows. T1 ranks first; its performance claim sits at the same level as T2's, but rests on a reliable record. T2 ranks second; its strong and reliable claim on support service puts it ahead of T3, but the low reliability of its performance claim costs it first place to T1. T3 is last; its claims are reliable but modest on both criteria.

The organisation's hesitation: what happens if T2's performance claim is updated to "high" reliability, with a broad reference list instead of a few pilot deployments? Recomputed independently, T2's net flow rises to 1.50, T1's falls to 0.00, and T2 moves into first place. This shows the reliability component is not cosmetic, but an input that genuinely changes the ranking.

In the report: "T1 clearly ranks first, even though its performance claim sits at the same level as T2's, because this claim rests on a reliable record. If the reliability of T2's performance claim rises, the ranking may shift in T2's favour."

Source: A validation example prepared by DecisionMind for the Z-PROMETHEE engine. The algorithm follows the reliability-based shrinking and level-criterion steps described by Nuriyev (2020); it is not the paper's own table and figures. The net flows and the reliability-update scenario were calculated by running the engine independently.

A municipality will choose one of three candidate buildings for a new nursery. The criteria are physical safety compliance and teaching-staff experience; both are "higher is better." One building's operator claims "very high" safety, but this claim rests only on their own statement; there is no independent audit report. Another building's safety claim is more modest but has recently passed an independent audit.

The method computes every building's reliability-shrunk values, makes a pairwise comparison with the level criterion, and finds the net flows. Suppose the audited building, with its more modest claim, moves ahead of the unaudited but more confidently claimed building, because the latter's low reliability shrinks its claim in the calculation.

The municipality's hesitation: if the unaudited building's claim is later confirmed (by an independent audit), could the ranking change? This shows the decision should not be finalised before the audit is complete; a choice resting on a claim of uncertain reliability can be reversed by information confirmed afterwards.

In the report: "The building that has passed an independent audit stands out clearly, even though its claim is more modest, because its reliability is high. If the unaudited building's safety claim is confirmed, the ranking may change."

In the software-vendor table, entering T2's performance claim into the calculation with the same weight as T1's, without regard to reliability, is wrong: it equates an unverified, low-reliability claim with a proven one, and wrongly shows T2 as first. The second error is leaving the reliability level to the vendor's own statement; T2 saying "we are reliable" is not a measure of reliability, it must come from an external source such as the number of references or a record history. The third error is calculating with the Type-4 thresholds (q, p) left at their default without ever setting them, and never stating this choice in the report; these thresholds are specific to the problem, and the values chosen must be written down explicitly.