Proiectarea modelului unificat de date multi-INT pentru platforme de intelligence militar

Orice platformă serioasă de intelligence militar se confruntă în cele din urmă cu aceeași problemă structurală: cinci sau mai multe discipline de intelligence produc date în formate proprii, la viteze proprii, cu semantici proprii — iar analiștii au nevoie de o imagine unificată care să raționeze simultan asupra tuturor. Ghidul complet pentru fuziunea datelor de apărare acoperă pipeline-ul de procesare în linii mari. Acest articol merge mai adânc la nivelul schemei — modelul canonic de date care stă sub motorul de fuziune și îi oferă ceva coerent cu care să lucreze.

Proiectarea corectă a modelului de date nu este un detaliu. O schemă prost proiectată forțează logica specifică disciplinei în stratul de aplicație, face interogările cross-sursă fragile și transformă migrațiile de schemă în înghețări ale platformei de mai multe săptămâni. Un model bine proiectat absoarbe tipuri noi de INT, suportă interogări bi-temporale și păstrează proveniența intactă prin fiecare etapă a fuziunii. Acest articol acoperă toate deciziile care determină în care categorie se încadrează platforma dumneavoastră.

De ce fiecare INT necesită o adaptare diferită a schemei

Cele cinci discipline principale de intelligence diferă nu doar prin ceea ce colectează, ci și prin modul în care sunt structurate datele, la ce viteză ajung și ce metadate sunt disponibile în mod inerent. Aceste diferențe nu sunt superficiale. Ele determină ce logică de adaptare este necesară înainte ca orice model unificat să poată ingera o sursă și constrâng ce interogări cross-INT sunt fezabile.

HUMINT (human intelligence — intelligence uman) este în principal textual. Un raport HUMINT este un document narativ care descrie ce a observat, auzit sau i s-a spus unei surse. Marcajele temporale sunt adesea imprecise — raportul poate descrie un eveniment petrecut pe parcursul mai multor zile, cu incertitudine atât în timp, cât și în locație. Cel mai important metadat este evaluarea sursei: cât de fiabilă este această sursă particulară și cât de credibilă este această informație specifică? Volumul datelor HUMINT este redus — zeci până la sute de rapoarte pe zi la un punct de colectare activ, nu mii pe secundă.

SIGINT (signals intelligence — intelligence de semnale) — acoperind atât COMINT (comunicații) cât și ELINT (intelligence electronic) — are volum ridicat, este foarte structurat și marcat temporal la precizie de milisecunde. O interceptare SIGINT sau o detecție de emițător conține parametrii de frecvență, unghiuri de azimut, fixuri de diferență de timp de sosire și caracteristici de modulație. Conținutul semantic (ce s-a spus) este adesea clasificat separat față de parametrii semnalului. Volumul datelor SIGINT poate ajunge la milioane de înregistrări pe oră pentru un sistem modern de colectare care acoperă un mediu electromagnetic contestat.

IMINT (imagery intelligence — intelligence imagistică) produce înregistrări de observație structurate derivate din analiza imaginilor: casete de delimitare cu etichete de clasă de entitate și scoruri de încredere, coordonate de geolocalizare, rezoluție la sol și marcaj temporal de colectare. O singură trecere de satelit sau un zbor de drona poate genera mii de înregistrări de detecție a obiectelor. Provocarea este că detecțiile IMINT sunt instantanee spațiale — vă spun unde era ceva la un moment specific, nu unde se îndreaptă.

OSINT (open-source intelligence — intelligence din surse deschise) este structural cel mai heterogen. Include postări pe rețele sociale, articole de știri, analize de imagini satelitare comerciale, date de urmărire a zborurilor și fluxuri AIS maritime. Fiecare tip de sursă are propria schemă. OSINT este, de asemenea, cel mai puțin controlat — calitatea surselor variază de la publicații guvernamentale autorizate la afirmații anonime neverificate pe rețele sociale.

