Gegevensintegratie

Stamgegevensbeheer voor defensie: entity resolution, golden record en consistentie tussen systemen

Door Corvus Intelligence Engineering Team · Over het team →

26 juni 2026 12 min leestijd

Een logistiek officier op bataljonsniveau vraagt een gereedheidsrapport op. Het C2-systeem vermeldt 47 voertuigen die aan de eenheid zijn toegewezen. Het materieelverantwoordingssysteem registreert 51 voertuigen onder dezelfde eenheidsidentificatie. Het onderhoudssysteem volgt 44 van die voertuigen onder andere serienummerformaten, en drie zijn als niet inzetbaar gemarkeerd onder identificaties die in geen van de andere twee systemen voorkomen. Niemand kan de vraag “hoeveel operationele voertuigen heeft deze eenheid op dit moment” beantwoorden zonder te bellen — omdat dezelfde fysieke entiteiten worden vertegenwoordigd door verschillende records, verschillende identificaties en verschillende attribuutwaarden in systemen die nooit zijn ontworpen om met elkaar overeen te stemmen.

Dit is het MDM-probleem van defensie in zijn meest voorkomende vorm. Stamgegevensbeheer (MDM) is de discipline die één gezaghebbende weergave creëert van elke kernentiteit — persoon, organisatie, materieel, locatie — waarnaar alle systemen consistent verwijzen. Het is geen rapportagetool en geen datawarehouse. Het is de laag die joins tussen systemen zinvol maakt, multidomeinanalyses vertrouwenswaardig en op data gebaseerde operationele beslissingen betrouwbaar. Dit artikel behandelt de architectuur van een MDM-systeem voor defensie, van de keuze van het hubmodel tot entity resolution, de opbouw van golden records, stewardship-workflows en de eisen aan overlevingsvermogen die MDM haalbaar maken in betwiste omgevingen.

Het MDM-probleem van defensie — materieelrecords in drie systemen met drie verschillende ID's, personeelsrecords die uiteenlopen tussen HR en C2, de kosten van inconsistentie

Bij defensieorganisaties hoopt de versnippering van de bron van waarheid zich organisch op. Het HR-systeem is aangeschaft voor het beheer van de personeelsadministratie. Het C2-systeem is gebouwd om de eenheidsstructuur en tactische toewijzingen bij te houden. Het logistieke systeem is ontworpen voor het beheer van bevoorrading en materieelverantwoording. Elk systeem is ontworpen door een ander programmabureau, in een ander decennium in gebruik genomen en gebruikt een ander datamodel. Geen van de systemen is ontworpen om op het niveau van entiteitsidentiteit met de andere samen te werken.

Het resultaat is een verzameling identificatieschema's die door hun ontwerp onverenigbaar zijn. Een persoon kan worden geïdentificeerd door het personeelsnummer in HR, de combinatie van de code voor de militaire specialisatie en de rang in C2 en de identificatie als materieelbeheerder in de logistiek — drie identificaties voor één mens, zonder een door een systeem bijgehouden koppeling ertussen. Bij materieel is het erger: een M1A2-tank kan een bumpernummer hebben dat met een sjabloon op de romp is aangebracht (gebruikt door de bemanning en C2-operators), een activity address code van het Department of Defense in de logistiek, een barcode met unieke itemidentificatie (UII) in de materieelverantwoording en een onderhoudswerkordernummer in het onderhoudsbeheersysteem. Geen van deze identificaties heeft hetzelfde formaat, en de systemen die ze gebruiken zijn niet gebouwd om ertussen te vertalen.

De kosten van deze inconsistentie zijn niet louter ongemak. Wanneer een gereedheidsanalist C2-gegevens over eenheidstoewijzing joint met logistieke bevoorradingsdata om de score voor de operationele capaciteit van een eenheid te berekenen, slaagt de join er niet in records te koppelen die onder verschillende identificaties naar hetzelfde fysieke materieel verwijzen. De resulterende capaciteitsscore is onjuist — en onjuist in een richting die de analist niet kan opsporen zonder elk systeem afzonderlijk te verifiëren, wat het doel van het analytische model ondermijnt. Voor een geïntegreerd beeld van hoe deze integratiefouten zich in de bredere data-architectuur manifesteren, verwijzen wij naar onze behandeling van integratiepatronen voor defensiedata.

Het uiteenlopen van personeelsrecords tussen HR en C2 is een extra, afzonderlijk probleem. HR beheert het administratieve record: vaste rang, functiepositie, toegewezen eenheid, machtigingsniveau, opleidingshistorie. C2 beheert het operationele beeld: welke persoon fysiek aanwezig is bij welke eenheid, welke rol die persoon in de huidige taakorganisatie vervult en welke systemen die persoon bevoegd is te bedienen. Onder stabiele garnizoensomstandigheden komen deze records redelijk goed overeen. Tijdens operaties — wanneer personeel aan andere eenheden wordt toegevoegd, wanneer de taakorganisatie afwijkt van de organisatie- en uitrustingstabel (TO&E), wanneer tijdelijke detacheringen secundaire verbanden creëren — lopen de twee records snel uiteen. Een MDM-systeem dat de persoonsentiteit beheert, moet zowel de administratieve als de operationele weergave samenbrengen in één coherent golden record dat bruikbaar is voor zowel gereedheidsrapportage als operationele planning.

MDM-hubarchitectuur — hubmodellen registry versus consolidatie versus coëxistentie, selectiecriteria voor defensieomgevingen, hubplaatsing voor geclassificeerde versus niet-geclassificeerde data

Drie hubmodellen domineren MDM-implementaties in productie, elk met een eigen relatie tot de bronsystemen die het bedient en een eigen set operationele afwegingen die in defensieomgevingen van belang zijn.

Het registrymodel slaat alleen de kruisverwijzingstabel op — een koppeling van elke bronsysteem-identificatie aan de door MDM toegekende globale entiteits-ID — zonder entiteitsattributen in de hub zelf te repliceren of op te slaan. Wanneer een consument entiteitsdata nodig heeft, vraagt die de hub om de globale ID en bevraagt vervolgens de juiste bronsystemen met de bronspecifieke identificaties die de kruisverwijzing teruggeeft. Het registrymodel heeft de kleinste data-voetafdruk en vereist geen synchronisatie van attribuutdata naar de hub, waardoor het aantrekkelijk is voor omgevingen waar het repliceren van geclassificeerde data naar een centrale locatie autorisatieproblemen oproept. De beperking is dat elke consument entiteiten tijdens de query over meerdere bronsystemen moet oplossen, wat operationeel onpraktisch is voor operationele queries met hoge frequentie.

