Holacracy Architecture

Holacracy Architecture

How the fXYZ Network implements Holacracy v5.0 as its organizational operating system, with circles as the core primitive for governance, work tracking, and multi-org membership.

Overview

fXYZ Network uses Holacracy v5.0 as its organizational framework. Rather than traditional management hierarchies, authority is distributed through self-organizing circles -- teams with defined purpose, roles, and accountabilities.

In the application, circles are first-class entities stored in Neo4j as graph nodes. Each circle has a type, a purpose, roles with fillers, projects, next-actions, budgets, and elections. The circle hierarchy is expressed through parentCircleId relationships, forming a tree rooted at an anchor circle.

For the full governance framework, see Holacracy Overview.

Anchor Circle = Organization

Each anchor circle (circleType: "anchor") represents an independent top-level organization. A user can be a member of multiple anchor circles simultaneously.

• The default anchor circle is fXYZ Core (circle-fxyz-network), which serves as the general supercircle for the network.
• Users can create their own anchor circles, effectively creating new organizations.
• The OrgSwitcher component in the sidebar lets users switch between organizations.
• When a user switches orgs, all circle-related views filter to that organization's hierarchy.

Per Holacracy v5.0 Article 1.4, the anchor circle has no Circle Lead. It is governed by its ratifiers -- in fXYZ, these are FOUNDER-tier members.

Circle Hierarchy

Circles form a tree through parentCircleId references:

Anchor Circle (org root)
  +-- Technology Circle (functional)
  +-- Community Circle (functional)
  +-- Markets Circle (functional)
  +-- Governance Circle (functional)
  +-- Project Alpha (project)
       +-- Alpha Frontend (functional)
       +-- Alpha Research (project)

The hierarchy is traversed in two directions:

• Upward (resolveActiveOrgId): Given any sub-circle, trace parentCircleId up to find its anchor. This determines which organization a circle belongs to.
• Downward (filterCirclesByOrg): Given an anchor ID, filter the user's circles to only those whose parent chain reaches that anchor.

Both operations include cycle detection to handle malformed data gracefully.

Circle Types

Each type has a distinct color scheme in the UI for badges and tree visualization.

Structural Roles

Every circle has four structural roles defined by Holacracy v5.0:

Elections follow the Integrative Election Process with phases: Nominating, Change of Stand, Objection Round, Completed.

Role eligibility is governed by the member tier system:

• Only NAVIGATOR and FOUNDER tier members can hold structural roles.
• EXPLORER members can fill non-structural (custom) roles.
• INITIATE members can fill custom roles only.
• OBSERVER members cannot fill any role.

Projects and Next-Actions

Work within circles is tracked through two primitives:

Projects

A project is an outcome to achieve, with:

• Status: active, completed, on_hold, someday
• Priority: Numeric priority for ordering
• Description: What the project aims to accomplish

Next-Actions

A next-action is a concrete physical action, with:

• Status: pending, completed, waiting, scheduled
• Context: Where/when the action can be done (e.g., "@computer", "@phone")
• Associated project: Optional link to a parent project

This follows the GTD-inspired approach built into Holacracy's tactical meeting process, where tensions are processed into concrete next-actions and projects.

Multi-Org Architecture

The multi-org architecture allows users to participate in multiple independent organizations simultaneously. This is implemented through three layers:

1. State Management

The CircleProvider context manages:

• activeOrgId -- Which organization the user is currently viewing. Derived from the active circle's anchor, or set explicitly via setActiveOrg.
• orgCircles -- The user's circles filtered to only those within the active org's hierarchy.
• activeCircle -- The currently selected circle within the active org.

Both activeOrgId and activeCircle are persisted to localStorage so the selection survives page reloads.

2. Org Resolution

When the user selects a circle, resolveActiveOrgId() traces up the parentCircleId chain to find the anchor circle. This anchor becomes the active org. The algorithm:

1. If the circle itself is type anchor, return its ID.
2. Otherwise, follow parentCircleId up the chain.
3. Stop when an anchor-type circle is found.
4. Return null if no anchor is reachable (with cycle detection).

3. Org-Scoped Filtering

filterCirclesByOrg() takes the user's full circle list and the active org ID, returning only circles that belong to that org's hierarchy. This filtering is applied to the sidebar tree, the circle switcher, and all circle-scoped views.

Fallback Behavior

When a user has no circle assignments at all, the system queries for the anchor circle (GET_CIRCLE with id: "anchor") as a fallback. The resolver maps this synthetic ID to the actual anchor circle in the database, ensuring downstream queries receive a real circle ID.

Privacy and Membership

Current Implementation

• Circle membership is determined by role assignments -- if you fill a role in a circle, you are a member.
• The GET_MY_CIRCLES query returns only circles where the current user has at least one role.
• Circle detail views show role fillers, projects, and actions scoped to that circle.
• Financial data (budgets, spending) is fetched separately via GET_MY_CIRCLE_FINANCIALS to keep the membership query lightweight.

Future: NFT-Based Membership

The membership system uses on-chain NFTs on Solana for network-level identity. Future work will extend this to circle-level membership tiers, enabling:

• Token-gated access to specific circles
• On-chain proof of circle membership
• Automated tier progression based on contribution

Key Files

FIBO Integration

The FIBO integration adds a formal financial ontology layer alongside the Holacracy circle structure. While circles govern how work is organized, FIBO governs what legal entities exist and how people relate to them.

How Circles and FIBO Entities Relate

Each anchor circle corresponds to an organization. When a new organization is created through the FIBO-powered wizard, the system:

1. Creates a LegalPerson node classified by FIBO entity type (Corporation, LLC, DAO, etc.)
2. Links it to a Country node for jurisdiction (from FIBO ISO 3166 data)
3. Creates an anchor circle as the organizational root
4. Assigns the creator a CompanyOwner role in the new organization context

The circle hierarchy exists within the organizational context established by FIBO classification. A circle's members act through Party-Role-Context (PRC) assignments -- each person has a specific FIBO role (Individual, Investor, Operator, etc.) within a specific context (the organization, a fund, or a project).

Organization Creation Wizard

Creating a new anchor circle now uses a 4-step FIBO-classified wizard:

1. Identity -- Select the acting party (person or legal entity)
2. Entity Type -- Choose from 11 FIBO-classified types (Corporation, LLC, DAO, Trust, etc.)
3. Jurisdiction -- Select country from 249 ISO 3166 countries stored in Neo4j
4. Review -- Confirm and create the entity, FIBO links, and anchor circle

This replaces the previous simple "Create Organization" dialog with proper legal entity classification.

Related Documentation

• FIBO Integration -- Financial ontology, entity classification, and party-role-context
• Holacracy Overview -- Framework philosophy and principles
• Constitution -- Governance rules and processes
• Elections -- Integrative election process
• Member Tiers -- Contribution-based tier system
• Roles and Circles -- Detailed role definitions
• DAO Integration -- How holacracy integrates with token governance