Grafy wiedzy dla wywiadu wojskowego: rozróżnianie encji i analiza linków

Wywiad wojskowy zawsze dotyczył powiązań: który dowódca kontroluje którą jednostkę, który finansista wspiera którą komórkę, który węzeł infrastruktury umożliwia które łańcuchy logistyczne. To są problemy grafowe. Dane, które na nie odpowiadają — przechwycone komunikaty, raporty agentów, metadane zdjęć satelitarnych, otwarte rejestry — napływają z dziesiątek oddzielnych systemów zbierania danych, z których każdy inaczej nazywa tę samą encję ze świata rzeczywistego i przechowuje relacje w niekompatybilnych formatach. Grafy wiedzy zapewniają warstwę strukturalną, która łączy te fragmenty w spójny, konfigurowalny obraz. Niniejszy artykuł analizuje, jak bazy grafowe i grafy wiedzy są stosowane w procesach wywiadu wojskowego — od podstawowych niedoskonałości podejść relacyjnych, przez projektowanie ontologii zgodne z PMESII, rozróżnianie encji ze źródeł multi-INT, reprezentację obiektów STIX, dobór bazy grafowej dla środowisk tajnych, wzorce zapytań Cypher do analizy linków, aż po integrację z potokami C2 i OSINT.

Dlaczego relacyjne bazy danych zawodzą w analizie linków wywiadu

Kanoniczne pytanie wywiadu nie brzmi: „znajdź wszystkie rekordy, gdzie kolumna X równa się wartości Y". Brzmi: „zaczynając od tej encji, przeglądaj jej sieć do głębokości pięciu poziomów, filtrując według typu relacji i poziomu ufności, i powiedz mi, do jakich społeczności należą te encje". Relacyjne bazy danych dobrze odpowiadają na pierwsze pytanie. Na drugie odpowiadają przez łączenie operacji JOIN, których koszt obliczeniowy rośnie wykładniczo z każdym kolejnym krokiem.

Dwukrokowe JOIN dla tabeli z dziesięcioma milionami rekordów encji jest zazwyczaj wykonalne — może kilka sekund przy dobrych indeksach. Pięciokrokowe złączenie zwrotne tej samej tabeli wymaga czterech kolejnych operacji JOIN, z których każda mnoży zestaw roboczy przez średni współczynnik rozgałęzienia. Przy realistycznych danych wywiadowych — gdzie węzeł osoby może mieć pięćdziesiąt kontaktów komunikacyjnych, z których każdy ma własne pięćdziesiąt — pośredni zestaw wynikowy na głębokości pięciu może przekroczyć pamięć dowolnego serwera jeszcze przed zastosowaniem filtrowania. Optymalizator zapytań nie może tego uniknąć, ponieważ relacja sama w sobie nie istnieje w bazie danych jako przechowywany obiekt: jest rekomputowana przez dopasowanie kolumn kluczowych w czasie zapytania. Każdy krok to pełna rekomputacja.

Problem ujednoznaczniania encji dodatkowo to komplikuje. Osoba pojawia się w przechwyceniu SIGINT jako „Ahmed M.", w raporcie HUMINT jako „Ahmad Mansour", a w rejestrze finansowym jako „A. Mansouri". W schemacie relacyjnym są to trzy oddzielne wiersze w trzech oddzielnych tabelach, chyba że analityk (lub potok deduplikacji) jawnie je połączył. Bez tego powiązania JOIN zaczynające się od rekordu SIGINT nigdy nie przejdzie do rekordu finansowego, a sieć widziana przez analityka jest systematycznie niekompletna. Relacyjne bazy danych nie mają natywnego mechanizmu wyrażania „te dwa wiersze prawdopodobnie dotyczą tej samej encji, z ufnością 0,85." To prawdopodobieństwo musi żyć poza schematem, w logice aplikacji, która zazwyczaj jest ręczna i rzadko spójna.

Eksplozja JOIN i problem ujednoznaczniania encji wyjaśniają razem, dlaczego analiza linków w tradycyjnych systemach wywiadu obronnego — zbudowanych na relacyjnych bazach danych — wymagała dedykowanej pracy analityków, którą baza grafowa do analizy wywiadowczej może zautomatyzować. Graf przechowuje relacje jako natywne krawędzie z bezpośrednimi wskaźnikami między węzłami, więc koszt przeszukiwania rośnie proporcjonalnie do rozmiaru lokalnego sąsiedztwa, a nie do globalnego rozmiaru tabeli. Rozróżnianie encji jest pierwszoklasowe: operacja scalania sprowadza wiele rekordów do jednego kanonicznego węzła, a wszystkie krawędzie odwołujące się do któregokolwiek z rekordów teraz odwołują się do węzła kanonicznego. Graf jest modelem danych zaprojektowanym dla tej dziedziny problemów.

