Toward a Theory of Systems Engineering

Systems engineering has been recognized as an emerging subdiscipline of engineering for at least 50 years. Still, the systems engineering community has not reached agreement either on what constitutes systems engineering or a disciplinary basis for systems engineering. Kasser et al. [1] suggest that “a discipline generally matures when an overriding axiom is presented and accepted by the majority of practitioners.” They then present seven principles for system-engineered solution systems. While these principles fall short of comprising an axiom, the first is rather provocative: “There shall be a clear, singular objective or goal.”

A goal of the International Council on Systems Engineering (INCOSE) has long been to create a theory or theories of systems engineering. A step toward this goal is exemplified in a recently issued white paper entitled “Systems Engineering Principles” [2]. This white paper presents seven criteria for a theory of systems engineering: (1) transcends lifecycle, (2) transcends system types, (3) transcends context, (4) informs a world view on systems engineering, (5) not a how-to statement, (6) supported by literature and/or widely accepted in profession, and (7) economy of principle. Strangely, however, this list does not include the concept that an underlying theory should provide a validity or consistency test, which would seem to be a key requirement of any such theory.

In the 1990s, Hazelrigg [3–6] proposed to the engineering design and systems engineering communities that design and systems engineering are decision-making processes and that decisions are optimizations requiring objective functions or preferences. This concept reinforces the notion of Kasser and Hitchings that systems engineering needs a clear, singular objective and also hints to the notion that theories of systems engineering are more likely to be preference-based than based on physical principles or “laws of nature” as have been other engineering disciplines.

In keeping fully with the criteria of INCOSE and the notion that systems emerge as the consequence of the decisions that define them, we propose a preference-based theory with a more intuitive objective, “I want the best system I can get.”¹ We contend that this preference should be widely accepted given that the definition of “best” is left entirely to the project manager or systems engineer to specify. Our principal goal for this theory is to create distinctions among methods, approaches, procedures, or practices that support this preference versus those that fail to support it, thus leading to a fundamental theory of systems engineering.² The preference statement itself provides a basis for mathematical proof of certain methods that lead to choices supporting the preference, while it also identifies methods, approaches, procedures, or practices that fail to support this preference, for example: (1) by virtue of faulty mathematics, (2) by their use outside the boundaries of their validity, (3) by their ability to create path dependencies where given inputs can yield multiple results with radical differences in system performance, or (4) by leading to unwanted and/or unnecessary reductions in system performance.

As noted in the review by Sage [7], prior research seeking to develop a theory of systems engineering has been ongoing for over 50 years. This research has taken two distinctly different paths, a descriptive path (how systems engineering is performed) and a normative path (how systems engineering should be performed). Consider the example of arithmetic. A descriptive study of arithmetic might examine how children learn to add numbers. The knowledge gained from such a study could prove useful in determining how to teach addition to both accelerate the learning process and minimize mistakes. A normative study, on the other hand, would examine the theory of addition, leading to an understanding of what to teach, that is, what rules or procedures lead to correct results. The theory of systems engineering presented here is normative. Its focus is on how systems engineering should be done. Hence, we shall concentrate our review of prior work on this research path.

The earliest concepts of value under uncertainty and risk were formulated by Daniel Bernoulli in the early 1700s [8], and the fundamental concepts of decision theory were laid down by Dodgson in the book, Alice’s Adventures in Wonderland [9], written for children in 1865.³ In Alice’s encounter with the Cheshire Cat, the Cat provides Alice with the fundamental axioms of decision-making [6]. In the 1940s, these axioms were extended by John von Neumann and Oskar Morgenstern [10] to the case where outcomes are uncertain. Their mathematic is referred to as utility theory, and they also, in the same reference, lay out the foundations of game theory. Interestingly, the derivation provided by von Neumann and Morgenstern offers a proof of the existence of “utility” as a valid measure of preference under uncertainty and, within the context of a well-argued set of axioms, shows that it is the only mathematically consistent measure. Accepting this proof demands that a rigorous theory of systems engineering must be consistent with the utility theory.

