The question as an architectural object

Most data architectures begin from sources or target technologies. A more mature approach begins from classes of questions. Not individual dashboard requests, but durable question families: What happened? What is happening now? What deviates from expectation? What is likely to happen? Which intervention changed the outcome? Each family implies different data structures and evidential obligations.

A question can be represented as a tuple

where $E$ is the entity set, $\tau$ the temporal frame, $\kappa$ the measures, $\varphi$ the predicates or filters, and $\rho$ the required level of reliability. This formalisation matters because two linguistically similar questions may require radically different evidence. “How many delayed reports were there last month?” is not equivalent to “Which process conditions caused report delays?” The former is descriptive aggregation; the latter requires causal assumptions, counterfactual reasoning, or at least careful process analysis.

A Data Platform should not pretend that every query result is an explanation. It should preserve the distinction between measurement, inference, and decision. This is part of a cultivated data culture: the ability to say not only what a number is, but what kind of claim the number can support.