pzx/tensor-k18 packages a MAAT-integrated processing component ("tensor") with three separate customer/site config profiles (IPZY, T1-2, YSP), each with its own maat_redis.conf, and the repo itself is named "tensor-k18" — direct evidence this component is built and configured specifically for the K18 (Kazakhstan) deployment.

pangu_valve.conf explicitly binds the 'PanguValve' traffic-control daemon (阀门, ASMIS_PROC_NAME=Pangu/PanguValve) to the Astana, Kazakhstan (K18) site — REMOTE_DIR=ASTANA and a MAAT_EFFECTIVE_RANGE tag of location=Astana — and configures it to receive live rule updates from a MAAT Redis backend rather than static files, tying this enforcement component directly to a real-time MAAT rule-dispatch pipeline at a named export deployment.

The T1/NTC (text-content DPI) node's wired-config manifest (main.conf, dated 2019-01-30) sets REMOTE_DIR=ASTANA/KAZAKHTELECOM/, directly naming Kazakhtelecom — Kazakhstan's dominant state-linked telecom operator — as the carrier context for this K18 deployment. The NTC_MAAT module's EFFECTIVE_FLAG further scopes rules to {location: Astana, isp: Tanstelecom}, naming a second Kazakhstani ISP (Transtelecom) tied to the same deployment.

The AV/frag_monitor tool (headers AV_kill_connection.h + Maat_rule.h/Maat_command.h, i.e. a MAAT-integrated flow classifier with active connection-termination capability) ships per-deployment JSON templates including frag_monitor_k_online.json — explicitly defaulted to "K project" per a 2018-12 commit, matching taxonomy's K18/Kazakhstan site codename — plus a dedicated frag_monitor_k_online_youtube.json template and a "zhongxin" (中信)-named template, indicating per-target (YouTube) and per-site blocking profiles built on top of an active kill-connection primitive.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

The IPReuse/mrl tool -- a NAT link-learning daemon integrated with Marsio (which fills VXLAN headers using MRL-supplied virtual link IDs) and MAAT (shared 'maat_feather' candidate/nominee tables) -- ships a Kazakhstan-specific MaxMind-format IP geolocation database (Kazakhstan_v4.mmdb) directly in its own config directory and again inside its bundled IPLocator dependency. Commit history describes self-learning of link info, SNAT/DNAT policy support, and sending virtual link IDs to 'the platform' for Marsio's VXLAN encapsulation.

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.