The applicability of decision theory to systems engineering has been recognized for at least 50 years. An early application by Miles at the Jet Propulsion Lab considered the design of the science of a Mars mission. Miles also contributed to the application of decision theory for other missions [11–13]. In addition, Sage [7,14] and Tribus [15] clearly recognized the role of decision theory in engineering design. Both Sage and Tribus outline utility theory as a tool for engineering design under uncertainty. In the early 1970s, Hazelrigg, under support by the NASA Planetary Office, applied utility theory to the study of rationality in NASA’s planetary missions, resulting in a master’s thesis by Brigadier [16]. For the past 50 years, Howard [17–19] has been a major contributor to the foundations and teaching of decision theory. He has fostered the application of decision theory in many areas of business and engineering. By the late 1990s, ABET (the Accreditation Board for Engineering and Technology) formally recognized this.⁴ Also, in 1996, Hazelrigg [20] recognized the relevance of how Arrow’s Impossibility Theorem establishes that certain approaches used in engineering design and systems engineering cannot lead to optimal choices. Yet, despite the extensive research and application of decision theory to engineering design, there has been no attempt to use decision theory as a basis for the derivation of a theory of systems engineering. That is the unique challenge addressed here.

The proposed approach is not the first attempt to mathematize engineering design and systems engineering, however. About 30 years ago, Suh [21] published his work on axiomatic design. In so doing, he recognized the value of a mathematically rigorous axiomatic approach to the establishment of a science of design. But his approach was not based on the mathematics of decision theory, and he did not posit his theory as being based on a preference. Axiomatic design is based on two design axioms, the information axiom–minimize the information content of the design, and the independence axiom–maintain independence of functional requirements. Mathematically, these axioms describe a constrained optimization framework.⁵ The preference (or objective) of Suh’s framework is less information is better. But this dictates to the decision maker a preference that he or she most likely does not hold, nor is it intuitively obvious that it is a preference that he or she should hold. As noted by Dodgson [9], no person nor method should dictate preferences to a decision maker.⁶

A second problem with Suh’s axiomatic design lies with the independence axiom. This axiom is actually a constraint. Constraints never improve optimal results. They are either inactive or active. Constraints that are inactive are satisfied automatically by the optimal solution and have no impact on the result. In effect, they are not constraints at all. Constraints that are active only degrade the performance of the system—they never improve it. As a result, it is generally desirable to impose as few constraints as possible on the design of a system.

Despite these shortcomings of Suh’s axiomatic design, much work has been done to derive operative theorems from Suh’s “axioms.” Although not meaningful in the context of a rigorous framework, this work nonetheless shows the potential for a preference-driven theory of systems engineering.

Many systems engineering decision-making approaches have been posited and published over the past 50 years. Among these are such widely used approaches as analytical hierarchy process (AHP) [22,23], axiomatic design [21,24], Taguchi [25], robust design [26], Pahl and Beitz [27], the Pugh method [28,29], Physical Programming [30], Quality Function Deployment (QFD) [31], and Six Sigma [32]. It would seem reasonable to subject methods such as these to a validity test, particularly as the extant evidence for their efficacy is largely anecdotal. High on this list is the notion of systems thinking [33,34]. Many researchers, authors, and practitioners of systems engineering advocate systems thinking–thinking in terms of the big picture—as a rigorous approach to system design. It would seem reasonable to challenge this view.

A clear goal for a theory of systems engineering is to give credibility to Systems Engineering as an engineering discipline. In this context, a discipline may be defined as a field of study or branch of knowledge, a set of rules, or code of behavior. We view an engineering discipline as an agreed upon and demonstrably valid set of fundamental rules, laws, processes, procedures, or methods that define a field of study. The rules and laws of the discipline distinguish between processes, procedures, or methods that are deemed valid and those that are deemed not valid. For example, we would not consider a person who does not accept the first, second, and third laws of thermodynamics to be a thermodynamicist. Without such distinctions, there is no way to distinguish a person who is an expert versus one who is a complete neophyte or even a rebel to a discipline. Systems engineering has lacked such distinctions, and we believe that this is a key reason that it has yet to emerge as a maturing discipline.