MASINT (measurement and signature intelligence — intelligence prin măsurare și semnătură) acoperă măsurarea fenomenelor fizice: seismic, acustic, radiație nucleară, semnături chimice/biologice și profiluri de secțiune transversală radar. Observațiile MASINT sunt adesea indirecte — detectează un fenomen (explozie, mișcare a vehiculului, emisie RF) mai degrabă decât identifică direct o entitate. Lanțul de la observația MASINT la identificarea entității necesită pași de inferență expliciti care trebuie modelați în schemă.

Implicația pentru un model unificat este că schema trebuie să acomodeze această diversitate fără a o comprima. Răspunsul este un plic de bază tipizat cu sarcini utile de extensie specifice disciplinei — un șablon de proiectare acoperit în detaliu în seria construirea pipeline-ului de fuziune pentru apărare, partea 1.

Tipuri canonice de entități pentru un model unificat

Punctul de plecare al proiectării schemei este definirea taxonomiei tipurilor de entități — lista exhaustivă a lucrurilor din lumea reală pe care platforma trebuie să le urmărească și să le analizeze. Pentru majoritatea platformelor de intelligence militar, șase tipuri de entități acoperă marea majoritate a obiectelor de intelligence:

• Persoană — subiecți umani individuali: combatanți, comandanți, facilitatori, civili de interes
• Organizație — grupuri, unități, rețele, structuri de comandă
• Locație — situri geografice fixe: facilități, infrastructură, repere, zone de interes denumite
• Echipament — vehicule, sisteme de arme, senzori, dispozitive de comunicații
• Eveniment — ocurențe discrete: angajamente, explozii, întâlniri, transmisii
• Document — materiale capturate, publicații, rapoarte de intelligence ca obiecte de analiză

Fiecare tip de entitate are un set de câmpuri de bază care este agnostic față de INT — câmpuri care trebuie populate indiferent de disciplina de intelligence care a contribuit la informație:

EntityCore {
  entity_id:       UUID           // unic global, imuabil
  entity_type:     Enum           // Person | Organization | Location |
                                  // Equipment | Event | Document
  classification:  ClassMarkings  // a se vedea secțiunea proveniență
  valid_time:      TimeInterval   // [start, end) când faptul era adevărat
  transaction_time:TimeInterval   // [start, end) când rândul era curent
  confidence:      Float[0..1]    // încredere fuzionată dintre surse
  source_obs_ids:  UUID[]         // ID-urile înregistrărilor de observație
  schema_version:  SemVer         // pentru compatibilitate la evoluție
  created_at:      Timestamp
  updated_at:      Timestamp
}

Dincolo de bază, fiecare tip de entitate are extensii de atribute tipizate. O entitate Persoană conține identificatori biometrici, aliasuri, naționalitate și legături la organizații asociate. O entitate Echipament conține tipul de platformă, identificatori de serie dacă sunt cunoscuți și legătura cu unitatea asociată. O entitate Eveniment conține clasa evenimentului, referințele la entitățile implicate și amprenta spațială. Aceste extensii sunt stocate ca sarcini utile tipizate atașate la plicul de bază — nu ca coloane pe tabelul de bază. Această separare permite schemei să absoarbă atribute noi pentru un tip de entitate fără a-l afecta pe celelalte.

Același principiu de separare se aplică contribuțiilor INT. Când o interceptare SIGINT se leagă de o entitate Persoană (deoarece un IMSI a fost rezolvat la un individ cunoscut), acea legătură este stocată ca o înregistrare de observație cu o sarcină utilă tipizată SIGINT care indică UUID-ul entității Persoană. Entitatea Persoană în sine nu conține coloane specifice SIGINT — acea cuplare ar face schema fragilă față de orice modificare a colectării SIGINT.

Proveniența și urmărirea surselor

Proveniența este cerința non-funcțională cea mai critică a oricărui model de date de intelligence. Fiecare informație din imaginea fuzionată trebuie să fie trasabilă înapoi la observația sa sursă, la sistemul de colectare care a produs-o și la evaluările umane aplicate fiabilității sale. Fără acest lanț, analiștii nu pot evalua calitatea imaginii cu care lucrează, iar platforma nu poate efectua o revenire la starea anterioară când se descoperă că o sursă este nesigură.