Podstawy grafów wiedzy dla zastosowań wojskowych

Graf wiedzy rozszerza graf własności o wspólne słownictwo — ontologię — która nadaje każdemu typowi węzła i krawędzi zdefiniowane, uzgodnione znaczenie. To wspólne słownictwo sprawia, że zapytania są kompozytywne między źródłami: dwa oddzielne potoki pozyskiwania, które oba używają etykiety węzła MilitaryUnit i typu krawędzi SUBORDINATE_TO, produkują grafy, po których można łącznie przeszukiwać. Bez ontologii każdy potok wymyśla własne nazwy, a graf gromadzi dziesięć synonimicznych etykiet dla tego samego pojęcia.

Dla wywiadu wojskowego framework PMESII zapewnia naturalny szkielet ontologiczny. Każdy z sześciu wymiarów — Polityczny, Wojskowy, Ekonomiczny, Społeczny, Infrastrukturalny, Informacyjny — staje się rodziną etykiet węzłów:

Wymiar PMESII	Etykiety węzłów	Kluczowe typy krawędzi
Polityczny	Government, Official, PoliticalParty, Faction	CONTROLS, ALLIED_WITH, OPPOSES
Wojskowy	Unit, Commander, WeaponsSystem, Base	COMMANDS, SUBORDINATE_TO, EQUIPPED_WITH, DEPLOYS_AT
Ekonomiczny	Organization, FinancialAccount, SupplyChain, Commodity	FINANCES, TRANSACTS_WITH, SUPPLIES
Społeczny	Person, Group, Community	MEMBER_OF, COMMUNICATES_WITH, RECRUITS
Infrastrukturalny	Facility, TransportLink, PowerGrid, NetworkNode	CONNECTS, DEPENDS_ON, OPERATED_BY
Informacyjny	MediaChannel, PsyopActor, NarrativeTheme	AMPLIFIES, TARGETS, DISSEMINATES

Każdy węzeł zawiera wymagany zestaw właściwości: kanonicznego identyfikatora, nazwy, etykiety klasyfikacji, odniesienia do źródła i znacznika czasu utworzenia. Każda krawędź zawiera: typ, source_ref, ufność (liczba zmiennoprzecinkowa między 0 a 1), valid_from (najwcześniejszy czas zaobserwowania relacji), valid_until (null, jeśli nadal aktywna) oraz klasyfikację. Te wymagane właściwości sprawiają, że graf jest audytowalny: każde wywnioskowane powiązanie można prześledzić wstecz do obserwacji, które je potwierdzają, wraz z metadanymi zbierania i wynikami ufności.

Krawędzie między wymiarami PMESII są często najbardziej wartościowymi celami wywiadowczymi. Węzeł Ekonomiczny finansujący węzeł Wojskowy łączy dwa wymiary; węzeł Informacyjny rozpowszechniający narrację w imieniu węzła Politycznego łączy dwa inne. Zapytania, które szczególnie poszukują ścieżek między wymiarami — jakie organizacje Ekonomiczne finansują tę jednostkę Wojskową? — są strukturalnie proste w grafie własności, ponieważ krawędź istnieje jako natywny obiekt łączący dwa węzły.

Rozróżnianie encji ze źródeł multi-INT

Dane wywiadowe są zbierane przez źródła, które nigdy nie były projektowane do wspólnego identyfikatora encji. System SIGINT identyfikuje osobę po jej numerze telefonu. Raport HUMINT nazywa ją w prozie. Analityk IMINT oznacza pojazd w adnotacji obrazkowej. Otwarta baza danych rejestruje organizację według jej nazwy prawnej w obcym piśmie. Umieszczenie tego wszystkiego w jednym spójnym grafie wymaga rozróżniania encji: decydowania dla każdej pary przychodzących rekordów, czy odnoszą się do tej samej encji ze świata rzeczywistego.