To show that a theory, method, practice, or procedure is valid, it must be proven to be valid in all relevant cases or the boundaries of its validity must be clearly distinguished. For example, to show that the laws of addition are valid, it must be shown that they are valid for all possible combinations of cardinal numbers. To show that a theory, method, practice, or procedure is not valid, it is necessary to show that it is not valid in only one relevant case⁷ or to show that it violates an accepted underlying premise.⁸ To show that a theory, method, practice, or procedure is subject to path dependencies, it must be shown only that path dependencies may occur in at least one case, unless those cases can be specifically excluded by some rules or mechanisms.

Recognizing that engineered systems emerge as a consequence of the set of decisions that determine the system, a theory of systems engineering should provide a mechanism to distinguish between methods, approaches, procedures, or practices that support decision-making that improves overall system performance and methods that degrade system performance.⁹ In addition, a theory of systems engineering should have clearly defined boundaries, namely, a well-defined set of conditions, within which the theory is provably always valid.

We begin our derivation of a theory of systems engineering with the concept of “best” as expressed in the preference statement, I want the best system I can get. So long as the relevant decision maker is allowed to define “best” in any way he or she wishes, it would seem that this would be a universally acceptable preference. Conceivable alternatives to this preference might be, “I want the worst system I can get,” or simply, “I don’t want the best system I can get.” The former preference statement merely redefines best to be “worst” and so is the same as our proposed preference. The latter alternative simply eliminates one system alternative, the best one, and fails to distinguish between all others. To enforce this preference, we first must define best to be sure to exclude it, and then, we must be indifferent to all other outcomes. This leads us to a final alternative, I don’t care how good the system is. But this statement would render systems engineering valueless.

A third condition is that the set of allowable alternatives be closed. For example, if a requirement is that the system must weigh less than w pounds, and if the system performance improves with weight, then (mathematically) there will be no “best” design because there is no weight that is closest to but less than w pounds. Alternatively, a “best” system may exist if the requirement is stated. “the system may not weigh more than w pounds,” as this requirement yields a closed alternative set. Under these conditions, it should be immediately clear that a simple preference statement such as, “I like money and more is better,” enables the existence of a “best” outcome.

Where there is a single decision maker or a dictator who determines the preference that defines “best,” we can argue that the transitivity condition must be met, particularly in the case of well-considered decisions such as system design decisions. A person who has an intransitive preference is subject to a “money pump” [36], which subjects the person to a circular series of trades that drain the person of his or her wealth with no resulting benefit. But, beyond this, to be irrational, a person must know that they are being irrational.¹¹ For example, the person must be presented two alternatives, A and B, each with a clear and distinct outcome such that the person clearly prefers one, say A, over the other, yet consciously chooses B. It would appear inconceivable how this could happen. For example, suppose the person is presented with two stacks of money from which he may choose one. Stack A contains $1,000, stack B contains $100, the person is clearly aware of these amounts, and the person clearly wants more money rather than less, yet consciously chooses stack B. Perhaps the person simply doesn’t, for whatever reason, want to take the choice that most satisfies his preference for money. For example, perhaps he wants to leave the money on the table for another person. But this want overrides the preference for more money, and the person winds up choosing according to his real preference at that moment. There is no irrationality in this decision although, to an observer, the decision may appear to be irrational.¹² Furthermore, given the seriousness of systems engineering decisions, it would make sense that well-considered and rational decisions are to be preferred.

It is important to note here that we do not suggest that all systems engineering theories, approaches, etc. either do or must adhere to the conditions for the existence of a best design, nor do we limit ourselves to such cases. Rather we have examined the necessary and sufficient conditions for the existence of a best design in order that we can definitively identify theories, methods, approaches, procedures, or practices that fail to meet these conditions, examine their impact on system performance and propose corrective or ameliorative actions. We have already done this in the cases of continuous improvement and requirements flowdown processes, and the breadth of this theory will be demonstrated by the range of its applicability to such cases.

