From Rules to Relationships: How Machines Are Learning to Understand Each Other

Communication systems have evolved from simple bit transmission to intelligent information sharing. Traditional systems focus on moving raw data from point A to point B as reliably as possible. Now, with the explosion of machine-to-machine communication in IoT devices, autonomous systems, and smart infrastructure, we’re hitting a fundamental bottleneck.

Modern networks are drowning in unnecessary data. But machines don’t need every bit of information that traditional systems transmit.

Let’s take a look at the following security monitoring interaction:

Security Camera: Spots someone walking around in a restricted area during off-hours and captures a high-resolution video frame of size 5 MB

Traditional System: Sends the entire 5MB frame with every single bit

Central Monitoring: Analyzes frame and determines: “Unauthorized person detected in Zone A”

In this interaction, the monitoring system primarily cares about the security alert rather than the person’s clothing details, facial features, or background. But traditional communication gives equal importance to every pixel, transmitting millions of irrelevant bits along with the few that matter for decision-making.

Semantic communication emerged as a paradigm shift that transmits meaning rather than bits. Instead of sending the entire 5MB video frame, a semantic communication system would extract and transmit only: “zone_A, unauthorized_person, threat_level_high” while requiring just a tiny fraction of data, while preserving all decision-relevant information.

The receiving system gets exactly what it needs to make the right decision by deploying security personnel to Zone A for an unauthorized intrusion.

Early systems relied on Semantic Knowledge Bases (SKBs) to reduce bandwidth usage without losing the actual meaning of the message.

But SKB-based systems have limitations. They work well in controlled environments but fail when encountering unknown scenarios. This limitation sparked the development of knowledge graph-based semantic communication that promises to solve unknown situations through relational reasoning.

Why does SKBs-based semantic communication fail?

SKB systems have a critical weakness. To understand it, we first need to see how they process information.

In our security monitoring example, both the camera and monitoring station maintain a shared knowledge base K = {k_m ∈ R^d}_{m∈M}where each k_m represents semantic attributes for category m. When a security camera captures a video frame x, the semantic encoder S_α(·) extracts features s ∈ R^d.

Instead of transmitting “s” directly, the system finds the closest match using cosine similarity:

where D(s, k_m) represents the cosine similarity between s and k_m.

In our example, the camera sees someone in a restricted area and extracts features like “human shape, no uniform, nighttime movement.” It compares these against its knowledge base and finds the best match is “unauthorized_person” at index v in the knowledge base. Instead of sending all the feature details, it just transmits “v.”

This simple approach significantly reduces bandwidth usage while preserving all the information the monitoring system needs to make decisions.

Where does this break down?

The system works great until something unexpected shows up. What happens when the camera spots something that’s not in its knowledge base?

Let’s look at the following example:

Security Camera: Spots a maintenance worker in work clothes carrying tools during off-hours.

SKB System: Only knows “unauthorized_person,” “authorized_person,” “vehicle,” “animal”

System Decision: Confidently classifies worker as “unauthorized_person” with high threat level

Result: False alarm — security team gets dispatched to stop legitimate maintenance work

The math behind this might seem simple, but it’s actually quite problematic. The system always picks the “best” match, even when all the options are terrible. It’s like being forced to choose an answer on a multiple-choice test when none of the choices make sense. You still have to pick something, and the system has no way to say it doesn’t know.

These problems get worse in real deployments. For example, if your training data didn’t include shadows, the system starts calling them “intruders.” Train without winter clothing examples, and it thinks heavy coats are “suspicious gear.” The system never admits uncertainty. It always sounds confident, even when it’s completely wrong.

How do Knowledge Graphs Fix this?

Knowledge graph based semantic communication solves SKB limitations by encoding relationships between nodes rather than just isolated categories. Instead of asking “which category does this match?” it asks “how does this relate to what I already know?”

Let’s walk through our maintenance worker example to see the difference:

Step 1: Detection and Feature Extraction
The camera detects the same features as before, such as “human shape, work clothes, carrying tools, off-hours timing”

Step 2: Relationship Mapping
Instead of forcing these features into a single category, the knowledge graph maps them to multiple connected nodes.

Human shape → triggers “human” node
Work clothes + tools → triggers “work_tools” and “maintenance_equipment” nodes
Off-hours timing → triggers “unusual_access_time” node

Step 3: Relationship Traversal
To track connections between nodes, the system uses following formula:

where “z_v” denotes the updated representation of node v, and the sum aggregates information from all neighboring nodes u. Each node picks up its meaning from the neighbors it’s connected to.

work_tools → indicates → maintenance_activity
maintenance_activity → performed_by → maintenance_worker
maintenance_worker → is_a → authorized_personnel (conditional)
off_hours_access + authorized_personnel → requires → verification

Step 4: Contextual Reasoning
The knowledge graph combines these relationship paths: “This appears to be a maintenance activity by potentially authorized personnel, but the timing requires verification before determining threat level.”

Final classification is made using the following formula:

where ŷ is the predicted category, φ(y) is the knowledge graph embedding for category y, and ŝ is the received semantic information. This leads to “verify before alarm” instead of SKB’s forced “unauthorized person” classification.

The Key Difference

The difference from the maintenance worker example is that the SKB system sees “human in restricted area during off-hours” and is forced to pick from its existing categories. In our example, the system chose “unauthorized_person” because it’s the closest match.

A knowledge graph-based system takes a completely different approach. It sees the same person but starts connecting the dots. A person carrying work tools suggests a maintenance activity, which typically serves a legitimate purpose. But happening during off-hours means it needs verification first. The system generates a smart response — “verify before alarm.” Even though the system was not trained for this scenario, it was able to reason using relation graphs.

Evaluation

Knowledge graph systems showed significant improvements over SKB-based systems, showing 70–80% better accuracy in both familiar and unfamiliar environments. The system worked well even when the signal quality wasn’t great, which proved it could actually function in real-world situations where communication is noisy.

That said, knowledge graph systems have their own limitations. Graph building requires domain expertise and significant computing power. Our testing was limited to a specific dataset with predetermined categories, so we’re not sure how it would it perform in a large-scale real-world deployment. These systems need more testing before they can completely replace the SKB-based systems.

Conclusion

SKB systems were great when everything was predictable, but failed in an unfamiliar environment. Knowledge graphs solve this problem by truly understanding how nodes connect to each other. This allows the system to reason through unfamiliar environment by these connections, rather than needing explicit training for every possible situation. They are harder and more expensive to build, but they are suitable for real-world scenarios.