Epistemic Flatness in Query Interfaces

Epistemic Flatness in Query Interfaces

Pattern

Structured data storage is epistemically flat by default. Every row returned by SELECT * arrives with equal authority. But the territory it represents is epistemically hierarchical — some records are observations, some are corrections to observations, some are tombstones of observations, some are tentative proposals.

The schema often encodes this hierarchy (columns like billing_disposition, billing_note, superseded_by, review_status). But the query interface strips it. The result set is a bag of equals. A consumer must know which columns carry epistemic metadata AND how to interpret them — knowledge that requires operational literacy, not just data literacy.

Upstream of ORA-2026-0094

ORA-0094 addresses the production side: produce honest maps, not dishonest ones. This pattern addresses the consumption side: even when the data layer produces honest maps, the query layer strips the honesty and returns flat result sets. The data is honest. The query is epistemically naive. Any surface built on naive queries inherits the naivety.

Evidence

CMB-2347 Permar investigation: heartwood-db correctly encoded a duplicate receipt as billing_disposition: non-billable with billing_note: "Duplicate placeholder. Canonical receipt: eab0b786...". The data was honest. A query that joined receipts to reconciliation candidates without checking epistemic metadata produced a decision surface showing 3 false anomalies — all dissolved once the canonical receipt was identified.

The fix is shallow (and that's the point)

The deep problem (agents lack situated operational understanding) cannot be solved by architecture. The shallow fix — query the data's metadata about itself before building surfaces — is a mechanical substitute for operational intuition. It is structural and enforceable:

1. Default read surfaces should pre-filter non-canonical records (views like v_receipts_canonical) 2. An epistemic_status enum (canonical | placeholder | superseded | tentative) makes the hierarchy structural, not semantic 3. Returning non-canonical records should require explicit opt-in (WHERE include_ghosts = true) 4. Before building any surface that represents data to a human: check the data's epistemic metadata first. Ask the data "what are you?" before asking "what do you contain?"

The deep problem is ameliorated by something shallower: making epistemic weight a first-class interface property, not a column interpretation exercise.