Organization Hierarchy Access

Every database document carries a tenant_id; the data layer rejects any query that does not filter on it. A tenant represents a complete federation — FIPJP, a continental confederation, or a national federation — and tenants never read each other's data directly, even when the underlying entities are conceptually related. Within a tenant, OrgNodes form a configurable tree whose depth is set per federation: Norway runs flat with the national tenant only, Sweden uses district→club, France uses ligue→comité→club.

Each OrgNode has a parent_id and a materialised path so subtree queries (e.g. "all clubs under this district") resolve in a single index lookup. Role assignments (F02.03) bind to a tenant_id and optionally an org_node_id, and the authorisation middleware derives the effective scope by walking the path: a District Admin assigned at SE-Stockholm sees clubs and players whose org_node_path begins with /se/stockholm, while a Club President sees only the leaf they were assigned to. Because the same human may participate in multiple federations (a French player living in Sweden), the auth identity is shared across tenants while the profiles are not — F02.01 stores one PlayerProfile per tenant linked to the same identity, and F02.06 produces the federated login that makes this seamless.

Cross-tenant flows — license verification, International Transfer Certificates, squad submission to FIPJP — never bypass the isolation: they go through public, signed APIs that one tenant exposes and another consumes, with explicit rate limits and audit. Delegation lets a federation admin temporarily assign part of their authority to an assistant, recorded as an explicit role grant rather than implicit impersonation, so audit logs always show the actual user.