The "galaxy" TSG-OLAP Storm deployment topology processes four parallel log streams -- CONNECTION-RECORD-LOG, RADIUS-RECORD-LOG, PROXY-POLICY-LOG and SECURITY-POLICY-LOG -- through a shared "completion" and "knowledge" pipeline (radius-account-knowledge.jar), i.e. a real-time architecture for joining RADIUS/AAA subscriber records with connection and security-policy logs, consistent with the subscriber-identity correlation capability documented for CyberNarrator.

CyberNarrator's flink-stream-schedule-platform runs its own volumetric-DDoS "sketch" detection consumer (DosSketchEtl, wired in via business.properties' dos.sketch.etl.class) that is architecturally separate from Galaxy's own storm-based DoS pipeline. Each Kafka message is a batched detection window (sketch_start_time, sketch_duration, attack_type) carrying a nested report_ip_list that the ETL explodes into one record per flagged source/destination IP pair with session, packet, and byte counters, each tagged with the originating "sled" appliance IP and data center — i.e. detection happens upstream on distributed sensor appliances that emit periodic aggregate sketches rather than raw flow records, and this stream-schedule platform is a generic reflection-based Flink job runner (one Schedule implementation class instantiated per business.properties entry) reused across CyberNarrator's ETL jobs.

The DOS-SKETCH-RECORD Kafka input topic CyberNarrator's flink-stream-schedule-platform consumes from is SASL-authenticated with a hardcoded, product-branded credential (redacted here — see evidence_quote note) against internal brokers on port 9094 — the password itself embeds the Galaxy product name and an apparent 2019 provisioning year — which, together with cn-web/cn-admin's dedicated (if still-unimplemented) net.geedge.modules.galaxy.controller.GalaxyController class already seen alongside GalaxyProxyController/GalaxyResolveController, corroborates that CyberNarrator's backend infrastructure was bootstrapped under and remains operationally tied to the Galaxy platform rather than being a fully independent product line.

license-admin-api's actual controller/util code shows CyberNarrator's HASP licensing is per-feature, not a single product-wide dongle check — every operation (C2V generation, V2C license upload, status query, verify) is scoped by a caller-supplied vendorCode + featureId pair against the Aladdin/Thales Sentinel HASP SDK, and the query-format XML schemas expose a license object model of hasp/feature/product/vendor plus a license_manager block carrying host_fingerprint, hostname, OS, uptime, and IP — meaning individual CyberNarrator capabilities can be independently entitled/revoked per customer and the license is host-fingerprint-bound (requiring a fresh C2V/V2C exchange to move to different hardware), not a simple boolean unlock.

A MESA Lab monthly report states that adjustments to a VPN-detection module accumulated over 10,000 Psiphon3 server IPs and delayed a Psiphon3 client's ability to get online by at least 3 minutes in the researchers' test environment, an earlier-stage data point consistent with the much larger-scale (~70-73K IP) 'vpn-thwarting'/CyberNarrator Psiphon-harvesting pipeline documented elsewhere in this corpus.

MESA Lab group-meeting notes record parallel R&D on a whitelist-filtering module and a project to fingerprint cloud-hosted circumvention/proxy infrastructure at the IP-block (not single-IP) level, explicitly modeled on 2017/2019 academic 'Bulletproof-hosting IP block' research; the notes also mention local packet captures that found Psiphon IPs, the domain types/ratios Psiphon uses, and active-probing behavior with candidate detection countermeasures.

A 2020 MESA Lab progress report on the 'SAT' project describes a 'status2radius' script (Kafka heartbeat tuning), a 'GTP RST' scheme with a 'GTP DECAP' module (mobile-network GTP-tunnel decapsulation) under joint development, and deployment/acceptance-testing of an 'I3S' user-station module with a traffic gatekeeper ('GK') function for an unnamed customer ('甲方').