When a new trading system goes live, engineers spend weeks validating that outputs match expected values — but almost no time asking whether the expected values themselves were correctly specified. This is the invisible failure mode that the American philosopher John Dewey called 'the problem of the problem': we optimize fiercely for answering the question as given, while the real error was baked into the question's formulation. In finance IT, this shows up constantly — a risk dashboard that perfectly measures what it was built to measure, while the genuinely dangerous exposures were never modeled because nobody thought to ask. Dewey argued in 'Logic: The Theory of Inquiry' (1938) that the quality of any solution is bounded by the quality of the problem-statement, and that most institutional failures are failures of problem-finding, not problem-solving. The practical move: before the next sprint planning session or system design review, spend five minutes asking 'what are we not measuring, and why did we decide not to measure it?' That gap is usually where the actual risk lives.

What is one assumption embedded in your current system's data model that has never been formally challenged — and who would even have the authority to challenge it?

Drawing from American Pragmatism / Philosophy of Inquiry — John Dewey (Logic: The Theory of Inquiry, 1938, on problem-formulation as the determinative phase of inquiry)