Un bloc de proveniență atașat la fiecare înregistrare de observație ar trebui să conțină cel puțin:

ProvenanceBlock {
  int_type:            Enum     // HUMINT | SIGINT | IMINT | OSINT | MASINT
  source_id:           UUID     // referință internă la registrul surselor
  source_reliability:  Char     // A–F (scala de admiralitate NATO)
  info_credibility:    Integer  // 1–6 (scala de admiralitate NATO)
  collection_time:     Timestamp
  report_time:         Timestamp  // când a intrat raportul în sistem
  originator:          String     // unitatea sau sistemul care a produs raportul
  classification:      ClassMarkings
  handling_caveats:    String[]   // NOFORN, ORCON, REL TO, etc.
  dissemination_ctrl:  String[]
}

Scala de admiralitate NATO codifică două evaluări umane independente pentru fiecare informație de intelligence. Fiabilitatea sursei (A până la F) evaluează istoricul și credibilitatea sursei — o sursă cu nota A a fost în mod constant exactă și fiabilă; o sursă cu nota F are un istoric necunoscut sau slab. Credibilitatea informației (1 până la 6) evaluează plauzibilitatea informației specifice independent de istoricul sursei — un element cu nota 1 este confirmat de alte surse independente; un element cu nota 6 este improbabil față de ceea ce se știe altfel.

Aceste două note sunt evaluări umane făcute de ofițeri de intelligence instruiți. Ele sunt distincte față de, și nu trebuie confundate cu, scorul de încredere al fuziunii calculat de mașină pentru entitate. Încrederea în fuziune reflectă acordul statistic între sursele coroborante; notele de admiralitate reflectă judecata umană privind calitatea sursei. Ambele trebuie păstrate și prezentate analiștilor separat.

Marcajele de clasificare necesită reprezentare structurată, nu text liber. Un tip ClassMarkings trebuie să codifice: nivelul de clasificare (DE LA NECLASIFICAT LA TOP SECRET), compartimentele și cuvintele-cod și avertismentele de gestionare ca o listă enumerată. Structura permite aplicarea programatică a controlului accesului — platforma poate evalua la momentul interogării dacă autorizarea unui utilizator dat satisface clasificarea fiecărui câmp și poate selectiv să redacteze sau să rețină câmpurile care depășesc autorizarea utilizatorului, mai degrabă decât să refuze să returneze întreaga entitate.

Rezoluția entităților cross-INT

Rezoluția entităților — determinarea că înregistrările din surse diferite se referă la aceeași entitate din lumea reală — este problema centrală a fuziunii și este cea mai dificilă tocmai la granița cross-INT. În cadrul unui singur INT, schemele de identificare sunt coerente: două înregistrări SIGINT care partajează un IMSI se referă la același dispozitiv. Între INTs, nu există niciun identificator partajat implicit. O detecție IMINT a unui vehicul, un fix de azimut SIGINT pe un emițător colalizat cu acel vehicul și un raport HUMINT care numește o persoană văzută în acel vehicul trebuie legate prin inferență probabilistică, nu printr-o cheie partajată.

Pipeline-ul de rezoluție a entităților pentru un model unificat trebuie să gestioneze trei scenarii de legătură:

Legături tari — identificatori partajați care leagă definitiv înregistrările la aceeași entitate. Un IMSI cunoscut, o placă de înmatriculare citită de două treceri IMINT, o potrivire biometrică. Legăturile tari ar trebui propagate automat fără deteriorarea încrederii.

Legături slabe — asocieri probabilistice bazate pe similaritatea atributelor în limitele de incertitudine. Două observații care raportează un vehicul din aceeași clasă în locații suprapuse într-o fereastră temporală compatibilă cu deplasarea între ele. Legăturile slabe poartă un scor de încredere a potrivirii calculat de motorul de rezoluție.

Legături deduse — asocieri derivate din cunoștințe de domeniu: dacă un azimut de emițător SIGINT se mișcă în mod constant împreună cu o pistă de vehicul IMINT, este probabil vorba de aceeași platformă. Aceste legături necesită definiții explicite de reguli și au o încredere mai mică decât legăturile slabe bazate pe suprapunerea directă a atributelor.