Potok rozróżniania ma trzy etapy. Pierwszym jest normalizacja: zanim można dokonać jakiegokolwiek porównania, identyfikatory muszą być sprowadzone do formy kanonicznej. Numery telefonów normalizują się do formatu międzynarodowego E.164. Imiona transliteruje się do wspólnego pisma (zazwyczaj łacińskiego) według zdefiniowanego standardu transliteracji (BGN/PCGN dla języków słowiańskich, ALA-LC dla arabskiego), a następnie normalizuje do formy bazowej, która usuwa honoratywne i odmiany kolejności imion. Współrzędne konwertowane są do WGS84. Rekord, w którym numer telefonu jest zapisany jako „0044-20-7946-0123", i inny, w którym numer to „+44 20 7946 0123", muszą oba dawać ten sam znormalizowany klucz przed jakimkolwiek etapem blokowania lub porównania.

Drugi etap to blokowanie: mechanizm ograniczający, które pary rekordów są porównywane. Porównanie każdego przychodzącego rekordu z każdym istniejącym węzłem grafu jest kwadratowe w złożoności i operacyjnie niewykonalne na dużą skalę. Strategie blokowania obejmują: sortowane sąsiedztwo (rekordy sortowane według klucza blokowania, porównywane tylko w ruchomym oknie), blokowanie odwróconego indeksu (rekordy dzielące co najmniej jeden token w fonetycznym kodowaniu imienia są kandydatami) oraz mieszanie lokalnie wrażliwe MinHash dla atrybutów o wartości zbiorczej, takich jak znane aliasy. Każda strategia wymienia recall na wydajność: pominięty kandydat blokowania to pominięte dopasowanie encji, więc klucze blokowania powinny być dostrajane na podstawie wzorcowego zestawu testowego znanych duplikatów.

Trzeci etap to ocenianie i decyzja. Pary kandydatów otrzymują wektor podobieństwa według wielu atrybutów: podobieństwo imienia (Jaro-Winkler lub Jaccard nad tokenami imienia), nakładanie się identyfikatorów (wspólny telefon, IMEI, adres), bliskość geograficzna i współwystępowanie czasowe. Regresja logistyczna lub klasyfikator z gradientowym wzmacnianiem daje wynik ufności scalania. Pary powyżej wysokiego progu (zazwyczaj 0,90) są scalane automatycznie; pary w paśmie niepewności (0,65–0,90) są kolejkowane do sprawdzenia przez analityka; pary poniżej dolnego progu są pozostawiane jako oddzielne węzły.

Architektura fuzji wieloczujnikowej obsługująca korelację śledzenia na poziomie czujnika stosuje wiele tych samych zasad probabilistycznych — bramkowanie na pozycji, prędkości i atrybutach tożsamości — ale działa przy opóźnieniu milisekund nad ustrukturyzowanymi komunikatami czujnika. Rozróżnianie encji dla grafów wiedzy działa przy znacznie mniejszym wolumenie (miliony rekordów zamiast milionów na sekundę), ale na znacznie bardziej nieustrukturyzowanych danych. Obie dziedziny wymagają tej samej dyscypliny: jawna ufność, odwracalne decyzje i audytowalność.

Reprezentowanie obiektów STIX w bazie grafowej

STIX (Structured Threat Information eXpression) jest standardem NATO i Five Eyes do udostępniania informacji o cyberzagrożeniach. Pakiet STIX składa się z obiektów domeny STIX (SDO) — encji: aktorów zagrożeń, kampanii, wskaźników, złośliwego oprogramowania, podatności, wzorców ataków, infrastruktury — oraz obiektów relacji STIX (SRO), które wyrażają skierowane relacje między nimi: „ThreatActor X używa Malware Y", „Kampania A celuje w Sektor B". To jest natywny graf własności. Każde SDO staje się węzłem; każde SRO staje się skierowaną krawędzią.

Mapowanie jest proste:

// STIX SDO → węzeł Neo4j
MERGE (n:StixObject {stix_id: $bundle.id})
SET n.type        = $sdo.type,
    n.name        = $sdo.name,
    n.confidence  = $sdo.confidence,
    n.modified    = datetime($sdo.modified),
    n.revoked     = coalesce($sdo.revoked, false),
    n.labels      = $sdo.labels,
    n.classification = $sdo.object_marking_refs[0]

// STIX SRO → krawędź Neo4j
MATCH (src:StixObject {stix_id: $sro.source_ref})
MATCH (tgt:StixObject {stix_id: $sro.target_ref})
MERGE (src)-[r:STIX_REL {stix_id: $sro.id}]->(tgt)
SET r.relationship_type = $sro.relationship_type,
    r.confidence        = $sro.confidence,
    r.valid_from        = datetime($sro.start_time),
    r.valid_until       = datetime($sro.stop_time),
    r.modified          = datetime($sro.modified),
    r.revoked           = coalesce($sro.revoked, false)