Het consolidatiemodel kopieert en normaliseert entiteitsattributen van alle bijdragende bronsystemen naar de hub, voert entity resolution uit om duplicaten te koppelen en levert een uniforme entiteitsweergave aan consumenten. Bronsystemen worden niet gewijzigd — de hub is een voor lezen geoptimaliseerde consument van brondata en schrijft er niet naar terug. Dit model is het meest praktisch voor defensieomgevingen, omdat het geen wijzigingsrechten op bronsystemen vereist (C2-, HR- en logistieke systemen kunnen doorgaans niet door het MDM-programma worden aangepast) en de rekenkracht voor entity resolution in de hub concentreert in plaats van over consumenten te verdelen. De architectuur van een militaire data lake gebruikt doorgaans de golden records van de MDM-consolidatiehub als een curated referentielaag, in plaats van ruwe brontabellen rechtstreeks te joinen.

Het coëxistentiemodel voegt terugschrijfmogelijkheid toe aan het consolidatiemodel: de hub bouwt het golden record op en propageert vervolgens gezaghebbende attribuutwaarden terug naar de bronsystemen, waarbij lokaal beheerde waarden worden overschreven met de door de hub bepaalde gezaghebbende waarde. Dit model levert de sterkste consistentie tussen systemen op, maar vereist dat elk deelnemend bronsysteem door de hub geïnitieerde schrijfacties accepteert — een eis die vaak wordt geblokkeerd door autorisatiebeperkingen van systemen, wijzigingsbeheerprocessen van leveranciers en operationele risicoaversie bij systemen in productie.

Hubplaatsing voor geclassificeerde versus niet-geclassificeerde data vereist afzonderlijke hubinstanties aan elke classificatiegrens. Eén MDM-hub die zowel geclassificeerde als niet-geclassificeerde entiteitsdata verwerkt, zou op het hogere classificatieniveau moeten opereren, waardoor niet-geclassificeerde consumenten geen enkele entiteitsdata van de hub zouden kunnen benaderen — wat het doel ervan ondermijnt. De praktische architectuur zet een niet-geclassificeerde hub in voor entiteiten die uitsluitend in niet-geclassificeerde bronsystemen voorkomen (algemene referentiedata, niet-geclassificeerde locatiedata, records van commerciële leveranciers) en een geclassificeerde hub op het passende classificatieniveau voor entiteiten met geclassificeerde attributen. Entity resolution over classificatiegrenzen heen — vaststellen dat een entiteit in het niet-geclassificeerde systeem overeenkomt met dezelfde fysieke entiteit in een geclassificeerd systeem — vereist een gespecialiseerde guard van een cross-domain solution die alleen de kruisverwijzing van identificaties over de classificatiegrens draagt en nooit de geclassificeerde attributen zelf.

Entiteitstypen in MDM voor defensie — persoon (militair personeel), organisatie (eenheid/commando), materieel (platform/eindproduct), locatie (faciliteit/positie)

MDM voor defensie beheert vier primaire entiteitsdomeinen, elk met eigen bronsystemen, identificatieschema's, attribuutstructuren en datakwaliteitsuitdagingen.

Het domein van de persoonsentiteit omvat militair personeel, contractanten en coalitiepartners. De belangrijkste bronsystemen zijn het personeelsbeheersysteem (administratief record, vaste plaatsing, rang), het C2-systeem (huidige operationele plaatsing, positie in de taakorganisatie) en het machtigingenbeheersysteem (machtigingsniveau, compartimentautorisaties, vervaldata van toegang). De belangrijkste uitdaging bij identificatie is dat dezelfde persoon in HR kan voorkomen onder de eenheid van vaste plaatsing, terwijl die in C2 operationeel aan een andere eenheid is toegevoegd — beide records zijn juist in hun eigen systeem, maar ze vertegenwoordigen twee verschillende operationele toestanden van dezelfde entiteit. Bij de opbouw van het golden record voor het persoonsdomein moeten zowel de administratieve als de operationele toestand worden vastgelegd als afzonderlijke attribuutgroepen, in plaats van ze samen te voegen tot één veld voor eenheidstoewijzing.

Het domein van de organisatie-entiteit omvat eenheden, commando's, subeenheden en taskforces. Organisaties in defensieomgevingen hebben een hiërarchische ouder-kindstructuur (een brigade bevat bataljons, een bataljon bevat compagnieën) en een temporele dimensie (taskforces worden gevormd, fuseren, worden herorganiseerd en opgeheven op operationele tijdschalen). Het MDM-systeem moet de huidige organisatiehiërarchie bijhouden, de historische toestanden ervan op eerdere tijdstippen en de relaties tussen de administratieve TO&E-structuur en de huidige operationele taakorganisatie. Bronsystemen zijn de eenheidshiërarchie in het C2-systeem, de TO&E in het personeelsbeheersysteem en het record van het commandoelement in logistieke systemen.

Het domein van de materieelentiteit omvat platforms, voertuigen, wapensystemen en de inventaris van eindproducten. Dit is in de praktijk het domein met de meeste versnippering van identificaties: één fysiek item draagt doorgaans vier of meer verschillende identificatieschema's in de systemen die het beheren. De UII (unieke itemidentificatie) is de standaard van het Department of Defense voor een wereldwijd unieke barcode voor materieelitems met serienummer en zou als masteridentificatie voor het materieeldomein moeten dienen, maar legacysystemen van vóór de UII-standaard gebruiken eigen identificaties die een koppeltabel vereisen om ze aan de UII-ruimte te koppelen. Matching tussen systemen vereist fuzzy matching op serienummervelden die, afhankelijk van het systeem dat de identificatie heeft vastgelegd, verschillende scheidingstekens, voorloopnullen of voorvoegsels met fabrikantcodes kunnen bevatten.

Het domein van de locatie-entiteit omvat faciliteiten, installaties, benoemde aandachtsgebieden en tactische posities. Locatiematching is in de kern een geospatiaal probleem: dezelfde fysieke locatie kan in het ene systeem worden aangeduid met MGRS-coördinaten, in een ander met geografische coördinaten in decimale graden en in een derde met een plaatsnaam in natuurlijke taal. Geospatiale blocking groepeert kandidaatlocatierecords op nabijheid met behulp van een geohash-raster, en de matching bepaalt of twee ruimtelijk nabije records naar dezelfde faciliteit verwijzen of naar afzonderlijke locaties in de buurt. Locatie-entiteiten hebben ook een temporele dimensie — de classificatie van een faciliteit, de operationele status en de controlerende strijdmacht veranderen in de loop van de tijd — waardoor het golden record temporele geldigheidsintervallen voor belangrijke locatiekenmerken moet bevatten. De laag voor realtime inlichtingenfusie die ISR-detecties correleert met bekende locaties, hangt rechtstreeks af van de nauwkeurigheid en volledigheid van de locatie-entiteitsmaster.

