Philosophical Foundations
Ontology, epistemology, and the hidden assumptions behind every architectural decision
Learning Objectives
By the end of this module you will be able to:
- Distinguish substance ontology from process ontology and articulate why the distinction matters for how software systems are modeled.
- Explain the pragmatist account of truth (James, Dewey) and connect it to engineering practices that favor feedback loops over upfront correctness.
- Apply fallibilism to technical claims and identify when a team is acting as if its knowledge is more certain than it is.
- Recognize how everyday engineering commitments — object-oriented design, event-driven architectures — embed ontological assumptions that most practitioners never examine.
Core Concepts
What ontology actually is
Ontology is the branch of philosophy that asks: what kinds of things fundamentally exist, and how do they relate to each other? For engineers, this sounds abstract until you realize that every data model, API, and domain design answers these questions — just implicitly.
When you decide whether an Order is an entity with an ID or an event stream, you are making an ontological choice. The question is whether you are making it deliberately.
Substance ontology: things are primary
The oldest and most influential answer to the question "what fundamentally exists?" comes from Aristotle. In his framework, substance is the primary and most fundamental category: all other kinds of things — quantities, qualities, relations, positions — depend on substances for their existence, whereas substances exist independently.
Aristotle organized all of being into ten categories: substance, quantity, quality, relation, place, time, position, state, action, and passion. These are meant to be exhaustive — a complete classification of what can exist. Substance anchors everything else.
Within substance, Aristotle draws a further distinction: primary substances are particular individuals (this horse, Socrates), while secondary substances are universal kinds ("horse," "animal"). Primary substances are more fundamental: they exist on their own; universal kinds are predicated of them.
Substances function as bearers of properties. A substance possesses redness, weight, or courage — but is not itself possessed by anything else. Properties are ontologically dependent on the substance that bears them; the substance exists independently. This creates a philosophical puzzle: is the "bearer" a featureless substrate underlying all properties — a "bare particular" — or is it constituted by the bundle of properties it bears?
Substances are also understood as causally efficacious agents: they possess causal powers. Things act on other things. This causal framing — objects as active agents — pervades how we intuitively model systems.
In substance ontology, things come first. Change is something that happens to things. Properties belong to things. Causality is exercised by things.
Process ontology: becoming is primary
Process ontology inverts this hierarchy entirely. Rather than treating stable things as primary and change as derivative, process ontology treats events, activities, and becoming as the fundamental constituents of reality. Entities are not stable substances that happen to change; they are temporary stabilizations of underlying flux.
In Whitehead's formulation — the most developed version of this view — the basic unit of reality is the actual occasion: a momentary experiential event that arises, perishes, and contributes to the creative advance of future occasions. What we call "things" are patterns or regularities within a continuous stream of such occasions, not independent bearers of properties.
Process ontologists hold that change is more fundamentally real than objects. Becoming precedes being. Activity and relationality are intrinsic to entities, not external to them. A substance ontologist says: "here is an object; it is changing." A process ontologist says: "here is a pattern of activity; we have named it."
This tension is ancient. Heraclitus held that everything is flux ("you cannot step into the same river twice"). Parmenides argued that change is illusory and only being is real. Aristotle and subsequent Western philosophy largely sided with Parmenides. Process philosophy sides with Heraclitus.
Universals and particulars
A cross-cutting distinction runs through both substance and process views: the difference between universals and particulars. Particulars are unique, non-repeatable entities that exist at specific locations and times — Socrates, this specific order with id 42a7f. Universals are general, repeatable patterns that can be instantiated in multiple particulars — the property of being "in-flight," the relation "belongs-to."
This distinction matters in modeling: when you define a class, you are defining a universal. When you instantiate an object, you are creating a particular. When you argue about whether "Customer" should be the same entity in the billing and shipping contexts, you are arguing about whether a universal should have one or two corresponding classes of particulars.
Pragmatism: truth is what works
The second major philosophical current in this module is epistemological rather than ontological — it concerns how we know, not what exists.
Pragmatism, developed primarily by William James and John Dewey in the late 19th and early 20th centuries, rejects the idea that truth is a fixed correspondence between ideas and reality. Instead, James argued that truth is a dynamic process determined by practical consequences. One can say of an idea either that "it is useful because it is true" or "it is true because it is useful" — both mean the same thing. An idea that "gets fulfilled and can be verified" through its practical application is true. "The ultimate test for us of what a truth means is the conduct it dictates or inspires."
Dewey pushed further into the mechanics of how we come to know. His instrumentalism holds that ideas are instruments — tools and plans of action — whose validity is determined by whether they work when applied to actual problems. Knowledge results from discerning correlations between events through experimentation, not from abstract reasoning. Inquiry requires action: "we must experiment — manipulate or change reality in certain ways" and see what happens. All human experience is a cycle of interpretation, action, and reflection on outcomes.
Crucially, pragmatism explicitly turns away from abstraction and first-principles reasoning as the primary mode of inquiry. James described pragmatists as turning away from "verbal solutions, bad a priori reasons, fixed principles, closed systems, and pretended absolutes." The priority is actual experience over pre-determined frameworks.
Fallibilism: knowledge is always provisional
Closely linked to pragmatism is fallibilism: the epistemological position that all knowledge is fundamentally fallible and subject to revision. Fallibilism is not skepticism — it does not deny that we can know things. It holds that whatever we know, we could be wrong about, and that critical reflection on the limits and uncertainties of our knowledge is essential.
Pragmatist fallibilism reframes error as opportunity. If all knowledge is provisional, then failure and revision are not signs of incompetence but inevitable features of inquiry into complex systems. This philosophical position supports engineering cultures that embrace learning from incident analysis, treat current designs as hypotheses, and build systems designed for graceful revision when assumptions are violated.
Engineering epistemology
Engineering knowledge combines descriptive knowledge (how systems work) with normative know-how (what actions produce desired outcomes). Engineers learn through designed interventions: testing designs against constraints and objectives, discovering through action what works and what does not. This makes engineering a form of knowledge production distinct from pure science.
Pragmatism provides a coherent philosophical foundation for this: knowledge emerges from experimental engagement with the world, and its validity is judged by practical consequences. However, engineering epistemology also incorporates elements that are not purely pragmatist — formal modeling, mathematical proof, and standards compliance. Neither pure rationalism nor pure pragmatism alone captures what engineers do.
Holism and reductionism
A final epistemological axis worth naming: reductionism and holism are complementary approaches to understanding complex systems, not mutually exclusive alternatives. Reductionism analyzes phenomena at simpler, more fundamental levels — the basis for most of modern science. Holism holds that systems have properties not present in any component part — an Aristotelian insight preserved in contemporary systems thinking.
Systems thinking integrates both: combining mechanistic reductionist insights with holistic analysis of emergent systemic properties. For engineers, neither pure component optimization nor dismissal of low-level analysis is sufficient. Both stances are required — and knowing when to apply each is a judgment that philosophy can help calibrate.
Compare & Contrast
Substance ontology vs. process ontology
| Dimension | Substance ontology | Process ontology |
|---|---|---|
| What is primary | Things (substances) | Events and processes |
| How change is understood | Accidents modifying a persistent substance | Patterns arising within continuous flux |
| Identity over time | A persistent bearer that remains | A regularity in a stream of events |
| Properties | Possessed by a bearer | Relational, constituted through activity |
| Foundational figure | Aristotle | Heraclitus, Whitehead |
| Software analogy | Objects and entities with stable IDs | Event streams, state machines, CQRS |
Object-oriented programming is grounded in substance metaphysics. In OOP, an object's identity is independent of its values — two objects can be distinct ("identical" in the technical sense) yet have the same attribute values. This mirrors the Aristotelian idea of substance: the bearer persists across changes in its accidents. Domain-Driven Design's tactical vocabulary — Entities (persistent identity), Value Objects (property bundles without identity), and Aggregates (compound substances with a root) — directly encodes these substance-ontological commitments.
Event-driven architectures and event sourcing, by contrast, are more comfortable with process-ontological assumptions: the event log is primary, the current "state" is derived from it, and what we call an "order" is a pattern computed from a stream of events.
Pragmatism vs. rationalism in engineering
| Dimension | Rationalist stance | Pragmatist stance |
|---|---|---|
| How knowledge is validated | Conformity to principles and formal derivation | Practical consequences and experimental verification |
| Source of truth | Abstract reasoning, first principles | Experience and feedback |
| Relation to failure | Failure indicates error in reasoning | Failure is information; revision is normal |
| Relation to iteration | Iteration is a cost to be minimized | Iteration is the mechanism of inquiry |
| Relation to design upfront | Design should be correct before implementation | Designs are hypotheses; implementation tests them |
Common Misconceptions
"Philosophy is just abstract theory; engineering is practical." This is itself a philosophical position — a pragmatist one, ironically. The claim that practice trumps theory is a claim about how knowledge works. Philosophy does not compete with engineering practice; it describes the assumptions embedded in it. Every time you argue for or against an architectural decision, you are doing philosophy — just without the vocabulary to make the assumptions explicit.
"Substance ontology is old-fashioned; process ontology is modern and therefore better." Both frameworks are active areas of philosophical inquiry, and both have compelling engineering analogues. The question is not which is correct in some absolute sense, but which is more useful for a given modeling problem. A billing system probably benefits from entity-centered, substance-oriented modeling. A market data pipeline probably benefits from process-oriented, event-first modeling. The pragmatist move is to choose the ontological frame that best serves the problem at hand.
"Fallibilism means we can never be confident in our decisions." Fallibilism is not epistemic paralysis. It means holding confidence proportional to evidence and remaining open to revision when new evidence arrives. You can be highly confident in a well-tested architectural decision while still accepting that it may need revision as load patterns, team structures, or requirements evolve. The alternative — certainty — is not available to engineers working in complex systems.
"Pragmatism means 'whatever works, do it.'" This misreads James and Dewey significantly. Pragmatism is a rigorous epistemological framework, not a license for cutting corners. The "what works" test requires actual inquiry: defining what "working" means in a specific context, designing ways to observe it, and being willing to revise beliefs when outcomes differ from predictions. Vague appeals to "pragmatism" to justify bypassing rigor are anti-pragmatist.
"OOP is a programming paradigm, not a philosophical stance." OOP imports substance-ontological intuitions from everyday manipulation of physical objects in the real world. Treating this as a neutral technical choice makes it invisible and therefore unexaminable. Making the philosophical assumption explicit — "we are modeling this domain as a set of persistent entities with stable identities" — immediately opens a productive design question: is that assumption appropriate here?
Key Takeaways
- Ontology is not optional. Every data model and domain design embeds assumptions about what kinds of things fundamentally exist. The choice is between making those assumptions deliberately or letting them remain invisible.
- Substance and process ontology are competing frameworks, each with engineering analogues. Substance ontology underlies OOP and entity-centric modeling; process ontology underlies event-driven and stream-processing approaches. Choosing between them is a design decision, not just a technology choice.
- Pragmatism reorients truth toward consequences. A design decision is validated not by conformity to abstract principles but by whether it produces the expected outcomes in practice. This makes feedback loops — not upfront analysis — the primary mechanism of knowledge production.
- Fallibilism is the correct epistemic posture for engineers. All knowledge of complex systems is provisional. Designing for revision, learning from failure, and maintaining uncertainty proportional to evidence are not signs of weakness — they are the epistemologically correct responses to irreducible complexity.
- Holism and reductionism are both necessary. Complex systems exhibit emergent properties that cannot be understood by analyzing components alone, yet component-level understanding remains essential. Engineering judgment is knowing which lens to apply when.