Unlike engineering subdisciplines that have their bases in laws of nature, the theory of systems engineering that we propose derives from mathematics, independent of the physical world. Accordingly, the validation of such a theory is obtained through rigorous derivation and the presentation of mathematical proofs rather than experimental or anecdotal evidence. Axioms comprise the basis for such proofs and, although there is no “correct” set of underlying axioms such that we could conclude that all other sets are incorrect or inappropriate, the object of the axioms that underlie much of mathematical theory is that they be self-evident and well argued. For example, such is the case for the axioms of arithmetic [37]. A mathematical theory is comprised of the set of conclusions (theorems) that one can draw from a given set of axioms. While one has considerable freedom to choose the axioms that enable the derivation of a particular mathematical theory, it is strongly preferred that axioms chosen comprise a parsimonious set and mandatory that they comprise a self-consistent set. That is, no axiom in the set may contradict any other axiom in the set. Furthermore, when one mathematical theory builds on, combines with or adds to another, any additional axioms that enable the composite theory must also be entirely consistent with all other axioms spanning the entire range of the resulting theory. It is not a valid practice to combine mathematical theories whose validity depend on axiomatic bases that are in conflict with each other. Where such conflicts occur in current systems engineering practice, we shall strive to point them out and offer evidence of errors that result from their use.

It is also necessary to recognize that it is not sufficient to merely provide the derivation of a solution procedure to a problem to assure that the procedure is valid. To assure validity, one must also provide an existence proof of the solution itself. That is, to assure that an answer to a problem is correct, we first must be certain that a solution actually exists [38]. Note that, in the absence of the existence of a solution, it is ipso facto that the solution is incorrect.

Another matter of which we must be aware is that certain procedures may enable path-dependent results, that is, results that depend on the particular sequence of computations or the path taken to obtain the results [35]. A rigorous theory of systems engineering must either avoid such possibilities or devise a plan to efficiently handle this difficulty.

In some instances, it may prove difficult or even impossible to avoid analytical or computational procedures that enable manifestations of the above behaviors. In cases such as these, it will be our goal either to derive conditions under which a procedure can be trusted to produce the desired result or to provide alternative procedures that bound the unwanted behavior.

The specific branches of mathematics that we draw upon most heavily in this work include probability theory as defined by the Kolmogorov axioms, optimization theory, decision theory, von Neumann-Morgenstern utility theory, and social choice theory.

We begin with the assumption that a system preference exists at least in the mind of some entity responsible for the overall system. For example, one might assert the preference, “I like money, and more is better.” This statement rank orders all monetary outcomes for this particular decision entity, and the resulting ranking is entirely independent of any perception of which outcomes may or may not be possible. Preferences are independent of outcomes. Furthermore, preference statements are particularly powerful as they divulge the goal of the decision-making entity.

Our implementation of the system preference shall start by replacing the preference statement with a more precise mathematical expression. We begin by defining some terms. Let $X$ be a set of statements that fully describe a system through its entire life cycle with the objective of facilitating a prediction of system performance, especially as measured in terms of a preference. This set may include statements regarding sizes, shapes, colors, dimensions, procedures, practices, and even beliefs, that is, probabilistic statements. We then denote by $Xi$ the ith instantiation (namely, the ith specific system description) of $X$⁠. A complete system description $X$ enables estimation of the outcome of a choice to instantiate $X$⁠. We shall denote the outcome by the symbol $Ω(X)$ or, for the ith instantiation of $X$⁠, by $Ωi(Xi)$ or simply Ω_i. Ω_i may be numeric or nonnumeric or both, and it may comprise a set of statements that describe an outcome.

We note again that the transitivity condition on preferences demands that preferences be deterministic. This is because transitivity cannot be guaranteed otherwise. The rationale for acceptance of this condition in the case of a single decision maker is that preferences are in the head of and belong to the decision maker and are thus known precisely to the decision maker. Accordingly, preferences must be clear and distinct. This means that the decision maker knows his or her preferences without question and therefore does not require mathematical aids for their determination. It follows that these aids are at best superfluous or, more likely, misleading. Optimization theory rests heavily on this condition. So, failure to accept this condition invalidates much of optimization theory.¹⁴ The conditions imposed here are necessary for the existence of a best system design, and they accordingly invite investigation into cases where a transitive preference would appear not to exist.