Dwie komplikacje specyficzne dla STIX wymagają jawnej obsługi. Po pierwsze, wersjonowanie: STIX aktualizuje obiekt przez ponowne wyemitowanie tego samego id z nowym znacznikiem czasu modified. Powyższy wzorzec MERGE-na-stix_id obsługuje to poprawnie, nadpisując właściwości w miejscu. W przypadku przepływów pracy, które muszą odtworzyć obraz wywiadowczy z określonego momentu — na przykład w przeglądzie po incydencie — potrzebny jest wzorzec wersjonowania czasowego: zamiast nadpisywania, tworzy się nową wersję węzła i łączy wersje krawędziami HAS_VERSION, przechowując efektywny znacznik czasu w każdym węźle wersji.

Po drugie, unieważnienie: obiekt STIX z revoked: true powinien być wykluczony z przeszukiwań, ale nie usunięty, aby zachować ślad audytu. Konwencją jest ustawienie revoked: true w węźle i dodanie filtra WHERE NOT n.revoked do każdego domyślnego zapytania przeszukiwania. Unieważniona krawędź, która twierdziła o relacji między dwoma aktorami zagrożeń, musi pozostać w bazie danych, aby analityk mógł zobaczyć, że twierdzenie zostało złożone, a następnie wycofane — samo wycofanie jest informacją wywiadowczą.

STIX definiuje również obiekty Sighting, które rejestrują, że SDO zostało zaobserwowane w określonym kontekście. Sightings mapują się na krawędzie łączące obserwowany obiekt z identyfikującą tożsamością, z właściwościami sighting_count oraz first/last_seen. To jest mechanizm łączący abstrakcyjną analizę zagrożeń — „ta rodzina złośliwego oprogramowania" — z konkretną obserwacją operacyjną: „to złośliwe oprogramowanie zostało wykryte w tej sieci o tym czasie."

Dobór bazy grafowej dla środowisk wojskowych

Wybór bazy grafowej do tajnego wdrożenia wojskowego nie jest przede wszystkim decyzją wydajnościową. Dominują kilka niefunkcjonalnych ograniczeń:

Silnik	Air-gap	Język zapytań	Natywne algorytmy GDS	Uwagi
Neo4j Enterprise	Tak (licencja offline)	Cypher / openCypher	Biblioteka GDS: PageRank, Louvain, Dijkstra, WCC	Większość narzędzi analitycznych celuje w Cypher; udokumentowana historia wdrożeń w środowiskach Five Eyes
TigerGraph	Tak (pakiet on-prem)	GSQL	Wbudowane: centralność, społeczność, ścieżka	Wyższa przepustowość dla analityki wsadowej; GSQL bardziej wymagający dla analityków
Amazon Neptune	Nie (usługa chmurowa)	openCypher / Gremlin / SPARQL	Neptune ML dla grafowych sieci neuronowych	Odpowiedni tylko dla chmurowych dzierżaw TS/SCI; nie dla prawdziwego air-gap
JanusGraph	Tak (open source)	Gremlin	Via Spark/Hadoop	W pełni open-source; działa na HBase, Cassandra lub RocksDB; najlepszy dla węzłów edge z wbudowanym storage

Dla wywiadowczych węzłów wdrożonych na linii frontu lub na obrzeżach sieci — zespół eksploatacyjny z laptopem i siecią taktyczną — wbudowane magazyny grafowe oparte na RocksDB (JanusGraph + EmbeddedGraph) lub tryb wbudowany Neo4j oferują najmniejszy ślad zasobów. Dla garnizonowych sieci analitycznych z wieloma jednoczesnych analitykami, klastrowane wdrożenie Neo4j Enterprise lub architektura rozproszona TigerGraph zapewniają przepustowość potrzebną do jednoczesnych sesji analizy linków. Amazon Neptune jest odpowiedni tylko wtedy, gdy enklawa klasyfikacyjna jest już hostowana w suwerennej chmurze na wymaganym poziomie klasyfikacji.

