Skip to content
Davide Scuteri Moretti
Senior Data Architect
Home/Architectures/Emergency Response
Emergency Response
Role
Principal Architect
Years
2023 – 2025
Scale
High availability · 24/7 operations

RMS-EMMA / NUE 112

Governed Silver Reconstruction Layer

Bronze and Silver architecture with entity resolution, surrogate-key reconstruction and governed operational timelines.

Architecture Flow
Source EvidenceOperational systems · calls· events · logsBronze Data ObjectsImmutable ingestion ·source alignedCanonicalisationStandardisation & semanticalignmentMatching DecisionEntity resolution &governed rulesSilver ReconstructionReconstructed entities &relationshipsOperational TimelineTrusted, ordered,explainable events
§ 01 Context

The Silver layer reconstructs enterprise entities from source-aligned Bronze evidence. Original Bronze identifiers are never used as enterprise primary keys — Silver introduces deterministic surrogate keys through canonicalisation, business signatures and explicit matching decisions.

§ 02 Designed System
Canonicalisation and semantic alignment
Business signatures for entity comparison
Matching decisions: NEW_ENTITY, MATCH_EXISTING, MERGE, SPLIT, REJECT
Deterministic surrogate keys
Silver relationships as first-class Data Objects
Governed operational timelines with record-level and field-level lineage
§ 03 Capabilities
  • Entity resolution across heterogeneous emergency-response sources
  • Trusted, ordered and explainable operational timelines
  • Reconstructed entities with full provenance back to Bronze evidence
§ 04 Objects & Stack
Data Objects
  • Silver Person
  • Silver Location
  • Silver Event
  • Silver Situation
  • Operational Timeline
  • Matching Decision Log
Technologies
PythonSparkAirflowPostgreSQLKafkaKubernetes
§ 06 Related Reading
Essay 11
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.
Essay 08
From Conceptual Lineage to Executable Lineage
Lineage diagrams often show that a source contributes to a dataset or that a process touches a Data Object. Such maps are valuable, but they do not yet explain how a particular output attribute was computed, which predicate filtered a record, which reference version supplied a code, or which policy authorised publication. This essay develops a layered model of lineage from conceptual relevance to executable derivation. It formalises lineage as a typed, versioned, temporal provenance graph; distinguishes data, control, semantic, policy, and decision dependencies; and examines the conditions under which lineage can support impact analysis, replay, and explanation. The argument is that lineage becomes operational only when it can participate in computation. A picture documents architecture; executable lineage constrains and directs it.