We have already alluded to certain conditions that would impede or preclude application of the decision rule. These would include, for example, the nonexistence of a transitive system preference, nonexistence of beliefs on system outcomes, reliance on choice resulting from group interactions, design by multiple persons each of whom is acting on their personal preferences rather than the overall system preference, and inconsistent belief systems (probability estimations) across system decision makers. These all offer to induce choices that lower overall system performance. Acknowledging these impediments to optimal system design decision-making, the decision rule leads to the following theorems.

While this theorem may appear to be evident and trivial, it is not. Subtle implications of this result are described in the  Appendix. Furthermore, in light of Theorem 2, lexicographic ordering can be viewed as a form of organizational design. The ranking on this ordering is imposed by the transitivity condition as required by Theorem 2.

As a result of these theorems, we see that failure of all system decision makers to use a common system preference as the basis for their system choices cannot result in system performance better than that achievable using only the common system preference and, in general, will result in a loss of performance as measured by the common system performance. This conclusion applies at all levels of systems engineering in a project. It is also the case that, to achieve system optimality, system choices must be based not only on a common system preference, but also on a common set of beliefs (namely, probabilities on all system uncertainties). Achieving these conditions will pose formidable problems in the formation of such things as incentives that promote cooperative decision-making.

Consider the constrained optimization problem, maximize $J=f(X)$ subject to constraints $g(X)≤b$⁠, where $g(X)$ comprise a vector of constraints imposed on the optimization of the scalar objective $f(X)$⁠.

Alternatively, we note that constraints do not add alternatives to the set of available choices. They only serve to remove alternatives from this set and, if they remove the unconstrained optimal choice(s), performance must be reduced. Some constraints, such as laws of nature, may be unavoidable and must be applied. But others, requirements for example [43], may inhibit alternatives when designing a system and may be avoided by better choice of the system preference. For instance, a requirement that the design of a telephone must connect by wire to the telecommunication system precludes the possibility of designing a cell phone.

Thus, we know that constraints never lead to improved performance as measured by the objective $f(X)$ and, if the constraints are active, they always result in lowered performance as measured by this objective. As a result, we see that we must be aware of procedures that impose arbitrary constraints on system design and find ways to prevent such constraints from penalizing system performance or eliminate them altogether.

It is important that we understand the difference between the system objective or preference and constraints. Constraints are not and never can be thought of as an objective. Objective functions or preferences rank order system design choice outcomes, thus enabling design optimization whereas constraints define choices that are not allowed. Constraints do not provide information necessary to rank outcomes, and they do not enable design optimization. A good definition of a constraint is, it is something that we don’t get to decide about. Laws of nature (F = ma, for example) are an example of something we don’t get to decide about, and they legitimately constrain system design choices. Unfortunately, common systems engineering procedures often arbitrarily assign constraints (for example, requirements [43]) to facilitate the engineering process. As we see from the aforementioned proof, arbitrary constraints never enable the achievement of higher levels of performance than when such constraints are not imposed. In this regard, it should be noted that the need for requirements can often be avoided by proper selection of the system preference.

Before proceeding, it is worth reviewing the assumptions upon which this theory is based:

1. Engineered systems emerge as the consequence of a set of choices made largely by the system design workforce, and the environment, structure, and rules within which the workforce performs its design tasks. Beginning in the 1960s and continuing since, engineering design and systems engineering have become increasingly viewed as a decision-making process. Decision theory, game theory, and social choice theory [44] have emerged as the important mathematics of design and systems engineering.

2. Preferences exist. Rational system design is not possible in the absence of a preference relating to system performance. In the absence of a system preference, there can be no distinction in performance between alternative system designs and, hence, there would be no need for systems engineering.

3. Uncertainty is a significant factor in the systems engineering process. Engineers have a tendency to consider uncertainty in systems engineering decision-making as being applicable only to their ability to predict system behavior as a function of system design. But this is only one source of uncertainty and often far from the largest. There is also uncertainty on manufacturability, system reliability, demand for the system, and uncertainty in the environment within which the system will function such as future fuel prices and regulations. It is the nonengineering uncertainties that often dominate system design considerations.

