From Collecting Data to Producing Answers

Abstract

Data engineering is frequently organised around the movement and persistence of datasets, while the users of data are organised around questions. The resulting gap explains why technically successful ingestion programmes can yield limited organisational value. This essay proposes an answer-oriented architecture in which sources, contracts, transformations, and products are designed in relation to durable classes of inquiry. It distinguishes data availability from answerability and models the path from question to evidence as a typed computational pipeline. Decision theory, query planning, and epistemology are used to define what makes an answer relevant, timely, reproducible, and proportionate to the claim being made. The argument is not that architecture should be reduced to current reporting requirements, but that data assets should be evaluated by the range of legitimate questions they can support at controlled marginal cost.

1. The source-oriented habit

Most data programmes begin with an inventory: systems, tables, APIs, files, streams, and volumes. This is understandable because sources are concrete and procurement requires technical scope. Yet a source-oriented programme can become an endless ingestion factory. Success is measured by connectors and terabytes while users continue to assemble answers manually.

The alternative is not to ignore sources but to connect them to question families. Let $Q$ be the space of legitimate organisational questions and $D$ the available data products. Define an answerability relation

A question is answerable when there exists a governed combination of products, transformations, and policies capable of supporting the claim. This relation is richer than “dataset contains relevant columns.”

2. Questions have types

Questions differ in epistemic structure. At minimum, we can distinguish:

• descriptive: what happened?
• state-oriented: what is true now?
• diagnostic: where and how did deviation occur?
• predictive: what is likely next?
• causal: what would change under intervention?
• normative: what should be done under objectives and constraints?

Each type requires different data and assumptions. A descriptive aggregation may require complete event capture. A current-state query requires state derivation. A causal question requires treatment of confounding and counterfactuals. A normative decision requires objectives, constraints, and risk preferences.

Represent a question as

where $E$ identifies entities, $T$ temporal scope, $M$ measures, $F$ filters, and $H$ hypotheses or assumptions. Making these components explicit prevents a dashboard from silently upgrading description into explanation.

3. The evidence path

An answer is produced through a chain:

Each arrow may fail. Requirements may be ambiguous; selection may omit a source; transformation may distort units; validation may be insufficient; inference may exceed the evidence; presentation may hide uncertainty.

A platform should materialise this chain as metadata and reusable computation. The answer is then not a detached number but an object with provenance:

This structure supports both machine consumption and human scrutiny.

4. Relevance and the cost of excess data

More data are not always better. Irrelevant attributes increase complexity, privacy exposure, and validation burden. For question $q$, the minimal sufficient evidence set $D_q^i$ can be conceptualised as

subject to

where ${\rho }_q$ is the required evidential threshold. This is not always computable exactly, but it expresses a principle of proportionality: collect and publish what is necessary for the intended claim.

The principle aligns with privacy minimisation and with sound scientific practice. An answer-oriented platform does not indiscriminately expose every field simply because it exists.

5. Query latency versus answer latency

Database query latency measures execution after the query has been formulated. Answer latency begins when the question arises. It includes discovery, clarification, access, preparation, validation, and interpretation.

Optimising only $L_{compute}$ may have little effect if other terms dominate. Data catalogues reduce discovery; contracts reduce clarification; policy automation reduces access delay; reusable Data Objects reduce preparation; observability reduces validation effort.

Thus platform components should be justified by their contribution to end-to-end answer latency, not by isolated technical benchmarks.

6. Data products as answer-enabling contracts

A data product should not be defined merely as a curated table. It is a supported interface to a stable class of evidence. It has consumers, documentation, quality expectations, ownership, and change policy.

Let product $P_i$ be

A product becomes answer-enabling when its semantics align with recurrent question requirements. For example, a longitudinal observation product should represent event time, subject identity, method, unit, validity, and revision. Without these, it may contain values but not support reliable longitudinal questions.

The product orientation protects architecture from the volatility of individual dashboards. Question families remain relatively stable even when visualisations change.

7. Decision theory and the value of answers

An answer matters because it may change an action. In decision theory, the value of information is the difference between expected utility with and without the information.

Let actions be $a\in A$, states $s\in S$, utility $U(a,s)$, and observation $z$. The expected value of sample information is

A Data Platform creates value when it provides observations that alter decisions beneficially, net of acquisition and operational cost. This model also reveals why some requested analytics have little value: they are interesting but do not change any action, or arrive after the decision window.

Not every answer must directly automate a decision. Some reduce uncertainty, support accountability, or create institutional memory. Yet the link between answer and possible use should be explicit.

8. The culture of the answer

A cultivated data culture distinguishes a result from a warranted answer. A query can return a count, but the organisation should ask:

• What is the population definition?
• Which time semantics were used?
• Are late records included?
• Which revisions apply?
• What data are missing?
• Is the result descriptive or causal?
• Can it be reproduced under the same version?

These questions are not pedantry. They are the grammar of accountable quantification. Alain Desrosières showed that statistics are both descriptions and conventions: they make phenomena comparable by establishing categories. A platform should expose the conventions rather than presenting numbers as self-evident.

9. Designing for the next question

An answer-oriented architecture must avoid becoming report-driven. The goal is not to precompute every future answer, which is impossible, but to stabilise reusable evidence primitives.

If $C(q)$ is the cost of answering question $q$, platform design should minimise expected marginal cost over future questions:

This explains the value of identity services, event models, Data Objects, semantic layers, and shared metrics. They are not answers themselves; they reduce the effort required to construct many answers.

The architecture should be judged by the shape of the cost curve. A project-based estate has low cost for known reports and high cost for variation. A platform invests upfront to flatten the marginal cost of legitimate novelty.

10. Epistemic service levels

Platforms commonly publish service-level objectives for freshness and availability, but answer-oriented systems also need epistemic service levels. These describe the strength of the evidence supplied, not only the speed with which bytes arrive. A product may declare, for example, that ninety-nine per cent of records possess a resolved identity, that all derived metrics expose a definition version, or that late-arriving events are incorporated within a specified correction window.

Let an epistemic service profile be

where identity coverage, temporal completeness, provenance coverage, reproducibility, and uncertainty disclosure are measured. A consumer can then select a product whose evidential properties match the decision risk. Exploratory work may tolerate lower completeness; regulated or safety-relevant use may require stronger guarantees.

This prevents a damaging equivalence between technical availability and epistemic readiness. A table can be queryable while remaining unfit for the intended claim. Making that difference contractual allows engineers, stewards, and decision-makers to discuss quality in terms that connect architecture to use.

Conclusion

Collecting data is an engineering activity. Producing answers is an epistemic and organisational activity supported by engineering. The two should be connected through explicit question types, evidence paths, contracts, validation, and decision context.

A mature Data Platform does not organise itself exclusively around sources or current dashboards. It creates reusable, governed evidence from which classes of questions can be answered quickly and responsibly. Its ultimate unit of value is not the ingested record but the warranted claim that can be produced, challenged, and reproduced from it.

Conceptual references

Desrosières, A. The Politics of Large Numbers (1993/1998). Howard, R. A., writings on decision analysis. Pearl, J. Causality (2000). Floridi, L. The Philosophy of Information (2011). Simon, H. A. The Sciences of the Artificial (1969).