Kluczowym zagadnieniem operacyjnym jest warstwa egzekwowania wielopoziomowego bezpieczeństwa (MLS). Sama baza grafowa zazwyczaj nie jest świadoma MLS: przechowuje dane i wykonuje zapytania bez inherentnego rozumienia etykiet klasyfikacji. Warstwa egzekwowania znajduje się w bramce zapytań — komponencie middleware, który przepisuje każde przychodzące zapytanie Cypher, dodając klauzulę WHERE filtrującą do autoryzowanego zestawu klasyfikacji użytkownika. Musi to być zaimplementowane starannie: użytkownik z poświadczeniem SECRET nie może wywnioskować istnienia krawędzi TOP SECRET poprzez różnice czasowe lub komunikaty o błędach, nawet jeśli nie może zobaczyć zawartości krawędzi.

Wzorce zapytań do analizy linków

Analiza linków w Cypher sprowadza się do małego słownictwa wzorców, które składają się w złożone pytania analityczne. Poniższe przykłady zakładają Neo4j i bibliotekę GDS, ale wzorce transliterują się do GSQL lub Gremlin z drobnymi zmianami składniowymi.

Najkrótsza ścieżka między dwoma encjami zainteresowania:

// Znajdź najkrótszą ścieżkę, filtrując do krawędzi o wysokiej ufności, nieunieważnionych
MATCH (a:Entity {id: $seedA}),
      (b:Entity {id: $seedB}),
      p = shortestPath((a)-[*1..6]-(b))
WHERE ALL(r IN relationships(p)
      WHERE r.confidence >= 0.6
        AND NOT coalesce(r.revoked, false)
        AND (r.valid_until IS NULL OR r.valid_until > datetime()))
RETURN p, length(p) AS hops
ORDER BY hops ASC

Rozszerzenie sąsiedztwa K-krokowego od ziarna, z oknem czasowym:

// Sąsiedztwo 3-krokowe aktywne w 30-dniowym oknie operacyjnym
MATCH (seed:Entity {id: $seedId})-[r*1..3]-(neighbor)
WHERE ALL(rel IN r
      WHERE rel.confidence >= 0.5
        AND rel.valid_from <= $windowEnd
        AND (rel.valid_until IS NULL OR rel.valid_until >= $windowStart))
RETURN DISTINCT neighbor, labels(neighbor) AS types
LIMIT 500

Wykrywanie społeczności algorytmem Louvain (uruchamiane na projekcji grafu w pamięci):

// Projektuj podgraf ważony ufnością, uruchom Louvain, zapisz ID społeczności
CALL gds.graph.project(
  'intel-graph',
  ['Entity'],
  {COMMUNICATES_WITH: {properties: ['confidence']}})

CALL gds.louvain.write('intel-graph', {
  writeProperty: 'communityId',
  relationshipWeightProperty: 'confidence'
}) YIELD communityCount, modularity

// Następnie pokaż rówieśników ze społeczności ziarna
MATCH (seed:Entity {id: $seedId})
MATCH (peer:Entity {communityId: seed.communityId})
WHERE peer.id <> $seedId
RETURN peer ORDER BY peer.degreeCentrality DESC LIMIT 50

Czasowa analiza linków — kadencja aktywności w czasie:

// Policz aktywacje krawędzi na tydzień kalendarzowy do analizy wzorców czasowych
MATCH (a:Entity {id: $seedId})-[r:COMMUNICATES_WITH]-()
WHERE r.valid_from >= $rangeStart AND r.valid_from <= $rangeEnd
WITH r,
     date.truncate('week', r.valid_from) AS week
RETURN week,
       count(r) AS contact_count,
       avg(r.confidence) AS avg_confidence
ORDER BY week ASC

Czasowa analiza linków jest mostem do tradycji analizy wzorca życia w wywiadzie wojskowym: gdy kadencja aktywacji krawędzi węzła zmienia się — częstotliwość spada, godziny się zmieniają, partnerzy kontaktowi rotują — graf ujawnia tę zmianę jako anomalię strukturalną, nawet zanim na encji zostanie wytrenowany celowy model behawioralny. Zapytanie grafowe jest detektorem pierwszego przejścia; model behawioralny jest warstwą potwierdzającą.

Uwaga dotycząca wydajności: algorytmy wykrywania społeczności i centralności działają na pełnym projektowanym grafie, nie tylko na podgrafie. Dla grafu z dziesiątkami milionów węzłów algorytmy te muszą być planowane jako wsadowe zadania w tle, a nie zapytania interaktywne. Wyniki — communityId i degreeCentrality zapisane z powrotem jako właściwości węzła — są wtedy dostępne do natychmiastowego wyszukiwania w zapytaniach analityków bez ponownego uruchamiania algorytmu.

