Appendix: Technical Details

Status: Draft v0.1 (November 2025) Part of: Participation Framework b1 v0.43

A. Coalition Benefits

1. Partner Discovery

The coalition serves as a platform for discovering and establishing mutual-recognition relationships.

For organizations without existing partners:

  • Access to a network of potential collaborators

  • Transparent recognition patterns to identify aligned organizations

  • Low-barrier entry to coordination networks

  • Natural filtering through mutual recognition mechanics

How it works:

  1. Join the coalition and declare your capacities, needs, and goals

  2. Review other participants' recognition patterns and state declarations

  3. Identify organizations whose goals align with your contributions

  4. Begin recognizing mutually and building coordination relationships

2. Critical & Timely Resource Sharing

Coalition participation enables rapid resource coordination without bureaucratic overhead.

Key distinction: Sharing resource capacities is separate from promising or committing specific resources.

Traditional Approach
Coalition Approach

Formal commitments required

Declare available capacity

Legal agreements necessary

Recognition-based allocation

Long approval processes

Real-time matching

Inflexible allocations

Dynamic responsiveness

Benefits:

  • Speed: Resources flow based on recognition and need, not approvals

  • Flexibility: Adjust capacities as organizational situation changes

  • Autonomy: You decide who to recognize and how much capacity to share

  • Transparency: All participants see capacity and need declarations

Example use cases:

  • Emergency response funding during crises

  • Technical expertise sharing across projects

  • Equipment and facility access coordination

  • Knowledge transfer and capacity building

3. Enhanced Information Sharing

Coalition membership provides structured information exchange across all aspects of coordination.

Information sharing covers:

Category
Examples

Existing Information

Research findings, impact assessments, lessons learned

Data Collection Capabilities

Monitoring systems, evaluation frameworks, measurement tools

Future Information Potential

Planned studies, upcoming assessments, data partnerships

Personnel Expertise

Staff capabilities, technical specializations, advisory capacity

Facilities & Equipment

Lab access, testing facilities, specialized equipment

Networks & Relationships

Partner connections, stakeholder access, community ties

Advantages over traditional information sharing:

  • Structured formats: Standardized data declarations enable automated matching

  • Real-time updates: Information stays current as situations evolve

  • Filtered access: Subscribe only to relevant information streams

  • Provenance tracking: Clear attribution of information sources

  • Interoperability: Data formats designed for cross-system integration

4. Reduced Coordination Overhead

Coalition protocols minimize the transaction costs of multi-stakeholder coordination.

Traditional coordination costs:

  • Endless coordination meetings

  • Proposal writing and grant applications

  • Bureaucratic approval processes

  • Negotiation and contracting

  • Monitoring and reporting

Coalition alternative:

  • Recognition patterns replace lengthy negotiations

  • Need declarations replace grant applications

  • Automated allocation replaces manual decisions

  • Public records replace redundant reporting

Time savings example:

Traditional funding process: 3-6 months (proposal → review → approval → transfer) Coalition allocation: Minutes to hours (need declared → recognition calculated → allocation determined)

5. Network Resilience

Coalition structure creates redundant coordination pathways and reduces single points of failure.

Resilience features:

  • Distributed coordination: No central bottleneck or single point of failure

  • Multiple providers: Resources can flow from various participants

  • Dynamic reallocation: Network adapts automatically to changing conditions

  • Transparent alternatives: Clear visibility into backup options

Coalition Principles

Solidarity

Coalition members are invited to offer support to each other in:

  • Protocol implementation and technical assistance

  • Knowledge sharing and capacity building

  • Recognition of mutual contributions

  • Coordination aligned with freedom of association principles

In practice:

  • Experienced members mentor new participants

  • Technical challenges solved collaboratively

  • Success and lessons learned shared openly

  • Organizational autonomy always respected

Freedom of Association

Participants retain full autonomy to:

  • Choose who to recognize and at what level

  • Decide what capacities to share

  • Determine their own priorities and goals

  • Enter or exit the coalition freely

No one can force you to:

  • Recognize specific organizations

  • Share resources you don't want to share

  • Accept allocations you don't need

  • Implement decisions you don't support

Organizational Expression

Each participant maintains their unique identity and approach:

  • No standardized organizational structure required

  • Diverse decision-making processes respected

  • Multiple coordination protocols supported

  • Cultural and contextual differences honored

B. Technical Clarifications

Recognition Types:

  • Contribution Recognition (-100% to 100%): Evaluates whether an entity positively or negatively impacts your goals/needs. Negative recognition acknowledges harmful or obstructive relationships. Used for evaluation and assessment.

  • Allocation Weight (0-100%, non-transferable, dynamically adjustable): Determines how to divide shared capacities among recognized contributors. Only positive values—you allocate to those you support. Used in resource distribution formulas.

