Derivative works — US Patent 12301627

Defensive Disclosure for U.S. Patent No. 12,301,627

Publication Date: May 1, 2026
Author: Senior Patent Strategist and Research Engineer
Subject: Defensive publication relating to U.S. Patent No. 12,301,627, "Correlating network event anomalies using active and passive external reconnaissance to identify attack information."

This document discloses technical variations and alternative embodiments of the system and method described in U.S. Patent No. 12,301,627 (the '627 patent). The purpose of this disclosure is to establish prior art for subsequent inventions that may be considered obvious extensions or modifications of the '627 patent's teachings.

Derivative Variations of Core Claims

The following disclosures expand upon the core concepts of the '627 patent: the cyber-physical graph, the reconnaissance engine, and the directed computational graph engine for anomaly correlation and root cause analysis.

I. Variations on the Cyber-Physical Graph (CPG) Module

The '627 patent describes a CPG with nodes representing entities and edges representing relationships. The following are derivative implementations:

1. Material & Component Substitution: Neuromorphic CPG Representation

Enabling Description: The CPG is implemented not on traditional von Neumann architecture but on neuromorphic computing hardware, such as Intel's Loihi 2 or IBM's TrueNorth chips. Entities (nodes) are represented by clusters of artificial neurons, and relationships (edges) are modeled as synaptic connections with varying weights and plasticity. This allows for ultra-low power, continuous, and real-time updating of the CPG, where the graph's structure and state are inherently parallel and event-driven. The "normal behavior model" is established by training the synaptic weights through Hebbian learning principles, where frequently co-occurring events strengthen their corresponding synaptic links. Anomalies are detected as signals that fail to propagate along established strong synaptic pathways or that activate normally dormant or weakly connected neural clusters.

Mermaid.js Diagram:

graph TD
    subgraph Neuromorphic Chip
        A[Neuron Cluster: DB_Server_01]
        B[Neuron Cluster: User_Admin_A]
        C[Neuron Cluster: Web_Firewall]
        D[Neuron Cluster: External_IP_X]

        B -- Synapse_Login(weight=0.9) --> A;
        C -- Synapse_Allow(weight=0.8) --> A;
        D -.-> C;
        subgraph Anomaly Detection Unit
            E[Inhibitory Neurons];
            F[Unexpected Firing Pattern];
        end
        D -- Synapse_Blocked(weight=0.1) --> C;
        D --"Spurious Spike Train"--> E;
        E --"Inhibits C->A path"--> C;
        A --"Fires erratically"--> F;
    end

2. Operational Parameter Expansion: Quantum Entanglement-based Relationship Mapping

Enabling Description: For highly sensitive and secure environments, the CPG's edges, which represent relationships, are encoded using quantum entangled particle pairs (qubits). Each critical node (e.g., a root certificate authority, a domain controller) is associated with one qubit from a pair. A change in the state of one entity (e.g., a user logon, a file access) is used to measure the state of its associated qubit. Due to entanglement, this measurement instantly affects the state of the paired qubit associated with the related entity. This provides a tamper-evident and instantaneous method of relationship verification. An attempt to intercept or alter the relationship (a "man-in-the-middle" attack on the CPG itself) would break the entanglement, which is immediately detectable. This method operates at the quantum level, providing a theoretically unbreakable link representation.

Mermaid.js Diagram:

graph TD;
    subgraph Quantum CPG
        A[Node A: Key_Server];
        B[Node B: Admin_Terminal];
        C(Qubit_A) --- D{Entangled Pair};
        E(Qubit_B) --- D;
        A -- "AssociatedWith" --> C;
        B -- "AssociatedWith" --> E;
        F[State Measurement @ A] --> G{Result: |0>};
        H[State Collapse @ B] --> I{Result: |1>};
        G & I -- "Correlation Verified" --> J[Relationship Intact];
        K[Decoherence Event] --> L[Entanglement Broken];
        L -- "ALERT: Relationship Compromised" --> M[Security Console];
    end

3. Cross-Domain Application: Agricultural IoT (AgTech)

Enabling Description: The CPG is applied to a large-scale precision agriculture system. Nodes represent soil sensors, irrigation controllers, autonomous tractors, drones, weather stations, and crop yield databases. Edges represent physical proximity, data flow (e.g., moisture data from sensor to irrigation controller), and operational dependencies (e.g., tractor pathing depends on crop row data). An "anomalous event" could be a sudden drop in soil moisture that is not correlated with a lack of irrigation or expected weather patterns. The system would traverse the CPG backward to identify the cause: a malfunctioning irrigation valve (hardware failure), a clog in the water line (physical obstruction), or a malicious command sent to the controller (cyberattack).

Mermaid.js Diagram:

graph LR
    subgraph AgTech CPG
        WS[Weather Station] -->|Forecast| A[Irrigation_Scheduler];
        SM1[Soil_Moisture_Sensor] -->|Data| A;
        A -- "Schedule" --> V1[Valve_Controller_1];
        V1 -- "Opens" --> I1[Irrigator_1];
        Tractor[Autonomous_Tractor] -- "Avoids" --> I1;
        YieldDB[Yield_Database] -- "Receives_Data" --> Tractor;
    end

    subgraph AnomalyAnalysis
        Anom{Anomaly: Low Moisture @ SM1} -->|Trace Back| V1;
        V1 -- "Check Status" --> S1{Status: Open};
        V1 -- "Check Flow" --> F1[Flow_Meter];
        F1 -- "Reports" --> Z1{Result: Zero Flow};
        Z1 --> Clog[Conclusion: Physical Clog];
    end

4. Integration with Emerging Tech: CPG on a Decentralized Ledger (Blockchain)

Enabling Description: The state of the CPG, including all nodes, edges, and their attributes, is stored on a private or consortium blockchain. Each change to the CPG (e.g., adding a new device, changing user permissions) is a transaction that is cryptographically signed, timestamped, and added to the immutable ledger. The reconnaissance engine acts as an oracle, feeding validated external data into the blockchain via smart contracts. This creates an auditable, tamper-proof history of the network's configuration and state. An anomalous event can be cross-referenced against the blockchain record to verify if a system state change was authorized. The "behavior graph" itself can be constructed as a series of related transactions on the chain, providing a permanent and verifiable record of the attack path.

Mermaid.js Diagram:

sequenceDiagram
    participant RE as Reconnaissance Engine
    participant Oracle
    participant SC as Smart Contract
    participant CPG_Ledger as Blockchain
    participant DCG as DCG Engine

    RE->>Oracle: Provide external data (e.g., new IP threat)
    Oracle->>SC: Trigger update_cpg()
    SC->>CPG_Ledger: Create Transaction (Add Node, Update Edge)
    DCG->>CPG_Ledger: Read Current CPG State
    DCG->>DCG: Detect Anomaly
    DCG->>CPG_Ledger: Query historical transactions related to affected nodes
    CPG_Ledger-->>DCG: Return Tamper-Proof Event Log
    DCG->>DCG: Construct Behavior Graph from Transaction History

5. The "Inverse" or Failure Mode: Graceful Degradation CPG

Enabling Description: This variation is a CPG designed for critical infrastructure (e.g., power grid, telecommunications) that must maintain partial functionality during a large-scale attack. The CPG includes "resilience" scores on its edges, representing the dependency and criticality of each link. When a severe anomaly is detected, the directed computational graph engine doesn't just trace the attack; it calculates the "blast radius" (as described in FIG. 9) and identifies non-essential subgraphs that can be predictively and safely isolated. Instead of a full shutdown, the system initiates a "graceful degradation" protocol. It automatically severs low-resilience edges in the CPG, shutting down non-critical services (e.g., billing portals, public websites) to preserve the core operational nodes (e.g., power generation controllers, core network routers). The behavior graph is used not to find the origin, but to map a "safe mode" operational state.

Mermaid.js Diagram:

graph TD
    A[Core Control System] -- Resilience: 1.0 --> B(Substation A);
    A -- Resilience: 1.0 --> C(Substation B);
    B --- D[Billing System];
    C --- E[Customer Portal];
    D -- Resilience: 0.2 --> F((External API));
    E -- Resilience: 0.3 --> F;

    subgraph Attack_Scenario
        X(Attack Origin) --> F;
        F --"Compromised"--> D & E;
    end

    subgraph Degradation_Protocol
        Y{Analyze CPG & Blast Radius} --> Z["Isolate Non-Critical Subgraph"];
        Z -- "Sever Edge" --> D;
        Z -- "Sever Edge" --> E;
    end

    style F fill:#f9f,stroke:#333,stroke-width:4px

II. Variations on the Reconnaissance Engine

The '627 patent describes a reconnaissance engine performing active and passive scans. The following are derivative implementations:

1. Material & Component Substitution: Swarm-Based Micro-Bot Reconnaissance

Enabling Description: Instead of centralized scanning servers, the reconnaissance engine deploys a swarm of lightweight, ephemeral software agents (micro-bots) across the network and even onto public cloud infrastructure. These micro-bots are implemented using WebAssembly (WASM) for portability and sandboxing. Each bot performs a single, specific micro-task (e.g., check a single port on a single host, query a specific DNS record, scan a single entry on a pastebin site). The bots operate as a decentralized, self-organizing collective, communicating via a peer-to-peer gossip protocol. This makes the reconnaissance highly resilient and difficult to detect or block, as there is no central point of origin. The collected data fragments are cryptographically signed and reassembled by a collector node.

Mermaid.js Diagram:

graph TD
    subgraph Recon Engine
        A(Orchestrator) -- Deploy --> B((Micro-Bot_1));
        A -- Deploy --> C((Micro-Bot_2));
        A -- Deploy --> D((Micro-Bot_n));
    end
    subgraph Target Network
        E[Host 1];
        F[Host 2];
        G[Host 3];
    end
    subgraph Public Internet
        H[Pastebin];
        I[DNS Server];
    end

    B -- "Port Scan" --> E;
    C -- "Query Record" --> I;
    D -- "Scrape Page" --> H;

    B <--> C;
    C <--> D;
    B <--> D;

    B --"Partial Data"--> J(Collector);
    C --"Partial Data"--> J;
    D --"Partial Data"--> J;
    J -- "Assembled Recon Data" --> K[CPG Database];

2. Operational Parameter Expansion: Sub-millisecond Active Probing for High-Frequency Trading (HFT) Networks

Enabling Description: In the context of an HFT environment, where microsecond latency is critical, the reconnaissance engine operates at an extremely high frequency. It uses specialized FPGA-based network interface cards (NICs) to generate and analyze network probes. Instead of standard TCP/IP packets, it uses custom, minimal-size packets that elicit responses from network hardware (switches, routers) without engaging the host OS, minimizing latency. The engine monitors for minute changes in round-trip times (RTT), jitter, and packet ordering, which can indicate network saturation, device misconfiguration, or the precursor to a denial-of-service attack. The "normal behavior model" is a nanosecond-precision statistical model of network latency, and anomalies are deviations measured in microseconds.

Mermaid.js Diagram:

stateDiagram-v2
    [*] --> Normal_Latency
    Normal_Latency --> Normal_Latency: Probe RTT < 50µs
    Normal_Latency --> Latency_Spike: Probe RTT > 50µs
    Latency_Spike --> Normal_Latency: RTT returns to normal
    Latency_Spike --> Sustained_Anomaly: RTT > 50µs for 100ms
    Sustained_Anomaly --> [*]: Trigger Alert & CPG Correlation

3. Cross-Domain Application: Automotive CAN Bus Monitoring

Enabling Description: The reconnaissance engine is adapted to monitor the Controller Area Network (CAN bus) within modern vehicles. Passive reconnaissance involves listening to all CAN messages to build a "normal behavior model" of inter-ECU (Electronic Control Unit) communication. For example, the engine control unit (ECU) should broadcast RPM data every 20ms, and the brake controller should send a status message when the pedal is depressed. Active reconnaissance involves carefully injecting diagnostic queries (conforming to the OBD-II or UDS standard) to verify ECU presence and status. An anomaly, such as a malformed message from the infotainment system attempting to command the brakes, would be immediately flagged. The behavior graph would then trace the anomalous message from its origin ECU through any gateway ECUs it traversed.

Mermaid.js Diagram:

sequenceDiagram
    participant Infotainment
    participant Gateway
    participant BrakeController
    participant Analyst

    loop Normal Operation
        BrakeController->>Gateway: Brake Status (ID: 0x244)
    end

    Infotainment->>Gateway: **INVALID** Brake Command (ID: 0x244, data: APPLY_MAX)
    Gateway->>BrakeController: **INVALID** Brake Command
    BrakeController->>Analyst: Anomaly Detected: Unauthorized Command
    Analyst->>Analyst: Trace Origin to Infotainment ECU

4. Integration with Emerging Tech: AI-Powered Adversarial Reconnaissance

Enabling Description: The reconnaissance engine integrates a Generative Adversarial Network (GAN). The "Generator" component is trained to create novel, stealthy network scan packets and reconnaissance patterns that mimic benign traffic or exploit zero-day protocol ambiguities. The "Discriminator" component, which is trained on the organization's own real-time network traffic (the "normal behavior model"), attempts to distinguish the Generator's traffic from legitimate traffic. This continuous adversarial process fine-tunes the reconnaissance engine to become increasingly effective at bypassing modern Intrusion Detection Systems (IDS) and firewalls, allowing it to map the external attack surface as a real attacker would see it. The results provide a more realistic vulnerability assessment for the CPG.

Mermaid.js Diagram:

graph TD
    A[Real Network Traffic] --> D{Discriminator};
    G(Generator) -- "Generates" --> P[Synthetic Probe Packet];
    P -- "Attempts to Evade" --> D;
    D -- "Classifies as Real/Fake" --> L{Loss Function};
    L -- "Updates Weights" --> G;
    L -- "Updates Weights" --> D;
    P -- "Sent to Target" --> T[Target Network];
    T -- "Response" --> R[Reconnaissance Data Store];

5. The "Inverse" or Failure Mode: "Honeypot" Reconnaissance Engine

Enabling Description: This version of the engine is designed not to scan outwards, but to attract and analyze inbound reconnaissance. It deploys a network of high-interaction honeypots and honey-tokens that emulate the organization's real services and data assets (e.g., fake login portals, decoy databases, counterfeit AWS keys). When an external attacker performs reconnaissance, they interact with these decoy systems. The engine logs every action—the types of scans used, the vulnerabilities probed, the credentials attempted—in extreme detail. This "passive" data collection provides a highly accurate profile of an active attacker's TTPs (Tactics, Techniques, and Procedures). This information is then used to create a "threat actor behavior model," which is correlated with anomalies detected on the real network to identify if a known attacker is present.

Mermaid.js Diagram:

graph TD
    subgraph Internet
        A[Attacker]
    end
    subgraph DMZ
        B(Fake Web Server)
        C(Decoy Database)
        D(Fake VPN Endpoint)
    end
    subgraph Analysis_Engine
        E[Log Aggregator]
        F[TTP Analyzer]
        G[Threat Actor Profile]
    end
    A -- "Scans & Probes" --> B;
    A -- "SQL Injection" --> C;
    A -- "Brute Force" --> D;
    B -->|Logs| E;
    C -->|Logs| E;
    D -->|Logs| E;
    E --> F;
    F --> G;

III. Variations on the Directed Computational Graph (DCG) Engine

The '627 patent uses a DCG to analyze correlations, generate a behavior graph, and trace it backward. The following are derivative implementations:

1. Cross-Domain Application: Financial Fraud Detection

Enabling Description: The system is applied to detect complex financial fraud. The CPG nodes are customers, accounts, merchants, IP addresses, and physical terminals. An anomaly is a transaction flagged by a simple rule (e.g., large transfer to a new beneficiary). The DCG engine then correlates this event. It pulls in other, non-anomalous events: the customer logged in from a new device (node), used a new IP address (node), and the beneficiary account was created only hours before (time-series attribute). The DCG constructs a behavior graph showing the flow of funds from the source account, potentially through several intermediary mule accounts, to the final destination. Traversing this graph backward reveals the initial point of compromise—not the fraudulent transaction itself, but the earlier, seemingly benign event of the "new device login," which can now be identified as an account takeover.

Mermaid.js Diagram:

graph LR
    A[User_Account] -- "Owns" --> B(Bank_Account_123);
    C[New_Device] -- "Logged In" --> A;
    D[New_IP] -- "Used By" --> C;
    E(Beneficiary_Account_789) -- "Created 2h Ago" --> F[Fraudster];
    
    subgraph Anomaly_Flow
        B -- "Transaction (Anomaly)" --> E;
        E -- "Withdrawal" --> F;
    end

    subgraph Investigation
        G{DCG Analysis}
        G -- "Correlates" --> C & D;
        G -- "Traces Back" --> H(Point of Origin: Account Takeover);
    end

2. Cross-Domain Application: Epidemiological Outbreak Tracing

Enabling Description: The CPG maps individuals (nodes), locations (nodes like workplaces, schools, public transport), and interactions (edges with timestamps and duration). The initial "anomalous event" is a positive test result for a contagious disease. The DCG engine correlates this with the infected individual's recent location history and known contacts from the CPG. It builds a behavior graph (a transmission tree) by analyzing temporal and spatial overlaps with other individuals. By traversing this tree backward, the system can identify the likely index case or a superspreader event (a node with an unusually high number of outgoing edges in a short time frame) that served as the point of origin for that particular cluster of infections.

Mermaid.js Diagram:

graph TD
    subgraph Population CPG
        A(Person A)
        B(Person B)
        C(Person C)
        D(Person D)
        E(Workplace)
        F(Cafe)

        A -- "Co-worker" --> B
        A -- "Visited" --> E
        B -- "Visited" --> E
        C -- "Visited" --> F
        D -- "Visited" --> F
        B -- "Met At" --> C
    end

    subgraph Traceback
        G{Anomaly: Person A is Positive}
        G --> H{Find Correlations};
        H -- "Common Location" --> E;
        H -- "Contact" --> B;
        I{Person B Positive} --> J{Find Correlations};
        J -- "Contact" --> C;
        K{Person C Positive} --> L{Find Correlations};
        L -- "Common Location" --> F;
        L -- "Contact" --> D;
        M{Conclusion: Superspreader Event at Cafe};
    end

3. Integration with Emerging Tech: Predictive Anomaly Simulation with Digital Twins

Enabling Description: The system integrates with a "digital twin" of the organization's network—a full, real-time, software-based simulation. The DCG engine uses the CPG and normal behavior models to run thousands of "what-if" attack scenarios on the digital twin. It uses machine learning (specifically, reinforcement learning) to discover novel attack paths that haven't been seen in the wild. The "behavior graph" is generated for these simulated attacks. By traversing these predictive behavior graphs backward, the system identifies potential "patient zero" vulnerabilities or single points of failure before a real attack occurs. The output is not a reaction to a past event, but a prioritized list of weaknesses to fix based on their likelihood of being the starting point of a future breach.

Mermaid.js Diagram:

sequenceDiagram
    participant CPG
    participant DigitalTwin as Digital Twin
    participant RLAgent as Reinforcement Learning Agent
    participant DCG as DCG Engine

    DCG->>CPG: Get current network state
    DCG->>DigitalTwin: Replicate state
    RLAgent->>DigitalTwin: Launch simulated attack (Action)
    DigitalTwin->>RLAgent: Report system state change (Observation)
    RLAgent->>RLAgent: Calculate Reward (e.g., successful breach)
    loop until optimal attack path found
        RLAgent->>DigitalTwin: Launch refined attack
    end
    RLAgent->>DCG: Report most successful attack path
    DCG->>DCG: Generate behavior graph from simulation
    DCG->>DCG: Traverse backward to find simulated point of origin

4. The "Inverse" or Failure Mode: Minimum Viable Correlation Engine

Enabling Description: This is a low-power, resource-constrained version of the DCG engine for deployment on edge devices or in IoT gateways. It does not store the full CPG. Instead, it maintains a lightweight "ego-graph" for the device it's on—a model of its direct, one-hop neighbors and typical communication patterns. When an anomaly is detected locally, the engine does not perform a full backward trace. It enters a "containment" mode. It generates a "quarantine behavior graph" that includes only itself and its immediate neighbors, and then proactively severs connections or drops packets from any neighbor implicated in the anomaly, effectively isolating its small segment of the network. It then forwards a compressed summary of the local anomaly and containment action to a central cloud-based DCG for full, non-real-time analysis.

Mermaid.js Diagram:

graph TD
    subgraph Central_Cloud
        A[Full CPG]
        B[Main DCG Engine]
    end
    subgraph Edge_Device
        C(Local Anomaly Detector)
        D(Micro-DCG Engine)
        E(Ego-Graph)
        F[Local Containment Logic]
    end
    subgraph Local_Network
        G[Neighbor_1]
        H[Edge_Device_Itself]
        I[Neighbor_2]
    end

    H -- "Communicates" --> G
    H -- "Communicates" --> I
    C -- "Detects Anomaly from G" --> D
    D -- "Analyzes" --> E
    D -- "Triggers" --> F
    F -- "Blocks Traffic" --> G
    D -- "Sends Report" --> B

Combination Prior Art Scenarios with Open-Source Standards

1. Integration with STIX/TAXII for Standardized Threat Intelligence

Enabling Description: The system's reconnaissance engine and DCG are modified to natively use the Structured Threat Information eXpression (STIX) format for data representation and Trusted Automated eXchange of Indicator Information (TAXII) for transport. External reconnaissance data (e.g., from threat feeds like Abuse.ch or commercial providers) is ingested via a TAXII client. The CPG itself is augmented to store STIX Domain Objects (SDOs) and Relationship Objects (SROs) as its native nodes and edges. For example, a network host node can have a relationship to an "Indicator" object (e.g., a known malicious IP address). When the DCG detects an anomaly involving that host communicating with the malicious IP, the resulting "behavior graph" is automatically generated as a STIX Bundle, containing the related Indicator, Observed Data, and Sighting objects, ready for immediate sharing with other security tools or organizations via a TAXII server.

Mermaid.js Diagram:

flowchart TD
    subgraph External Feeds
        A[Threat Intel Provider] -->|TAXII| B(TAXII Client);
    end
    subgraph '627 System'
        B --> C{Reconnaissance Engine};
        C -- "STIX Objects" --> D[CPG w/ STIX Data Model];
        E[DCG Engine] -->|Analyzes| D;
        E -- "Anomaly Found" --> F(Generate STIX Bundle);
        F --> G(TAXII Server);
    end
    subgraph Security Ecosystem
        G -->|TAXII| H[SIEM];
        G -->|TAXII| I[SOAR Platform];
    end

2. Integration with Open Policy Agent (OPA) for Policy-as-Code Anomaly Definition

Enabling Description: The logic for determining what constitutes an "anomalous event" is decoupled from the DCG engine and offloaded to an Open Policy Agent (OPA) sidecar. The "normal behavior model" is translated into a set of policies written in OPA's Rego language. For example, a policy might state deny if input.source_ip is in trusted_subnets and input.destination_port is 22 and user.role is not admin. The DCG engine streams every observed network event as a JSON object to the OPA engine for evaluation. The OPA engine returns a simple allow/deny (anomaly/not anomaly) decision. This allows security teams to define and update the rules for anomaly detection in a declarative, version-controlled, and auditable way, without modifying the core Go or Java code of the DCG engine. This makes the system more flexible and auditable.

Mermaid.js Diagram:

sequenceDiagram
    participant Network_Tap
    participant DCG_Engine
    participant OPA_Engine
    participant CPG

    Network_Tap->>DCG_Engine: New Event (JSON)
    DCG_Engine->>OPA_Engine: Evaluate Event
    OPA_Engine->>CPG: Query Context (e.g., user role, device trust)
    CPG-->>OPA_Engine: Return Context Data
    OPA_Engine->>OPA_Engine: Apply Rego Policy
    alt Event is Anomalous
        OPA_Engine-->>DCG_Engine: Decision: "Anomaly"
        DCG_Engine->>DCG_Engine: Start Correlation & Traceback
    else Event is Normal
        OPA_Engine-->>DCG_Engine: Decision: "Normal"
    end

3. Integration with Prometheus and OpenTelemetry for Data Ingestion

Enabling Description: The system replaces proprietary data collectors and agents with components based on the OpenTelemetry standard. Application logs, system metrics (CPU, memory), and network flow data are collected by OpenTelemetry agents deployed on hosts and network devices. This data is exported in a standardized format to a Prometheus time-series database, which serves as the primary data source for building the "normal behavior model." The reconnaissance engine queries the Prometheus instance using PromQL to get historical data and establish baselines. This approach leverages a widely adopted, vendor-neutral observability framework, allowing the system to easily integrate into modern cloud-native environments and eliminating the need for custom agents. The CPG is populated by discovering resources and their relationships via the metadata (labels) attached to the OpenTelemetry data streams.

Mermaid.js Diagram:

graph TD
    subgraph Monitored Systems
        A[Web Server] -- "OTel Agent" --> B;
        C[Database] -- "OTel Agent" --> B;
        D[Kubernetes Pod] -- "OTel Agent" --> B;
    end

    subgraph Observability Pipeline
        B(OpenTelemetry Collector) --> E(Prometheus TSDB);
    end

    subgraph '627 System'
        F[Reconnaissance Engine] -- "PromQL Query" --> E;
        F -- "Populates/Updates" --> G[Cyber-Physical Graph];
        H[DCG Engine] -- "Reads Baselines" --> E;
        H -- "Reads Topology" --> G;
        H --> I{Anomaly Detection};
    end