Integracja grafów wiedzy z potokami C2 i OSINT

Graf wiedzy niepołączony z żywymi źródłami danych jest artefaktem historycznym, a nie narzędziem operacyjnym. Architektura integracji ma trzy kanały pozyskiwania i dwa punkty konsumpcji.

Pozyskiwanie kanałów CTI (STIX/TAXII). Klient TAXII odpytuje zarejestrowane punkty końcowe kolekcji — sojusznicze platformy udostępniania CTI, krajowe kanały informacji o zagrożeniach — i przetwarza przychodzące pakiety STIX przez potok SDO-do-węzła / SRO-do-krawędzi opisany powyżej. Przetwarzanie pakietów jest idempotentne: MERGE na stix_id zapewnia, że ponownie dostarczony obiekt aktualizuje właściwości, a nie tworzy zduplikowanego węzła. Nowe obiekty są rozróżniane encji względem istniejącego grafu przed zatwierdzeniem; jeśli nowy STIX ThreatActor pasuje do istniejącego węzła Person spoza STIX przez probabilistyczne rozróżnianie tożsamości, dwa są scalane i wszystkie krawędzie z obu rekordów są teraz przeszukiwalne z węzła kanonicznego.

Pozyskiwanie raportów HUMINT. Raporty w języku naturalnym ze źródeł ludzkich są przetwarzane przez potok NLP, który przeprowadza rozpoznawanie encji nazwanych, ekstrakcję relacji i rozróżnianie koreferencji, a następnie mapuje wyekstrahowane encje i relacje na schemat grafu. Potok NLP nie jest grafem: jest warstwą transformacji z prozy na ustrukturyzowane elementy grafu. Wyekstrahowane encje przechodzą przez ten sam potok rozróżniania encji co każde inne źródło, z typowo niższą ufnością bazową (ekstrakcja z prozy jest mniej niezawodna niż ustrukturyzowany rekord bazodanowy), która jest propagowana do krawędzi obsługiwanych przez raport HUMINT.

Pozyskiwanie śladów SIGINT. Obserwacje SIGINT — komunikacja między dwoma punktami końcowymi o określonej godzinie, urządzenie pojawiające się w określonej lokalizacji — napływają jako kanał strumieniowy. Każda obserwacja tworzy lub odświeża krawędź w grafie: krawędź COMMUNICATES_WITH między dwoma węzłami osoby lub urządzenia, lub krawędź OBSERVED_AT między urządzeniem a lokalizacją. Właściwość valid_from krawędzi to znacznik czasu obserwacji; valid_until jest null, chyba że kanał SIGINT jawnie zamyka obserwację. Masowe pozyskiwanie strumieniowe wymaga wspartego kolejką ingestora (Kafka lub odpowiednik), który buforuje obserwacje i pakuje je w zapisy do bazy grafowej z prędkością, którą baza może wchłonąć bez blokowania zapytań interaktywnych.

Dwa punkty konsumpcji to stacja robocza analityka i wspólny obraz operacyjny (COP) C2.

Stacja robocza analityka udostępnia interfejs analizy linków, gdzie analityk określa encję źródłową, wybiera typy relacji i progi ufności oraz rozszerza ograniczone sąsiedztwo. Wynik jest renderowany jako układ grafu siłowego, z ufnością zakodowaną jako przezroczystość krawędzi i przynależnością do społeczności zakodowaną jako kolor węzła. Wyniki centralności określają rozmiar węzła. Analityk nigdy nie widzi całego grafu — tylko ograniczony, filtrowany, napędzany zapytaniami podgraf, który odpowiada na konkretne pytanie. Dobry interfejs wyświetla wzorzec Cypher na pasku bocznym, żeby analityk rozumiał dokładnie, co zostało zapytane, i mógł to doprecyzować.

Integracja COP C2 wyświetla profile encji wywiedzionych z grafu — znane podwładne jednostki, przynależność do społeczności danej osoby, zależności zaopatrzeniowe obiektu — jako wyskakujące okienka na obrazie taktycznym. Gdy operator klika śledzoną encję, system C2 odpytuje graf wiedzy o kontekst sieciowy tej encji i wyświetla pięć najwyżej powiązanych encji według ufności i centralności. Przekształca to graf wiedzy z samodzielnego narzędzia analitycznego w aktywny komponent obrazu operacyjnego: ustrukturyzowana inteligencja relacyjna, dostępna w kontekście, bez konieczności otwierania oddzielnego narzędzia przez operatora.