4. Mathematical integrity is a necessity. Mathematics is the “science” of consistency. It is crucial that consistency of thought be maintained throughout as a basis for a rigorous derivation of a normative theory of system engineering.

These premises are not only reasonable but also necessary for the formulation of a normative theory of system engineering.

The system preference, “I want the best system I can get,” and the theorems proven earlier lead to the following fundamental principles of systems engineering:

1. The concepts of better and best exist only in the context of system preferences. In the absence of a system preference, there is no performance distinction between system alternatives and no rational basis for design choices.

2. System decisions based on preferences other than the common system preference can result in degraded performance as measured by the common system performance. This principle results from Theorem 2 and infers that system decisions made at all levels and by all system decision makers should adhere to a specified common system preference.

3. No theory or method should constrain a system preference in any way. The relevant project management or oversight authority should be free to define the system preference.

4. A theory of systems engineering should apply to all system choices throughout the life cycle of a system. Every element of a theory of systems engineering must apply to all phases of the life cycle of a system unless clear and mathematically provable distinctions are made as to when this is not the case.

5. The imposition of arbitrary constraints¹⁹ should be minimized. Theorem 3 shows that constraints never result in improved system performance. Hence, methods or procedures of systems engineering should strive to minimize the imposition of arbitrary constraints.

6. Kolmogorov probability²⁰ is a valid mathematic of beliefs. The Dutch Book Argument offers strong assurance that all alternatives to Kolmogorov probability pose inconsistencies that invalidate them.

7. Methods, processes, or procedures that lead to path dependencies should be avoided were possible, and where they cannot be avoided, procedures should be sought to handle them efficiently and to prevent them from reducing system performance. Methods or procedures that result in path dependencies can lead to system designs that differ according to the path taken to get them (for example, the order of decision-making), and they can have significantly different levels of performance with no indication of nonoptimality [35].

8. System decision makers exercise their own preference and beliefs in making system decisions; their decisions are not necessarily aligned with the common system preference. This reality generally results in a degradation of system performance. Therefore, a goal of systems engineering management should be to provide incentives that align systems engineers’ preferences with the common system preference.

9. Existence proofs are a necessary component of the validation of a systems engineering analysis, method, process, or procedure. While the need for existence proofs is well understood in the mathematics community, it has not been equally recognized in the systems engineering community [38].²¹

The key contribution of this article is to show that fundamental principles of systems engineering can be obtained from the preference statement, “I want the best system I can get.” It is argued that this should be a universally acceptable system preference, particularly given that the definition of best is left entirely to the project manager or systems engineer. Nine fundamental principles of systems engineering resulting from this preference statement are presented. They provide a mathematically sound basis for a comprehensive and overarching theory of systems engineering. It is not so much that these principles are new or unexpected that is the key contribution, but rather that it is shown that they derive from a fundamentally sound argument based on a preference. Nor is it our intent to infer that a theory of systems engineering exists only within the context of all conditions that enable the existence of a best system design. Rather, the principles are intended to underlie and guide the further development of systems theory and, wherever such conditions are not met, caution that actions should be taken to limit penalties to system performance if complete resolution is impossible.

It is clear from the nine fundamental principles that the resulting theory will enable the derivation of validity tests based at a minimum on the following classes of extant systems engineering methods, processes and procedures:

1. Methods, processes, or procedures that are mathematically consistent with the fundamental principles of systems engineering and are therefore valid, and

2. Methods, processes, or procedures that are mathematically inconsistent with the fundamental principles of systems engineering and are therefore not valid.

The work that now remains to be done is to critique extant systems engineering principles, theories, processes, and procedures to validate those that are mathematically sound and to provide insights into why other systems engineering principles, theories, processes, and procedures lead to less-than-optimal results and, perhaps, to offer suggestions that will correct or enhance these principles, theories, processes, and procedures. Some such processes and procedures are noted above. Work also remains to be done to find methods that extend our ability to optimize systems engineering decision-making taking into account the diversity of factors that work to inhibit optimal decision-making, particularly in large-scale projects. Such topics include:

