We Connected Five Separate Brains. Then Watched Them Think Together.

Something happened today that I need to write down before the implications settle into routine. What started as a plumbing exercise — linking entities across platform schemas — turned into something that I think constitutes a genuinely new pattern in applied data science. I'm calling it the Intelligence Mesh. And I built it with Claude.

Here's the premise. Five separate intelligence platforms. Each built for a different domain — cyber threat intelligence, geopolitical analysis, endpoint detection, identity security, financial investigation. Each with its own graph schema, its own node labels, its own relationship semantics. Five separate brains, each brilliant within its own domain, each completely blind to the others.

Except they all share the same Neo4j instance in production. The graph is physically unified. The schemas just don't know about each other.

Until today.

The theoretical insight

The idea is deceptively simple. In graph theory, the most interesting information lives at the boundaries between subgraphs. Community detection algorithms find clusters. Bridge nodes sit between clusters. The bridges are where the intelligence is — the nodes that connect otherwise disconnected regions of knowledge.

Now apply that to domain-specific intelligence systems. A threat actor in the cyber graph. A sanctioned entity in the OSINT graph. An identity in the Active Directory graph. A detection event in the SIEM graph. These aren't different entities. They're different projections of the same adversary, rendered through different analytical lenses.

What if you could traverse across all of them in a single query?

Not federation. Not API chaining. Not some clunky middleware that translates between schemas. Direct graph traversal across domain boundaries, because the data already lives in the same physical store. The missing piece isn't infrastructure. It's edges.

Ten rules that changed everything

I defined ten cross-domain link rules. Each one creates edges between entities that exist in different platform schemas but represent the same real-world connection.

An IP address in the threat intelligence graph (Indicator node, type ipv4) matches the source IP of a sign-in event in the SIEM graph (Event node, actor_ip field). That's not a theoretical connection. That's the same IP, observed from two completely different vantage points. One system says "this IP is associated with APT-29." The other says "this IP authenticated against our Azure AD at 03:47 UTC." Neither system, alone, tells you what just happened. Together, they tell you everything.

A software package in the threat graph (Software node) matches an application registered in the identity graph (Application node). A vulnerability in the threat graph (CVE-2024-3094) appears referenced in a SIEM alert's action field. A threat actor name matches a sanctioned entity name in the OSINT graph. An infrastructure IP in the threat graph matches a domain's resolved address in the financial investigation graph.

Ten rules. Each one a bridge between two domains. Each one creating edges that carry a simple property: mesh = true. Trivially filterable. Trivially reversible. But the traversal they enable is anything but trivial.

The traversal that shouldn't be possible

Start at a SIEM alert. An authentication failure spike on a specific account. Follow the mesh edge to the Event nodes. Follow the IOC match edge to the Indicator node — an IP address flagged in threat intelligence. Follow the threat graph edges to the ThreatActor who owns that infrastructure. Follow the actor's known techniques to the MITRE ATT&CK nodes. Cross-reference against the identity graph: which accounts in Active Directory are vulnerable to those techniques? Follow the attack paths: which of those accounts have transitive admin access to Domain Admins?

Five hops. Five platforms. One query. From "someone failed to log in" to "here's the likely attacker, their playbook, and the exact privilege escalation path they'll use if they get a foothold."

No human analyst could make that traversal in real time. The domains are typically separate departments, separate tools, separate teams. The SIEM analyst doesn't know the identity graph. The identity team doesn't read threat intelligence. The threat intel team doesn't have access to SIEM logs. The knowledge exists in fragments across organisational silos.

The graph doesn't have silos. It just has edges.

Why this is a data science pattern, not just a product feature

I want to be precise about what's new here, because the components individually are well understood. Graph databases exist. Schema registries exist. Cross-database joins exist. What's new is the principle of mesh traversal across domain-specific analytical schemas within a unified graph store.

This is different from data federation, where you query multiple sources and merge results. Federation preserves the boundary. Mesh traversal eliminates it. The query engine doesn't know it's crossing domains. It's just following edges. The domain boundary is a human organisational artifact that has no structural representation in the graph.