Pipeline-ul de rezoluție produce ipoteze de potrivire. Ipotezele de peste un prag de înaltă încredere sunt fuzionate automat în înregistrarea de aur. Ipotezele din intervalul mediu sunt marcate pentru revizuire de către analist. Ipotezele sub pragul scăzut sunt păstrate ca entități separate. Valorile pragului sunt configurabile și ar trebui să fie reglabile pe tip de entitate — fuziunile de entități Persoană justifică praguri de încredere mai ridicate decât fuziunile de Echipament, deoarece fuziunile false de persoane produc consecințe analitice mai grave decât fuziunile false de echipamente.

Gestionarea înregistrărilor de aur necesită o politică de fuzionare definită pentru conflictele de atribute. Când două surse nu sunt de acord asupra unui atribut — un raport HUMINT spune că o persoană se afla la locația A, o detecție IMINT o plasează la locația B la o oră mai târziu — politica de fuzionare trebuie să specifice cum să reconcilieze atributul în înregistrarea de aur. Politicile comune includ: cel mai recent timp valid câștigă, cea mai mare fiabilitate a sursei câștigă, combinație ponderată pentru atributele numerice. Politica aleasă trebuie stocată pe înregistrarea de aur ca metadate, astfel încât analiștii să poată înțelege de ce înregistrarea de aur prezintă o anumită valoare de atribut.

Modelul de fuziune a datelor JDL formulează rezoluția entităților ca o problemă de Nivel 1 (rafinarea obiectelor) și Nivel 2 (rafinarea situației). Proiectarea schemei descrisă aici este cea care face nivelurile JDL implementabile în practică.

Modelare temporală: timp valid vs timp de tranzacție

Modelarea bi-temporală nu este opțională pentru o platformă de intelligence militar. Este structura temporală minimă necesară pentru a susține cele două tipuri de interogare cele mai critice: „ce era adevărat în lume la momentul T?" (interogare de timp valid) și „ce știa sistemul despre X la momentul T?" (interogare de timp de tranzacție). Acestea sunt întrebări diferite care necesită răspunsuri diferite, iar o schemă care le confundă — folosind un singur marcaj temporal pe înregistrare — nu poate răspunde corect la niciuna.

Timpul valid reprezintă când un fapt era adevărat în lumea reală. Pentru o detecție IMINT a unui vehicul la o coordonată de grilă, timpul valid este marcajul temporal al imaginii. Pentru un raport HUMINT care descrie o întâlnire, timpul valid este estimarea cea mai bună a analistului privind momentul în care a avut loc întâlnirea — care poate fi un interval de zile, nu un marcaj temporal precis. Timpul valid este o proprietate a lumii, nu a bazei de date.

Timpul de tranzacție reprezintă când o înregistrare era curentă în baza de date. Pentru aceeași detecție IMINT, timpul de tranzacție începe când înregistrarea de detecție a fost inserată și se termină dacă înregistrarea este vreodată înlocuită (de exemplu, dacă geolocalizarea este reprocesată și corectată). Timpul de tranzacție este o proprietate a bazei de date, gestionată automat de sistem.

Combinația permite două operații critice. Prima, interogări as-of: „reconstruiește imaginea completă de intelligence așa cum o deținea sistemul la 14:00 în ziua D." Aceasta necesită interogarea în timp de tranzacție — returnând numai înregistrările care erau curente în baza de date la 14:00 în ziua D, indiferent de momentul în care cade timpul lor valid. Este esențial pentru analiza post-incident și pentru auditul deciziilor bazate pe intelligence. A doua, interogări de fapte istorice: „ce evenimente au avut loc la locația X între ziua D-7 și ziua D?" Aceasta interogează în timp valid — returnând înregistrările al căror interval de timp valid se suprapune cu fereastra de interogare, indiferent de momentul în care au fost inserate.

