Inlichtingen uit SIGINT, IMINT, HUMINT en OSINT tot één samenhangend beeld fuseren klinkt in theorie eenvoudig. In de praktijk is het een van de lastigste technische problemen in defensiegegevensinfrastructuur. Elke discipline produceert gegevens met een andere snelheid, in een ander formaat en met een ander betrouwbaarheidsmodel — en een systeem dat deze feeds alleen aggregeert zonder ze echt te correleren, levert een ruisiger beeld op dan een goed beheerde feed van één INT, geen beter beeld. Serieuze gegevensintegratie voor defensie-inlichtingen vereist een architectuur die vanaf eerste principes rond de eigenschappen van elk brontype is ontworpen, geen generiek datawarehouse met losse INT-adapters.
Dit artikel doorloopt de volledige architectuur van een realtime multibron-fusesysteem — van de stream-ingestielaag die heterogene feeds opneemt, via entiteitsresolutie en de correlatie-engine, tot betrouwbaarheidsscoring en de publicatie van een verrijkt inlichtingenbeeld naar C2-systemen. Elke sectie behandelt de specifieke ontwerpkeuzen die productiefusie onderscheiden van prototypesystemen die in een demo correct lijken, maar op operationele schaal falen.
Het probleem van multibron-inlichtingenfusie — waarom het fuseren van SIGINT/IMINT/HUMINT/OSINT lastiger is dan het lijkt
Drie structurele problemen maken multibronfusie kwalitatief lastiger dan het op schaal verwerken van één enkele INT. Ze negeren — fusie behandelen als puur een gegevenspijplijnprobleem — is de meest gemaakte architectuurfout, en het levert een systeem op dat niet meer te corrigeren is zodra gegevens in productievolume doorstromen.
Formaatheterogeniteit is het meest zichtbare probleem. Een ELINT-onderscheppingsrecord bevat zendfrequentie, pulsrepititie-interval, scantype, peiling en time-difference-of-arrival-gegevens. Een IMINT-detectie bevat een begrenzende rechthoek, een betrouwbaarheidsscore in pixelruimte, een ground sample distance en een UTM-coördinaat met bijbehorende CEP. Een HUMINT-verhaalextract bevat vrije tekst, een bronwaardering van een analist, een benoemde locatie en een tijdsvenster in uren of dagen. Deze drie records kunnen allemaal naar hetzelfde object in de echte wereld verwijzen — een radarvoertuig — maar ze delen geen enkel gemeenschappelijk veld, geen gemeenschappelijke coördinatenconventie en geen gemeenschappelijke identifier. Ze normaliseren naar één canoniek schema vereist adapters op maat per brontype en een canoniek entiteitsmodel dat ze allemaal kan herbergen zonder hun semantiek te laten samenvallen. Het ontwerp van het gegevensmodel voor militaire multi-INT-sensorfusie behandelt die canonieke laag in detail.
Onverenigbare betrouwbaarheidsmodellen is subtieler, maar veroorzaakt meer analytische fouten. Elke INT hanteert een eigen betrouwbaarheidsmodel. SIGINT-geolocatie bevat een CEP (Circular Error Probable) in meters — een geometrische nauwkeurigheidsschatting. IMINT-detectie bevat een classificatiekans — de logit-uitvoer van het neurale netwerk voor de objectklasse. HUMINT bevat een admiraliteitsbetrouwbaarheidswaardering — een menselijk oordeel op een schaal van zes punten. Deze drie getallen betekenen fundamenteel iets anders. Een naïef fusesysteem dat ze middelt, produceert een getal dat wiskundig geldig is, maar analytisch betekenisloos. Een correct betrouwbaarheidsmodel moet eerst elke brongebonden betrouwbaarheid naar een gemeenschappelijk probabilistisch kader vertalen en daarna over bronnen heen aggregeren met een Bayesiaans of bewijscombinatieschema (zoals Dempster-Shafer) dat afhankelijk en onafhankelijk bewijs correct afhandelt.
Temporele scheefheid is het probleem dat realtime fusiearchitecturen het meest zichtbaar breekt. Bronnen hebben sterk verschillende latenties van gebeurtenis tot aankomst in de pijplijn. Een SIGINT-onderschepping kan binnen seconden na de transmissie in de pijplijn aankomen. IMINT van een ingezette satelliet kan 60–90 minuten beeldverwerking nodig hebben voordat een detectierecord ontstaat. Een HUMINT-rapport over de gebeurtenissen van gisteren kan op dag D+2 worden opgenomen. Een fusie-engine die records correleert op aankomsttijd in de pijplijn, associeert gebeurtenissen systematisch verkeerd — hij koppelt de SIGINT-onderschepping en de IMINT-bevestiging niet, omdat ze 90 minuten uit elkaar aankwamen, terwijl ze dezelfde gebeurtenis beschrijven. De architectuur moet gebeurtenistijd (wanneer de gebeurtenis in de wereld plaatsvond) scheiden van opnametijd (wanneer het bericht in de pijplijn aankwam) en alle temporele correlatie op gebeurtenistijd uitvoeren, waarbij opnametijd alleen dient voor bewaking van de pijplijnprestaties.
Stream-ingestiearchitectuur — Kafka versus Pulsar voor inlichtingenfeeds, schema registry voor heterogene berichttypes, afhandeling van backpressure
De stream-ingestielaag moet berichten aankunnen die binnenkomen met snelheden van enkele HUMINT-rapporten per uur tot miljoenen SIGINT-records per uur vanuit één verzamelsysteem, allemaal in dezelfde fusiepijplijn. Het ontwerp moet piekverkeer van snelle bronnen opnemen zonder die backpressure door te geven aan trage bronnen met hoge prioriteit — een HUMINT-rapport dat in een piek naast een SIGINT-vloed aankomt, mag niet vertragen doordat de pijplijn verzadigd is.
De primaire architectuurkeuze op deze laag ligt tussen Apache Kafka en Apache Pulsar. Beide zijn gedistribueerd, fouttolerant en beproefd op de schaal van defensiesystemen. Kafka heeft een groter ecosysteem en nauwere integratie met streamverwerkingsframeworks — zowel Kafka Streams als Apache Flink heeft first-class Kafka-bronconnectors. Pulsar biedt native multi-tenancy, topicisolatie per namespace en een gescheiden computer-opslagarchitectuur. Voor een single-tenant fusieplatform binnen één classificatiedomein is Kafka de pragmatische keuze. Voor een platform dat feeds per classificatieniveau moet isoleren, vooruitgeschoven ontkoppelde nodes moet ondersteunen die asynchroon naar een achtergelegen cluster synchroniseren, of meerdere tenantorganisaties moet bedienen, biedt de architectuur van Pulsar schonere isolatieprimitieven zonder ad-hoc-werkoplossingen.
Ongeacht de keuze van broker moet de topicstructuur één topic per brontype afdwingen, niet één topic per INT-discipline:
Een schema registry is verplicht voor de genormaliseerde uitvoertopics. Zonder afgedwongen schema's kan één onjuist bericht van een willekeurige adapter de deserialisatiecontext van een downstream consumer corrumperen en de hele fusiepijplijn laten vastlopen. Het register dwingt Avro- of Protobuf-schema's af op elke write naar fusietopics en verwerpt berichten die de validatie niet doorstaan voordat ze de broker bereiken. Schema-compatibiliteitsregels — BACKWARD, FORWARD of FULL — moeten per topic worden ingesteld op basis van hoe consumers evolueren. Voor het genormaliseerde observatieschema is BACKWARD-compatibiliteit passend: nieuwe schemaversies kunnen optionele velden toevoegen, en oude consumers die nieuwe velden niet begrijpen, blijven correct functioneren.
Afhandeling van backpressure vereist snelheidslimieten per brontype met prioriteitsclassificatie. Bronnen met hoge prioriteit — SIGINT en IMINT van live-verzamelsystemen — mogen nooit worden begrensd. Bronnen met lage prioriteit — bulkopname van OSINT, historische HUMINT-lading — moeten expliciete prioriteitsgewichten dragen waarmee de broker hun consumers kan afknijpen wanneer de pijplijndoorvoer beperkt is. In Kafka gebeurt dit via consumer-group-quota's en partition-toewijzingsstrategieën. In Pulsar bieden snelheidslimieten en dispatchquota's per namespace equivalente controle. De architectuurpatronen voor de militaire inlichtingen-datapijplijn behandelen wachtrijbeheer en consumer-group-ontwerp in detail.
Entiteitsresolutie en deduplicatie — blocking-strategieën voor het genereren van entiteitskandidaten, ML-gebaseerde gelijkenisscoring, op grafen gebaseerd entiteitensamenvoegen
Entiteitsresolutie is de component die een stroom onafhankelijke observaties — elk met een gedetecteerd object of een gerapporteerde gebeurtenis — omzet in een set uniforme entiteitsrecords waarin alle observaties over hetzelfde object in de echte wereld zijn samengevoegd. Het is de lastigste component om goed te krijgen en de component die het sterkst stil kan degraderen: een systeem met slechte entiteitsresolutie crasht niet; het produceert een beeld met te veel entiteiten (gefragmenteerde sporen) of te weinig (onterechte samenvoegingen), en deze fouten stapelen zich in de tijd op doordat fusie voortbouwt op gecorrumpeerde entiteitstoestand.
De naïeve aanpak — elke binnenkomende observatie vergelijken met elke bestaande entiteit — is op geen enkele realistische schaal computationeel haalbaar. Een ELINT-verzamelsysteem dat 10,000 onderscheppingsrecords per minuut produceert tegen een corpus van 50,000 actieve entiteitssporen zou 500 miljoen vergelijkingen per minuut vergen, voordat er enige gelijkenisscoring plaatsvindt. Blocking-strategieën beperken dit tot een hanteerbare kandidatenset door de structuur van inlichtingengegevens te benutten:
- Geocel-blocking — indexeer elke entiteit op de geschatte locatie met een H3-hexagonaal raster op resolutieniveau 9 (cellen van ongeveer 0,1 km²). Een binnenkomende observatie genereert alleen kandidaatparen tegen entiteiten in dezelfde cel en de zes directe buren. Dit ene blocking-sleutel elimineert meer dan 99,9% van de kandidaatparen voor ruimtelijke gegevens en behaalt tegelijk een hoge recall voor observaties die echt dezelfde locatie delen.
- Temporele blocking — beperk kandidaten tot entiteiten waarvan het geldigheidsinterval overlapt met een configureerbaar venster rond de gebeurtenistijd van de observatie. Voor een bewegend voertuig moet het venster rekening houden met de maximaal aannemelijke snelheid tussen de laatste en de huidige observatielocatie — een tank kan niet 50 km afleggen in 5 minuten. Temporele blocking zonder geocel-blocking levert enorme kandidatensets op voor elke wereldwijd actieve entiteit; de twee werken samen als een samengestelde sleutel.
- Blocking op harde identificatiecodes — groepeer alle records met dezelfde deterministische identifier (IMSI, OCR-uitvoer van een kenteken, biometrische hash, Mode-S-transpondercode van een vliegtuig) in één kandidaatcluster, ongeacht locatie of tijd. Harde identificatiecodes omzeilen alle andere blocking en worden als definitief samenvoegsignaal behandeld, in afwachting van een deduplicatiecontrole op de identifier zelf.
- Blocking op INT-type-affiniteit — bepaalde paren van INT-typen zijn structureel onwaarschijnlijk een match en moeten niet worden gescoord. Een observatie van een maritieme SIGINT-emissie mag niet worden gescoord tegen een IMINT-track van een landvoertuig. Affiniteitsregels, per entiteitstype gedefinieerd, elimineren structureel ongeloofwaardige kandidaatparen vóór de scoring.
Gelijkenisscoring van kandidaatparen gebruikt een gradient-boosting-model (XGBoost of LightGBM), getraind op gelabelde match-/non-match-paren uit historische inlichtingengegevens. De featurevectoren omvatten: ruimtelijke afstand genormaliseerd op positieonzekerheid, temporele afstand genormaliseerd op de snelheidsenvelop van het entiteitstype, attribuutoverlapscore voor getypeerde attributen (entiteitsklasse, affiliatie, uitrustingssoort) en een compatibiliteitsgewicht per INT-type. Het model levert een matchkans in [0, 1]. Paren boven een hoge drempel (doorgaans 0,85–0,92) worden automatisch samengevoegd; paren in een middelste band gaan naar beoordeling door een analist; paren onder een lage drempel worden als aparte entiteiten behandeld.
Op grafen gebaseerd entiteitensamenvoegen behandelt de meerwegsituatie — waarin drie of meer observaties allemaal op dezelfde entiteit moeten worden vastgelegd. Er wordt een graaf bijgehouden waarin knopen observatierecords zijn en randen samenvoegbeslissingen met bijbehorende betrouwbaarheidsscores. Verbonden componenten van de graaf vertegenwoordigen kandidaatentiteitsclusters. De golden record voor elk cluster wordt berekend door het gedefinieerde samenvoegbeleid toe te passen op alle bijdragende observaties. Wanneer een nieuwe rand met hoge betrouwbaarheid twee eerder losse componenten verbindt, worden de componenten samengevoegd en hun golden records gecombineerd. De graafweergave maakt ook splitbewerkingen mogelijk: het verwijderen van een rand met hoge betrouwbaarheid en het opnieuw berekenen van verbonden componenten is het mechanisme om een onterechte samenvoeging te corrigeren.
Ontwerp van de correlatie-engine — op vensters gebaseerde correlatie (temporele nabijheid), ruimtelijke correlatie (geocel-bucketing), semantische correlatie (matching van entiteitsattributen)
Waar entiteitsresolutie de vraag stelt “beschrijven deze observaties hetzelfde object?”, stelt de correlatie-engine de vraag “vormen deze gebeurtenissen met verschillende objecten een betekenisvol patroon?”. Een voertuig dat bij een logistiek depot wordt gedetecteerd, 20 minuten later hetzelfde voertuig bij een brandstofpunt, gevolgd door een SIGINT-onderschepping van een radio-oproep die past bij een eenheidspositierapport vanaf het brandstofpunt — deze drie gebeurtenissen gaan over hetzelfde voertuig, maar beschrijven ook een situationeel patroon (bevoorradingsactiviteit) dat analytisch zwaarder weegt dan welke enkele observatie dan ook. De correlatie-engine produceert dat inlichtingenobject van hogere orde.
Correlatie werkt tegelijk op drie vlakken:
Temporele correlatie groepeert gebeurtenissen in vensters op hun gebeurtenistijdstempel en zoekt naar co-occurrencepatronen binnen elk venster. De vensterdefinitie is per regel configureerbaar: een regel die gelijktijdig beginnende storing en uitval van eigen communicatie detecteert, kan een venster van 30 seconden gebruiken; een regel die een voertuig op een waypoint detecteert, gevolgd door een ander voertuig op hetzelfde waypoint, kan een venster van 2 uur gebruiken. Verschuivende vensters (met de helft van de vensterduur overlappend) zorgen ervoor dat gebeurtenissen op venstergrenzen niet worden gemist. Event-time windowing met watermarks in Apache Flink is de standaard implementatiekeuze, omdat dit out-of-order aankomst van gebeurtenissen correct afhandelt — cruciaal voor een pijplijn waarin IMINT en HUMINT heel verschillende opnamelatenties hebben.
Ruimtelijke correlatie groepeert entiteiten op hun geschatte locatie met geocel-bucketing op een resolutie die is gekalibreerd op de ruimtelijke schaal van de correlatieregel. H3-resolutie 8 (ongeveer 0,7 km²) is passend voor het detecteren van voertuigen die in dezelfde zone actief zijn; H3-resolutie 6 (ongeveer 36 km²) voor het detecteren van activiteitspatronen over een regio. Anders dan geocel-blocking bij entiteitsresolutie (die hoge recall nodig heeft), heeft ruimtelijke bucketing bij correlatie precisie volgens de regel nodig: een correlatieregel die co-locatie van een commandovoertuig met een logistiek voertuig detecteert, moet een dichter celgebruik hebben dan een regel die gebiedsbrede bevoorradingsactiviteit detecteert. Regels coderen hun eigen ruimtelijk resolutieparameter in plaats van die van een globale instelling over te nemen.
Semantische correlatie matcht entiteiten op attribuutwaarden in plaats van op ruimtelijke of temporele nabijheid. Een entiteit die als luchtverdedigingsradar is geclassificeerd en begint uit te zenden, gecorreleerd met een entiteit die als gevechtsvliegtuig is geclassificeerd en de dekkingszone van de radar binnenvliegt — de correlatie wordt gedreven door attribuutsemantiek (radartype versus vliegtuigtype en traject), niet door hun co-locatie. Semantische regels coderen attribuutpredicaten over entiteitstypen: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Deze predicatenuitdrukkingen worden door de streamprocessor geëvalueerd op elke entiteitsupdate; wanneer alle predicaten in een regel binnen het venster afgaan, vuurt de correlatie.
Correlatieregels worden opgeslagen als declaratieve definities in een regelregister, niet als vastgecodeerde logica. Zo kunnen inlichtingenanalisten nieuwe regels schrijven zonder tussenkomst van engineering, en kunnen regelwijzigingen worden doorgevoerd zonder de correlatie-engine opnieuw uit te rollen:
Elke afgevuurde correlatie produceert een Situation-entiteit — een nieuw inlichtingenobject op de JDL Level 2-laag dat verwijst naar de UUID's van de bijdragende entiteiten, het regel-ID en het betrouwbaarheidsgewicht van de regel draagt, en samen met de standaard entiteitsupdates naar de verrijkte entiteitenstroom wordt gepubliceerd.
Betrouwbaarheidsscoring en herkomst — matrix van bronbetrouwbaarheid × informatiecredibiliteit (NAVO-admiraliteitssysteem), propagatie van betrouwbaarheid over gefuseerde entiteiten
Elke entiteit in het gefuseerde beeld draagt een betrouwbaarheidsscore, maar betrouwbaarheid in een multibron-fusesysteem is niet één getal — het is een samengestelde waarde die langs verschillende dimensies moet worden ontleed om analytisch bruikbaar te zijn. Een score van 0,73 die uit drie elkaar bevestigende SIGINT-records is voortgekomen, betekent iets heel anders dan een score van 0,73 uit één onbetrouwbaar HUMINT-rapport en verder niets. De architectuur moet de ontleding bewaren, niet alleen het aggregaat.
Het betrouwbaarheidsmodel legt drie invoeren in lagen. Eerste: gewicht voor bronbetrouwbaarheid, afgeleid van de admiraliteitsgraad voor bronbetrouwbaarheid: A=1.0, B=0.8, C=0.6, D=0.4, E=0.2, F=0.1. Dit gewicht schaalt de bijdrage van elke bronobservatie aan de fusieberekening. Tweede: gewicht voor informatiecredibiliteit, afgeleid van de admiraliteitsgraad voor credibiliteit: 1=1.0, 2=0.8, 3=0.6, 4=0.4, 5=0.2, 6=0.1. Dit gewicht wordt per observatie toegepast, onafhankelijk van de bronbetrouwbaarheid, omdat een betrouwbare bron onzekere informatie kan melden. Derde: overeenstemmingsscore tussen bronnen — het aandeel van de onafhankelijk bevestigende bronnen dat hetzelfde zegt over de kernattribuutwaarde, gewogen met hun bronbetrouwbaarheid. Een positiewaarde die door drie bronnen met waardering A en informatiewaardering B2 wordt bevestigd, scoort heel anders dan een die door twee bronnen met waardering E en informatiewaardering D4 wordt bevestigd.
De samengestelde betrouwbaarheid voor een attribuut is:
Propagatie van betrouwbaarheid over afgeleide entiteiten volgt een verdunningsregel: een Situation-entiteit die de correlatie-engine uit twee golden records van bijdragende entiteiten afleidt, kan geen hogere betrouwbaarheid hebben dan de bijdragende entiteit met de laagste betrouwbaarheid. Betrouwbaarheid kan alleen stijgen wanneer extra onafhankelijke bevestigende observaties aan de bijdragende entiteiten worden toegevoegd. Zo kan de correlatie-engine geen betrouwbaarheid kunstmatig opkrikken door entiteiten van lage kwaliteit aan elkaar te koppelen.
Herkomstketens worden opgeslagen als een keten: elke golden record verwijst naar de observatie-UUID's die eraan hebben bijgedragen; elke observatie verwijst naar haar bron-ID, verzamelsysteem en admiraliteitsgraden. De keten is onveranderlijk — die wordt nooit ter plekke bijgewerkt. Wanneer een bijdragende bron later als onbetrouwbaar of misleidend wordt beoordeeld, levert de keten de volledige set entiteiten die opnieuw moeten worden beoordeeld zonder de bijdragen van die bron. Het intrekken van een bron is een first-class bewerking, geen noodprocedure.
Publicatie van het inlichtingenbeeld — publicatie van verrijkte entiteiten naar C2-systemen via CoT/NIEM, latentiedoelen voor tijdgevoelige inlichtingen
De verrijkte entiteitenstroom is de interne weergave. Publicatie zet die weergave om in de draadformaten die C2-systemen en downstream consumers daadwerkelijk begrijpen. Voor de meeste defensie-inzetten betekent dat Cursor on Target (CoT) voor trackgegevens en op NIEM gebaseerde berichtformaten voor gestructureerde inlichtingenrapporten.
CoT-publicatie koppelt elke update van een verrijkte entiteit aan een CoT-event. De koppeling moet drie updatetypen afhandelen: positie-updates (nieuwe coördinaten met bijgewerkte onzekerheid), attribuut-updates (wijziging van betrouwbaarheid, activiteitstoestand of affiliatiebeoordeling) en levenscyclusgebeurtenissen van entiteiten (aanmaken, uittreden en split-/samenvoeggebeurtenissen). Positie-updates zijn eenvoudig — ze vertalen naar een CoT-pointevent met de geschatte positie van de entiteit en de positiebetrouwbaarheid gecodeerd in het CoT-errorveld. Attribuut-updates vertalen naar CoT-remarks of detail-elementupdates op de bestaande entiteit. Levenscyclusgebeurtenissen — vooral samenvoegen en splitsen — vragen speciale afhandeling: een samenvoeggebeurtenis trekt de CoT-track van de entiteit met de lagere betrouwbaarheid in en werkt de CoT-detail van de overblijvende entiteit bij met herkomstinformatie; een splitgebeurtenis maakt een nieuwe CoT-track aan voor de net afgesplitste entiteit.
Het CoT-veld stale_time is het natuurlijke mechanisme voor TTL-beheer aan de ontvangende C2-zijde. Elk gepubliceerd CoT-event stelt stale_time in op entity_publication_time + entity_TTL. Het ontvangende C2-systeem (ATAK, CURSOR of vergelijkbaar) verwijdert de entiteit uit zijn weergave wanneer stale_time is verstreken zonder vernieuwing. Het fusesysteem moet garanderen dat entiteiten met actieve observaties CoT-vernieuwings-events krijgen met een interval korter dan hun TTL — doorgaans op 50% van TTL — zodat geldige entiteiten tijdens normaal bedrijf niet uit het beeld verdwijnen.
Latentiedoelen bepalen hoe de publicatielaag moet worden geïmplementeerd. Voor tijdgevoelige targetingworkflows moet de end-to-end latentie van sensorgebeurtenis tot C2-weergave onder de 30 seconden blijven. Dit vereist: asynchrone, niet-blokkerende publicatieworkers; parallelle CoT-serialisatie over entitiepartities; geprioriteerde uitvoerwachtrijen die voorrang geven aan sporen met hoge betrouwbaarheid boven updates van statische entiteiten; en directe TCP-multicastbezorging naar C2-ontvangers in plaats van REST-API-polling. Voor algemeen situationeel bewustzijn op operationeel niveau is een latentie van 60–120 seconden doorgaans aanvaardbaar, wat eenvoudigere synchrone batchpublicatiepatronen mogelijk maakt.
NIEM-publicatie bedient consumers van inlichtingenrapporten — systemen die gestructureerde, machineleesbare inlichtingenbeoordelingen nodig hebben in plaats van trackgegevens. Een Situation-entiteit uit de correlatie-engine wordt gepubliceerd als een NIEM Intelligence Message met de UUID's van de bijdragende entiteiten als verwijzingen, de situation-klasse als onderwerp, en de betrouwbaarheids- en herkomstgegevens in het NIEM-metadatablok. NIEM-consumers omvatten multidomeinplatforms voor inlichtingendeling, interoperabiliteitsgateways naar systemen van partnerlanden en archiefsystemen die gestructureerde herkomst nodig hebben voor auditcompliance.
Omgaan met temporele onzekerheid en verouderde inlichtingen — TTL-beheer voor inlichtingenentiteiten, vervalcurves voor positie-/activiteitsbetrouwbaarheid, herbeoordelingstriggers
Inlichtingen zijn bederfelijk. Een positierapport voor een voertuigspoor dat 20 minuten geleden accuraat was, is dat nu niet meer — het voertuig kan zijn verplaatst. Een activiteitsbeoordeling op basis van één SIGINT-onderschepping 4 uur geleden weerspiegelt mogelijk niet langer het huidige gedrag. Een fusesysteem dat deze achteruitgang niet modelleert en niet doorgeeft aan het gepubliceerde beeld, zorgt ervoor dat analisten beslissingen nemen op basis van verouderde informatie met hoge betrouwbaarheidsscores die door oudere observaties zijn verdiend.
TTL-beheer begint met TTL-toewijzing bij het aanmaken van de entiteit. TTL-waarden zijn specifiek per entiteitstype en betrouwbaarheidsklasse:
- Spoor van een bewegend voertuig met hoge betrouwbaarheid (betrouwbaarheid ≥ 0,80, mobiliteitsklasse = WHEELED/TRACKED): TTL 8–15 minuten
- Bewegend spoor met gemiddelde betrouwbaarheid (betrouwbaarheid 0,50–0,79): TTL 4–8 minuten
- Voorlopig spoor met lage betrouwbaarheid (betrouwbaarheid < 0,50): TTL 2–4 minuten
- Vaste faciliteit met hoge betrouwbaarheid (betrouwbaarheid ≥ 0,80, mobiliteitsklasse = STATIC): TTL 24–72 uur
- Personeelsentiteit (op activiteit, niet op positie): TTL 30–120 minuten, afhankelijk van het laatste activiteitstype
- Situation-entiteit (afgeleide correlatie): TTL gelijk aan de kortste TTL van een willekeurige bijdragende entiteit, met een maximum van 60 minuten
Vervalcurves voor betrouwbaarheid modelleren hoe de positie- en activiteitsbetrouwbaarheid achteruitgaan tussen bevestigende observaties. In plaats van een binaire actief/verouderd-toestand levert de vervalcurve een continue betrouwbaarheidsfunctie over de tijd sinds de laatste observatie:
Herbeoordelingstriggers vuren wanneer een nieuwe observatie binnenkomt die ruimtelijk en temporeel consistent is met een verouderde entiteit. In plaats van voor de nieuwe observatie een nieuwe entiteit aan te maken, leidt de trigger die door de entiteitsresolutiepipeline met de verouderde entiteit als kandidaat. Als de matchbetrouwbaarheid de samenvoegdrempel overschrijdt, vernieuwt de nieuwe observatie de verouderde entiteit: de TTL-klok wordt gereset, de betrouwbaarheid wordt opnieuw berekend uit de nieuwe observatie (mogelijk omhoog vanuit de verwaarloosde waarde, als de nieuwe observatie sterke betrouwbaarheid heeft), en de entiteit gaat van STALE terug naar ACTIVE-status. De vernieuwing wordt als update-event vastgelegd in de audittrail van de entiteit.
Het vervalmodel moet ook aan C2-consumers worden gecommuniceerd, niet alleen intern worden toegepast. Een positie met hoge betrouwbaarheid naar CoT publiceren zonder te signaleren dat die positie 18 minuten oud is, zorgt ervoor dat het C2-beeld een scherp, betrouwbaar spooricoon toont dat de analist als realtime observatie kan interpreteren. Twee mechanismen pakken dit aan: het CoT-veld stale_time (al besproken) zorgt ervoor dat de entiteit uit het beeld verdwijnt wanneer die definitief verouderd is; en een veld met de leeftijd sinds de laatste observatie, gepubliceerd in het CoT-detailelement, geeft de analist realtime inzicht in hoe oud de onderliggende observatie is, zelfs voor entiteiten die hun stale-tijd nog niet hebben bereikt. Sommige C2-systemen gebruiken dit veld om de visuele betrouwbaarheidsweergave te moduleren — de dekking of grootte van het spooricoon te laten variëren met de leeftijd van de observatie.
Samen vormen de zeven architectuurcomponenten die in dit artikel worden beschreven — heterogene stream-ingestie, schema-afgedwongen normalisatie, blocking-plus-ML entiteitsresolutie, correlatie-engine over meerdere vlakken, gelaagde betrouwbaarheidsscoring, CoT-/NIEM-publicatie en TTL-vervalbeheer — een volledig realtime multibron-inlichtingenfusieplatform. Geen van deze componenten is op zichzelf nieuw. Wat de architectuur productieklaar maakt, is het expliciete ontwerp van de interfaces ertussen: het canonieke observatieschema dat normalisatie produceert en entiteitsresolutie verbruikt; het entiteitsgraafformaat dat entiteitsresolutie produceert en de correlatie-engine verbruikt; de verrijkte entiteitenstroom waarop zowel entiteitsresolutie als de correlatie-engine schrijven en die de publicatielaag leest. Een systeem waarin deze interfaces impliciet of ongedocumenteerd zijn — waarin elke component specifiek gedrag van zijn upstream veronderstelt — is fragiel precies op de punten waar inlichtingengegevens het meest wisselend van aard zijn.