Skip to main content

Architecture overview

FLNet follows a federated star architecture:

  • a platform layer provides discovery, orchestration, and user interaction
  • multiple client deployments are operated by independent data holders
  • tools run in controlled environments to execute transformations or analyses

The important design choice is that data holders do not need to give up local control just to participate in a shared network.

Main building blocks​

Platform​

The platform is the central user-facing layer. It typically handles:

  • authentication
  • metadata discovery
  • project creation
  • workflow orchestration
  • result presentation

This is where most users experience FLNet.

Clients​

Clients are the self-hosted nodes operated by data holders. They typically handle:

  • local user and access management
  • data ingestion through connectors
  • mapping local data to shared standards
  • participating in discovery and approved federated analysis

Each client is an operational and governance boundary.

Tools and workflows​

Tools are packaged units of analysis logic. They can be used:

  • centrally on uploaded data
  • locally inside a client context
  • as part of a federated workflow spanning several participants

The platform provides the orchestration layer; the tool provides the domain logic.

How data moves and does not move​

One of the most important architectural rules is that metadata discovery and raw data access are not the same thing.

In a typical flow:

  1. A data holder publishes metadata or schema information through a client.
  2. A user discovers relevant datasets through the platform.
  3. A project or analysis is proposed.
  4. Execution only happens within the permissions and technical boundaries that the participating clients allow.

That means discovery can be broad while raw data access remains controlled.

Trust boundaries​

When thinking about FLNet, treat these as separate trust zones:

  • User-facing platform: where users search, configure, and review analyses
  • Client deployments: where data holders define what is visible and executable
  • Runtime layer: where tools and workflows actually run

This separation is what allows the system to balance usability with governance.

Deployment modes​

There are two common ways to use the system:

Hosted product usage​

Users interact with a centrally hosted FLNet platform and join an existing FLNet deployment.

Self-hosted participation​

An institution deploys its own client, and optionally more of the surrounding platform stack, to keep tighter control over networking, authentication, and operations.

Why the architecture matters​

Understanding the architecture helps answer practical questions:

  • Do I need a client or just platform access?
  • Where are permissions enforced?
  • Why can I discover something before I can access it?
  • What has to be deployed locally versus centrally?

If your question is mainly about joining as a site, continue with Client deployment and usage. If your question is mainly about using available data and tools, continue with Platform usage.