Entity resolution: matching tussen bronsystemen — blocking-strategieën voor grootschalige defensie-entiteitssets, ML-matchingmodellen, deterministische versus probabilistische matching

Entiteitsresolutie is het proces dat bepaalt welke records in verschillende bronsystemen naar dezelfde entiteit in de echte wereld verwijzen en deze records koppelt onder een gedeelde globale identificatiecode. Op de schaal van een grote defensiedataset — miljoenen materieelrecords in logistieke systemen, onderhoudssystemen en systemen voor goederenverantwoording; honderdduizenden personeelsrecords in HR-systemen, C2-systemen en systemen voor veiligheidsmachtigingen — is een naïeve paarsgewijze vergelijking van alle records met alle andere records rekenkundig onhaalbaar. De matching-pipeline moet worden opgezet als een proces in twee fasen: blocking, dat de ruimte van kandidaatparen terugbrengt tot een hanteerbare omvang, gevolgd door matching, dat kandidaatparen met voldoende precisie evalueert om echte matches te onderscheiden van bijna-matches.

Blocking-strategieën voor defensie-entiteitsdomeinen gebruiken domeinspecifieke partitioneringssleutels om records te groeperen die aannemelijk dezelfde entiteit kunnen zijn. Bij personeelsrecords groepeert fonetische blocking op het veld achternaam, met het Soundex- of Double Metaphone-algoritme, records waarin verschillende systemen dezelfde naam hebben overgenomen met afwijkende spellingen, extra spaties of verschillen in koppeltekens — allemaal gangbaar in personeelsbeheersystemen die van vóór de Unicode-normalisatie dateren. Bij materieelrecords groepeert prefix-blocking op de eerste zes tekens van het serienummer (na normalisatie van witruimte en hoofdlettergebruik) records uit systemen die hetzelfde serienummer met verschillende conventies voor scheidingstekens weergeven. Bij locatierecords groepeert een geohash-raster met precisieniveau 6 (celbreedte van ongeveer 1,2 km) ruimtelijk nabije records en sluit het duidelijk verschillende locaties uit. Het blocking-ontwerp moet vóór de inzet worden gevalideerd aan de hand van een gouden-standaarddataset met bekende matches — de blocking-fase moet ten minste 95% van de echte matchparen in de kandidatenset behouden, anders levert de resolutiepipeline systematische fouten door gemiste matches op voor de uitgesloten recordtypen.

Binnen elk kandidaatblok evalueert het matchingmodel elk paar:

Deterministische matching past een vaste regelset toe die een binaire match-/non-matchbeslissing oplevert. Een deterministische regel voor materieelrecords: twee records matchen als en slechts als hun UII-barcodes identiek zijn (na verwijdering van niet-alfanumerieke tekens), of als hun serienummers identiek zijn en hun nationale voorraadnummers overeenkomen tot en met de eerste negen cijfers. Deterministische regels vereisen geen trainingsdata, zijn volledig controleerbaar en leveren geen fout-positieven op wanneer de regel correct is gespecificeerd. Ze zijn geschikt voor attributen die bedoeld zijn om wereldwijd uniek te zijn en die onder controles bij de gegevensinvoer worden onderhouden.
Probabilistische matching berekent een samengestelde matchscore uit gewogen gelijkenismaten op veldniveau. Bij het vergelijken van personeelsrecords kan men bijvoorbeeld Jaro-Winkler-gelijkenis toepassen op de voornaam, fonetische matching op de achternaam, een exacte match op de geboortedatum en fuzzy matching op de afkorting van de rang (om afwijkende opmaak op te vangen), gecombineerd met een classificator op basis van logistische regressie of gradient-boosted bomen die is getraind op gelabelde match-/non-matchparen uit de daadwerkelijke bronsystemen. Het getrainde model leert het relatieve belang van elk veld in de specifieke omgeving met vervuilde data — in sommige bronsystemen is de geboortedatum zeer betrouwbaar; in andere heeft deze een foutpercentage van 3%, waardoor het een zwak onderscheidend kenmerk is.
ML-matchingmodellen breiden probabilistische matching uit met geleerde representaties van de attribuuttekst van entiteiten. Een Siamees neuraal netwerk dat is getraind op paren van personeelsnamen leert een vectorrepresentatie van namen waarin fonetisch of orthografisch vergelijkbare namen vergelijkbare vectoren hebben — en legt zo gelijkenispatronen vast die met de hand ontworpen afstandsmaten voor tekenreeksen missen. ML-modellen vereisen grotere gelabelde datasets voor training en zijn moeilijker te auditen dan deterministische regels, maar ze presteren beter dan klassieke probabilistische modellen op entiteitssets met veel ruis, waar de foutpatronen bij gegevensinvoer complex en niet uniform over de bronsystemen zijn.

De uitvoer van de matching-pipeline voor elk kandidaatpaar is een matchbeslissing (match / non-match / beoordeling) en een betrouwbaarheidsscore. Paren boven de matchdrempel worden automatisch gekoppeld onder een gedeelde globale entiteits-ID. Paren in de beoordelingsband — waarvan de betrouwbaarheidsscore tussen de non-matchdrempel en de matchdrempel ligt — worden niet automatisch afgehandeld, maar ter beslechting naar een menselijke steward gestuurd.

Opbouw en onderhoud van golden records — survivorship-regels voor conflicterende bronattributen, betrouwbaarheidsscoring van golden records, geautomatiseerde versus door stewards ondersteunde resolutie

Zodra entiteitsresolutie records uit meerdere bronsystemen aan dezelfde globale entiteits-ID heeft gekoppeld, bouwt het MDM-systeem het golden record op: de gezaghebbende, verenigde representatie van die entiteit, waarvan de attributen voor elk veld uit de beste beschikbare bron worden gehaald. Het golden record is geen eenvoudige samenvoeging van alle bronattributen — wanneer bronnen het oneens zijn, moet een survivorship-regel bepalen welke waarde het golden record draagt.

Survivorship-regels worden gedefinieerd per attribuut per entiteitsdomein en leggen de gezagshiërarchie voor dat attribuut vast:

