Skip to content
Davide Scuteri Moretti
Senior Data Architect
Home/Architectures/Emergency Response
Emergency Response
Role
Principal Architect
Scale
24/7 operations

RMS-EMMA / NUE 112

Bronze Source-Preserving Architecture

Source-aligned Bronze Data Objects that preserve original emergency-response evidence without foreign keys, without a central event hub, and without silent normalisation of source identifiers.

Architecture Flow
Source EvidenceOperational systems · calls· events · logsBronze Data ObjectsImmutable · source-alignedAudit & LineagePayload hashes · versionsAnalytical CorpusML training · benchmarking
§ 01 Context

Historical NUE 112 data is captured as immutable Bronze evidence. Original payloads — telephone numbers, coordinates, localisation payloads, operational narratives — are preserved verbatim for audit, replay and controlled semantic reconstruction downstream.

§ 02 Designed System
No foreign keys among Bronze Data Objects
No central event hub in Bronze
No silent normalisation of source identifiers
No loss of original payloads
No unsupported population of future fields
§ 03 Capabilities
  • Explicit governance for telephone numbers, coordinates and localisation payloads
  • Preservation of operational narratives for downstream reconstruction
  • Corpus preparation for Advanced Analytics, ML training, benchmarking and validation
§ 04 Objects & Stack
Data Objects
  • Call Record
  • Location
  • Person (source-shaped)
  • Organisation (source-shaped)
  • Event (source-shaped)
  • Operational Narrative
Technologies
PostgreSQLSparkAirflowPythonKafkaParquet
§ 06 Related Reading
Essay 09
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.
Essay 05
Append-Only Architectures and the Ethics of Preserving History
Append-only architecture is commonly justified through auditability, recovery, and simplified concurrency. Its deeper importance is cultural. A mutable table tends to present the latest state as if it were the whole truth, whereas an append-only history records that every state was produced through events, revisions, and institutional decisions. This essay examines event histories, immutable logs, state derivation, bitemporal models, tombstones, corrections, and retention. It formalises state as a fold over ordered events and explores when append-only design is algebraically safe. It also addresses limits: infinite retention is neither technically neutral nor ethically desirable, and immutability can conflict with privacy, legal erasure, and minimisation. The argument is that preserving history is an ethical commitment only when history remains interpretable, governed, and proportionate. A platform should remember enough to explain itself, but it should not convert technical memory into indiscriminate surveillance.