1. Reduction of the negative impact of the requirements flowdown process,

2. Setting flowdown requirements optimally in the presence of uncertainty,

3. The derivation of incentives to assure that project engineers align their decision-making with the common system preference,

4. Finding approaches to setting a system preference in a case where there are multiple project managers with conflicting goals,

5. Creating a theory to enable the optimal assignment and management of tasks (e.g., subcontracts), and

6. Deriving methods for effective use of survey data.

To the extent that work is successful, we expect that it will establish a basis for systems engineering as a mathematically rigorous engineering discipline.

This work has been supported by the National Science Foundation under award CMMI-1923164.

There are no conflicts of interest.

No data, models, or code were generated or used for this paper.

=

is equal to, is the same as, x = y reads x equals or is the same as y

≠

is not equal to, is not the same as, x ≠ y reads x is not equal to y

$∀$

for all, $∀i≠j$ reads for all i not equal to j

<

is less than, x < y reads x is less than y

>

is greater than, x > y reads x is greater than y

≤

is less than or equal to, x ≤ y reads x is less than or equal to y

≥

is greater than or equal to, x ≥ y reads x is greater than or equal to y

$≻$

is preferred to, $A≻B$ reads A is preferred to B

⊁

Is not preferred to, A ⊁ B reads A is not preferred to B

∼

is indifferent to, A ∼ B reads A is indifferent to B

$≻∼$

is preferred or indifferent to, $A≻∼B$ reads A is preferred or indifferent to B

iff

if and only if

Theorem 2 may appear to be obvious, but it carries a subtle important message. Its strength can be appreciated by applying it to Arrow’s Theorem; by doing so, Arrow’s negative assertion disappears. To illustrate, according to Arrow’s Theorem, the majority vote rankings of pairs need not result in a transitive outcome. For instance, suppose of 15 voters, six have the ranking $A≻B≻C,$ five have $B≻C≻A$⁠, and four have $C≻A≻B.$ The outcome is a cycle where $A≻B$ by 10:5, $B≻C$ by 11:4, and $C≻A$ by 9:6. Each pair’s ranking is computed precisely, but the approach violates Theorem 2. This is because the tallying method is not compatible with the intent of having transitive conclusions.

To satisfy Theorem 2, the tallying method must be consistent with the global objective. This means the method must incorporate transitivity information. Doing so is simple, this is because with the transitive ranking $A≻B≻C$⁠, not only is $A≻C$⁠, but A is listed two above C; express this as $(A≻C,2)$⁠. More generally, let “IIIA,” the “intensity of IIA” (Arrow’s Independence of Irrelevant Alternatives), be where the ranking of a pair within a transitive ranking specifies how far the top-ranked alternative is listed above the other one; e.g., $(A≻D,4)$ means that A is listed four alternatives higher than D. In the above example, six voters have $(A≻C,2)$⁠, five have $(C≻A,1)$ and four have $(C≻A,1)$⁠. Computing a pair’s ranking by summing intensity levels leads to $A≻C$ by 12:9, which comes from 6 × 2 : (5 × 1) + (4 × 1). By using this intensity approach, which reflects the requirements of Theorem 2, the paired rankings now define the transitive $A∼B≻C$ with A ∼ B by 10:10, $B≻C$ by 11:8, and $A≻C$ by 9:6.

The difference between IIA and IIIA is that IIA does not include intensity information. This missing term drops information about the transitivity objective; this is what violates Theorem 2. The general result proved by Saari [45, Theorem 3.4.3] and [46] is that by exchanging Arrow’s Independence of Irrelevant Alternatives (IIA) with IIIA, Arrow’s negative assertion is replaced with a positive conclusion. The result follows.

This theorem captures the intent of Theorem 2. More generally, should a decision approach fail Theorem 2, even if the contributions made by the subsystems reach a high level of excellence (as determined by the isolated subsystem), it could be incompatible with the general objective.