# Materieelentiteit — survivorship-regels per attribuut serial_number: source_priority=[property_acct, maintenance, logistics] national_stock_num: source_priority=[property_acct, logistics] unit_assignment: source_priority=[c2_system, logistics] maintenance_status: source_priority=[maintenance, logistics] condition_code: source_priority=[maintenance, property_acct] location_mgrs: most_recent_update # C2 of logistiek, afhankelijk van wie het laatst heeft bijgewerkt end_item_code: source_priority=[property_acct] # Eén gezaghebbende bron # Personeelsentiteit — survivorship-regels per attribuut permanent_rank: source_priority=[hr_system] operational_unit: source_priority=[c2_system, hr_system] clearance_level: source_priority=[clearance_mgmt] duty_position: most_recent_update # HR of C2, afhankelijk van het type toewijzing name_legal: source_priority=[hr_system] name_preferred: most_complete # De bron met de minste lege naamvelden wint
            

Elk attribuut in het golden record draagt naast zijn waarde drie metadatavelden: een bronverwijzing (welk bronsysteem deze waarde heeft geleverd en de identificatiecode van het specifieke bronrecord), een updatetijdstempel (wanneer het bronsysteem deze waarde voor het laatst heeft bevestigd) en een betrouwbaarheidsscore (een genormaliseerde waarde die de betrouwbaarheid van de bron weerspiegelt, evenals de kwaliteit van de match die dit record aan de golden entiteit heeft gekoppeld). Een betrouwbaarheidsscore van 1,0 duidt op een deterministische match op een wereldwijd unieke identificatiecode uit een zeer betrouwbare bron; lagere scores weerspiegelen probabilistische matchresultaten, bronnen met bekende problemen met de datakwaliteit, of attributen waarbij de survivorship werd betwist tussen bronnen met conflicterende waarden.

De betrouwbaarheidsscore is geen versiering — ze is operationeel van belang. Een gereedheidsanalist die een capaciteitsbeoordeling opstelt, kan de query op het golden record filteren om attributen onder een betrouwbaarheidsdrempel uit te sluiten, of de analyselaag kan de bijdrage van elk materieelrecord aan de gereedheidsscore van de eenheid wegen op basis van de betrouwbaarheid van het attribuut voor onderhoudsstatus. Een analist die een gereedheidsmaatstaf ontvangt zonder inzicht in de onderliggende betrouwbaarheidsscores, kan geen onderscheid maken tussen een beoordeling met hoge betrouwbaarheid en een cijfer dat is samengesteld uit matches van lage kwaliteit en verouderde brondata.

Het onderhoud van golden records is een continu proces en geen eenmalige batchbewerking. Wanneer een bronsysteem een entiteitsrecord bijwerkt, ontvangt de ingestpipeline van het MDM-systeem de update, evalueert ze de survivorship opnieuw voor alle betrokken attributen en werkt ze het golden record dienovereenkomstig bij. Als de update ertoe leidt dat het golden record verandert voor een attribuut dat downstreamsystemen hebben afgenomen, wordt een wijzigingsmelding gepubliceerd op de MDM-eventbus, zodat afnemende systemen het bijgewerkte golden record opnieuw kunnen opvragen. De wijzigingsmelding bevat de globale entiteits-ID, de lijst met gewijzigde attributen en de waarden vóór en na de wijziging — voldoende informatie voor een afnemend systeem om te bepalen of de wijziging van invloed is op zijn actieve operationele data, zonder het golden record volledig opnieuw te hoeven ophalen.

Workflows voor data stewardship — toewijzing van stewards per domein (materieelsteward, personensteward), workflow voor geschillenbeslechting, audittrail voor wijzigingen aan golden records

Geautomatiseerde entiteitsresolutie en survivorship-regels handelen het merendeel van de match- en attribuutconflicten in een MDM-systeem in productie af — doorgaans kan 85 tot 95 procent van de records zonder menselijke tussenkomst worden opgelost wanneer de matching-pipeline goed is afgestemd op de data van de specifieke bronsystemen. De resterende 5 tot 15 procent van de gevallen — matches met lage betrouwbaarheid, betwiste attribuutwaarden waarbij meerdere bronnen gelijk gezag claimen, en entiteitssplitsingen of -samenvoegingen waarvoor een afweging nodig is — moet ter beslechting worden doorgestuurd naar een menselijke data steward.

Stewardship is georganiseerd per entiteitsdomein, waarbij elk domein is toegewezen aan een steward die beschikt over zowel de domeinexpertise als de bevoegdheid voor systeemtoegang die nodig is om geschillen te beslechten:

Materieelsteward — doorgaans ingebed in de functie voor goederenverantwoording of logistiek, heeft de bevoegdheid om het juiste materieelrecord vast te stellen wanneer systemen het oneens zijn over serienummers, toewijzing aan eenheden of conditiecode. De materieelsteward heeft directe toegang tot fysieke registers en kan de werkelijke situatie verifiëren door de oorspronkelijke papieren documentatie te raadplegen of af te stemmen met materieelbeheerders.
Personeelssteward — doorgaans ingebed in de HR- of personeelsbeheerfunctie, heeft de bevoegdheid om conflicterende naamspellingen, dubbele personeelsrecords (gebruikelijk wanneer iemand opnieuw in dienst treedt en een nieuwe door het systeem gegenereerde identificatiecode krijgt) en afwijkingen in de toewijzing tussen administratieve en operationele records op te lossen.
Organisatiesteward — doorgaans het J1- of J3-stafelement, heeft de bevoegdheid om onduidelijkheden in de eenheidshiërarchie bij wijzigingen van de taakorganisatie op te lossen, de data van activering en deactivering van eenheden te bevestigen en de toewijzing aan een bovenliggende eenheid te beslechten wanneer onderliggende eenheden tijdelijk aan meerdere hoofdkwartieren worden toegevoegd.
Locatiesteward — doorgaans de functie voor geospatiale inlichtingen of facilitair beheer, heeft de bevoegdheid om te bevestigen of twee ruimtelijk nabije records dezelfde faciliteit of afzonderlijke faciliteiten op dezelfde plek vertegenwoordigen, en om de canonieke coördinaat en naam vast te stellen voor een locatie die in verschillende systemen onder verschillende aanduidingen voorkomt.

