Essay

Dismantling the Source, Reconstructing Information

A computational Data Platform must often perform an operation that appears paradoxical: it dismantles source records in order to preserve information more faithfully. The source is decomposed into identities, events, attributes, relations, temporal anchors, and provenance, then recomposed as stable Data Objects and fit-for-purpose views. This essay formalises that operation as a sequence of projections and constrained joins. It distinguishes decomposition from destructive normalisation and reconstruction from the naïve reassembly of source tables. The broader cultural argument is that information architecture resembles critical interpretation: a received text is analysed into structures and variants before a responsible edition is produced. The platform should preserve the source as evidence while refusing to inherit its accidental organisation. The result is an architecture in which new sources can be absorbed and new views produced without repeatedly rebuilding the semantic foundations.

4 minute read·July 2026·Davide Scuteri Moretti

decompositionreconstructionprojectionnormalisationtask-based ingestionprovenancecomputational architecture

Themes

— Data Objects

Abstract

1. Why dismantling can preserve more

A source export often appears complete because it contains many fields in one row or document. Yet completeness of representation is not the same as integrity of meaning. When several entities and events are flattened together, their identities, temporalities, and update rules become entangled.

Dismantling means identifying the conceptual contributions of each source element. Let a source record $r$ have columns $C = {c_{1}, \dots, c_{n}}$ . We assign each column to a computational task through a total mapping

f_{1} : C \to T .

Tasks then produce or enrich one or more Data Objects through a typed relation

R_{T D} \subseteq T \times D \times K,

where $K$ indicates whether a task produces, references, enriches, validates, or derives an object. This relation is more faithful than a simple function $T \to D$ because one task may legitimately affect several objects.

The source is not discarded. It is analysed into contributions.

2. The task as a semantic workshop

The computational task is not merely an orchestration step. It is the place where source expressions are interpreted under a contract. A task may:

rename and type attributes;
split a compound field;
resolve or generate identifiers;
normalise units;
attach event and validity time;
classify quality outcomes;
map local codes;
establish relations;
emit provenance and telemetry.

We can model task $t$ as a partial function

τ_{t} : (C_{t}, M_{t}, R_{t}) \to (D_{t}, Q_{t}, L_{t}),

where $C_{t}$ is source content, $M_{t}$ metadata, $R_{t}$ reference data, $D_{t}$ outputs, $Q_{t}$ quality results, and $L_{t}$ lineage. It is partial because not every input satisfies the preconditions. Invalid records should be classified and quarantined rather than silently coerced.

3. Decomposition and losslessness

Database theory defines lossless decomposition: relations can be decomposed and rejoined without introducing spurious tuples or losing information, under specified dependencies. The platform problem is related but broader because source records may already be denormalised, inconsistent, or semantically ambiguous.

Suppose source relation $R (A, B, C)$ is decomposed into $R_{1} (A, B)$ and $R_{2} (A, C)$ . The decomposition is lossless if

R = R_{1} ⋈ R_{2}

under appropriate dependencies. In a Data Platform, exact reconstruction may not always be the objective. We may preserve the raw source separately while constructing cleaner domain objects that intentionally omit source-specific redundancy.

The requirement is therefore twofold:

raw evidence must remain recoverable;
semantic projection must be explainable and, where promised, reversible.

This is reconstruction with an editorial apparatus, not a claim that the source’s original shape is canonical.

4. Recomposition through identities and relations

After decomposition, information must be reassembled around stable identities and explicit relations. Let Data Objects be $D_{1}, \dots, D_{m}$ , each with key $k_{i}$ . Recomposition for a use case $u$ is a query plan

V_{u} = π_{A_{u}} σ_{P_{u}} (D_{i_{1}} ⋈_{R_{1}} D_{i_{2}} ⋈ \dots ⋈_{R_{m - 1}} D_{i_{m}}),

where projection $π$ selects attributes, selection $σ$ applies predicates, and joins follow governed relations. The resulting view is purpose-specific but derived from shared objects.

This architecture reverses the common pattern in which each report performs its own decomposition and reconciliation. The semantic labour is moved upstream and made reusable.

5. The dependency graph

Tasks rarely execute independently. Identifier resolution may precede object construction; reference-data mapping may depend on code-system recognition; state views depend on event publication.

Let tasks form a directed graph

G = (T, E),

where edge $(t_{i}, t_{j})$ means $t_{j}$ depends on $t_{i}$ . Requiring $G$ to be acyclic allows topological execution:

T o p o (G) = (t_{(1)}, \dots, t_{(n)}) .

Independent subgraphs can run in parallel. If task outputs are content-addressed or versioned, unchanged nodes may be reused. When a mapping changes, the platform can compute the affected descendant set