Epistemic Engineering
What the subtitle means — and the one assumption it drops.
“For me normative epistemology is a branch of engineering. It is the technology of truth-seeking […]. The normative here, as elsewhere in engineering, becomes descriptive when the terminal parameter is expressed.”
W. V. Quine
Epistemic engineering, in Quine’s sense, is normative epistemology done as engineering: given an epistemic end, find the means that are necessary or optimal for it — and when none exist, revise the end. Feldbacher-Escamilla has worked this out formally: where an absolute ideal is provably out of reach, trade it for an optimum and engineer the means to that.
The programme assumes, mostly without saying so, that the judge is not among the judged: success is scored by a measure none of the competing methods can touch. Feldbacher goes further than most — his adversary knows the method and plays against it. He puts the demon inside the loop. The judge stays outside.
Calculating Space works where that assumption does not hold: systems that cannot outsource the job of checking themselves. That is not an end anyone chooses. In requirements language it is a domain assumption — a statement about the system’s situation, not about what anyone wants. What follows from it is a requirement: the system must carry its own truth predicate, and with it self-reference. Classical logic adds two licences for free: to reuse a premise as often as needed (contraction), and to conclude B from A and “if A then B” (detachment). Curry’s paradox, read as a feasibility result, says that with an ordinary conditional the three cannot be had together without everything becoming provable. Self-reference is fixed by the requirement; the licences are not. They are what gets restricted. Non-triviality is the one requirement that is never relaxed.
For verification and validation, three obligations follow, and they part ways. That the system carries its own truth predicate is verified by inspection. That it stays non-trivial is tested at run time: probe it with a sentence it must never assert — a trivial system asserts everything, the probe included. That its own judgements are correct cannot be independently verified at all: independent V&V needs an independent party, and the domain assumption says there is none. No amount of budget or rigour changes that. What engineering can still guarantee is weaker, and checkable: when the system fails, the failure does not spread to everything.
Whether a given system falls under the domain assumption is a validation question, settled system by system. Many do not: wherever judgement can be handed to a simpler trusted monitor, an independent verifier or a human, an independent judge is available and the usual architecture does the job. Calculating Space works on the same engineering questions — requirements, trade-offs, verification and validation — for systems where no such hand-off exists.
Sources
- W. V. Quine, “Reply to Morton White”, in L. E. Hahn and P. A. Schilpp (eds.), The Philosophy of W. V. Quine, expanded ed. (Open Court, 1998), 664–665.
- Christian J. Feldbacher-Escamilla, Epistemic Engineering: Uncovering the Logic of Deceivability and Meta-Induction (Heinrich Heine University Düsseldorf, 2019), §1.4.
- Pamela Zave and Michael Jackson, “Four Dark Corners of Requirements Engineering”, ACM Transactions on Software Engineering and Methodology 6 (1997).
- Haskell B. Curry, “The Inconsistency of Certain Formal Logics”, Journal of Symbolic Logic 7 (1942).
- IEEE Std 1012-2024, IEEE Standard for System, Software, and Hardware Verification and Validation.