> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solo.one/llms.txt
> Use this file to discover all available pages before exploring further.
# Networks
> The trust boundary that groups participants, roles, products, and policies
A **network** is the trust boundary of p SOLO platform. It groups the
participants who have agreed to share data, the **products** they can use, the
**policies** that govern those products, and the data that gets furnished.
Everything you do — furnishing, querying, applying policies — happens *within* a
network you belong to.
## What a network represents
A network is a logical grouping that ties together three things:
* **Participants** — the entities that operate within the network (see
[Network Roles](/concepts/governance/network-roles))
* **Data** — every furnished record carries a network reference, so the network
acts as a boundary on what data can be read
* **Rules** — the [querying policies](/concepts/governance/querying-policies) and
[furnishing policies](/concepts/governance/furnishing-policies) that govern each
product, and how data is allowed to move between this network and neighbouring
networks (see [Network Governance](/concepts/governance/network-governance))
A network has a name, an optional description, and a single **governor entity**
that owns it.
## The network tree
Networks are not flat. Every network has at most one **parent network**, so
networks form a **tree** where smaller, more specific networks live underneath
broader ones. A network with no parent sits at the top of the tree and is called
a **root** network. Networks below it are its **descendants**; the networks
directly under it are its **children**.
```mermaid theme={null}
graph TD
Federation[Federation Root]
BankA[Coastal Bank]
BankB[Summit Bank]
BankASub1[Coastal — Credit Cards]
BankASub2[Coastal — Mortgages]
BankBSub1[Summit — Auto Loans]
Federation --> BankA
Federation --> BankB
BankA --> BankASub1
BankA --> BankASub2
BankB --> BankBSub1
```
In the diagram above, *Coastal Bank* is a child of *Federation Root* and a parent
of *Coastal — Credit Cards*. *Summit Bank* is a **sibling** of *Coastal Bank*
because they share a parent. *Coastal — Credit Cards* and *Summit — Auto Loans*
are **cousins** because they share a common ancestor (the Federation) without
being in each other's direct line.
This lets a single arrangement — such as a sponsor bank and the fintechs it
sponsors — share a parent network while keeping each participant's data within
its own boundary.
## Relations between networks
These are the words SOLO uses to describe how any two networks relate. They show
up throughout the permissioning model, so it's worth getting them straight up
front.
| Term | Meaning |
| - | - |
| **Parent** | The network directly above this one. |
| **Child** | A network whose parent is this one. |
| **Ancestor** | Any network reachable by walking upward — parent, grandparent, and so on, up to the root. |
| **Descendant** | Any network reachable by walking downward — child, grandchild, and so on. |
| **Sibling** | Two networks that share the same parent. |
| **Cousin** | Two networks that share a common ancestor but are not in each other's ancestor or descendant line. |
| **Root** | A network with no parent. |
SOLO treats siblings as a special case of cousins for permissioning purposes.
Anywhere governance rules talk about cousins, siblings are included.
## Kinds of network
Every network carries a `network_type` describing its place in an arrangement:
**standard** networks are the default, while **sponsor** and **partner**
networks describe a sponsor bank and the fintechs it sponsors, nested under it
in the tree. All kinds behave the same way — they can have their own
participants, their own data, and their own governance settings.
When you furnish, the upload targets a network directly, and that network's
mapping assignments determine how the data is accepted and routed (see
[Furnishing Policies](/concepts/governance/furnishing-policies)).
If you operate a single product line, you probably only need one network. Child
networks become useful when you want to keep data, participants, or rules
isolated between distinct offerings under the same operator.
## Network lifecycle
Networks are created deliberately, through the **SOLO Dashboard**, as
part of onboarding your organization or standing up a new arrangement (a
consortium, a sponsorship structure, a new line of business). A new network
needs:
* a **name** and an optional **description**,
* an optional **parent network**, which places it in the tree, and
* a **governor entity** — the entity that owns and administers it.
The entity that creates the network is recorded as its governor entity, and
SOLO automatically provisions that entity's **governor membership** on the new
network at the same time. This means a freshly created network is never
ownerless: from the first moment, exactly one entity can administer it, add
participants, and configure its [governance
rules](/concepts/governance/network-governance).
After creation, the governor typically:
1. adds participants with the [roles](/concepts/governance/network-roles) they need
(furnisher, querier, or additional governors),
2. creates and configures the [querying
policies](/concepts/governance/querying-policies) and [furnishing
policies](/concepts/governance/furnishing-policies) for the products the network
will use, and
3. optionally enables governance rules to open query paths to related networks.
## Permissions & roles
Your organization joins a network with one or more **roles**. Roles describe what
you can do, not what data you can see.
| Role | What it allows |
| - | - |
| **Governor** | Administer the network — configure policies and directory metadata. A governor seat is **not** a backdoor to other members' data. |
| **Furnisher** | Contribute data into the network for a product. |
| **Querier** | Run product queries scoped to the network. |
A single organization can hold several roles at once (for example, both furnisher
and querier). See [Network Roles](/concepts/governance/network-roles) for the full model.
Governing a network does **not** automatically let you read what other members
have furnished. Reading another participant's data still requires
[consent](/concepts/identity/consent) and [entitlement](/concepts/governance/entitlement). Roles
grant *capabilities*, not *visibility*.
## Policy usage within a network
A network ties products to participants through policies:
* A **[querying policy](/concepts/governance/querying-policies)** binds a product
to the network and defines, field by field, what queriers may read.
* A **[furnishing policy](/concepts/governance/furnishing-policies)** defines how
one type of furnished record is mapped, validated, and persisted.
When you query, you scope the request to one or more network ids and a querying
policy, so the network knows both *where* to read and *which* reading rules
apply. When you furnish a file, each record's `_type` routes it to the network's
furnishing policies that claim that type — you never pass a furnishing policy id
yourself.
```mermaid theme={null}
flowchart LR
M[Your organization] -->|querier| QP[Querying policy]
M -->|furnisher| FP[Furnishing policy]
QP --> Prod[Product]
FP --> Prod
Prod --> Net[(Network data)]
```
## Joining a network
Membership and roles are arranged with your SOLO account manager. Once you're a
member, you can:
* **search** for entities within the network,
* **furnish** products into it (as a furnisher), and
* **query** products from it (as a querier, with [consent](/concepts/identity/consent)).
See the [quickstart](/home/quickstart/join-a-network) for a walkthrough.
## In the dashboard
## Related concepts
How entities participate in a network.
How data can flow between related networks.
The field-level read rules a network applies to each product.
How furnished data is accepted, validated, and routed.
Why network membership alone doesn't grant data access.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.