De workflow voor geschillenbeslechting presenteert elke aan een steward voorgelegde zaak als een gestructureerd pakket. Het zaakpakket bevat: de kandidaatrecords uit elk bronsysteem waarvan het MDM-systeem vermoedt dat ze naar dezelfde entiteit kunnen verwijzen, gelijkenisscores op veldniveau voor elk vergeleken attribuut, de geautomatiseerde aanbeveling van het MDM-systeem (match, non-match of de aanbevolen winnende waarde voor een betwist attribuut) en een duidelijk overzicht van waar de bronnen het eens en oneens zijn. De steward kiest uit de beschikbare oplossingsopties — de geautomatiseerde aanbeveling bevestigen, deze overrulen met een alternatieve oplossing, of de zaak markeren als een zaak waarvoor aanvullende informatie nodig is voordat ze kan worden opgelost. In een vrijetekstveld voor de motivering kan de steward de redenering achter niet-vanzelfsprekende beslissingen vastleggen.

De audittrail voor wijzigingen aan golden records legt elke statusovergang in de geschiedenis van het golden record vast, ongeacht of de wijziging is veroorzaakt door een geautomatiseerde survivorship-update of door een handmatige beslissing van een steward. Elk auditrecord bevat:

De globale entiteits-ID en het entiteitsdomein
De gewijzigde attributen en de waarden vóór en na de wijziging voor elk attribuut
De aanleiding voor de wijziging: een geautomatiseerde survivorship-regel (met regel-ID en versie), een binnenkomende bronupdate (met ID van het bronsysteem en ID van het bronrecord) of een beslissing van een steward (met ID van de stewardzaak)
De geauthenticeerde identiteit van de principal die verantwoordelijk is voor de wijziging — het serviceaccount van het systeem bij geautomatiseerde wijzigingen, de geauthenticeerde identiteit van de steward bij handmatige beslissingen
Het tijdstip van de wijziging (logische klokwaarde bij gedistribueerde implementaties, kloktijd bij implementaties met één hub)

Auditrecords worden weggeschreven naar append-only-opslag en kunnen na het schrijven niet meer worden gewijzigd. Dankzij deze onveranderlijkheid kan het MDM-systeem de volledige toestand van elk golden record op elk moment in het verleden reconstrueren door de audittrail af te spelen vanaf het aanmaken van het oorspronkelijke record — een mogelijkheid die operationeel noodzakelijk is wanneer analisten moeten beoordelen wat het MDM-systeem op een bepaald historisch moment over een entiteit aannam, en een compliancevereiste voor systemen die gerubriceerde entiteiten beheren.

Overleefbaarheid van MDM in losgekoppelde omgevingen — lokale MDM-cache voor vooruitgeschoven systemen, conflictoplossing bij herverbinding, model van uiteindelijke consistentie voor losgekoppelde nodes

Een gecentraliseerde MDM-hub die voor elke entiteitsquery netwerkverbinding met het achterliggende echelon vereist, is operationeel onbruikbaar in een betwiste omgeving waar de communicatie is verslechterd of verbroken. Vooruitgeschoven C2-systemen, logistieke systemen en hulpmiddelen voor operationele planning zijn allemaal afhankelijk van entiteitsresolutie om correct te functioneren — als de MDM-hub onbereikbaar is, moeten ze terugvallen op ruwe bronidentificatiecodes die tussen systemen mogelijk niet overeenkomen, waardoor het operationele beeld terugkeert naar de situatie van vóór MDM, met gefragmenteerde entiteitsidentiteit. Een ontwerp voor MDM-overleefbaarheid voorkomt deze terugval door een lokale cache vooruit te plaatsen en een strikt synchronisatieprotocol voor de herverbindingsfase te definiëren.

De vooruitgeschoven MDM-cache is een vooraf gepositioneerde leesreplica van de golden records en de kruisverwijzingstabel voor de subset van entiteiten die relevant is voor het operationele bereik van het vooruitgeschoven element. “Relevant bereik” wordt bepaald aan de hand van twee dimensies: het geografische operatiegebied (alle locatie-entiteiten binnen het AO, alle materieelentiteiten met een laatst bekende locatie binnen het AO) en de taakorganisatie (alle persoons-, organisatie- en materieelentiteiten die zijn gekoppeld aan eenheden in de taakorganisatie van het vooruitgeschoven element). De cache wordt gevuld voordat het vooruitgeschoven element wordt ingezet, met behulp van een snapshot-export uit de centrale hub. Ze wordt uitgerold op hardware die onafhankelijk van het wide-area network werkt — een ruggedized server die samen met de vooruitgeschoven C2-node is geplaatst, of die is ingebed in de rekenomgeving van de tactische commandopost.

Tijdens losgekoppeld gebruik bevragen tactische systemen de lokale cache precies zoals ze de centrale hub zouden bevragen — dezelfde API, hetzelfde antwoordformaat. Verzoeken om entiteitsresolutie worden afgehandeld vanuit de lokale kruisverwijzingstabel. Query's op golden records leveren de gecachete attribuutwaarden op, samen met een actualiteitstijdstempel die aangeeft wanneer elk attribuut voor het laatst door de centrale hub is bevestigd. Tactische systemen zijn verantwoordelijk voor het tonen van deze actualiteitstijdstempel aan gebruikers wanneer de gegevens mogelijk verouderd zijn, in plaats van gecachete gegevens te presenteren alsof ze actueel zijn.

Alle aanmaakacties, updates, samenvoegingen en splitsingen van entiteiten die tijdens de losgekoppelde periode plaatsvinden, worden weggeschreven naar een lokaal wijzigingslogboek — een geordende, begrensde wachtrij van wijzigingsgebeurtenissen voor entiteiten. Elke gebeurtenis draagt een vectorklok-tijdstempel die een partiële ordening van gebeurtenissen over losgekoppelde nodes vaststelt zonder dat gesynchroniseerde klokken nodig zijn. De capaciteit van het wijzigingslogboek beperkt de duur van het losgekoppelde gebruik: een wijzigingslogboek dat is gedimensioneerd voor 72 uur aan typische operationele updatefrequenties voor entiteiten, biedt 72 uur zelfstandig functioneren voordat synchronisatie verplicht wordt om overloop van het logboek te voorkomen. Het operationele planningsproces moet met deze beperking rekening houden.

Het synchronisatieprotocol bij herverbinding werkt in drie fasen wanneer het vooruitgeschoven element de netwerkverbinding met de centrale hub herstelt:

