WebsiteInterface

Protocol

Protocol

Free-Association Organizational Protocol

Organization

Protocol operates through three computational mechanisms:

  1. Membership Module: Determines who participates based on mutual recognition density

  2. Collective Recognition: Allocates resources based on recognized needs and collective capacities

  3. Decider: Structured decisions for threshold setting and parameter tuning

No governance. No committees. No appointments. Pure computation from recognition patterns.

Core Principles

The 100% Recognition Constraint

Each participant has exactly 100% recognition to distribute.

This is not arbitrary - it represents a fundamental truth:

  • Your self-actualization is a whole (100%)

  • Everything that enables your self-actualization sums to that whole

  • You cannot exceed 100% (you can't self-actualize more than fully)

  • You cannot go below 100% (your self-actualization is complete as-is)

What this means:

Trade-offs are real:

Dynamic adjustment:

Non-transferable:

1. Membership: Who Participates

Recognition as Fundamental Unit

Recognition is your acknowledgment of contributions toward your own self-actualization.

Each participant has 100% total recognition to distribute:

  • Represents what enables you to self-actualize

  • Includes direct contributions to your work/life

  • Includes contributions to social values and needs you care about

  • Non-transferable (cannot be sold or traded)

  • Dynamically adjustable as relationships and contributions evolve

Mutual Recognition = minimum of bidirectional recognitions

Why the minimum?

  • Ensures reciprocity in proportion

  • One-sided recognition doesn't create mutual relationship

  • Both must acknowledge the other's contribution to their own self-actualization

  • Creates genuine mutual interdependence, not patronage

Example:

Membership Computation

Mutual Recognition Score (MRS):

Network Average:

Mutual Recognition Density (MRD):

Membership Status:

Properties

  • No gatekeeping: Membership emerges from mutual recognition

  • No appointments: MRD computation is automatic

  • Self-correcting: Stop contributing → recognition drops → lose membership

  • Sybil-resistant: Fake accounts can't build genuine mutual recognition

  • Scale-invariant: Threshold adjusts automatically as network grows

Example

2. Resource Allocation: Who Gets What

Recognition and Self-Actualization

Core Principle: You recognize contributions that enable your self-actualization.

When you recognize someone:

  • You acknowledge they contribute to your ability to self-actualize

  • This could be direct (they help your work)

  • Or indirect (they contribute to social values/conditions you need)

Examples:

Recognition flows naturally toward enabling contributions:

  • Those who enable many people's self-actualization receive high aggregate recognition

  • Those who enable few people's self-actualization receive low aggregate recognition

  • Quality and breadth of enabling contribution determines recognition

Needs and Capacities

Need Declaration:

Provider Capacity Declaration:

Why only providers declare capacities:

  • Providers know what they can actually provide (eliminates phantom capacity)

  • Non-providers speculating about capacity adds no value

  • Providers evaluate needs directly through their own capacity lens

  • Eliminates intermediate "claim" concept

Collective Recognition Allocation

When Foundation X declares a capacity for {Alice, Bob, Charlie, Dave, Eve}:

Step 1: Calculate Collective Recognition Pool

Step 2: Calculate Each Person's Collective Recognition Share

Step 3: Provider Sees Needs and Allocates

Allocation when capacity is constrained:

Key insight:

  • Providers aren't "donating" - they're investing in what enables their own self-actualization

  • Collective recognition shares guide allocation priorities

  • Providers see actual needs and allocate based on their available resources

  • No intermediate "claims" needed - direct from capacity to allocation

Self-Correction Mechanisms

Phantom Capacity Eliminated:

Success Amplifies:

Failure Corrects:

Multiple Provider Lenses

Primary Model: Administrative Entity as Computational Provider

This is the core model. The administrative entity holds funds and allocates computationally.

Key principle: The admins don't decide allocations. The protocol computes allocations based on collective recognition + needs + compliance filters.

Secondary Model: External Provider via Administrative Entity

External providers can use the administrative entity as an execution agent for their allocations.

Capacity Filters: Compliance and Restrictions

Providers are wholly responsible for implementing filters to comply with socio-technical-legal limits.

Each provider can apply filters to their capacity based on:

  • AML/KYC compliance (Know Your Customer verification)

  • Sanctions screening (OFAC, UN sanctions lists)

  • Legal jurisdiction restrictions

  • Tax compliance requirements

  • Mission/purpose alignment

  • Risk assessment

Allocation Filter Model:

Example: Compliance Filtering with Limits

Union of Filters (External Provider via Administrative Entity):

Compliance Responsibility:

3. Decision Making: Setting Parameters

When to Use Decider

Rarely. Only for:

  • Setting membership threshold (default 0.5)

  • Setting minimum recognition level (default 0%)

  • Setting computation frequency (default weekly)

  • Constitutional/structural changes

Not for:

  • Resource allocation (use Collective Recognition)

  • Membership decisions (use MRD computation)

  • Daily operations (use Collective Recognition)

  • Project priorities (use Collective Recognition)

Decider Process

Participants: Only current members (MRD ≥ threshold)

Weighted by Recognition: Support points × MRD score

Example: Setting Membership Threshold

Decider Properties

  • Structured: Clear phases prevent chaos

  • Weighted: More integrated members have more influence

  • Collaborative: Ideas improve through challenges and discussion

  • Transparent: All proposals, challenges, support visible

  • Fair: Everyone can propose, challenge, support

4. Complete System in Action

Scenario: Bioregional Water Trust

Week 0: Bootstrap

Week 1: First Resource Allocation

Week 4: New Member Integration

Week 8: Multiple Provider Lenses

Month 6: Success Amplification

Month 12: Parameter Tuning

Year 2: Network Scaling

5. Properties of This System

Philosophical Foundation

This is not charity or altruism - it's mutual self-actualization.

Traditional model:

  • "Donors" give to "beneficiaries"

  • Donor sacrifices for recipient's benefit

  • Creates power dynamic (giver/receiver)

  • Recipient feels dependent or grateful

  • Giver feels benevolent or superior

Free-association model:

  • Everyone invests in their own self-actualization

  • Alice enables Bob's self-actualization; Bob enables Alice's self-actualization

  • Both recognize what enables them

  • Resources flow based on mutual recognition

  • No giver/receiver dynamic - mutual enabling relationship

Example:

This transforms the entire dynamic:

  • Resources flow to what enables self-actualization (not to who can write best grant)

  • Recognition measures actual enabling contribution (not performance for funders)

  • Success = enabling more self-actualization across network (not extracting more funding)

  • Everyone is both enabling and enabled (not givers vs. receivers)

What It Eliminates

  • ❌ Membership approval processes

  • ❌ Resource allocation committees

  • ❌ Grant application reviews

  • ❌ Appointed roles or positions

  • ❌ Governance meetings (except rare Decider for parameters)

  • ❌ Arbitrary funding targets

  • ❌ Selection of beneficiaries

  • ❌ Centralized planning

  • ❌ Giver/receiver power dynamics

  • ❌ Charitable dependency relationships

  • ❌ Performance theater for funders

  • ❌ Intermediate "claim" concept (providers allocate directly to needs)

  • ❌ Admin discretion over entity funds (automatic computational allocation)

What It Guarantees

  • ✓ Membership emerges from contribution and recognition

  • ✓ Resources flow to recognized needs from willing providers

  • ✓ Success amplifies through recognition increase

  • ✓ Failure corrects through recognition decrease

  • ✓ Only providers with actual resources declare capacity

  • ✓ No single point of failure

  • ✓ Transparent and auditable

  • ✓ Scale-invariant (works from 5 to 5000 participants)

  • ✓ Sybil-resistant

  • ✓ Self-organizing around real contribution

  • ✓ Direct allocation from capacity to needs (no intermediate claims)

  • ✓ Entity's own funds allocated computationally (admins never decide)

Emergence Without Central Control

Roles emerge naturally:

Priorities emerge naturally:

Quality emerges naturally:

6. Data Structures

Recognition Data

Membership Output

Need Declaration

Provider Capacity Declaration

Allocation

Decider Session

Need-Capacity Mirror Structure

Key Insight: Needs and Capacities are mirror images of each other.

Why this matters:

  • Sophisticated matching: Can match needs to capacities by time/location/quantity constraints

  • Temporal coordination: "I need 10 hours Monday" matches with "I have 15 hours Monday available"

  • Spatial coordination: "I need office space in Berlin" matches with "I have desk space in Berlin"

  • Flexible fulfillment: One need with multiple slots can be fulfilled by different providers at different times/locations

  • Natural scheduling: Time patterns (recurrence, deadlines) enable automatic scheduling

  • Explicit symmetry: The mirror structure makes the relationship clear and enables algorithmic matching

Example matching:

7. Computation Cycles

Weekly: Membership

Daily: Resource Allocation

As-Needed: Decider

8. Interfaces

Participant Interface

View Your Status:

  • Current MRD score

  • Membership status

  • Recognition breakdown (who recognizes you for what)

  • Trajectory over time

  • Distance to threshold

Submit Recognition:

  • Recognize others (allocate your 100%)

  • Tag recognition by contribution type

  • See your recognition history

Declare Needs:

  • Post what you need

  • See allocations from providers

  • Update as needs change

Declare Capacity (if you're a provider):

  • Declare your available resources

  • Specify set of participants you can support

  • System calculates collective-recognition-shares

  • You allocate to needs based on recognition + availability

View Allocations:

  • Allocations you've received from providers

  • Fulfillment status of your needs

  • Which providers allocated to you

Make Allocations (if you're a provider):

  • See all needs in network

  • Filter by participants in your capacity sets

  • See collective-recognition-shares within your sets

  • Allocate your resources to needs

Observer Interface

Network Health:

  • Member count

  • Total MRS in network

  • Average MRD

  • Recognition density

  • Need fulfillment rate

Active Needs:

  • All open needs

  • Fulfillment rates by type

  • Provider allocation patterns

Recognition Patterns:

  • Who recognizes whom (anonymized)

  • Recognition by type

  • Network topology

  • Emerging roles

Resource Flows:

  • Provider allocations over time

  • Need fulfillment trends

  • Resource velocity

  • Distribution patterns

9. Edge Cases

What if someone tries to declare capacity they don't have?

What if everyone recognizes everyone maximally?

What if a member stops contributing?

What if two disconnected clusters form?

What if threshold is too high/low?

10. The Self-Actualization Economy

From Extraction to Mutual Enabling

Traditional economic models are based on extraction:

  • Employees extract wages from employers

  • Employers extract labor from employees

  • Consumers extract value from producers

  • Producers extract payment from consumers

  • Donors extract gratitude/status from recipients

  • Recipients extract resources from donors

Each transaction is zero-sum or extractive. Someone gains, someone loses.

Free-association is based on mutual enabling:

Key properties:

  1. Non-zero-sum: Alice enabling Bob doesn't diminish Alice - it's part of Alice's self-actualization

  2. Positive feedback: More enabling → more recognition → more resources → more enabling

  3. Natural alignment: Everyone's self-interest is to enable others (that's how you self-actualize)

  4. No extraction: Resources flow to what enables self-actualization, not extracted from losers to winners

Recognition as Truth-Telling About Enablement

Recognition cannot lie (for long):

The system creates pressure toward truth:

  • False recognition hurts your own self-actualization (wrong allocation)

  • Missing recognition hurts your own self-actualization (enabler may reduce contribution)

  • Accurate recognition optimizes your self-actualization

  • Truth-telling is self-interested, not altruistic

Provider Lenses as Organizational Intelligence

Provider capacity declarations reveal organizational perspectives:

No single "correct" organization:

  • Multiple provider lenses

  • Multiple perspectives on who can effectively use resources

  • Multiple coordination pathways

  • Prismatic coordination (same people, different provider views)

Intelligence emerges from multiplicity:

  • Network becomes more intelligent as more provider lenses exist

  • Each provider lens reveals different enabling relationships

  • Providers allocate through their own capacity lenses

  • No central planning needed - organizational intelligence is distributed

Why This Works: Alignment of Incentives

In traditional systems, incentives misalign:

  • Grantseekers optimize for grant writing (not impact)

  • Donors optimize for visible credit (not effectiveness)

  • Committees optimize for defensible decisions (not best outcomes)

  • Organizations optimize for survival (not mission)

In free-association, incentives align:

Self-interest becomes pro-social:

  • Your self-interest = enable others (that's how you self-actualize)

  • Others' success = your success (they recognize you more)

  • Network health = your health (more enabling relationships available)

  • Truth-telling = optimal strategy (accurate recognition optimizes your outcomes)

Scaling Properties

Traditional systems scale poorly:

  • More people → more committees → more bureaucracy

  • More resources → more gate-keeping → more politics

  • More complexity → more rules → less responsiveness

Free-association scales elegantly:

Why it scales:

  1. Fixed individual complexity: Each person manages 100% recognition (doesn't increase with network size)

  2. Distributed computation: No central processor bottleneck

  3. Natural clustering: Sub-networks form around enabling relationships

  4. Multiple coordination layers: Provider capacities create high-level coordination without requiring all-to-all connections

  5. Provider-need matching: Automatic discovery of alignment without search committees

Network effects increase with scale:

  • More providers → better need fulfillment rates

  • More provider capacity declarations → more coordination opportunities

  • More enabling relationships → more self-actualization pathways

  • More specialization → higher quality enabling contributions

11. Administrative Entity Integration

Overview

The Free-Association protocols are implementation-agnostic. They can operate with any legal or administrative structure that provides:

  1. Legal personality or fiscal host relationship (ability to hold/access funds)

  2. Execution mechanism (admins who can approve/execute transfers)

  3. Transparency layer (public or member-visible ledger)

  4. Compliance framework (KYC/AML as required by jurisdiction)

Key principle: The administrative entity/host doesn't decide anything - it acknowledges and executes what the protocols compute.

Implementation Patterns

The protocols can be wrapped by:

A. Incorporated Entity (e.g., Swiss Verein, US 501(c)(3))

B. Fiscally Hosted Collective (e.g., via Open Collective Europe)

C. DAO/Smart Contract (future)

  • On-chain execution

  • Automated compliance via oracles

  • No traditional admins (code executes)

Core Integration Requirements

Regardless of implementation, all structures need:

1. Membership Registry

2. Resource Tracking

3. Execution Mechanism

4. Compliance Layer

5. Transparency

Implementation-Specific Details

For complete implementation guides including:

  • Legal requirements and mappings

  • Admin selection and responsibilities

  • Compliance procedures

  • Financial record keeping

  • Meeting protocols

  • Step-by-step setup instructions

See implementation-specific documentation:

  • Swiss Verein: playnet.gitbook.io/docs/fiscal-interfaces/swiss-association

  • Open Collective Hosted: playnet.gitbook.io/docs/fiscal-interfaces/open-collective

  • Other jurisdictions: Adapt patterns from above examples

Generic Operational Flow

For any implementation:

Key Principles Across All Implementations

  • Admins never decide allocations - Protocol computes based on recognition

  • Compliance filters are computational - Applied before admin sees instructions

  • Membership is automatic - MRD computation determines who participates

  • Resources flow by recognition - Not by voting or discretionary approval

  • Transparency is mandatory - All transactions and rationale visible

  • No governance overhead - Computation replaces committees and approvals

Note: Section 11 previously contained detailed Swiss Verein-specific examples. These have been moved to statutes.md to keep this protocol specification implementation-agnostic. The protocol described here works identically whether wrapped by a Swiss Verein, an Open Collective hosted collective, a US 501(c)(3), or any other administrative structure.

12. Summary

Free-Association

Philosophical Foundation:

Recognition = Your acknowledgment of contributions to YOUR self-actualization

  • Each person has 100% to distribute (your complete self-actualization)

  • Non-transferable (only you can judge what enables you)

  • Dynamically adjustable (as enabling relationships change)

  • Includes both direct contributions and contributions to values/conditions you need

Mutual Recognition = min(recognition in both directions)

  • Ensures reciprocity in proportion

  • Measures genuine mutual interdependence

  • One-sided recognition doesn't create mutual relationship

Resources flow to what enables self-actualization

  • Not charity or altruism - mutual enabling

  • Providers invest in their own self-actualization by allocating to needs

  • Everyone is both enabling and enabled

  • Non-zero-sum: your enabling others IS your self-actualization

Three Computational Mechanisms:

  1. Membership Module → Determines who participates (MRD ≥ threshold)

  2. Resource Allocation → Allocates resources (provider capacities + needs)

  3. Decider → Tunes parameters (rarely, weighted by MRD)

Zero Governance:

  • No appointments (admins = top MRD, opt-in)

  • No committees (computation handles all)

  • No approval processes (MRD determines membership)

  • No voting (except rare Decider for parameters)

  • No centralized planning (provider lenses create coordination)

  • No grant applications (needs + provider allocations)

Complete Functionality:

  • Membership emerges from mutual recognition patterns

  • Resources flow to recognized needs through provider allocations

  • Success amplifies automatically (higher recognition → higher collective-recognition-shares)

  • Failure corrects automatically (lower recognition → lower collective-recognition-shares)

  • Roles emerge from recognition patterns (who's recognized for what)

  • Priorities emerge from allocation patterns (what gets fulfilled)

  • Quality emerges from enabling outcomes (what actually helps self-actualization)

Self-Correcting Properties:

  • Phantom capacity eliminated (only providers with actual resources declare capacity)

  • False recognition hurts your own self-actualization (wrong allocation)

  • Success increases recognition (enabling others → they recognize you more)

  • Failure decreases recognition (not enabling → recognition drops)

  • Stop contributing → lose membership (MRD drops below threshold)

  • Truth-telling is optimal strategy (accurate recognition optimizes outcomes)

Scaling Properties:

  • Fixed individual complexity (always manage 100% recognition)

  • Distributed computation (no bottlenecks)

  • Natural clustering (sub-networks around enabling relationships)

  • Multiple coordination layers (provider capacities)

  • Network effects increase with scale (more providers, more coordination opportunities)

Implementation Integration:

  • Administrative entity is thin wrapper around protocols

  • Admins = top participants by MRD (opt-in)

  • Admins execute protocol outputs (don't make decisions)

  • Members acknowledge computational results (formality)

  • Legal requirements handled by administrative structure

  • Zero governance overhead (computation does the work)

  • Even entity's own funds are allocated computationally (admins never decide)

The Key Insight:

Traditional fiscal interfaces require governance because they assume:

  • Someone must decide who belongs

  • Someone must decide who gets resources

  • Someone must monitor performance

  • Someone must coordinate activity

Free-association eliminates need for governance by recognizing:

  • Recognition patterns determine who belongs (MRD computation)

  • Recognition patterns determine resource flows (provider allocations based on collective recognition)

  • Recognition patterns measure performance (recognition increases/decreases)

  • Recognition patterns create coordination (provider capacities + need matching)

Result: An organization that operates through recognition of mutual enabling, with computational mechanisms handling all coordination, and administrative wrapper for compliance only.

Everyone participates by recognizing what enables them. Resources flow to what's recognized as enabling. The system optimizes for genuine mutual enabling because that's what generates recognition.

The organization is a computational protocol for mutual self-actualization.

PreviousGrammarNextOpen Collective

Last updated

Was this helpful?