Derivation Algorithms:

  • Mutual Recognition: Calculated as minimum of bidirectional recognition: min(A→B recognition, B→A recognition). Identifies symmetric cooperation relationships.

  • Organizational Recognition: Aggregates individual recognitions weighted by organizational membership. Formula: Σ(member_recognition × member_weight) / total_members where member_weight reflects their standing within the organization.

  • Allocation Formula: Resources distributed proportionally to allocation weights among recognized entities. For capacity C allocated among entities E with weights W: entity_share = (W_entity / ΣW_all) × C

Identity & Verification:

  • UUIDs: Universal Unique Identifiers generated using UUID v4 standard (RFC 4122). Participants self-generate and register their identifiers.

  • Contact Verification: Email addresses verified via confirmation link; public keys verified through challenge-response signing or cross-referenced with existing key servers (PGP, X.509 CAs, DIDs).

Registry vs. Records:

  • Records: Append-only, immutable, timestamped entries in participant-owned namespaces. Each participant writes records only to their own space; all members read from all participant spaces.

  • Registries: Derived views computed from records. Current state representation (e.g., "who is currently a member" derived from all membership_update records aggregated across all participants).

Bootstrap Process:

  1. Initial Participants: Self-organized group declares itself as the founding secretariat

  2. First Protocol: Founding secretariat adopts initial decision-making protocol via consensus

  3. Registry Initialization: Members register their UUIDs and contact information

  4. First Assembly: Convened to formalize structure and invite additional participants

  5. Operational Phase: Regular operation begins with annual assembly cycle

Temporal Aspects & State Management:

  • Record Validity: State declarations include valid_until or expiry timestamps. Expired records don't automatically delete—they remain in history but are excluded from current state derivations.

  • Recognition Currency: Recognition distributions remain valid until superseded by newer distributions from the same issuer. No automatic expiry; participants update as relationships evolve.

  • Framework Versioning: Each framework version tracked via framework_version records. Participants may operate on different versions simultaneously; interoperability maintained through schema transformations.

  • Retroactive Amendments: Amendments don't alter original records (immutability). Instead, record_amendment records reference originals and provide corrected interpretations. Derived views apply latest amendments.

Error Handling & Validation:

  • Format Validation: All records validated against schemas before acceptance. Invalid records receive validation_report with status="invalid" and detailed error descriptions.

  • Logic Validation: Checks for consistency (e.g., recognition percentages within bounds, referenced UUIDs exist). Warnings issued for anomalies but don't block acceptance.

  • Authority Validation: Verifies issuer has authority for the action (participant can only write to their own namespace). Unauthorized writes automatically rejected by topology.

  • Technical Conflict Resolution: When concurrent record edits occur, CRDT semantics provide automatic field-level conflict resolution via last-write-wins with timestamp tie-breaking.

  • Dispute Resolution: When semantic conflicts arise (e.g., two entities claim same identifier, factual disagreements), dispute mechanism invoked. Secretariat applies dispute resolution protocol to determine authoritative interpretation.

Assembly Mechanics:

  • Quorum: Decision-making protocol specifies quorum requirements (typically majority of registered members).

  • Participation Modes: Physical presence, video conference, and asynchronous participation all supported. Assembly minutes record participation method per attendee.

  • Assembly Types:

    • Annual: Yearly gathering, reviews operations and updates protocols

    • Emergency: Convened for urgent matters, expedited decision timeline

    • Working Group: Focused sub-assembly addressing specific topics, reports to main assembly

  • Attendance Confirmation: Invitations require responses. Attendees confirmed when they post invitation_response with response="accept". Minutes use attendance list from responses.

Subscription Mechanism:

  • Data Stream Types: Participants can subscribe to membership changes, recognition updates, state declarations, or computed derivations from any entity.

  • Filters: Subscriptions include optional filter criteria (e.g., "only recognition >10%", "only capacity offers of type 'funding'"). Filters reduce notification volume.

  • Notification Methods:

    • Webhook: Real-time HTTP callbacks when matching records posted

    • Poll: Subscriber queries for updates at their convenience

  • Subscription Privacy: Source entities see who subscribes to their data streams. Enables relationship awareness and reciprocal subscriptions.

  • Implementation: Subscribers post subscription records to their own namespace. Implementations monitor source entity record spaces and deliver matching records according to specified notification method. See format.md for subscription lifecycle details.

Data Topology:

  • Participant-Centric: Each participant maintains their own record space; no shared write location exists

  • CRDT Conflict Resolution: Concurrent record submissions resolve automatically via field-level timestamps

  • Local Aggregation: Each member aggregates records from all participants into local derived views

  • Network Partition Tolerance: Local-first architecture allows continued operation during connectivity issues

PreviousParticipation FrameworkNextCoalition Service Entity

Last updated