Fase 1 — Overdracht van het wijzigingslogboek: De vooruitgeschoven node stuurt zijn volledige wijzigingslogboek naar de centrale hub. De hub bevestigt de ontvangst en wijst aan elke gebeurtenis een globaal volgnummer toe. De vooruitgeschoven node blijft tijdens deze fase lokale query's uit de cache bedienen. Fase 2 — Conflictdetectie en -oplossing: De hub speelt het vooruitgeschoven wijzigingslogboek opnieuw af tegen zijn huidige entiteitsstatus. Voor elke vooruitgeschoven gebeurtenis controleert de hub of hetzelfde attribuut tijdens de losgekoppelde periode is bijgewerkt op de hub of op een andere vooruitgeschoven node. Geen conflict: de vooruitgeschoven wijziging wordt ongewijzigd toegepast. Conflict (hetzelfde attribuut bijgewerkt door twee bronnen): de geconfigureerde survivorship-regel wordt toegepast (meest vertrouwde bron, meest recente logische klok). Als de survivorship-regel geen duidelijke winnaar oplevert: doorsturen naar de stewardwachtrij. Fase 3 — Hersynchronisatie van de cache: De hub stuurt de samengevoegde entiteitsstatus na conflictoplossing naar de vooruitgeschoven cache. De vooruitgeschoven cache vervangt zijn snapshot door de samengevoegde status. De hub stuurt het opgeloste wijzigingslogboek naar alle andere vooruitgeschoven caches, zodat ook zij updates ontvangen die op deze vooruitgeschoven node zijn ontstaan. Alle nodes bevestigen de ontvangst voordat de hub de synchronisatiecyclus als voltooid markeert.
            

Het model van uiteindelijke consistentie waarop deze architectuur berust, biedt een garantie: na herverbinding en succesvolle afronding van het synchronisatieprotocol bevatten alle nodes in de MDM-topologie — de centrale hub en alle vooruitgeschoven caches — dezelfde entiteitsstatus. Tijdens een losgekoppelde periode kunnen nodes uiteenlopen. Het synchronisatieprotocol is zo ontworpen dat deze divergentie begrensd, detecteerbaar en oplosbaar is zonder gegevensverlies — er worden geen entiteitsupdates weggegooid die tijdens de losgekoppelde periode zijn doorgevoerd; ze worden alleen opnieuw geordend en mogelijk overschreven door een survivorship-regel die de door de organisatie gedefinieerde gezagshiërarchie toepast.

De operationele consequentie is dat analisten en systemen die de vooruitgeschoven cache tijdens een losgekoppelde periode gebruiken, moeten begrijpen dat ze werken vanuit een snapshot van onzekere actualiteit. De vooruitgeschoven cache moet op cacheniveau een veld “last sync timestamp” en op het niveau van het afzonderlijke golden-recordattribuut een tijdstempel “last confirmed” beschikbaar stellen, zodat downstreamsystemen over de informatie beschikken die ze nodig hebben om passende betrouwbaarheidskanttekeningen te tonen wanneer operationele beslissingen afhangen van entiteitsdata die niet recent door de centrale hub is bevestigd. Een gereedheidsbeoordeling van een eenheid op basis van golden records van materieel met een snapshot van 12 uur oud en een losgekoppelde periode van 71 uur rechtvaardigt een ander betrouwbaarheidsniveau dan een beoordeling op basis van records die 30 minuten vóór het genereren van de beoordeling zijn gesynchroniseerd. Dit onderscheid zichtbaar maken in de data — in plaats van het te verbergen achter een uniforme weergave van golden-recordattributen — maakt MDM nuttig in plaats van misleidend in betwiste operationele omgevingen.

Veelgestelde vragen

Wat is master data management (MDM) in een defensiecontext?

Stamgegevensbeheer in een defensiecontext is de discipline waarbij van elke kernentiteit — persoon, organisatie, materieel en locatie — één gezaghebbende versie wordt gecreëerd en onderhouden die alle operationele systemen als referentie hanteren. Zonder MDM komt een militair in het HR-systeem voor onder één personeelsnummer, in het C2-systeem onder een ander, door de eenheid toegekend ID en in het logistieke systeem onder een derde identificatie die aan materieeltoewijzing is gekoppeld. Wanneer een analist die systemen joint, kan die niet vaststellen of drie records naar dezelfde persoon verwijzen of naar drie verschillende personen. MDM lost dit op door een entity resolution-proces uit te voeren dat records tussen systemen vergelijkt, duplicaten onder één globale identificatie koppelt en een golden record opbouwt dat de best bekende status van elke entiteit weergeeft. Alle nageschakelde analyse- en operationele systemen gebruiken het golden record via een gedeelde API, in plaats van elk bronsysteem afzonderlijk te bevragen. Het resultaat zijn consistente entiteitsverwijzingen over C2, logistiek, HR en ISR, wat de voorwaarde is voor elk betrouwbaar multidomein-situatiebeeld.

Wat zijn de drie hubmodellen in MDM en welk model is het beste voor defensie?

De drie standaard hubmodellen voor MDM zijn registry, consolidatie en coëxistentie. In het registrymodel slaat de MDM-hub alleen de kruisverwijzingstabel op — een koppeling van bronsysteem-identificaties aan de globale entiteits-ID — zonder zelf stamattributen op te slaan. Elk systeem behoudt zijn eigen kopie van de entiteitsattributen, en consumenten bevragen de bronsystemen rechtstreeks, waarbij ze de kruisverwijzing gebruiken om de identiteit te bepalen. In het consolidatiemodel kopieert en bewaart de hub de entiteitsattributen van alle bronsystemen, verrijkt en ontdubbelt deze en levert het geconsolideerde resultaat; de bronsystemen worden niet gewijzigd. In het coëxistentiemodel slaat de hub de geconsolideerde master op en schrijft deze de attributen van het golden record ook terug naar de bronsystemen, waardoor een gedeelde gezaghebbende status ontstaat over alle deelnemende applicaties. Voor defensieomgevingen is het consolidatiemodel het meest praktisch: het vereist geen wijziging van gezaghebbende bronsystemen (HR-, logistieke en C2-systemen zijn zelden aan te passen), eist niet dat alle systemen door de hub geïnitieerde schrijfacties accepteren (autorisatie voor terugschrijven is complex in geclassificeerde omgevingen) en biedt toch één centrale plek waar analyse- en inlichtingensystemen consistente entiteitsdata kunnen bevragen. Het registrymodel is geschikt wanneer opslagreplicatie niet haalbaar is vanwege eisen voor classificatiescheiding.

Welke entiteitstypen beheert een MDM-systeem voor defensie?