Implementarea în PostgreSQL folosește coloane de perioadă. Dimensiunea de timp valid este reprezentată ca o coloană tstzrange (interval de marcaj temporal conștient de fus orar). Dimensiunea de timp de tranzacție folosește fie un tabel temporal de perioadă de sistem (suportat nativ în unele extensii PostgreSQL) fie o pereche explicită de coloane transaction_start și transaction_end, cu transaction_end setat la infinit pentru rândurile curente și marcat la actualizare pentru a indica momentul în care rândul a fost înlocuit. Toate actualizările trebuie implementate ca operații de inserare-rând-nou / marcare-rând-vechi, niciodată ca suprascrieri în loc.

Controlul versiunilor și trasabilitatea obiectelor fuzionate

Entitățile de intelligence nu sunt statice. O entitate Persoană poate începe ca o identificare tentativă dintr-un singur raport HUMINT, să obțină confirmare spațială dintr-o detecție IMINT trei zile mai târziu și să primească o confirmare biometrică dintr-un eveniment de colectare separat o săptămână după aceea. Fiecare dintre aceste actualizări modifică înregistrarea de aur — dar stările anterioare trebuie să fie recuperabile, nu suprascrise.

Implementarea standard este un jurnal de evenimente append-only per entitate. Fiecare modificare de stare a unei înregistrări de aur generează un eveniment de actualizare. Fiecare eveniment este imuabil odată scris și conține:

• UUID-ul entității
• Tipul evenimentului (Creat / Actualizat / Fuzionat / Divizat / Retras)
• Instantaneul stării anterioare (copie completă a înregistrării de aur înainte de modificare)
• Instantaneul noii stări
• ID-urile înregistrărilor de observație care au declanșat actualizarea
• Numele și versiunea politicii de fuzionare aplicate
• Marcajul temporal al tranzacției
• ID-ul operatorului (analist uman sau proces de sistem)

Înregistrarea de aur curentă este rezultatul aplicării tuturor evenimentelor în secvență de la începutul jurnalului. Acesta este șablonul de event-sourcing aplicat datelor de intelligence. Oferă o pistă de audit completă pentru fiecare stare a entității la fiecare moment în timp, care este necesară pentru responsabilitatea intelligence-ului în majoritatea cadrelor militare.

Revenirea la starea anterioară este o operație de primă clasă: dat un UUID de entitate și un marcaj temporal de tranzacție țintă, platforma re-materializează înregistrarea de aur așa cum exista la acel marcaj temporal prin redarea jurnalului de evenimente până la, dar neincluderea evenimentelor de după momentul țintă. Revenirea este declanșată când o sursă este evaluată ca înșelătoare sau eronată — toate înregistrările de aur care au încorporat observații din acea sursă trebuie re-evaluate cu observațiile contaminate excluse.

Un eveniment de retragere este mecanismul de gestionare a acestui scenariu la scară. Când sursa S este invalidată, sistemul generează un eveniment de retragere pentru fiecare observație atribuită lui S, apoi rulează din nou fuzionarea pentru fiecare entitate care a referit oricare dintre acele observații. Entitățile care au fost susținute exclusiv de sursa retrasă revin la o stare de încredere mai scăzută sau sunt marcate neconfirmate. Entitățile care aveau surse coroborante din alte INTs absorb retragerea cu o penalitate de încredere, dar rămân în imagine.

Modelul de trasabilitate permite, de asemenea, evenimente de divizare — inversul rezoluției entităților. Dacă două entități au fost fuzionate incorect (o fuziune fals pozitivă), un eveniment de divizare le separă: înregistrarea de aur eronată este retrasă și sunt create două înregistrări de entitate noi, fiecare moștenind observațiile sursă care îi aparțin în mod corespunzător. Evenimentul de divizare păstrează istoricul complet al stării fuzionate și al deciziei de divizare, permițând analiștilor ulteriori să înțeleagă de ce a avut loc divizarea.

Evoluția schemei în producție

O platformă de intelligence militar nu este un produs static. Apar noi sisteme de colectare, noi discipline INT sunt adăugate în scopul de acoperire și schemele existente necesită adăugiri de atribute pe măsură ce apar noi cerințe analitice. Evoluția schemei pe o platformă de producție care nu poate tolera indisponibilitate necesită decizii deliberate de proiectare încă de la început.

