Siren Federate Is So Much More Than Federated Search

If you’ve assumed that Siren Federate is a federated search tool, that’s a fair reading of the name. We hear it often enough that it’s worth addressing directly.

The surface similarity is real. Both federated search and Siren Federate are responses to the same problem: data scattered across many sources, and analysts who need a unified way to work with it. But the kind of unification each provides and what you can do once the data is unified, is fundamentally different.

What federated search does?

Federated search is an information retrieval pattern. A user submits a query; that query is broadcast to multiple independent data sources, databases, APIs, cloud storage, SaaS platforms. Each source runs its own search and returns results. Those results are aggregated, deduplicated, ranked, and presented through a single interface.

It’s a practical solution. Organizations have data in many systems, and analysts shouldn’t need to log into each one separately. Federated search gives you one search bar for many sources.

But the unification happens at the query level. Each source is queried independently, and the results are merged into a list. The sources never see each other. There are no joins between a record in one source and a record in another. You get visibility across silos, but not the ability to reason across them.

What Siren Federate does?

Siren Federate takes a different approach. Rather than querying sources independently and merging their answers, it integrates data from multiple sources into a single knowledge graph; where entities, events, and their relationships span source boundaries. The unification happens at the data model level, not just at the moment of the query.

This is the knowledge graph layer of the Siren platform. Data from heterogeneous sources , structured databases, unstructured documents, communication records, transaction logs are represented as entities and relationships within one connected model. And that model is accessible through a single API supporting three data access paradigms that are normally handled by separate systems:

Information retrieval – full-text search, vector similarity, spatial queries, inherited from the Elasticsearch foundation that Siren Federate extends.

Relational operations – distributed joins and semi-joins across indices. This is what allows you to connect a record in one index to related records in another at query time, something Elasticsearch cannot do natively.

Graph operations – path traversal, pattern matching, multi-hop exploration. These allow analysts to trace chains of relationships across the knowledge graph. With our recent adoption of GQL, the ISO standard for graph query languages these operations can now be expressed in a language designed for how investigators think about relationships. I spoke about this in more detail in this video.

In most architectures, you’d need a search engine for text, a relational database for joins, and a graph database for traversals. Siren Federate brings these together in one engine, operating over the same data, within the same query.

A concrete example

Consider a financial crime investigation. A federated search for “John Smith” might return matching records from five different databases bank accounts, corporate filings, phone records, travel logs, property registers. The results are aggregated into a single list. Useful for finding where data exists. But the work of figuring out how those records relate to each other is left to the analyst.

With Siren Federate, the starting point is an entity in the knowledge graph, a person, an account, a phone number. From there, you can join across indices to find linked accounts, trace transaction chains through intermediary entities, follow communication paths through call detail records, and surface the network of relationships connecting them. Not by running five separate searches, but through queries that combine text search, relational joins, and graph traversals over a unified model.

Why this matters?

In investigative work like law enforcement, financial crime, cybersecurity and risk analysis the challenge is rarely finding a single record. It’s understanding how entities relate to each other across large, heterogeneous datasets. That requires joining and traversing data, not just retrieving it.

Siren Federate was designed for this. It operates at scale, across hundreds of nodes and large scale (hundreds of terabytes) with interactive response times. Its architecture has been refined through a decade of production deployments. And every operation is traceable from query to result, which matters in domains where findings need to be defensible.

In short

Federated search unifies your answers, it connects you to many sources through one interface. Siren Federate unifies your data into a knowledge graph you can reason across, connecting data to other data, so relationships that only become visible when sources are brought together can be searched, joined, and traversed in one place.

Same word, different meaning.

The Backstory

Even though our technology is not a simple “federated search”, at the time of inception we very deliberately called the product “Federate”. The name was chosen to capture the broader vision of the Siren joins.

Enabling organisations to work across multiple, distributed datasets in real time, without moving or centralising the data, while also maintaining control, ownership and compliance. It reflects the idea of connecting independent systems through a shared analytical layer, not just searching them.

“Federate” conveys both the collaborative power and architectural modernity of the platform, signalling that Siren is built for secure, cross-boundary analysis in environments where data sensitivity and sovereignty are critical.

For all of those reasons, “Siren Federate” is likely to stay.