Een MDM-systeem voor defensie beheert vier primaire entiteitsdomeinen. Het persoonsdomein omvat militair personeel — soldaten, officieren, contractanten en coalitiepartners — met attributen afkomstig uit HR-systemen, personeelsbeheer, beheer van veiligheidsmachtigingen en C2-systemen. Het organisatiedomein omvat eenheden, commando's, subeenheden en taskforces, inclusief hun hiërarchische relaties en de huidige structuur van de taakorganisatie, die tijdens operationele planning vaak verandert. Het materieeldomein omvat platforms, voertuigen, wapensystemen en de inventaris van eindproducten, met attributen afkomstig uit logistieke, onderhouds- en materieelverantwoordingssystemen; elk materieelitem heeft een serienummer en een unieke itemidentificatie (UII) die moet worden gematcht tussen systemen die mogelijk verschillende identificatieformaten vastleggen. Het locatiedomein omvat faciliteiten, installaties, benoemde aandachtsgebieden en tactische posities, en vereist afstemming tussen systemen die dezelfde fysieke locatie aanduiden met coördinaten in het militaire rasterreferentiesysteem (MGRS), geografische coördinaten of plaatsnamen in natuurlijke taal. Elk domein vereist domeinspecifieke matchingalgoritmen en stewardtoewijzingen, omdat de attributen, identificatieschema's en datakwaliteitspatronen aanzienlijk verschillen tussen domeinen.

Hoe werkt entiteitsresolutie op de schaal van een grote defensiedataset?

Entity resolution op defensieschaal — miljoenen materieelrecords, honderdduizenden personeelsrecords uit meerdere bronsystemen — vereist een blocking-stap voordat enige paarsgewijze vergelijking kan worden uitgevoerd. Blocking verdeelt de volledige recordset in kleinere kandidaatgroepen waarbinnen alle records aannemelijk naar dezelfde entiteit zouden kunnen verwijzen. Zonder blocking is het vergelijken van elk record met elk ander record kwadratisch duur en rekenkundig onhaalbaar voor grote datasets. Blocking-strategieën voor defensie-entiteitssets zijn onder meer fonetische blocking op achternaamvelden (Soundex, Metaphone) voor personeelsrecords, prefix-blocking op serienummervelden voor materieelrecords en geohash-blocking voor locatierecords. Na de blocking beoordeelt een matchingmodel elk kandidaatpaar binnen een blok. Deterministische matching past een vaste regelset toe — als twee records exact hetzelfde serienummer en hetzelfde nationale stocknummer hebben, zijn ze een match. Probabilistische matching berekent een betrouwbaarheidsscore voor de match uit een gewogen combinatie van gelijkenisscores op veldniveau en vergelijkt die met een drempel. ML-gebaseerde matching traint een classifier op gelabelde match/non-match-paren uit de specifieke dataset en leert zo het relatieve gewicht van elk veld en de patronen van invoerfouten die kenmerkend zijn voor de bronsystemen in de omgeving.

Wat is een golden record en hoe wordt het opgebouwd uit conflicterende brondata?

Een golden record is de gezaghebbende, uniforme weergave van één entiteit in het MDM-systeem, samengesteld uit de attributen die zijn aangeleverd door alle bronsystemen die records voor die entiteit bevatten. Wanneer twee of meer bronsystemen verschillende waarden voor hetzelfde attribuut leveren — bijvoorbeeld wanneer de toegewezen eenheid van het materieel verschilt tussen het logistieke systeem en het C2-systeem — bepaalt een survivorship-regel welke bronwaarde wint. Gangbare survivorship-regels zijn: meest recente wint (de bron die het attribuut het laatst heeft bijgewerkt krijgt voorrang), meest vertrouwde bron wint (een vaste prioriteitsrangorde van bronnen bepaalt van welk systeem de waarden gezaghebbend zijn voor elk attribuuttype) en meest complete wint (de waarde van de bron met het laagste percentage null-waarden voor dat attribuut heeft de voorkeur). In de praktijk combineert een MDM-systeem in productie regels: de eenheidstoewijzing is gezaghebbend vanuit het C2-systeem, de onderhoudsstatus is gezaghebbend vanuit het logistieke systeem en de identificatieattributen (serienummer, nomenclatuur) zijn gezaghebbend vanuit het materieelverantwoordingssysteem. Elk attribuut in het golden record draagt een betrouwbaarheidsscore en een herkomstverwijzing die aangeeft welke bron de waarde heeft geleverd en wanneer deze voor het laatst is bevestigd. Attributen die zijn afgeleid van matches met lage betrouwbaarheid of van bronnen met bekende datakwaliteitsproblemen krijgen lagere betrouwbaarheidsscores, wat zichtbaar is voor nageschakelde consumenten die de betrouwbaarheid van de entiteitsdata beoordelen.

Wat is data stewardship en hoe werkt het in een MDM-implementatie voor defensie?

Data stewardship is de menselijke governancelaag die match- en attribuutconflicten oplost die het geautomatiseerde MDM-systeem niet met voldoende zekerheid kan oplossen. Een data steward is een persoon met domeinexpertise en toegangsbevoegdheid tot het systeem, die dubbelzinnige matches beoordeelt, conflicterende attribuutwaarden beslecht en voorgestelde constructies van golden records goedkeurt of afwijst. In een MDM-implementatie voor defensie is stewardship georganiseerd per entiteitsdomein: een materieelsteward heeft gezag over het materieeldomein en is doorgaans ondergebracht bij de functie materieelverantwoording of logistiek; een personeelssteward heeft gezag over het persoonsdomein en is doorgaans ondergebracht bij de HR- of personeelsbeheerfunctie. Een workflow voor geschiloplossing leidt matchbeslissingen met lage betrouwbaarheid en attribuutconflicten met hoge waarde door naar de wachtrij van de juiste steward, met een gestructureerd casusdossier: de kandidaatrecords van elke bron, de gelijkenisscores voor elk gematcht veld, de geautomatiseerde aanbeveling en de alternatieve oplossingen waaruit de steward kan kiezen. De beslissing van de steward wordt in de MDM-audittrail vastgelegd, met de identiteit van de steward, de genomen beslissing en de motivering. Deze audittrail is zowel een operationeel record als een governance-artefact dat aantoont dat het golden record door een bevoegde domeinexpert is beoordeeld.

Hoe moet MDM worden ontworpen om te overleven in een losgekoppelde, vooruitgeschoven omgeving?