Principiul de bază este compatibilitatea inversă ca un contract. Plicul de bază al entității — câmpurile EntityCore — trebuie versionat strict folosind un câmp schema_version. Orice modificare a plicului de bază care elimină un câmp sau schimbă tipul unui câmp este o modificare majoră și necesită o incrementare a versiunii majore cu o cale de migrare definită. Adăugarea de câmpuri opționale la bază este o modificare minoră de versiune. Câmpul de versiune permite consumatorilor să declare ce versiuni de schemă suportă și permite platformei să servească versiuni diferite unor consumatori diferiți în timpul unei perioade de migrare.

Sarcinile utile de extensie sunt vehiculul corect pentru adăugarea de noi tipuri INT sau de noi atribute. Când un nou sistem de analiză imagistică intră online și produce tipuri de atribute suplimentare (de exemplu, scoruri de evaluare a daunelor structurale derivate din imagini SAR), acele atribute intră într-o versiune nouă sau actualizată a sarcinii utile de extensie IMINT — nu în schema de bază a entității. Consumatorii existenți care nu au nevoie de atributele specifice SAR nu sunt afectați.

Taxonomia provenienței trebuie extinsă când se adaugă un nou tip INT. Enumerarea tipului INT câștigă o nouă valoare și definițiile scalei de fiabilitate și credibilitate a sursei trebuie revizuite pentru aplicabilitate la noul tip de sursă. Unele tipuri noi de sursă pot necesita criterii noi de credibilitate care nu se mapează curat pe scala existentă de șase puncte de admiralitate — în acele cazuri, blocul de proveniență ar trebui să conțină metadatele brute de fiabilitate specifice sursei în plus față de nota de admiralitate tradusă, păstrând fidelitatea.

Regulile de rezoluție a entităților sunt calea de evoluție cea mai intensivă din punct de vedere al muncii. Când un nou tip INT se alătură modelului unificat, inginerii de rezoluție trebuie să specifice cum observațiile din noua sursă pot fi legate la tipurile de entitate existente. Aceasta necesită atât analiză de date (ce atribute sunt disponibile pentru potrivire?) cât și cunoștințe de domeniu (ce praguri de proximitate a atributelor sunt semnificative din punct de vedere operațional?). Aceste reguli trebuie revizuite colegial de analiști de intelligence cu experiență, nu doar de ingineri software — regulile de rezoluție incorecte produc fuziuni false care corup silencios imaginea de intelligence.

Migrarea schemei într-un model bi-temporal are o considerație suplimentară: rândurile istorice trebuie migrate fără a le modifica istoricul de timp de tranzacție. O migrare care rescrie rândurile existente și le actualizează marcajele temporale de tranzacție sparge semantica interogărilor istorice. Migrările trebuie să fie aditive: adăugați coloane noi cu valori implicite pentru rândurile istorice, nu actualizați niciodată valorile coloanelor existente în înregistrările istorice.

Testarea evoluției schemei necesită o strategie pe mai multe niveluri: teste unitare pentru serializarea și deserializarea fiecărei versiuni de schemă; teste de integrare pentru compatibilitatea consumatorilor între versiuni; și teste de regresie folosind eșantioane de date de intelligence istorice pentru a confirma că interogările existente returnează rezultate identice după o migrare. Testele cu date istorice sunt cele mai frecvent omise și cele care detectează cele mai multe regresii care rup producția.

Modelul de date descris în acest articol reprezintă un țel de proiectare, nu un punct de plecare pentru o implementare dintr-un singur sprint. Majoritatea platformelor construiesc spre această arhitectură incremental — începând cu o schemă mai simplă pentru două sau trei tipuri INT și adăugând modelul bi-temporal, blocuri complete de proveniență și trasabilitate prin event-sourcing pe măsură ce cerințele operaționale se consolidează. Ceea ce contează este că deciziile de proiectare de bază — sarcini utile de extensie tipizate, plice de entitate agnostice față de INT, timp valid și timp de tranzacție separate — sunt luate devreme, deoarece retrofitarea lor pe o schemă monolitică este mult mai costisitoare decât construirea lor de la început.