Separating the Fact from the Local Format
A central architectural principle of computational Data Platforms is the separation of the event or condition being represented from the local format in which a source system records it. This separation is frequently described as dematerialisation, but the term should not imply that data become detached from material processes. On the contrary, the platform must preserve provenance while refusing to identify a fact with one contingent schema, file, message, or vendor representation. This essay develops a layered model of occurrence, observation, inscription, and computational projection. It uses formal mappings to show how several local records may refer to one event and how one local record may contain several conceptual objects. The philosophical discussion draws on the distinction between reality and representation without assuming naïve realism. The objective is a practical one: to build stable Data Objects that remain useful when source technologies change.
- — Data Objects
Abstract
A central architectural principle of computational Data Platforms is the separation of the event or condition being represented from the local format in which a source system records it. This separation is frequently described as dematerialisation, but the term should not imply that data become detached from material processes. On the contrary, the platform must preserve provenance while refusing to identify a fact with one contingent schema, file, message, or vendor representation. This essay develops a layered model of occurrence, observation, inscription, and computational projection. It uses formal mappings to show how several local records may refer to one event and how one local record may contain several conceptual objects. The philosophical discussion draws on the distinction between reality and representation without assuming naïve realism. The objective is a practical one: to build stable Data Objects that remain useful when source technologies change.
1. The category error of source realism
Source realism is the implicit belief that the structure of a source system reveals the natural structure of the domain. If the source has a table called report, the platform creates a report table. If a message contains one segment, the target creates one entity. If a vendor combines patient, encounter, and order attributes in one export, the platform reproduces the combination.
This is understandable because source structures are tangible. Yet they are products of application design, performance constraints, vendor history, and workflow compromise. They are not neutral ontologies.
Let be a domain of events and entities, an observation process, and a source representation:
The platform receives , not directly. It must infer a governed projection into shared objects while preserving the chain through which the representation was produced.
2. Fact, observation, and inscription
The word “fact” can mislead if it suggests unmediated access to reality. A more precise distinction includes:
- Occurrence: something happens or holds in the domain.
- Observation: a process detects, measures, or judges the occurrence.
- Inscription: the observation is encoded in a technical representation.
- Projection: the platform maps the inscription into a governed object.
- Use: a consumer interprets the object for a question.
Represent this as
Error or ambiguity can enter at every arrow. Dematerialisation does not purify the data into truth. It prevents the inscription format from being mistaken for the occurrence itself.
Bruno Latour’s studies of scientific practice are relevant: facts become durable through chains of instruments, inscriptions, and institutions. A Data Platform should preserve these chains sufficiently to support accountability.
3. Many records, one event; one record, many objects
A single event may be represented in multiple systems. A test order appears in an ordering system, laboratory system, billing system, and clinical record. Conversely, one source row may flatten patient, encounter, order, specimen, result, and report information.
Let source records be and domain objects . The relation is generally many-to-many:
A simple one-row-to-one-object mapping is therefore often inadequate. The platform needs task-based transformations that decompose records, reconcile repeated claims, and project attributes into distinct objects.
This is why the transformation layer is computational. It must decide which conceptual object an attribute belongs to, under which identity, time, and provenance.
4. The invariants of a stable object
If source formats change, what should remain stable? Not every attribute. Stability should be defined through invariants: properties that preserve the object’s identity and meaning across representations.
For Data Object , define a contract
where is identity, temporal semantics, attributes, relations, and quality constraints. Source mappings may change while the contract remains compatible.
A transformation is acceptable when it preserves required invariants:
For example, a laboratory result object may require patient context, observation code, value or categorical result, unit where relevant, collection time, report time, and provenance. The source may encode these in a message, CSV, database view, or API response. The object is stable because its invariants are independent of the transport.
5. Dematerialisation without decontextualisation
The danger of abstraction is loss of context. If the platform strips local details too aggressively, it may create clean but misleading objects. Dematerialisation should therefore be paired with contextual retention.
A projected value can be represented as
where both normalised and local values are retained, along with method, mapping version, and quality status. Not every field must carry all metadata physically; some can be represented through linked lineage and reference tables. The logical contract, however, should preserve access to context.
This resembles the philosophical distinction between abstraction and idealisation. Abstraction omits features irrelevant to a purpose; idealisation introduces simplifying assumptions. Architecture should state which operation it performs. Silent idealisation is dangerous because consumers may treat a simplified object as complete reality.
6. Source change as a boundary event
When a source changes, the platform should absorb variation at the boundary rather than propagate it through every consumer. Let source schema version be and stable object contract . Boundary mapping is
If the source adds a field compatible with the existing object, the mapping evolves additively. If it changes meaning, a new mapping version is required. If the shared contract must change, compatibility policy determines whether to introduce a new object version.
This separation creates a change firewall. It does not eliminate work, but it localises it. Consumers depend on the object contract rather than on every upstream schema variation.
7. Truth, models, and humility
The phrase “separate the fact from the format” should not be read as a claim that the platform possesses facts independently of models. Every Data Object is a constructed representation. The point is comparative: the shared model is designed around domain invariants and explicit purposes rather than inherited accidentally from one source.
Kant’s distinction between things as they are and things as organised through categories is too broad to map directly onto data engineering, but it offers a useful caution. We never receive raw reality; we receive reality under forms of observation and representation. Architecture should therefore cultivate epistemic humility.
A Data Object should be presented as a governed claim with provenance, not as the final essence of the entity. Versioning and lineage institutionalise this humility.
8. Testing the separation
An architecture genuinely separates fact from format if it can pass several tests:
- Can a source system be replaced without redesigning every consumer?
- Can the same object be populated from different source formats?
- Can source-specific values be recovered for audit?
- Are identity and time defined independently of source column names?
- Can mapping changes be versioned and replayed?
- Are consumers insulated from transport-specific details?
- Are non-equivalent source distinctions preserved rather than forced together?
A stability ratio can be estimated as
where a higher ratio indicates that more change is absorbed at the boundary. The metric is approximate but encourages architectural accountability.
9. Representation debt
When local formats are copied directly into shared layers, the platform accumulates representation debt. Each consumer must remember which source-specific assumptions remain embedded in a supposedly common dataset. The debt grows whenever another use relies on the accidental layout rather than on declared domain invariants.
Let be the number of source assumptions inherited by product , the number of downstream dependencies, and the probability that a source change invalidates an assumption. A simple exposure measure is
Dematerialisation reduces by converting hidden assumptions into explicit boundary mappings. It does not eliminate every dependency: method, instrument, or local workflow may remain relevant. The important distinction is that such relevance is represented intentionally rather than smuggled into the platform through a column name.
Representation debt is particularly difficult to detect because the data may continue to load successfully. The failure appears later as semantic inconsistency, inexplicable historical discontinuity, or a costly change campaign. Contract tests must therefore evaluate meaning and temporal behaviour as well as syntax.
Conclusion
Separating the fact from the local format means refusing to let a contingent technical inscription define the enduring structure of the platform. It requires a layered understanding of occurrence, observation, inscription, projection, and use; many-to-many mappings between records and objects; explicit invariants; and strong provenance.
The shared model is not reality itself. It is a disciplined representation designed to remain stable across technological change and to make its own mediation visible. This is the foundation of computational dematerialisation: not the disappearance of material context, but the liberation of meaning from one accidental format.
Conceptual references
Kant, I. Critique of Pure Reason (1781/1787). Latour, B. Pandora’s Hope (1999). Hacking, I. Representing and Intervening (1983). Floridi, L. The Philosophy of Information (2011).
- 01. Too Much Data, Too Few Answers
- 02. A Data Platform Is Not Another System to Use
- 03. The Data Platform as an Organisational Control Room
- 04. The Hidden Cost of Fragmented Data
- 05. Why Putting All Data in One Place Is Not Enough
- 06. Every Source Speaks a Dialect
- 07. From Collecting Data to Producing Answers
- 08. The Business Value of a Data Platform: Efficiency, Quality, and Innovation
- 09. Separating the Fact from the Local Format
- 10. Data Is Not the Table That Contains It
- 11. Dismantling the Source, Reconstructing Information
- 12. What Is a Data Object?
- 13. Data Objects: Beyond Tables, Before Reports
- 14. Contract-First: Design Meaning Before Loading Data
- 15. The Part That Changes and the Part That Must Remain Stable