Het overlevingsvermogen van MDM in losgekoppelde omgevingen vereist een gelaagde architectuur waarin een lichtgewicht MDM-cache voorwaarts wordt ingezet naast de tactische systemen die deze bedient, terwijl de gezaghebbende MDM-hub in het achterliggende echelon blijft. De voorwaartse cache bevat een vooraf gepositioneerde snapshot van de entiteitsmaster — de golden records en de kruisverwijzingstabel voor de entiteiten die relevant zijn voor het operatiegebied en de taakorganisatie van het voorwaartse element. Tactische systemen in de losgekoppelde omgeving bevragen de lokale cache voor entity resolution, in plaats van een netwerkverbinding met de centrale hub te vereisen. Wanneer het voorwaartse element losgekoppeld opereert, worden wijzigingen in entiteitsrecords naar een lokaal wijzigingslog geschreven — een begrensde wachtrij van create-, update-, merge- en split-bewerkingen — in plaats van verloren te gaan. Bij herverbinding wordt het wijzigingslog naar de centrale hub verzonden, die een deterministisch protocol voor conflictoplossing toepast om de voorwaartse updates samen te voegen met alle wijzigingen die tijdens de losgekoppelde periode bij de hub of bij andere voorwaartse nodes hebben plaatsgevonden. De conflictoplossing past standaard een ordening op basis van tijdstempels toe, met door een steward ondersteunde oplossing voor conflicten waarbij hetzelfde entiteitsattribuut tijdens het losgekoppelde venster door beide zijden is bijgewerkt.

Wat is het verschil tussen deterministische en probabilistische entiteitsmatching?

Deterministische matching past een vaste regelset toe waarbij een matchbeslissing binair is — twee records voldoen wel of niet aan alle matchcriteria. Een deterministische regel voor materieelrecords kan bepalen: twee records zijn een match als en alleen als hun serienummers identiek zijn na het verwijderen van witruimte en het normaliseren van hoofdlettergebruik, en hun nationale stocknummers (NSN's) overeenkomen in de eerste negen cijfers. Deterministische regels zijn eenvoudig te auditen, produceren geen fout-positieve matches als de regel correct is gespecificeerd en vereisen geen trainingsdata. Ze zijn de juiste keuze voor attributen die bedoeld zijn als wereldwijd unieke identificaties die door gezaghebbende bronnen worden beheerd. Probabilistische matching berekent een gewogen samengestelde score uit meerdere veldvergelijkingen, die elk een gedeeltelijke gelijkenisscore opleveren in plaats van een binair ja/nee. Bij de vergelijking van een personeelsrecord kan de fonetische gelijkenis van de achternaam met 0,35 worden gewogen, de gelijkenis van de voornaam met 0,25, een exacte match van de geboortedatum met 0,30 en de eenheidstoewijzing met 0,10, wat een samengestelde score oplevert die wordt vergeleken met een configureerbare matchdrempel. Records boven de drempel zijn kandidaat-matches; records in een beoordelingsband net onder de drempel worden doorgestuurd naar een steward. Probabilistische matching kan omgaan met de realiteit van vervuilde data in defensiesystemen — records met typefouten, varianten in naamspelling, ontbrekende velden of inconsistente codering — waar deterministische regels onaanvaardbaar hoge percentages gemiste matches zouden opleveren.

Hoe worden wijzigingen aan golden records geaudit in een MDM-systeem voor defensie?

Elke wijziging van een golden record in een MDM-systeem voor defensie moet worden vastgelegd in een onveranderlijke audittrail die de volledige toestand van de betrokken attributen vóór en na de wijziging registreert, de bron van de wijziging (geautomatiseerde survivorship-regel, handmatige beslissing van een steward of binnenkomende update van een bronsysteem), de identiteit van de principal die de wijziging heeft geautoriseerd (service-account van het systeem bij geautomatiseerde wijzigingen, geauthenticeerde menselijke identiteit bij beslissingen van een steward), het tijdstip van de wijziging en een verwijzing naar de bronevent die de wijziging heeft veroorzaakt (de ID van de ingest-batch bij geautomatiseerde updates, de casus-ID van de steward bij handmatige beslissingen). De audittrail wordt append-only opgeslagen — bestaande auditrecords kunnen nooit worden gewijzigd of verwijderd, er kunnen alleen nieuwe records worden toegevoegd. Deze onveranderlijkheid wordt op de opslaglaag afgedwongen met object lock of write-once-beleid op databaseniveau, in plaats van uitsluitend te vertrouwen op afdwinging op de applicatielaag. De audittrail maakt twee cruciale operationele toepassingen mogelijk: de reconstructie van de toestand van het golden record van een willekeurige entiteit op elk moment in het verleden (waarmee de vraag wordt beantwoord “wat geloofde het MDM-systeem op een bepaalde datum om 06:00 over het materieel van deze eenheid”) en het herleiden van de herkomst van een specifieke attribuutwaarde in het huidige golden record naar de update van het bronsysteem en de ingest-gebeurtenis die deze heeft geïntroduceerd.

Hoe werkt uiteindelijke consistentie in een MDM-systeem voor defensie met meerdere losgekoppelde nodes?

Uiteindelijke consistentie in een MDM-implementatie voor defensie betekent dat alle nodes in de MDM-topologie — de centrale hub en alle voorwaartse caches — na herverbinding en synchronisatie gegarandeerd convergeren naar dezelfde entiteitstoestand, maar tijdens een losgekoppelde periode uiteenlopende toestanden kunnen hebben. Het consistentiemodel is bewust versoepeld ten opzichte van sterke consistentie (waarbij alle nodes te allen tijde overeenstemmen over de huidige toestand), omdat sterke consistentie continue netwerkconnectiviteit vereist, wat onverenigbaar is met de eis van losgekoppelde werking. In het model van uiteindelijke consistentie verwerkt elke node updates lokaal en legt deze vast in zijn wijzigingslog. Wijzigingslogs gebruiken vectorklokken of hybride logische klokken in plaats van wall-clock-tijdstempels om een partiële ordening van gebeurtenissen over nodes heen vast te stellen zonder gesynchroniseerde klokken te vereisen — een realistische eis in voorwaarts ingezette omgevingen waar NTP-synchronisatie mogelijk niet beschikbaar is. Bij herverbinding verzamelt de hub de wijzigingslogs van alle nodes, voegt ze samen door de partiële ordening toe te passen en produceert een geconvergeerde golden record-toestand die alle updates van alle nodes bevat. Wanneer twee nodes tijdens het losgekoppelde venster conflicterende updates op hetzelfde attribuut hebben uitgevoerd — een situatie die te detecteren is door de partiële ordening van de vectorklokken te onderzoeken — wordt het conflict opgelost met de geconfigureerde survivorship-regel (meest vertrouwde bron, meest recent volgens de logische klok) of geëscaleerd naar een steward als de survivorship-regel geen duidelijke winnaar oplevert. Na convergentie propageert de hub de samengevoegde toestand terug naar alle nodes, zodat ze opnieuw worden gesynchroniseerd naar de consistente weergave.

Wat is stamgegevensbeheer (MDM) in een defensiecontext?