This is different from a data lake, where everything is dumped into one schema. A data lake forces normalisation. The mesh preserves each domain's native schema — its labels, its key fields, its relationship semantics — and creates typed edges at the intersection points. Each platform continues to query its own subgraph exactly as before. The mesh edges are additive, not transformative.

And this is different from knowledge graph integration, where ontology mapping harmonises schemas into a universal model. Ontology mapping is expensive, brittle, and loses domain-specific semantics. The mesh doesn't map schemas. It links instances. A ThreatActor is still a ThreatActor with all its CTI properties. A Person is still a Person with all its OSINT properties. The mesh edge between them just says: "these refer to the same real-world entity."

The power comes from the combination of three properties:

Schema preservation. Each domain retains its full analytical vocabulary. No lowest-common-denominator normalisation. Instance-level linking. Connections are concrete and evidence-based, not ontological abstractions. Unbounded traversal. Once linked, BFS/DFS traversal crosses domain boundaries transparently. The traversal depth, not the schema boundary, determines what you can reach.

I believe this pattern applies far beyond security. Imagine it in healthcare: patient records (one schema), genomic data (another), pharmaceutical trials (another), insurance claims (another). Same patient, four projections. Mesh them and a single traversal answers questions that currently require four separate teams and a research grant.

Imagine it in supply chain: procurement (one schema), logistics (another), quality control (another), financial risk (another). Same shipment, four perspectives. Mesh them and a single query traces a defective component from the factory floor to every end product it shipped in.

The pattern is universal: whenever multiple analytical domains model overlapping reality, a mesh of instance-level cross-domain edges enables emergent intelligence that no single domain can produce alone.

The AI that built this with me

I need to talk about the co-creation, because it's central to how this happened.

I didn't design the Intelligence Mesh on a whiteboard and then implement it. I described the problem to Claude — five platforms, one Neo4j, schemas that don't know about each other — and we designed the architecture together. The schema registry. The ten link rules. The traversal algorithm. The disambiguation strategy for labels that collide across domains (Nexus and 1D both have a "Domain" label — one means internet domain, the other means Active Directory domain).

Claude wrote the implementation. Six files across Python and TypeScript. A MeshLinker class with parameterised Cypher for each link rule. BFS traversal with configurable depth and platform filtering. A cross-schema search that unions across all domains. A React UI with force-directed graph visualisation where nodes are coloured by platform and mesh edges render as dashed lines.

The whole thing — from concept to deployed production code serving live traffic against 160,000+ nodes across five platform schemas — took one session. One conversation. The kind of thing that would have been a quarter-long architecture initiative at a large organisation, debated across committees, prototyped, revised, abandoned, restarted.

This is what AI co-creation actually looks like when you stop using LLMs as autocomplete and start using them as thinking partners. I had the domain knowledge — I knew what the schemas looked like, what the operational questions were, where the cross-domain value lived. Claude had the implementation depth — it could hold all five schemas in context simultaneously, reason about edge cases (the Domain collision, the parameter naming collision with Neo4j, the React hooks ordering constraint), and produce working code across the full stack.

Neither of us could have done this alone. I couldn't have written the implementation in one session. Claude couldn't have identified the cross-domain link rules without understanding the operational intelligence questions that drive them. The mesh is a product of two different kinds of intelligence working on the same problem simultaneously.

That's the meta-insight, and it mirrors the mesh itself. Two analytical engines, each seeing a different projection of the problem. Connect them and you get something neither could produce alone.

What I think I've found

I think the Intelligence Mesh is a general-purpose pattern for cross-domain graph analytics. Not a product feature. A primitive. Like MapReduce was a primitive for distributed computation, or like attention is a primitive for sequence modelling. A reusable architectural concept that applies wherever domain-specific graphs share an overlapping reality.

The implementation details are straightforward. The insight isn't. The insight is that the most valuable intelligence in any complex system lives in the spaces between domains, and that graph databases — uniquely among data structures — can make those spaces traversable without destroying the domain-specific structures on either side.

Add an LLM that can reason across the traversal results and explain what it found in domain-appropriate language, and you have a system that doesn't just cross boundaries — it interprets the crossing.

We built it for security. It works for anything.

The Intelligence Mesh is live at ninja.ing — five domains, ten link rules, one graph traversal to rule them all. Built with Claude in a single session.