Nondominium Documentation

Infrastructure for organization-agnostic, uncapturable, self-governed resources — built on Holochain and ValueFlows.

This page is the hub. Two alternate views of the same corpus: DOCUMENTATION_INDEX.md (annotated guide, with commands and per-area status) and SUMMARY.md (flat linear table of contents).

Getting Started

• TELOS - Project vision, mission, and philosophy
• Requirements - Full requirements document
• Implementation Status - Current development progress

Architecture

• Architecture Components - System design and zome interactions
• NDO v1 Architecture Design - NDO three-layer model
• Zomes Overview - Multi-DNA topology and the Person, Resource, Governance core
• Lobby Zome - Lobby DNA: agent presence and the global group registry
• Group Zome - Group DNA: cloned-cell coordination, membership, soft links, NDO anchors
• hREA Integration - ValueFlows / hREA integration strategy

Requirements

• Agent Ontology - Agent types, identity, affiliation model
• Resource Ontology - Property regimes, lifecycle, governance
• Governance Ontology - Embedded governance, PPR system, validation
• NDO Prima Materia - Normative NDO spec (REQ-NDO-*)
• UI Design - Lobby → Group → NDO navigational hierarchy

Technical Specifications

• Technical Specifications - Zome entries, functions, cross-zome API
• Governance Operator Architecture - State transition pattern
• Governance Implementation Guide - Implementation with code examples
• Cross-Zome API - Zome-to-zome call contracts
• Governance Model - Legacy governance model and decision processes
• Private Participation Receipt - PPR system design
• PPR Security Implementation - PPR security model
• ValueFlows Action Usage - VF action patterns with governance examples
• Protocol Bridge Specifications - Bun bridge for platform integration (Tiki, Odoo)
• UI Architecture - Svelte 5 service and store layer
• API Reference - Complete zome function reference

Development

• Implementation Plan - Phased delivery roadmap
• Development Report - Progress log
• Testing Infrastructure - Sweettest suite guide
• Test Commands - Canonical command reference for every suite
• E2E Test Suite - Playwright against real conductors
• UI README - Frontend dev harness and layout

Applications

• Artcoin - Open-source art economy use case
• Nondominium × Artcoin - Artcoin integration detail
• Distributed Journalism
• ERP Holochain Bridge
• HealthNet
• User Stories - Complete user journey scenarios

Post-MVP

• Unyt Integration - Economic settlement layer
• Flowsta Integration - Cross-app identity and DID
• Resource Transport Flow Protocol
• Full post-MVP set - Versioning, many-to-many flows, digital integrity, DSL

TELOS: Nondominium

Vision

A protocol for resource governance without ownership. Resources participate in Nondominium Object (NDO) lifecycles where rights and responsibilities attach to relationships, not to titles. The goal is infrastructure for commons-based economies that cannot be re-enclosed — not by platform operators, not by nation-states, and not by the project's own developers.

Mission

Build and ship the Holochain hApp and underlying protocol that demonstrates governance-embedded commons management at production scale. Integrate with hREA for ValueFlows semantics. Provide an incremental adoption path so existing organizations (Sensorica, Dolibarr/TikiWiki users, OVN-aligned cooperatives) can participate without wholesale migration.

Philosophy

• Protocol-level economic enforcement over policy-level. CAL-1.0 + AGPLv3 dual license with protocol-level constraints (no re-enclosure, no revocation of nondominium status) baked into governance rules, not documents.
• Three-layer progressive model. Prima Materia (potential, Layer 0) → Specified (designed, Layer 1) → Custodial/Process (instantiated, Layer 2). Coordination overhead matches social complexity; no pre-classification at creation.
• Private Participation Receipts (PPR) as user-sovereign reputation primitive. 16 categories, bilaterally signed, stored as Holochain private entries. No global scoring aggregator, no third-party visibility by default.
• Composability with hREA and ValueFlows, not replacement. NDO entries bridge to hREA's EconomicResource/Agent types. ValueFlows is the canonical action vocabulary.
• Capability-based security via Holochain capability tokens. Access rights are cryptographically issued, field-level scoped, and expire after 30 days maximum.
• Agent-centric data model. All data tied to individual agents' source chains. No shared database. DHT is the coordination layer, not the control layer.
• Embedded governance. Resources carry their own access and transfer rules as GovernanceRule entries on ResourceSpecification. The governance zome is a state-transition operator, not a policy server.

Operating Principles for the AI

• Prefer correctness over cleverness. This is governance infrastructure for real economic relationships. A wrong validation rule on the DHT cannot be rolled back.
• ValueFlows vocabulary is canonical. If a concept exists in VF (EconomicEvent, Commitment, Claim, VfAction), use VF terminology. Do not invent parallel ontologies.
• The NDO architecture in documentation/requirements/ndo_prima_materia.md is load-bearing. Changes to the three-layer model, capability slots, or lifecycle state machine ripple through governance, PPR, and UI. Flag any proposal that touches this document's scope and note the downstream impact.
• PPR must remain user-sovereign. Resist any design that aggregates reputation into global scores, centralizes storage, or enables third-party visibility without explicit capability grant.
• UI work uses Svelte 5 runes, UnoCSS, and Melt UI next-gen (melt). Not shadcn. Not Tailwind utility classes directly in templates. Not Svelte 4 reactive statements ($:). Check the mcp__svelte MCP server for current Svelte 5 API.
• Consult REVIEW.md before proposing PR-shaped changes. It explicitly lists patterns to flag. If your proposed code matches a flagged pattern, explain why it is safe before proceeding.
• Read CONTRIBUTING.md for branch model and commit conventions (feat/, fix/, refactor/, docs/, chore/ prefixes; Conventional Commits scopes).

What This PAI Is NOT For

• General TypeScript or Rust questions disconnected from Nondominium architecture. Use a generic AI session for language-level questions.
• Holochain learning content not specific to this codebase. The holochain-agent-skill covers Holochain generally; this TELOS is for Nondominium-specific decisions.
• Personal or spiritual contexts. Use a personal-level AI session.
• Speculation about post-MVP integrations (Unyt, Flowsta) without first reading their integration docs in documentation/requirements/post-mvp/.

Nondominium Project Documentation Index

Updated: 2026-08-13

Annotated guide to the documentation set. For the topic-grouped hub see README.md; for a flat table of contents see SUMMARY.md.

🎯 Project Overview

Nondominium is a ValueFlows-compliant Holochain application implementing distributed, agent-centric resource management with embedded governance, capability-based security, and cryptographically-secured reputation tracking through Private Participation Receipts (PPRs).

Quick Navigation

• Getting Started - Development setup & quick start
• Architecture - System design & zome interactions
• API Documentation - Complete function reference
• Testing - Test strategy & execution
• Implementation Status - Current development progress

🚀 Getting Started

Prerequisites & Setup

git submodule update --init --recursive  # Initialize the hREA submodule (REQUIRED)
nix develop                              # Enter reproducible environment (REQUIRED)
bun install                              # Install dependencies

Key Documentation:

• 🎯 TELOS - Project vision, mission, philosophy, and AI operating principles
• 📋 Main README - Complete project overview & setup guide
• 🔧 Development Environment - Development patterns & commands

Essential Commands

# Development
bun run start            # Start 2-agent development network with UIs
AGENTS=3 bun run network # Custom agent network

# Testing — Sweettest (Rust, primary)
bun run sweettest        # build:happ + all nondominium Sweettest tests
bun run sweettest:only   # skip the build step

# Testing — E2E (Playwright + real conductors)
bun run e2e
bun run e2e:ui

# Build
bun run build:zomes     # Compile Rust zomes to WASM
bun run build:happ      # Build zomes + hREA, pack all DNAs into the .happ bundle
bun run package         # Create final .webhapp distribution

Canonical command reference for every suite: TEST_COMMANDS.md.

Note: Tryorama (TypeScript) tests in tests/ are deprecated. All new tests use Sweettest (Rust). See tests/DEPRECATED.md.

🏗️ Architecture Overview

System Architecture

nondominium implements a Governance-as-Operator architecture that separates data management from business logic enforcement:

• Framework: Holochain HDK ^0.6.0 / HDI ^0.7.0 (Rust + WASM)
• Frontend: SvelteKit 2 + Svelte 5 + TypeScript + Vite 7
• Testing: Sweettest (Rust, primary) — Tryorama (TypeScript) deprecated
• Client: @holochain/client ^0.20.0
• Package Management: Bun for dependency management and build orchestration

Zome Structure

Governance-as-Operator Architecture

Key Design Principles:

• Modular Design: Resource zome manages data, governance zome enforces rules
• Swappable Governance: Different governance schemes can be applied to same resources
• Pure Function Governance: Stateless evaluation with deterministic outputs
• Event-Driven State Changes: All transitions generate audit events
• Cross-Zome Interface: Well-defined communication protocol

Documentation:

• Governance Operator Architecture - Technical architecture and design patterns
• Governance Implementation Guide - Detailed implementation with code examples
• Cross-Zome API - Complete API specifications

Key Concepts

• 🔐 Capability-Based Security: Progressive trust model (Simple → Accountable → Primary Accountable Agent)
• 📋 Private Participation Receipts (PPRs): Cryptographic reputation tracking across 16 categories
• 🔄 Economic Processes: Structured workflows (Use, Transport, Storage, Repair) with role-based access
• 🛡️ Private Data Sharing: Request/grant workflows with field-level control and time-limited grants (30-day maximum per PrivateDataCapabilityMetadata; shorter defaults may apply in UI flows — see person_zome.md)

📚 Core Documentation

Project Requirements

Architecture & Roadmap

Technical Specifications

Post-MVP Requirements

Testing & Infrastructure

Applications & Use Cases

🔧 API Documentation

Full reference: API Reference

Person Zome API

Core Identity & Access Management

• create_person() - Create agent profile with discovery anchors
• get_person() - Retrieve profile by hash
• get_all_persons() - Discover all agents via anchor traversal
• update_person() - Update profile with validation
• delete_person() - Soft deletion with cleanup

Capability & Security

• create_capability_token() - Issue capability tokens with role restrictions
• get_agent_capability_level() - Query current trust level
• promote_agent_capability() - Advance trust based on PPR milestones

Private Data Sharing

• request_private_data_access() - Request access to specific fields
• grant_private_data_access() - Grant time-limited access (subject to 30-day maximum enforced in capability metadata)
• get_private_data() - Retrieve authorized private data
• revoke_private_data_access() - Revoke granted permissions

Role Management

• assign_role() - Assign roles with validation metadata
• get_agent_roles() - Query current role assignments
• validate_role_requirements() - Check role qualification status

Resource Zome API (Data Model Only)

Resource Specification Management

• create_resource_specification() - Define resource types and properties
• get_resource_specification() - Retrieve specification details
• get_all_resource_specifications() - Discover all specifications
• update_resource_specification() - Modify specifications with validation

Economic Resource Management

• create_economic_resource() - Create resource instances with initial state
• get_economic_resource() - Retrieve resource current state and history
• get_economic_resource_with_state() - Retrieve resource with full state transitions
• update_operational_state() - Update EconomicResource.operational_state
• get_my_resources() - Discover resources where calling agent is custodian
• get_resources_by_specification() - Find resources conforming to specification
• get_resources_by_operational_state() - Query resources by operational state

Cross-Zome State Transitions

• request_resource_transition() - Request state change through governance evaluation
• batch_state_transitions() - Process multiple state transitions efficiently

Governance Zome API (State Transition Operator)

State Transition Evaluation

• evaluate_state_transition() - Evaluate governance rules for state changes
• get_applicable_rules() - Retrieve governance rules for resource/action
• evaluate_rule() - Evaluate individual governance rule
• check_agent_permissions() - Verify agent has required permissions
• get_agent_roles() - Retrieve agent's current role assignments

Economic Event Generation

• generate_economic_event() - Create audit events for state transitions
• validate_transition_chain() - Validate sequence of state changes
• get_transition_history() - Retrieve complete audit trail

Governance Rule Management

• create_governance_rule() - Create new governance rules
• update_governance_rule() - Modify existing rules
• get_governance_rules() - Retrieve applicable rules

Legacy Commitment Management (PPR System)

• create_commitment() - Create commitments with validation rules
• get_commitment() - Retrieve commitment details
• fulfill_commitment() - Mark commitments as fulfilled

PPR System

• issue_ppr() - Issue Private Participation Receipt (16 categories)
• get_ppr_summary() - Retrieve reputation summary across categories
• validate_ppr_eligibility() - Check qualification requirements
• derive_reputation_score() - Calculate cryptographic reputation metrics

Multi-Reviewer Validation

• create_validation_workflow() - Set up validation (2-of-3, N-of-M, simple_majority)
• submit_validation_review() - Submit validation assessments
• check_validation_consensus() - Determine validation outcomes

Agent Promotion

• evaluate_agent_promotion() - Assess readiness for capability advancement
• promote_to_accountable_agent() - Promote based on transaction validation
• promote_to_primary_accountable_agent() - Promote based on PPR milestones

🧪 Testing Infrastructure

Test Architecture

All new tests use Sweettest (Rust) in dnas/nondominium/tests/src/. Tryorama (TypeScript) tests in tests/ are deprecated.

# Prerequisites
bun run build:happ

# Run all tests
CARGO_TARGET_DIR=target/native-tests cargo test --package nondominium_sweettest

# Run a specific module
CARGO_TARGET_DIR=target/native-tests cargo test --package nondominium_sweettest --test person

# Verbose output
CARGO_TARGET_DIR=target/native-tests cargo test --package nondominium_sweettest -- --nocapture

Shared Setup Utilities

• setup_two_agents() — two conductors with nondominium DNA
• setup_three_agents() — three conductors with nondominium DNA
• setup_dual_dna_two_agents() — two conductors with nondominium + hREA DNAs

Development Tips

• Use warn! macro in Rust zome functions to log debugging information visible in test output
• Use #[ignore] on tests not yet ready for execution
• DHT sync between agents: await_consistency_20_s([&cell_a, &cell_b]).await.unwrap() (pass the array by value, not &[...])

📊 Implementation Status

✅ Phase 1 Complete: Foundation System

• Person Management: Agent profiles, roles, and basic capability tokens
• Identity System: Pseudonymous identity with public/private separation
• Basic Access Control: Role-based access with validation metadata
• hREA Bridge: Person/ReaAgent bridge for ValueFlows compliance

✅ MVP Complete: Advanced Governance & UI

• Capability-Based Sharing: Complete request/grant workflows with time-limited grants (30-day cap)
• PPR System: 16-category reputation tracking with cryptographic signatures
• Economic Processes: Four structured processes (Use, Transport, Storage, Repair)
• Multi-Reviewer Validation: 2-of-3, N-of-M, and simple majority validation
• Agent Promotion: Progressive trust model with automatic advancement
• NDO Layer 0: NondominiumIdentity permanent identity anchor with lifecycle transitions
• MVP UI: Lobby → Group → NDO three-level hierarchy, NDO creation, lifecycle browser, fork friction modal

🔄 Phase 2 (In Progress): Economic Processes & PPR Generation

• Economic processes (Use/Transport/Storage/Repair) backend
• PPR receipt generation from Commitment/Claim/Event cycles
• Governance-as-operator full implementation
• Agent promotion workflows

📋 Post-MVP

• Group DNA backend, NDO cell cloning
• PPR reputation UI
• Unyt/Flowsta integrations
• Collective agent types, affiliation spectrum

🔍 Advanced Features

Private Participation Receipt (PPR) System

16 PPR Categories:

Genesis Roles (Network Entry):

1. ResourceCreation - Recognition for successful resource contributions
2. ResourceValidation - Credit for network validation activities

Core Usage Roles (Custodianship): 3. CustodyTransfer - Outgoing custodian recognition 4. CustodyAcceptance - Incoming custodian validation

Intermediate Roles (Specialized Services): 5. MaintenanceCommitmentAccepted - Maintenance agreement recognition 6. MaintenanceFulfillmentCompleted - Maintenance service completion 7. StorageCommitmentAccepted - Storage service agreement 8. StorageFulfillmentCompleted - Storage service completion 9. TransportCommitmentAccepted - Transport service agreement 10. TransportFulfillmentCompleted - Transport service completion 11. GoodFaithTransfer - Trust-based transfer recognition

Network Governance: 12. DisputeResolutionParticipation - Constructive conflict resolution 13. ValidationActivity - Ongoing validation duties 14. RuleCompliance - Consistent governance adherence

Resource End-of-Life: 15. EndOfLifeDeclaration - Responsible lifecycle management 16. EndOfLifeValidation - Expert validation services

Economic Processes with Role-Based Access

Progressive Trust Model

Simple Agent (member)
├── General capability token
├── Can create resources & make first transaction
├── PPR eligibility: ResourceContribution upon validation
└── Promotion: First validated transaction → Accountable Agent

Accountable Agent (stewardship)
├── Restricted capability token
├── Can access resources & validate others
├── PPR eligibility: Service processes & validation
└── Promotion: PPR milestones + role validation → Primary Agent

Primary Accountable Agent (coordination/governance)
├── Full capability token
├── Can hold custody & validate specialized roles
├── PPR eligibility: All 16 categories
└── Advanced: Dispute resolution & end-of-life validation

🔗 External References

Technology Stack

• Holochain - Distributed application framework
• ValueFlows - Economic coordination ontology
• hREA - Holochain implementation of ValueFlows
• @holochain/client - UI client library
• Holochain Playground - Development tools

Development Tools

• hc CLI - Holochain development tool
• Svelte - Frontend framework
• Vite - Build tool and development server

📝 Development Notes

Code Patterns

• Entry Creation: All zomes follow consistent create/get/update/delete patterns
• Anchor Links: Discovery anchors for all major entry types
• Validation: Comprehensive validation with role-based access control
• Privacy: Public/private data separation with capability-based access

Testing Patterns

• Multi-Agent: All tests support 2+ distributed agents
• DHT Sync: Use await_consistency_20_s with the timeout wrapper
• Debug Support: Verbose logging with warn! macro for Rust debugging
• Isolation: Test isolation with proper cleanup between scenarios

Performance Considerations

• WASM Compilation: Rust zomes compiled to WASM for efficiency
• DHT Optimization: Efficient link traversal for discovery operations
• Validation Caching: Role and capability validation caching
• PPR System: Optimized reputation calculation with cryptographic proofs

🔄 Document Maintenance

Last Updated: 2026-05-04 Maintainers: Development Team

Update Process

1. Code changes → Update relevant API documentation
2. Feature completion → Update implementation status
3. Architecture changes → Update architecture overview
4. Test additions → Update testing documentation

nondominium - Requirements Document

1. Executive Summary

nondominium is a foundational infrastructure project aimed at enabling a new class of Resources that are organization-agnostic, uncapturable, and natively collaborative. These Resources are governed not by platforms or centralized authorities, but through embedded rules, transparent peer validation, and a comprehensive reputation system.

The project's central goal is to support a true sharing economy, overcoming the structural flaws of centralized platforms (centralization of power, censorship, unsuitable regulations).

Built on the Holochain framework and using the ValueFlows standard, nondominium allows any Agent to interact with these Resources in a permissionless but accountable environment, with automatic reputation tracking through Private Participation Receipts (PPRs).

Optional post-MVP economic ontology: The universal NDO baseline models ValueFlows' Agent and Resource primitives. Applications whose domain includes generative, non-ownable systems may progressively activate Source as a third category (watersheds, rivers, forests, fisheries, knowledge commons) that yields Resources, receives ecological effects, and carries adaptive stewardship governance. Source is not required for ordinary Project NDOs or resource-mutualisation applications. Sources are not owned EconomicResource instances and not intentional Agents. Normative detail: source-ndo-requirements.md (REQ-SOURCE-*); implementation phasing: implementation_plan.md §12.7.

2. Objective & Goals

2.1 Main Objective

Develop a new class of Resources that are:

• Permissionless Access: Anyone can Access Resources under defined governance rules
• Organization Agnostic: Exist independently of any single organization. Not owned or controlled by any single Agent or organization.
• Capture Resistant or Unenclosable: Uncapturable and resilient to monopolization. No Agent or group of Agents can control or delete Resources.
• Self-governed: Rules driven associated directly with the Resources, which govern interactions or Actions that Agents can take, as defined by the system. Roles: Set of Activities or types of interactions that an Agent can perform with respect to the Resource. Also related to Custody (responsibility), maintenance or improvements (obligations). Access control: Rules associated with Roles of Agents, membranes, to grant permissions to interact with Resources in specific ways, Role-related. Is pseudonymous.
• Self-regulated: Peer reviewed, verified and tested (quality control)
• Shareable by Default: Resources are designed for sharing from inception
• Credentials and Reputation-enabled: Built-in accountability through cryptographically-signed participation tracking
• Process-aware: Supporting structured Economic Processes (Use, Transport, Storage, Repair)
• Fully specified: Machine readable in terms of function, design architecture, standards (dimensions, tolerances, quality), etc.
• Composable: Resources can be combined into complex resources, allow fork and remix
• Hard to Clone: Governance, set of rules and incentives to make unnecessary copying of a resource unlikely.
• Lifecycle Managed: Resources have managed lifecycles from creation through validation to end-of-life.
• Traceable: Full provenance and economic activity tracking, affiliation to component resources

2.2 Supporting Goals

1. Digital Representation: Define machine-readable, digital, and material Resources as nondominium, implemented as DHT entries on Holochain
2. Proof-of-Concept Implementation: Build and test a prototype of a distributed platform supporting Resource sharing under the nondominium property regime
3. Governance and Incentive Layer: Implement all ValueFlows Actions and Economic Processes with embedded governance rules
4. Identity and Role System: Develop Agent identity infrastructure supporting pseudonymity, credentials, and private entry identification
5. Reputation System: Implement Private Participation Receipts (PPRs) for trustworthy, cumulative reputation tracking
6. Process Management: Support structured Economic Processes with role-based access control
7. Ecological and knowledge commons (optional post-MVP profile): Where an application's domain actually includes a generative system, activate Source / Source-NDO so boundary events (extraction, loading, restoration) are recorded on-ledger and govern adaptive access — without imposing Source concepts on simpler Project or resource-sharing applications (REQ-SOURCE-APP-, REQ-SOURCE-)

2.3 Post-MVP capability integrations and application profiles

The current MVP in this repository implements ResourceSpecification, EconomicResource, and GovernanceRule with governance-as-operator patterns as specified elsewhere in this document. Normative requirements for the generic Nondominium Object (NDO) — three-layer model, lifecycle vs operational state, capability slot surface, and typed integration with external operators — live in ndo_prima_materia.md (REQ-NDO-L0 through REQ-NDO-AGENT-08, REQ-NDO-CS-01 through REQ-NDO-CS-15, migration §10).

Optional, pay-as-you-grow integrations and application profiles (communities may adopt any subset):

Knowledge-base context (ontology, OVN alignment, gap analysis): resources.md, agent.md, governance.md, source-ndo-requirements.md. This PRD remains the anchor for MVP user stories and REQ-USER / REQ-RES / REQ-GOV IDs; NDO-wide REQ-NDO-* IDs are defined in ndo_prima_materia.md §9; Source-NDO REQ-SOURCE-* IDs are defined in source-ndo-requirements.md §8.

3. nondominium Resource Characteristics

The requirements below apply to appropriable Resources (EconomicResource instances under a ResourceSpecification). They do not apply to Sources (generative ecological or knowledge systems modeled as Source-NDOs post-MVP) — see §4.6 and REQ-SOURCE-ONT-02. In Ostrom's SES terms: a Source is the resource system; an EconomicResource is the resource unit extracted or held in custody from it.

nondominium Resources must exhibit the following characteristics:

• REQ-RES-01: Permissionless Access: Anyone can access nondominium Resources under defined governance rules. Post-MVP note: "defined governance rules" must be extensible to include AffiliationState-based conditions (e.g. min_affiliation: ActiveAffiliate) in addition to role-based conditions; see REQ-AGENT-03, REQ-AGENT-05, and REQ-GOV-09 annotation below.
• REQ-RES-02: Organization Agnostic: Resources exist independently of any single organization and are associated with Agents according to their Roles. Post-MVP note: "Agents" must encompass all AgentEntityType variants (Individual, Collective, Project, Network, Bot) — see REQ-AGENT-01 and REQ-AGENT-02; EconomicResource.custodian will expand from AgentPubKey to AgentContext.
• REQ-RES-03: Capture Resistant: No Agent or group can control, delete, or monopolize nondominium Resources
• REQ-RES-04: Self-governed: Governance rules are embedded within ResourceSpecifications and enforced programmatically
• REQ-RES-05: Fully Specified: Resources are machine-readable in terms of function, design, standards, and governance rules
• REQ-RES-06: Hard to Clone: Governance, incentives, and reputation systems make unnecessary copying unlikely
• REQ-RES-07: Shareable by Default: Resources are designed for sharing from inception
• REQ-RES-08: Process-Enabled: Resources can be used in structured Economic Processes (Use, Transport, Storage, Repair)
• REQ-RES-09: Lifecycle Managed: Resources have managed lifecycles from creation through validation to end-of-life
• REQ-RES-10: Source Boundary (post-MVP): Generative ecological or knowledge systems (watersheds, rivers, forests, fisheries, open knowledge commons) SHALL NOT be modeled as owned EconomicResource instances with a primaryAccountable custodian when their correct ontological category is Source. Such systems SHALL be registered as Source-NDOs (NondominiumIdentity + SourceProfile) with property_regime of Nondominium or CommonPool only. Extracted or appropriated units (water m³, fish landed, timber cut) remain EconomicResource instances linked to boundary events on the Source. See REQ-SOURCE-ONT-01, REQ-SOURCE-ONT-02, and §4.6.

4. User Roles & Stories

4.1 Simple Agent

A user who can search for nondominium Resources and contribute new ones. Linked to a general capability token.

Identity & Onboarding

• REQ-USER-S-01: As a Simple Agent, I want to use the nondominium hApp with minimal effort and without permission
• REQ-USER-S-02: As a Simple Agent, I want to complete my identity by associating private information (legal name, address, email, photo ID) with my Agent identity, stored as Holochain private entries

Resource Discovery

• REQ-USER-S-03: As a Simple Agent, I want to search for available nondominium Resources and their specifications
• REQ-USER-S-04: As a Simple Agent, I want to search for other Agents, view their public profiles and roles

Resource Creation

• REQ-USER-S-05: As a Simple Agent, I want to create new nondominium Resources with embedded governance rules
• REQ-USER-S-06: As a Simple Agent, I want to interact with Agents interested in accessing my created Resources

First Transaction & Promotion

• REQ-USER-S-07: As a Simple Agent, I want to make my first transaction, transferring my new Resource to an Accountable Agent
• REQ-USER-S-08: As a Simple Agent, I want to become an Accountable Agent after my first transaction is validated

4.2 Accountable Agent

A user who can signal intent to access Resources and participate in governance. Linked to a restricted capability token.

Resource Access

• REQ-USER-A-01: As an Accountable Agent, I want to search for available nondominium Resources and their governance rules
• REQ-USER-A-02: As an Accountable Agent, I want to search for other Agents and view their reputation summaries
• REQ-USER-A-03: As an Accountable Agent, I want to create new nondominium Resources with embedded governance rules
• REQ-USER-A-04: As an Accountable Agent, I want to signal intent to access Resources for specific Economic Processes (Use, Transport, Storage, Repair)

Role & Process Management

• REQ-USER-A-05: As an Accountable Agent, I want to acquire specialized roles (Transport, Repair, Storage) through validation. Conditional post-MVP note: applications that enable the Source-NDO profile add Steward as a validated functional role for generative-system governance (§4.6, REQ-USER-ST-*); other applications do not expose it
• REQ-USER-A-06: As an Accountable Agent, I want to initiate and complete Economic Processes according to my roles
• REQ-USER-A-07: As an Accountable Agent, I want to chain multiple process actions (e.g., transport → repair → transport) in a single commitment

Validation & Governance

• REQ-USER-A-08: As an Accountable Agent, I want to validate new Resources during first access events
• REQ-USER-A-09: As an Accountable Agent, I want to validate Agent identity information and first transactions
• REQ-USER-A-10: As an Accountable Agent, I want to validate Economic Process completions and outcomes

Reputation & Participation

• REQ-USER-A-11: As an Accountable Agent, I want to receive Private Participation Receipts for all my economic interactions
• REQ-USER-A-12: As an Accountable Agent, I want to view my reputation summary and participation history
• REQ-USER-A-13: As an Accountable Agent, I want to cryptographically sign participation claims to ensure authenticity

4.3 Primary Accountable Agent (Custodian)

The agent with physical possession (custodianship) of a material nondominium Resource.

Custodial Responsibilities

• REQ-USER-P-01: As a Primary Accountable Agent, I want all capabilities of an Accountable Agent
• REQ-USER-P-02: As a Primary Accountable Agent, I want to apply governance rules programmatically for access decisions
• REQ-USER-P-03: As a Primary Accountable Agent, I want to manage Resource custody transfers with full audit trails

Advanced Governance

• REQ-USER-P-04: As a Primary Accountable Agent, I want to validate specialized role requests from other Agents
• REQ-USER-P-05: As a Primary Accountable Agent, I want to participate in dispute resolution processes
• REQ-USER-P-06: As a Primary Accountable Agent, I want to initiate Resource end-of-life processes with proper validation

4.4 Agent Ontology Requirements (Post-MVP)

Status: Post-MVP. Gaps identified against the OVN wiki ontology (15 years of commons-based peer production practice). See documentation/requirements/agent.md for the full analysis. Requirements below are design targets for the generic NDO; the current MVP implements individual agents only.

Agent Type Taxonomy

• REQ-AGENT-01: Agent Type Field: Every agent context must carry an AgentEntityType discriminant: Individual, Collective(String), Project(ActionHash), Network(ActionHash), Bot { capabilities, operator }, ExternalOrganisation(String). The MVP supports Individual only; all other variants require post-MVP implementation.
• REQ-AGENT-02: Collective Agents — Dual-Face Model: Groups, working groups, projects, and network-level entities are composed agents. Each has an agent face (AgentContext with the relevant AgentEntityType variant) through which it participates in economic events as provider/receiver, and may optionally have a resource face (NondominiumIdentity) as its digital twin. The ActionHash in Project(ActionHash) and Network(ActionHash) links the agent face to the resource face. These two faces are ontologically distinct — the NondominiumIdentity is a Resource; the AgentContext is an Agent — and neither replaces the other. Individual agents hold roles in both their own profile and in collective agents' governance. Collective agents may act through multi-signature patterns (N-of-M member authorisation) when performing economic events.
• REQ-AGENT-03: Bot/AI Delegation: A DelegatedAgent relationship must allow a Person to authorise an AI agent or bot to act on their behalf within a defined scope of capabilities and for a defined duration.

Affiliation Spectrum

• REQ-AGENT-04: Five-State Affiliation: The system must model the OVN affiliation spectrum — UnaffiliatedStranger, CloseAffiliate, ActiveAffiliate, CoreAffiliate, InactiveAffiliate — as a derived (not stored) property computed algorithmically from PPR activity, recency, and contribution history. Binary "in/out" membership is insufficient for governance decisions.
• REQ-AGENT-05: Affiliation Record: Formal network entry must be formalised as an AffiliationRecord entry: the agent cryptographically signs acknowledgement of the Terms of Participation (ToP), the Nondominium & Custodian agreement, and the Benefit Redistribution Algorithm. This record is the prerequisite for ActiveAffiliate status.
• REQ-AGENT-06: Configurable Role Taxonomy: The RoleType enum must become configurable at the network level. Communities must be able to define their own role taxonomies rather than relying on the six predefined types (SimpleAgent, AccountableAgent, PrimaryAccountableAgent, Transport, Repair, Storage). Predefined roles become defaults, not constraints. Post-MVP note: Source-enabled applications add Steward as an application-profile role for generative-system governance (§4.6); applications without Sources SHALL NOT expose or require it.

Composable Profile

• REQ-AGENT-07: AgentProfile View: The system must expose a composable AgentProfile query that aggregates Person, ReputationSummary, PersonRole list, active commitment count, economic event counts, CapabilitySlot attachments, and network affiliations into a single queryable view. This view is computed from existing DHT data — it is not a new stored entry type.
• REQ-AGENT-08: Social Graph: The system must model peer relationships via an AgentRelationship bidirectional link type (typed: colleague, collaborator, trusted, voucher), stored privately. Social relations are part of agent wealth in the OVN model and must be legible to governance without being publicly exposed.
• REQ-AGENT-09: Network Affiliations: Agents must be able to hold membership in multiple NDO networks simultaneously. Cross-network affiliations must be modelled as typed links from Person to other NDO instance hashes, enabling agents to be bridge nodes between communities.
• REQ-AGENT-10: Needs and Wants: An optional AgentNeedsWants profile extension must allow agents to declare what resources they need and what they can offer, enabling matching at the network level.

Identity, Privacy, and Portability

• REQ-AGENT-11: CapabilitySlot on Agent: The Person entry hash must serve as a stigmergic attachment surface (analogous to the resource-level CapabilitySlot) for external credential wallets, DID documents, reputation oracles, and professional networks. Agents can attach capabilities to their identity without modifying the core Person entry.
• REQ-AGENT-12: Portable Credentials: The system must support a PortableCredential structure — a cryptographically signed summary of an agent's roles and ReputationSummary — that can be verified by other Holochain networks. This implements the OVN requirement for cross-network identity portability.
• REQ-AGENT-13: Zero-Knowledge Capability Proofs: Agents must be able to prove capability eligibility (I have at least N completed maintenance commitments) without revealing the underlying PPR data. ZKP proofs break the false binary between full data disclosure (low privacy) and no disclosure (no accountability).
• REQ-AGENT-14: Pseudonymous Participation Mode: The system must support ephemeral participation: an agent contributes under a temporary key without linking to their Person entry. Contribution is recorded but unlinkable to physical identity. This is the individual-level participation tier in the OVN individual/person model.
• REQ-AGENT-15: Sybil Resistance: Network membership must support optional sybil-resistance mechanisms: social vouching (existing agents vouch for new agents), biometric opt-in, or integration with an external Proof-of-Personhood system, configurable per network as a membrane proof.

Promotion Workflow Integrity

• REQ-AGENT-16: Queryable Promotion Requests: The request_role_promotion function must create a real, queryable RolePromotionRequest entry linked to both the requesting agent and an anchor for pending requests — not return a placeholder hash. Promotion requests must be discoverable by authorised approvers.

4.5 MVP UI Requirements

Status: Implemented in the current codebase. See documentation/specifications/ui_architecture.md for design; documentation/IMPLEMENTATION_STATUS.md for status.

These requirements govern the Svelte 5 / SvelteKit frontend implemented in the ui/ directory. They derive from documentation/requirements/ui_design.md and the reconciliation decisions documented in GitHub Issue #102 (where conflicts arose, ui_design.md is the source of truth).

Navigational Hierarchy

• REQ-UI-NAV-01: Three-Level Hierarchy: The UI must implement Lobby → Group → NDO as the navigational hierarchy. Users enter via the Lobby, join or create Groups, and access NDOs within a Group context.
• REQ-UI-NAV-02: Group-Scoped NDO Creation: NDOs may only be created from within a Group. There is no global "Create NDO" flow. The /ndo/new route must redirect to the relevant Group or provide an explanation.
• REQ-UI-NAV-03: Context-Aware Sidebar Link: The "New NDO" Sidebar link must navigate to /group/{id}?createNdo=1 when a Group is selected, or to /ndo/new (explanation) otherwise.

Lobby

• REQ-UI-LOBBY-01: NDO Browser: The Lobby must display all known NDOs in a browse-and-filter grid. Filter chips must allow multi-select across LifecycleStage, ResourceNature, and PropertyRegime simultaneously. OR logic applies within each dimension; AND logic applies across dimensions.
• REQ-UI-LOBBY-02: Group Sidebar: The Lobby must include a sidebar listing the agent's Groups, with "Create Group" and "Join Group" actions. New or joined Groups must appear immediately and navigate the agent to the Group view.
• REQ-UI-LOBBY-03: Lobby Profile Bar: The Lobby must display the agent's nickname from LobbyUserProfile, or a "Set up profile" CTA if no profile exists.

Identity — Three Levels

• REQ-UI-ID-01: LobbyUserProfile (Level 1): Agents must be prompted to create a LobbyUserProfile (nickname required; real name, bio, email, phone, address optional) on first Lobby entry. This profile is stored in localStorage only and does not require a DHT write.
• REQ-UI-ID-02: GroupMemberProfile (Level 2): On first entry to each Group, agents must be prompted to choose how their LobbyUserProfile data is presented to other Group members (anonymous vs. selective disclosure). This choice is stored per-Group in localStorage.
• REQ-UI-ID-03: Person entry (Level 3): A Person entry in zome_person is created at most once — on the agent's first DHT-active action (e.g., NDO creation, acceptance of a Commitment). Lobby browsing and Group membership do not require a Person entry.

Groups (DNA-backed)

• REQ-UI-GRP-01: Group as cloned DNA cell: Groups are DNA-backed (PR #107). Each group is a cloned Group DNA cell (clone_cell, zome_group) with its own isolated DHT, announced for discovery via the Lobby DNA. The LobbyService/GroupService interface remained stable across the localStorage→DNA migration so components were not changed. Only the Level 2 GroupMemberProfile presentation choice (REQ-UI-ID-02) remains in localStorage. (Originally specified as a localStorage shell; superseded by the Group DNA backend.)
• REQ-UI-GRP-02: Invite Links: Groups must support invite links that allow another agent to join by pasting a link. Implemented as a base64-encoded { network_seed, group_dna_hash, group_name } payload (?group=<base64>); joining provisions the same-seed clone cell and calls join_group. The joined group must appear without a page reload (gossip-retry on get_my_group with an invite-payload fallback).
• REQ-UI-GRP-03: Group-scoped NdoBrowser: The Group view must display only the NDOs anchored in that Group, using the same filter chip UI as the Lobby NdoBrowser.
• REQ-UI-GRP-06: NDOs are per-cell, anchored per group: Each NDO is its own cloned ndo DNA cell whose DnaHash is bound to the immutable Layer 0 classification through DNA properties (ADR-010/ADR-013). A group points at an NDO through an NdoAnchor entry on the group clone cell carrying the full clone coordinates (ndo_dna_hash, network_seed, identity_action_hash) plus cached card fields, so browsing renders from anchors without joining any NDO cell and any member can re-derive, verify, and join the cell from the anchor alone (ADR-011). The anchor is the only pointer the read paths follow: creating an NDO must fail if its anchor cannot be written, and associating an existing NDO with a second Group must write a second anchor there. Only name, description, and lifecycle_stage may be updated on an anchor; the identity coordinates are integrity-immutable. Rationale and constraints: documentation/specifications/adr/ADR-010-013-per-ndo-cells.md.
• REQ-UI-GRP-04: DHT-backed member list with self-healing membership: The Group view must list all group members, derived from GroupMembership entries on the group clone cell (get_group_members; each member is a membership action's author). Because joining commits membership best-effort over a gossiping DHT, the UI must idempotently reconcile membership when a group is opened (ensureMembership: resolve group hash → is_member → join_group if missing) so a joined agent reliably appears in every member's list. Cross-member visibility of newly committed memberships is subject to DHT gossip.
• REQ-UI-GRP-05: Reactive shared-group items: Changes to shared-group items (members, NDO associations) made by other members must surface in the UI without a manual reload. The MVP satisfies this with a pull model: per-open reconciliation plus a silent refresh on tab focus/visibility and a gentle poll while the group is open. Push-based delivery via Holochain remote_signal is the documented next step (TODO(signals)); until then, cross-member updates appear within the poll interval, on focus, or on reload.

NDO Management

• REQ-UI-NDO-01: NDO Creation Form: The NDO creation form must include: name (text), property_regime (select, 7 canonical options — Private, Commons, Collective, Pool, CommonPool, Public, Nondominium — with tooltips), resource_nature (select, 5 options with tooltips), lifecycle_stage (select, 7 creatable-at-registration stages — Ideation through Active; Hibernating and terminal stages are transition-only), description (textarea). Name uniqueness is checked client-side against existing lobby NDOs (warning, not block).
• REQ-UI-NDO-02: Initiator Display: The NDO identity panel must display the initiator's Person.name as a profile link, or fall back to a truncated AgentPubKey if no Person entry exists.
• REQ-UI-NDO-03: Lifecycle Transition: The initiator of an NDO must have access to a lifecycle transition button. The frontend must encode the full valid transition table (mirroring the Rust validation). Special cases: Deprecated requires successor NDO selection; Hibernating requires confirmation.
• REQ-UI-NDO-04: Transition History: NDO identity panels must show a collapsible transition history panel listing from_stage, to_stage, agent, timestamp, and event_hash (with copy-to-clipboard) for each recorded transition.
• REQ-UI-NDO-05: Fork Button: An informational "Fork this NDO" button must be accessible to all authenticated users. The fork modal must explain the fork friction concept (negotiation, consensus, post-MVP Unyt stake) and provide a copy-initiator-pubkey CTA. Actual fork submission is post-MVP.

4.6 Source Ontology Requirements (Post-MVP)

Status: Optional post-MVP application profile. Normative REQ-SOURCE-* IDs and full data-model specification live in source-ndo-requirements.md. Academic grounding: source-ndo-paper.md. Implementation phasing: implementation_plan.md §12.7. Source-NDO does not break existing REQ-NDO-* invariants (Layer 0 permanence, PPR privacy model) and is not part of the minimum UI or ontology for every NDO application.

Applicability and progressive activation

Source follows dynamic complexity matching: the application SHALL expose only the primitives required by its actual coordination problem. Agent + Resource remain the baseline. Source is activated only when agents must govern a generative system's condition, boundary flows, regeneration, or assimilation capacity.

Source is normally relevant when:

• the object of governance is a resource system rather than an appropriable unit (e.g. watershed vs water in a tank; fishery vs landed fish);
• extraction, loading, regeneration, or coupled Source condition must be visible on-ledger;
• adaptive stewardship rules must respond to accumulated condition signals.

Source is normally not relevant when:

• a Project-type NDO coordinates the design of an open-source hardware device; Agents contribute work and the design/artifacts are Resources;

• an NDO represents a mature, in-use Resource being mutualised, such as a 3D printer shared within or between Groups; Agents, custody, access, maintenance, and Resource events are sufficient;

• no generative system or Source boundary is itself being governed. Provenance from nature alone does not require Source activation.

• REQ-SOURCE-APP-01: Optional Application Profile: Source support SHALL be an opt-in application/profile capability, not a mandatory primitive in every NDO creation flow or detail view.

• REQ-SOURCE-APP-02: Complexity-Matched Activation: Applications SHALL activate Source features only when their domain requires governance of a generative system or its boundary effects. Ordinary Project and resource-mutualisation flows SHALL remain complete using Agent and Resource primitives alone.

• REQ-SOURCE-APP-03: No Universal UI Burden: Applications that do not enable the Source profile SHALL NOT display Source type selectors, regime-state fields, stewardship workflows, Source coupling graphs, or Source-specific navigation.

• REQ-SOURCE-APP-04: Progressive Enablement: Enabling Source support SHALL add Source-specific data, governance, and UI modules without changing existing Agent/Resource semantics or requiring existing NDOs to migrate into Source-NDOs.

Ontological position

ValueFlows and REA model Agent (acts, commits, bears responsibility) and Resource (appropriable output). A river, watershed, forest, or fishery fits neither honestly: as EconomicResource it implies ownership; as Agent it imports false intention; omitted entirely, extraction appears as resource-from-nowhere (raise) and depletion vanishes from the ledger.

Source is the third flow endpoint: a generative, non-ownable, partially unknowable system that yields Resources, receives ecological effects, conditions other Sources, and accumulates boundary-event history for adaptive stewardship. Source-NDOs use the same three-layer NDO model; Layer 0 carries a linked SourceProfile; stewardship uses stewardedBy (obligations), not primaryAccountable (ownership).

• REQ-SOURCE-ONT-01: The system SHALL recognise Source as a distinct ontological category for flow endpoints in economic events, separable from both Agent and EconomicResource (vf:Source ValueFlows extension).
• REQ-SOURCE-ONT-02: Source-NDOs SHALL NOT require a primaryAccountable agent. property_regime SHALL be Nondominium or CommonPool only. Governance SHALL reject any rule that assigns Source ownership or alienation.
• REQ-SOURCE-ONT-03: The system SHALL support Source-to-Source links (yields, conditions, providedBy) for hierarchies and ecological coupling (e.g. watershed → river; forest conditions river flow).
• REQ-SOURCE-ONT-04: Source-NDOs SHALL be NondominiumIdentity entries with a linked SourceProfile, using the permanent Layer 0 hash as the boundary-event ledger anchor.

Data model

• REQ-SOURCE-DATA-01: SourceProfile SHALL record ecological condition state (current_stock, flux_rate, assimilation_capacity, regime_state, resilience, tipping_threshold), complexity-economics indicators (adaptive_capacity, generative_capacity, dependency_index), classification (source_type, complex_interior), and stewarded_by. Full field spec: source-ndo-requirements.md §4.1.
• REQ-SOURCE-DATA-02: SourceRegimeState SHALL progress through Pristine → Stable → Stressed → Degraded → Critical → Transformed, with governance-validated transitions (not unilateral writes).
• REQ-SOURCE-DATA-03: Layer 1 SourceSpecification SHOULD support a multidimensional ecological value vector (Sustenance, Regeneration, Resilience, Adaptive Capacity, Generative Capacity, Commons Value, Learning Value).

Black-box principle: Ecological Source interiors are not modeled. Governance operates on observable boundary signals (withdrawals, pollutant loads, monitoring data, community observation) and adapts rules from the accumulated ledger — consistent with complexity-science treatment of SES as partially unknowable (source-ndo-requirements.md §2.4, §5.1).

Steward user stories

The Steward role is a functional stewardship role (obligations without alienation rights), distinct from PrimaryAccountableAgent custody of material Resources.

Source registration and monitoring

• REQ-USER-ST-01: As a Steward, I want to register a Source-NDO (watershed, river, fishery, knowledge commons) with initial condition indicators and named co-stewards, without assigning ownership
• REQ-USER-ST-02: As a Steward, I want to submit monitoring data and qualitative condition observations that update the Source's regime state through governance-validated assessment
• REQ-USER-ST-03: As a Steward, I want to link sub-Sources and coupling relations (watershed yields river; forest conditions river) so ecological structure is legible on the DHT

Boundary events and access

• REQ-USER-ST-04: As an Accountable Agent, I want to record extraction from a Source (provider: Source, receiver: Agent) so depletion is visible against current_stock or period quota — not as a phantom raise
• REQ-USER-ST-05: As an Accountable Agent, I want to record pollutant loading into a Source (receiver: Source) so assimilation capacity debits are visible on-ledger
• REQ-USER-ST-06: As a Steward, I want access affordance rules (quotas, seasonal limits, discharge caps) to adapt when regime state or monitoring indicates stress, through a defined governance process — not only static one-shot rule evaluation

Governance adaptation

• REQ-USER-ST-07: As a Steward, I want to propose SourceRegimeState transitions with evidence and multi-validator approval when ecological interpretation changes
• REQ-USER-ST-08: As a Steward, I want precautionary blocking when a proposed boundary event would push the Source past its tipping_threshold
• REQ-USER-ST-09: As a Steward, I want to participate in stewardship succession (transfer of steward obligations) through governance-validated events, without privatising the Source

Source UI requirements (conditional post-MVP profile)

The following requirements apply only when the host application enables the Source-NDO profile. They SHALL NOT expand the default Project or resource-mutualisation UI.

• REQ-UI-SOURCE-01: A Source-enabled NDO creation flow SHALL offer a distinct Source-NDO variant with property_regime restricted to Nondominium / CommonPool, SourceType selection, steward assignment, and optional initial condition fields. The generic NDO form SHALL remain unchanged when Source support is disabled
• REQ-UI-SOURCE-02: Source-enabled detail views SHALL display regime state, condition indicators, steward list, and boundary-event history linked to the Layer 0 hash; ordinary Resource and Project detail views SHALL omit these panels
• REQ-UI-SOURCE-03: A Source-enabled application SHALL visualise Source hierarchies and coupling links (watershed → river → resources) when Layer 1/Composition views mature
• REQ-UI-SOURCE-04: Source-enabled applications SHALL provide stewards a dashboard for monitoring obligations, pending regime transitions, and access-affordance rule proposals

5. Economic Process Requirements

5.1 Core Process Types

• REQ-PROC-01: Use Process: Any Accountable Agent can initiate Use processes for accessing Resources without consuming them
• REQ-PROC-02: Transport Process: Only Agents with Transport role can initiate transport processes to move Resources between locations
• REQ-PROC-03: Storage Process: Only Agents with Storage role can initiate storage processes for temporary Resource custody
• REQ-PROC-04: Repair Process: Only Agents with Repair role can initiate repair processes that may change Resource state

5.2 Process Management

• REQ-PROC-05: Process Initiation: Agents must have appropriate roles to initiate specialized processes
• REQ-PROC-06: Process Tracking: All processes must be tracked with status, inputs, outputs, and completion state
• REQ-PROC-07: Process Validation: Process completions must be validated according to process-specific requirements
• REQ-PROC-08: Process Chaining: Agents with multiple roles can chain process actions within a single commitment
• REQ-PROC-09: Process History: Complete audit trail of all processes affecting each Resource

5.3 Source boundary events (Conditional Post-MVP Profile)

Status: Applies only to Source-enabled applications. Requires vf:Source and the Source-NDO data model (§4.6). Boundary events on Sources are economic events where the Source is provider or receiver — distinct from, and unnecessary for, ordinary custody and use processes on EconomicResource instances.

• REQ-PROC-10: Source Extraction Recording: Extraction of resource units from a Source (water abstraction, fish harvest, timber cut) SHALL be recorded as boundary EconomicEvent entries with the Source as provider and an Agent as receiver, decrementing SourceProfile.current_stock or period quota — not as unanchored raise events (REQ-SOURCE-EVENT-01, REQ-SOURCE-EVENT-02)
• REQ-PROC-11: Source Loading Recording: Discharge, pollutant loading, or waste deposition into a Source SHALL be recorded with the Source as receiver, decrementing assimilation_capacity where applicable (REQ-SOURCE-EVENT-01, REQ-SOURCE-EVENT-02)
• REQ-PROC-12: Source Regeneration Recording: Restoration, remediation, or regeneration actions on a Source (reforestation, riparian repair) SHALL be recordable as governance-validated events that may increment stock, flux, assimilation capacity, or resilience indicators (REQ-SOURCE-EVENT-03)
• REQ-PROC-13: Non-Consumptive Source Use: Non-consumptive use of a Source (e.g. hydro flow alteration affecting regime without volume extraction) SHALL be recordable as boundary events affecting SourceRegimeState or flux characteristics without implying Resource custody transfer

6. Governance & Validation Requirements

6.1 Resource Lifecycle Management

• REQ-GOV-01: First Resource Requirement: Simple Agents must create at least one Resource before accessing others
• REQ-GOV-02: Resource Validation: New Resources must be validated by Accountable Agents through peer review during first access
• REQ-GOV-03: Agent Validation: Simple Agents must be validated by Accountable Agents during their first transaction to become Accountable Agents. Post-MVP note: this workflow currently assumes individual agents only; post-MVP must support collective agent promotion workflows where the promotee is a Collective/Project/Network NDO and the promoter is its designated PrimaryAccountableAgent representative (ref G1, REQ-GOV-16).
• REQ-GOV-04: Specialized Role Validation: Transport, Repair, and Storage roles require validation by existing role holders

6.2 Validation Schemes

• REQ-GOV-05: Role-Gated Validation: Certain validations are restricted to Agents with specific roles. Post-MVP note: ValidationReceipt.validator is currently AgentPubKey; post-MVP must accept AgentContext to allow collective agent and bot validators within their declared scope (ref G1, REQ-GOV-16).
• REQ-GOV-06: Multi-Reviewer Validation: Support configurable validation schemes (2-of-3, N-of-M reviewers)
• REQ-GOV-07: Process Validation: Economic Process completions must be validated according to process-specific criteria

6.3 Governance Rules

• REQ-GOV-08: Embedded Rules: ResourceSpecifications must contain embedded governance rules for access and process management. Post-MVP note: Source-NDOs use Layer 1 SourceSpecification for boundary definitions, monitoring framework, and access-affordance rule templates; adaptive revision is governed by §6.6
• REQ-GOV-09: Rule Enforcement: Governance rules must be enforced programmatically across all interactions. Post-MVP note: the governance evaluation engine (evaluate_transition) must be extended to support AffiliationState-based rule conditions in addition to the current role-membership check. This requires a cross-zome query from zome_governance to zome_person to derive the requesting agent's AffiliationState before evaluating GovernanceRule.rule_data["min_affiliation"]. See REQ-AGENT-03, REQ-AGENT-05, implementation_plan.md §3 [G2+Resource], and governance-operator-architecture.md §2.1 TODO G2. Source-NDO note: Source governance extends evaluation with an adaptive loop — boundary events accumulate on the Source Layer 0 hash, ecological interpretation feeds rule revision, and revised access affordances condition future boundary events (§6.6).
• REQ-GOV-10: Rule Transparency: All governance rules must be publicly visible and machine-readable

6.4 End-of-Life Management

• REQ-GOV-11: End-of-Life Declaration: Resources reaching end-of-life must go through formal decommissioning process
• REQ-GOV-12: End-of-Life Validation: Multiple validators required for end-of-life declarations to prevent abuse
• REQ-GOV-13: Challenge Period: Time-delayed finalization with challenge period for end-of-life declarations

6.5 Affiliation and Collective Governance (Post-MVP)

These requirements depend on post-MVP agent architecture (REQ-AGENT-01 through REQ-AGENT-07) and the AffiliationState/AffiliationRecord system from agent.md §4.2 and §6.4.

• REQ-GOV-14: Affiliation-Based Governance Access — governance processes gated by AffiliationState must be enforceable via GovernanceRule.rule_data["min_affiliation"]; the governance operator must cross-zome query AffiliationState from zome_person (refs G2, G6, governance.md §3.6.2)

• REQ-GOV-15: AffiliationRecord Governance Ceremony — signing an AffiliationRecord must generate a Commitment/EconomicEvent/Claim cycle in zome_governance, creating an auditable on-chain record of the Terms of Participation (ToP) signing event; this event triggers AffiliationState → ActiveAffiliate (refs G6, governance.md §3.6.3)

• REQ-GOV-16: Collective Agent Governance Participation — ValidationReceipt, PPR counterparty, EconomicEvent.provider/receiver, and GovernanceTransitionRequest.requesting_agent must accept AgentContext post-MVP; collective NDO governance requires designated-operator or N-of-M multi-sig patterns (refs G1, governance.md §6.6)

• REQ-GOV-17: Sybil Resistance for Governance — governance-tier role promotion (AccountableAgent → PrimaryAccountableAgent) must require either N-of-M active affiliate vouching or optional proof-of-personhood membrane proof (refs G9, governance.md §5.3)

• REQ-GOV-18: Pseudonymous Governance Participation — agents must be able to reach ActiveAffiliate status via pseudonymous AgentPubKey (no Person entry required); pseudonymous agents are blocked from governance roles requiring legal accountability (refs G10, governance.md §5.3)

6.6 Source governance and adaptive stewardship (Conditional Post-MVP Profile)

Status: Applies only to Source-enabled applications. Full REQ-SOURCE-GOV-* set in source-ndo-requirements.md §5.3. Extends governance-as-operator with a cybernetic loop for complex ecological systems — rules adapt as the Source event ledger grows, without modeling ecological interiors (black-box principle). Applications that coordinate Projects or mutualise mature Resources continue to use ordinary governance-as-operator without this loop.

Adaptive governance loop:

boundary events → ledger on Source L0 hash → ecological interpretation
  → governance rule revision → access affordances → conditioned future events

• REQ-SOURCE-GOV-01: Source-NDO governance MUST support adaptive rule revision with maintained rule version history; rules SHALL be updatable through a defined governance process, not only by the initiator
• REQ-SOURCE-GOV-02: Source-NDOs MUST support access affordance rules as quantitative constraints on boundary events (extraction quotas, discharge caps, seasonal limits, minimum restoration per extraction)
• REQ-SOURCE-GOV-03: Governance evaluation for Source boundary events MUST check SourceRegimeState and MAY block or require multi-validator approval when an event would approach or exceed tipping_threshold
• REQ-SOURCE-GOV-04: Source-NDOs SHOULD support monitoring obligations as a GovernanceRule class: continued access may require condition-data submission that updates SourceProfile indicators
• REQ-SOURCE-GOV-05: SourceRegimeState transitions MUST be governance-validated with evidence and multi-validator approval
• REQ-SOURCE-GOV-06: All Source boundary events MUST be recorded as EconomicEvent entries linked to the Source's Layer 0 hash, forming an auditable ledger
• REQ-SOURCE-GOV-07: Source-NDOs MUST accept qualitative and community-validated condition signals (narrative observation, indigenous knowledge assessments) as legitimate governance inputs alongside quantitative monitoring
• REQ-SOURCE-GOV-08: Sensitive ecological data attached to Source records SHALL use Holochain private entries with capability-grant access control, following the PrivatePersonData model

Stewardship vs custody: Sources have no EconomicResource.custodian. Responsibility is expressed through stewardedBy links and the Steward role — obligations to monitor, interpret, and implement governance decisions, without alienation or privatisation rights (REQ-SOURCE-ONT-02; source-ndo-requirements.md §5.4).

7. Private Participation Receipt (PPR) Requirements

7.1 Receipt Generation

• REQ-PPR-01: Bi-directional Issuance: Every economic interaction generates exactly 2 receipts between participating Agents
• REQ-PPR-02: Automatic Generation: PPRs are automatically issued for all Commitment-Claim-Event cycles
• REQ-PPR-03: Cryptographic Integrity: All receipts are cryptographically signed for authenticity
• REQ-PPR-04: Performance Tracking: PPRs include quantitative performance metrics (timeliness, quality, reliability, communication)

7.2 Receipt Categories

• REQ-PPR-05: Resource Creation: Receipts for Resource creation and validation activities
• REQ-PPR-06: Custody Transfer: Receipts for responsible custody transfers and acceptances
• REQ-PPR-07: Service Processes: Receipts for service commitments and fulfillments (Transport, Repair, Storage)
• REQ-PPR-08: Governance Participation: Receipts for validation activities and governance compliance
• REQ-PPR-09: End-of-Life: Enhanced receipt requirements for end-of-life declarations and validations

7.3 Privacy & Security

• REQ-PPR-10: Private Storage: PPRs stored as Holochain private entries accessible only to owning Agent
• REQ-PPR-11: Reputation Derivation: Agents can derive and selectively share reputation summaries from their PPRs
• REQ-PPR-12: Signature Validation: System must validate cryptographic signatures of participation claims

7.4 Privacy Tiers and Cross-Network Portability (Post-MVP)

TODO: The following requirements depend on post-MVP agent architecture (see REQ-AGENT-12 through REQ-AGENT-15 and documentation/requirements/agent.md Sections 4.4–4.5).

• REQ-PPR-13: Per-Interaction Privacy Level: Agents must be able to choose their privacy level per interaction type: fully anonymous (no PPRs, no reputation accumulation), pseudonymous (PPRs linked to persistent pseudonym, not physical identity), or named (PPRs linked to public Person entry). The current model only supports named participation.
• REQ-PPR-14: ZKP-Compatible Reputation Sharing: The reputation summary derived from PPRs must be ZKP-compatible, allowing agents to produce proofs of the form "I have at least N claims of type T" without revealing the counterparties, timestamps, or raw scores. This is a prerequisite for privacy-preserving meritocracy — governance access based on contribution without requiring surveillance.
• REQ-PPR-15: Cross-Network Reputation Export: The ReputationSummary must be exportable as a PortableCredential (see REQ-AGENT-12), signed by a Primary Accountable Agent and countersigned by the claim owner, verifiable by receiving networks. Without portability, contribution history cannot flow across organisational boundaries, blocking growth of the P2P ecosystem.

7.5 Source stewardship receipts (Conditional Post-MVP Profile)

Status: Applies only to Source-enabled applications. Uses the existing 16-category PPR taxonomy; Source interactions do not introduce a global reputation aggregator. Stewardship participation remains user-sovereign private entries.

Source-NDO stewardship emphasises these PPR categories (source-ndo-requirements.md §7):

• REQ-PPR-16: Stewardship PPR Eligibility: Stewardship participation on Source-NDOs (monitoring, restoration, governance interpretation, rule compliance) SHALL generate bilateral PPRs using the existing private-entry model, enabling stewards to accumulate governance standing through contribution to Source health without exposing individual interaction history by default

8. Security & Access Control

8.1 Capability-Based Security

• REQ-SEC-01: Capability Tokens: Use capability tokens to manage access rights (general for Simple Agents, restricted for Accountable Agents)
• REQ-SEC-02: Role-Based Access: Economic Processes enforce role-based access control with validated credentials
• REQ-SEC-03: Cross-Zome Validation: Maintain transactional integrity across zome boundaries

8.2 Privacy Architecture

• REQ-SEC-04: Private Identity: Personal identification information stored as Holochain private entries
• REQ-SEC-05: Private Receipts: Participation receipts stored privately while enabling reputation derivation
• REQ-SEC-06: Selective Disclosure: Agents control what private information to share and with whom. Post-MVP note: sensitive ecological data on Source-NDOs (endangered species locations, sacred sites) follows the same capability-grant model as PrivatePersonData (REQ-SOURCE-GOV-08)

8.3 Network Security

• REQ-SEC-07: Membrane Validation: DNA membrane controls network entry (permissionless for PoC with validation hooks)
• REQ-SEC-08: Dispute Resolution: Edge-based dispute resolution involving recent interaction partners
• REQ-SEC-09: Reputation Protection: False claims and end-of-life abuse severely impact Agent reputation

9. Technical Architecture Requirements

9.1 Zome Structure

The hApp must be structured with three zomes. Source support, where enabled, SHALL be added as profile-specific modules within these zomes rather than imposed on every application:

• zome_person: Agent identity, roles, reputation, and private data management. Source-enabled profile only: Steward functional role (§4.6)
• zome_resource: Resource specifications, economic resources, and process management (pure data model). Source-enabled profile only: SourceProfile, Source coupling links, and Source-NDO creation extending Layer 0 (§4.6)
• zome_governance: Validation, commitments, claims, and PPR issuance. Source-enabled profile only: Source-as-provider/receiver on EconomicEvent and adaptive Source governance evaluation (§6.6)

9.2 ValueFlows Compliance

• REQ-ARCH-01: REA Model: Implement the Agent–Resource–Event pattern with Economic Processes. Conditional post-MVP extension: Source-enabled applications recognise Source as a third flow endpoint (vf:Source) so boundary events on generative systems are first-class economic records; other applications remain complete with Agent and Resource (REQ-SOURCE-APP-02, REQ-SOURCE-ONT-01)
• REQ-ARCH-02: Standard Actions: Support all relevant ValueFlows actions with nondominium-specific extensions. Source-enabled profile only: boundary events use extraction, loading, non-consumptive use, and regeneration (raise on a Source) with Sources as provider or receiver — see REQ-SOURCE-EVENT-* and §5.3
• REQ-ARCH-03: Multi-Layer Ontology: Support Knowledge, Plan, and Observation levels. Source-enabled profile only: Layer 0 = NondominiumIdentity + SourceProfile; Layer 1 = SourceSpecification; Layer 2 = boundary events, commitments, claims, PPRs (source-ndo-requirements.md §6)

9.3 Modular Governance Architecture

REQ-ARCH-07: Modular Governance: The resource zome operates as a pure data model, while the governance zome operates as a state transition operator. This separation enables independent evolution of data structures and governance rules. Conditional post-MVP note: the Source profile extends the operator with an adaptive ecological loop; the base operator SHALL NOT depend on Source types or require Source configuration.

Business Benefits:

• Swappable Governance: Governance rules can be updated without modifying resource data structures
• Independent Evolution: Data model and governance logic can evolve separately
• Clear Separation of Concerns: Data management separated from business logic enforcement
• Testability: Governance logic can be tested independently of data management

REQ-ARCH-08: Swappable Governance: Governance rules and validation logic must be modifiable without changing the resource data model. Different governance schemes can be applied to the same resource types.

Business Value:

• Future-Proof: System can adapt to new governance requirements without data migration
• Multi-Tenancy: Different governance rules can be applied in different contexts
• Experimentation: New governance approaches can be tested without disrupting existing data

REQ-ARCH-09: Cross-Zome Interface: Well-defined interfaces between resource and governance zomes must support all state transitions while maintaining clear separation of responsibilities.

Interface Requirements:

• State Transition Requests: Resource zome requests state changes from governance zome
• Governance Decisions: Governance zome provides validation and new state decisions
• Event Generation: All state changes must generate corresponding economic events
• Audit Trail: Complete history of governance decisions and state changes

REQ-ARCH-10: Event-Driven State Changes: All resource state changes must generate corresponding economic events to maintain complete ValueFlows compliance and audit trails. Post-MVP note: Source boundary events (extraction, loading, regeneration) and governance-validated SourceProfile indicator updates are economic events anchored to the Source Layer 0 hash (REQ-SOURCE-GOV-06, REQ-ARCH-12).

Event Requirements:

• Complete History: Every state transition must be recorded as an economic event
• Governance Context: Events must include governance decision context
• ValueFlows Compliance: Events must follow ValueFlows standard patterns
• Reputation Integration: Events must support PPR generation for reputation tracking

9.4 Data Integrity

• REQ-ARCH-04: Entry Validation: Comprehensive validation logic in integrity zomes
• REQ-ARCH-05: Link Management: Proper linking between related entries across zomes
• REQ-ARCH-06: State Management: Resource and process state tracking with proper transitions

9.5 Source flow endpoints (Conditional Post-MVP Profile)

These requirements apply only when Source support is enabled. An application satisfying Agent/Resource use cases SHALL NOT need to implement or surface Source endpoints.

• REQ-ARCH-11: vf:Source Extension: A Source-enabled economic event model SHALL support vf:Source as a typed flow endpoint role, enabling EconomicEvent entries where a Source is provider (extraction, non-consumptive use) or receiver (loading, pollution) without attributing agency to the Source or ownership via primaryAccountable (REQ-SOURCE-ONT-01, REQ-SOURCE-EVENT-01)
• REQ-ARCH-12: Source Event Ledger: Boundary events on a Source SHALL anchor to the Source's permanent Layer 0 NondominiumIdentity hash, enabling queryable history of extraction, loading, restoration, and regime-relevant use independent of EconomicResource custody chains (REQ-SOURCE-GOV-06)
• REQ-ARCH-13: Source Condition Updates: Updates to SourceProfile indicators (current_stock, assimilation_capacity, regime_state, etc.) from boundary events SHALL be governance-validated state transitions, not direct writes by extracting or discharging agents (REQ-SOURCE-EVENT-02)

10. Future Enhancements

Phase 2 Requirements

• Advanced governance rule engines with conditional logic
• Automated validation workflows and smart contracts
• Enhanced dispute resolution mechanisms
• Cross-network resource sharing protocols

Phase 3 Requirements

• Integration with external governance systems
• Advanced reputation algorithms and trust networks
• Scalable validation schemes for large networks
• Economic incentive mechanisms and value accounting
• Source-NDO (optional application profile): For applications governing generative systems only — SourceProfile, vf:Source boundary events, adaptive stewardship, and cross-DNA source hierarchies (§4.6, §6.6; implementation_plan.md §12.7)

11. Future Development: Architecture Variants for P2P and Organizational Contexts

11.1 Context Overview

As Nondominium evolves beyond proof-of-concept, two distinct deployment contexts emerge:

• Pure P2P Context: Individual humans directly using Nondominium for peer-to-peer resource sharing
• Organizational Context: Organizations (using ERPs or web platforms like Tiki) accessing Nondominium through bridge services

While the core ValueFlows logic and resource model remain consistent, the governance, identity, and security layers require significant architectural adaptations to serve both contexts effectively.

11.2 Identity & Delegation Requirements

Pure P2P Context

• REQ-FUT-P2P-ID-01: Support direct 1:1 mapping between human individuals and Holochain agent keys
• REQ-FUT-P2P-ID-02: Enable personal device-based key management with biometric or password protection
• REQ-FUT-P2P-ID-03: Support direct agency where the individual is the sole signer and decision-maker

Organizational Context

• REQ-FUT-ORG-ID-01: Support organizational agent identities representing legal entities (e.g., "Acme Corp")
• REQ-FUT-ORG-ID-02: Implement delegation pattern where employee keys can sign on behalf of organizational agents
• REQ-FUT-ORG-ID-03: Support scoped delegations with specific capabilities (e.g., "Transport only", "Use up to $1000 value")
• REQ-FUT-ORG-ID-04: Support time-limited delegations with automatic expiry
• REQ-FUT-ORG-ID-05: Enable immediate delegation revocation (e.g., when employee leaves) without changing organizational identity
• REQ-FUT-ORG-ID-06: Track which delegate performed which action for internal organizational audit
• REQ-FUT-ORG-ID-07: Support delegation hierarchies (e.g., manager delegates to team lead, who delegates to employees)

11.3 Reputation & Accountability Requirements

Pure P2P Context

• REQ-FUT-P2P-REP-01: All reputation (PPRs) accrues directly to the individual agent
• REQ-FUT-P2P-REP-02: Support full reputation portability across contexts and networks
• REQ-FUT-P2P-REP-03: New users start with zero reputation and build it through transactions

Organizational Context

• REQ-FUT-ORG-REP-01: External reputation accrues to the organizational agent, not individual delegates
• REQ-FUT-ORG-REP-02: Support internal attribution linking PPRs to specific delegates (hashed/private)
• REQ-FUT-ORG-REP-03: Enable organizational reputation inheritance for new delegates
• REQ-FUT-ORG-REP-04: Distinguish between organizational performance and individual delegate performance
• REQ-FUT-ORG-REP-05: Support aggregation of delegate performance into organizational reputation metrics
• REQ-FUT-ORG-REP-06: Maintain privacy of internal organizational structure while supporting accountability

11.4 Governance & Decision-Making Requirements

Pure P2P Context

• REQ-FUT-P2P-GOV-01: Support ad-hoc, autonomous decision-making by individuals
• REQ-FUT-P2P-GOV-02: Enable social negotiation of resource access terms
• REQ-FUT-P2P-GOV-03: Support simple template-based governance rules

Organizational Context

• REQ-FUT-ORG-GOV-01: Support policy-driven, automated decision-making based on organizational rules
• REQ-FUT-ORG-GOV-02: Enable automated approval of resource requests based on criteria (e.g., credit score thresholds)
• REQ-FUT-ORG-GOV-03: Support multi-signature requirements for high-value transactions
• REQ-FUT-ORG-GOV-04: Enable threshold-based governance (e.g., 2-of-3 delegates must approve)
• REQ-FUT-ORG-GOV-05: Support integration with organizational policy engines
• REQ-FUT-ORG-GOV-06: Enable organizational administrators to configure governance rules without code changes

11.5 Custody & Ownership Requirements

Pure P2P Context

• REQ-FUT-P2P-OWN-01: Support convergent custody and ownership (same person)
• REQ-FUT-P2P-OWN-02: Handle temporary custody transfers (lending) and permanent ownership transfers (selling/giving)
• REQ-FUT-P2P-OWN-03: Simple custody validation based on physical possession

Organizational Context

• REQ-FUT-ORG-OWN-01: Support divergent custody and ownership (organization owns, employee holds custody)
• REQ-FUT-ORG-OWN-02: Track internal organizational custody transfers without triggering ownership change events
• REQ-FUT-ORG-OWN-03: Support location tracking for organizational resources
• REQ-FUT-ORG-OWN-04: Enable attachment of legal contracts (hashed PDFs) to commitments and events
• REQ-FUT-ORG-OWN-05: Distinguish between internal organizational moves and external transfers
• REQ-FUT-ORG-OWN-06: Support organizational inventory reconciliation with Nondominium state

11.6 Device & Session Management Requirements

Pure P2P Context

• REQ-FUT-P2P-DEV-01: Support personal, single-user devices
• REQ-FUT-P2P-DEV-02: Simple biometric or password-based security
• REQ-FUT-P2P-DEV-03: Keys stored securely on personal devices
• REQ-FUT-P2P-DEV-04: Support standard consumer mobile platforms (iOS, Android)

Organizational Context

• REQ-FUT-ORG-DEV-01: Support shared devices (e.g., warehouse tablets used by multiple employees)
• REQ-FUT-ORG-DEV-02: Enable rapid delegate login/logout on shared devices
• REQ-FUT-ORG-DEV-03: Support BYOD (Bring Your Own Device) with organizational key management
• REQ-FUT-ORG-DEV-04: Integrate with organizational IAM/SSO systems (OAuth, SAML)
• REQ-FUT-ORG-DEV-05: Map organizational authentication tokens to Holochain capability tokens
• REQ-FUT-ORG-DEV-06: Support enterprise device management policies
• REQ-FUT-ORG-DEV-07: Enable remote device key revocation for security

11.7 Bridge Integration Requirements

Organizational Context (ERP/Web Platform Bridges)

• REQ-FUT-ORG-BRG-01: Support RESTful bridge services using Node.js and @holochain/client
• REQ-FUT-ORG-BRG-02: Enable bidirectional synchronization between organizational systems and Nondominium
• REQ-FUT-ORG-BRG-03: Support real-time signal forwarding from Holochain to organizational systems
• REQ-FUT-ORG-BRG-04: Enable batch operations for efficiency in organizational contexts
• REQ-FUT-ORG-BRG-05: Support caching strategies for frequently accessed organizational data
• REQ-FUT-ORG-BRG-06: Enable webhook-based event notification to organizational systems
• REQ-FUT-ORG-BRG-07: Support organizational resource publishing from ERP inventory systems
• REQ-FUT-ORG-BRG-08: Enable organizational authentication mapping (OAuth/session tokens to agent keys)
• REQ-FUT-ORG-BRG-09: Support deployment via Docker containerization for organizational IT environments
• REQ-FUT-ORG-BRG-10: Enable organizational administrators to monitor bridge health and performance

11.8 Architecture Modularity Requirements

• REQ-FUT-ARCH-01: Design modular architecture supporting both P2P and organizational contexts
• REQ-FUT-ARCH-02: Core ValueFlows and resource model must remain context-agnostic. Post-MVP note: Source is an optional extension profile that must not burden organizational bridges or applications that need only Agent/Resource semantics; when enabled, extracted units remain EconomicResource and generative systems remain Source-NDOs
• REQ-FUT-ARCH-03: Governance and identity layers must support pluggable implementations
• REQ-FUT-ARCH-04: Support seamless interoperability between P2P agents and organizational agents
• REQ-FUT-ARCH-05: Enable organizations to act as agents in the P2P network with equal standing
• REQ-FUT-ARCH-06: Support mixed-mode transactions (P2P individual borrowing from organization)
• REQ-FUT-ARCH-07: Maintain unified reputation and trust framework across contexts

11.9 Privacy & Compliance Requirements

Pure P2P Context

• REQ-FUT-P2P-PRIV-01: Minimize data collection to essential transaction information
• REQ-FUT-P2P-PRIV-02: User controls all personal data disclosure
• REQ-FUT-P2P-PRIV-03: Support pseudonymous participation

Organizational Context

• REQ-FUT-ORG-PRIV-01: Support organizational data retention and audit requirements
• REQ-FUT-ORG-PRIV-02: Enable compliance with organizational security policies
• REQ-FUT-ORG-PRIV-03: Support organizational data export for regulatory compliance
• REQ-FUT-ORG-PRIV-04: Maintain separation between organizational data and public DHT data
• REQ-FUT-ORG-PRIV-05: Support organizational right-to-delete while preserving transaction integrity

11.10 Implementation Priority

Phase 1 (Current): Pure P2P implementation with direct agent-person mapping

Phase 2 (Future Development):

• Delegation pattern implementation
• Organizational reputation aggregation
• Basic bridge service architecture

Phase 3 (Future Development):

• Advanced multi-signature governance
• Enterprise device and session management
• Full IAM/SSO integration
• Production-ready organizational bridges

12. Success Criteria

The nondominium system is successful when:

1. Resources remain organization-agnostic and capture-resistant
2. Governance is transparent, fair, and community-driven
3. Reputation system enables trust without central authority
4. Economic Processes support real-world sharing scenarios
5. System scales while maintaining decentralized principles
6. Privacy is preserved while enabling accountability
7. (Conditional post-MVP) Applications whose domain includes generative ecological or knowledge commons can enable Source-NDO so boundary events are visible and stewardship adapts, while Project and mature-resource mutualisation applications remain simple and complete with Agent and Resource primitives

Agent: Ontology, Implementation, and Forward Map

Type: Archive / Knowledge Base Document
Created: 2026-03-11
Relates to: governance.md, resources.md, ndo_prima_materia.md, unyt-integration.md, flowsta-integration.md
Sources: MVP code (zome_person, zome_gouvernance PPR/validation), post-MVP design, OVN wiki — Agent, Identity, Individual profile, Organizational structure

Purpose

This document maps the three states of Agent understanding in the Nondominium / NDO project:

1. Implemented — what exists today in the MVP zome_person and governance-related agent handling
2. Planned — what is designed in post-MVP documents for agent evolution
3. Remaining — what the OVN wiki's 15 years of commons-based peer production practice contains that NDO does not yet plan for

The goal is to ensure the generic NDO agent model is as complete and principled as the OVN ontology, enabling diverse applications (resource-sharing, digital commons, open science, cooperative production) to configure agent behaviour through data, not custom code.

1. Conceptual Foundation: What is an Agent in P2P Complexity Economics?

1.1 Agent vs User — A Critical Distinction

The OVN wiki is unequivocal: "In a p2p context it is not advised to reduce agents or affiliates to users." The word user is appropriate for centralised platforms (Facebook, Uber) where participants have no control over the platform, interact on terms set by the owner, and provide data in exchange for access. An agent, by contrast, is an entity with agency — the capacity to plan and take actions, to own its own data, and to participate in defining the rules of the system it operates within.

This is not merely semantic. The data model follows the ontology: a "user" has an account on a server that another party controls. An agent has a cryptographic key pair that they control, a source chain of their own actions that only they can append to, and relationships with other agents that are maintained on a shared DHT — not a shared database controlled by an operator. Holochain is the first infrastructure natively designed for agent-centric data models. The NDO must take this seriously from the ground up.

1.2 The Agent Type Spectrum

MVP implements Individual only. Post-MVP targets: Collective (working groups, N-of-M signing), Project (AgentContext + linked NondominiumIdentity digital twin), Network (OVN as agent), Bot (capabilities declared, operator accountable). Governance complexity increases rightward.

The OVN wiki defines agents as: "anything that can perform an action. Has agency, i.e. can also plan to take actions. Agents can be individuals, groups, projects, networks. Agents can also be bots, machines (IoT)."

This spectrum is essential. In a P2P complexity economics framework, the system must model:

• Individual agents: human participants, each with a source chain
• Collective agents: groups, working groups, communities — entities with collective agency
• Project/venture agents: temporary organised efforts with their own goals and resources
• Network agents: larger-scale communities (an OVN as a whole is also an agent in its ecosystem)
• Artificial agents: bots, AI models, IoT devices — increasingly significant actors in the commons

The current NDO models only individual agents. This is a significant constraint for the generic NDO project, which aims to support Sensorica-style open value networks where ventures, networks, and partner organisations are themselves agents in economic processes.

1.3 Individual vs Person — The Two Layers of Agent Identity

Individual-type identity: cryptographic key pair, permissionless entry, no disclosure required — like a bus ticket. Person-type identity: created on first DHT-active action, role credentials, PPR history, enables governance and custodianship — like a medical credential. The progression is earned through participation, not granted.

The OVN wiki makes a distinction of deep philosophical and technical importance:

"An individual is the physical you. You exist and therefore you have access to certain things. A person is a representation of the physical you, it is an agent in a socio/economic context."

In practical terms:

• Individual-type identity: exists by virtue of holding a cryptographic key pair. Permissionless access. No disclosure required. Like Bitcoin: you only need keys to transact. This is the foundation of the NDO's permissionless entry model.
• Person-type identity: requires reputation, credentials, or demonstrated capabilities earned through participation. Required for sensitive processes: governance participation, custodianship, specialised service provision.

This two-layer model is not bureaucratic gatekeeping — it is a precise answer to the information-theoretic question: "what does this process require to function well?" Taking the bus requires a ticket, not identification. Performing surgery requires credentials. The NDO must distinguish which processes are ticket-level (individual-type) and which require person-type identity, and build the appropriate mechanisms for each.

In complexity economics terms: forcing all interactions through person-type identity is a high information-overhead solution applied to low-information-need situations. It reduces participation, increases friction, and creates centralisation risks (who issues the credentials?). The OVN model, and therefore the NDO model, reserves person-type identity for the specific processes that genuinely need it.

1.4 Identity ≠ Credentials

The OVN wiki offers a clarifying thought experiment: "When you take the bus you don't need to tell the driver all about yourself before boarding, you just show your ticket, which is the credential required to access the transportation service."

Credentials are context-specific access tokens derived from past actions or present conditions. They are not identity. You can prove you can safely use a 3D printer (credential) without revealing who you are (identity). This distinction, made precise through zero-knowledge proof technology, is the foundation for privacy-preserving participation in P2P systems.

The implications for NDO agent design: the system should be designed so that agents prove what they can do through minimally-revealing credentials, not by revealing who they are through full identity disclosure. This is currently only partially implemented: the PPR system generates verifiable contribution records (a form of capability credential), but there is no ZKP layer to share them without revealing the underlying data.

1.5 Agent as Network Node: Social Capital and Interconnection

The OVN wiki's individual profile description captures a dimension of agents often overlooked in technical implementations: an agent's profile includes "social relations (connections with other agents), which can be seen as social capital, may be shared in context / processes, part of the wealth structure of a network" and "network affiliations."

Social capital — the value embedded in relationships and network position — is an intangible resource that the NDO system should make legible, not obscure. In complexity economics, information flows through social networks, and an agent's connectivity is a measure of their access to collective intelligence. The individual profile should capture relational wealth, not just transactional history.

1.6 The Long Tail of Agent Engagement

From the governance archive, the OVN operates with a 1-9-90 engagement distribution: 1% core (entrepreneurial, high commitment), 9% active contributors, 90% occasional participants. This is not a design flaw — it is universal in open networks. The agent model must be designed for this reality.

An agent system designed only for the 1% (assuming high engagement, rich profiles, continuous participation) will exclude the 99% who should still be able to participate meaningfully at their actual engagement level. The affiliation model (unaffiliated → close → active → core) is the OVN's answer to this: design for the full spectrum, not just the core.

2. Current Implementation (MVP)

2.0 Three-Level Identity Model (UI)

The MVP UI introduces three distinct identity layers that reflect the Lobby → Group → NDO hierarchy defined in ui_design.md. These layers are intentionally separate: they allow progressive disclosure of personal information and defer DHT costs until the agent acts.

Level 1 — Lobby (UI-only, localStorage)

LobbyUserProfile is the outermost, lightest identity layer. It is never written to the DHT.

• Stored in localStorage under the key ndo_lobby_profile_v1.
• Written to app.context.lobbyUserProfile (Svelte $state) on every page load.
• Created via UserProfileForm.svelte (modal on first launch; page-mode for editing).
• Exists before any Person DHT entry is created. An agent can browse the Lobby anonymously (no profile) or under a pseudonym (nickname only).

Level 2 — Group (GroupMemberProfile, localStorage presentation + Group DNA membership)

Groups are DNA-backed: each group is a cloned Group cell (clone_cell with unique network_seed). GroupProfile and membership live on the group DHT via zome_group (create_group, join_group, get_group_members). The Lobby DNA announces groups for discovery (announce_group).

GroupMemberProfile is a per-group presentation choice derived from LobbyUserProfile. It controls how much of the Lobby profile the agent consents to show other group members. It is not the same as DHT membership — it is a UI-only disclosure layer.

• Stored in localStorage under ndo_group_profiles_v1, keyed by group network_seed (not in GroupProfile entry).
• Prompted via GroupProfileModal.svelte on first entry to each group.
• NDO-level pseudonymity: an agent may browse the Lobby with no profile, join groups under a nickname-only presentation (Level 2 anonymous), and defer creating a Person entry until a DHT-active economic action (Level 3).

Level 3 — NDO / Agent (DHT, zome_person)

Person is the public, on-chain agent profile. It is created when the agent performs their first DHT-active action — creating an NDO, joining an NDO, or accepting a commitment. This layer corresponds to the "person-type identity" described in §1.3.

• Written to the NDO's DHT via create_person in zome_person.
• Linked to the agent's AgentPubKey through Holochain's source chain.
• Required for governance participation, custodianship, and specialised service provision.
• Discoverable by other agents via the all_persons anchor.

This three-level model enables permissionless browsing (Level 1 not required), group participation under a pseudonym (Level 2), and full economic participation (Level 3), without conflating disclosure requirements across contexts.

Cross-reference: ui_design.md MVP section describes the intended UI flow. Implementation lives in app.context.svelte.ts (lobbyUserProfile), lobby.service.ts (Group DNA + saveGroupMemberProfile), group.service.ts (getMembers, SoftLinks), UserProfileForm.svelte, GroupProfileModal.svelte, and Sidebar.svelte.

2.1 The Two-Layer Identity Model in Code

The NDO MVP implements the individual/person distinction at the data model level:

Individual layer — the Holochain AgentPubKey:

• Cryptographic key pair generated locally by the agent
• Source chain is agent-owned and agent-controlled
• Permissionless network entry (validate_agent_joining returns ValidateCallbackResult::Valid unconditionally)
• No disclosure required for basic read access to the DHT

Person layer — the Person entry (public) + PrivatePersonData entry (private):

#![allow(unused)]
fn main() {
pub struct Person {
    pub name: String,
    pub avatar_url: Option<String>,
    pub bio: Option<String>,
}

pub struct PrivatePersonData {
    pub legal_name: String,
    pub email: String,
    pub phone: Option<String>,
    pub address: Option<String>,
    pub emergency_contact: Option<String>,
    pub time_zone: Option<String>,
    pub location: Option<String>,
}
}

Person entries are the public identity anchor — discoverable via the AllPersons anchor, versioned (via PersonUpdates links), and permanently immutable once created (validate_delete_person returns Invalid). They cannot be deleted: consistent with the OVN principle that contribution records and identity anchors must be permanent.

PrivatePersonData is a Holochain private entry stored only on the agent's source chain, accessible to others only through explicit capability grants.

2.2 The Capability-Based Private Data System

The MVP implements a sophisticated field-level capability sharing system for private data:

PrivateDataCapabilityMetadata: tracks each capability grant issued by an agent:

• granted_to, granted_by, fields_allowed (subset of: email, phone, location, time_zone, emergency_contact, address)
• context: why the access was granted
• expires_at with a hard-coded 30-day maximum duration
• cap_secret: stored locally for revocation

RevokedGrantMarker: explicit revocation record (important because Holochain native capability revocation is silent — this creates an auditable revocation trail)

FilteredPrivateData: the view of private data after capability filtering — what the other agent actually sees given their access level

This system implements the OVN principle of "absolute privacy by default" with agent-controlled selective disclosure. The legal_name field is notably never shared (not in allowed_fields), preserving the individual/person separation at the field level.

2.3 The Role System — Four Capability Levels

The MVP implements a six-role system across two dimensions:

Governance tiers (progressive trust levels):

• SimpleAgent (member) — permissionless entry; basic participation
• AccountableAgent (coordination) — validated private identity; can validate others; can initiate process commitments
• PrimaryAccountableAgent (governance) — highest trust; can promote agents; can approve governance decisions

Functional service roles (validated competencies):

• Transport, Repair, Storage (stewardship level)

Capability level hierarchy: member < stewardship < coordination < governance

The promotion workflow is a cross-zome interaction:

SimpleAgent → Accountable:
  1. Agent calls request_role_promotion("Accountable Agent")
  2. System validates private data exists (legal_name, email required)
  3. Cross-zome call: governance.validate_agent_for_promotion()
  4. Accountable/Primary agent approves: approve_role_promotion()
  5. Cross-zome call: governance.validate_agent_identity() (with first_resource_hash)
  6. Role entry created and linked to Person

Accountable → Primary:
  1. Requires PPR milestones (governance_claims in ReputationSummary)
  2. Specialized role validation for functional roles
  3. Governance-level approver required

The promotion workflow correctly implements the OVN's "access to governance is earned through contribution" principle. Simple agents exist (permissionless) but cannot act as validators or custodians without establishing person-type identity.

2.4 Multi-Device Agent Architecture

The MVP's most technically sophisticated agent-layer contribution: a clean many-to-many Agent ↔ Person relationship model.

AgentPersonRelationship: explicitly models the link between a cryptographic key (AgentPubKey) and a persistent identity (Person hash):

• relationship_type: Primary (initial device), Secondary (additional devices), Device (dedicated device agents)

Device entry: tracked per physical device with device_id, device_name, device_type (mobile/desktop/tablet/web/server), registration, last-active timestamps, and revocable DeviceStatus.

Bidirectional links: AgentToPerson (key to identity) and PersonToAgents (identity to all associated keys) enable multi-device coordination without leaking any of the devices' keys.

This is a forward-looking implementation: one person may use Nondominium from a phone, a desktop, and a shared lab computer. Each device has its own key. All keys are controlled by the same person. The Person is the persistent socio-economic identity; AgentPubKeys are the session-level cryptographic instruments.

2.5 What the MVP Does Well

• The individual/person dual layer correctly implements OVN's identity model: permissionless individual access + earned person-type credentials
• Permanent identity anchors (Person entries cannot be deleted): enforces the OVN principle that contribution history cannot be retroactively erased
• Field-level capability grants with 30-day expiry and explicit revocation are privacy-first by design, consistent with the OVN's "absolute privacy by default" principle
• Multi-device architecture is pragmatic and technically sound — most systems ignore this, resulting in brittle single-key identities
• The cross-zome promotion workflow is correctly designed: role assignment requires governance validation, not just peer-to-peer agreement
• Functional roles as validated competencies (not just trust levels) introduce the credential concept correctly, even if without portability

2.6 Known Gaps in the MVP

3. Post-MVP Roadmap

3.1 Collective Agents and Their Digital Twins

Agent face: AgentContext with member agents, acts as provider/receiver in economic events, accumulates PPRs. Resource face: NondominiumIdentity — permanent anchor, lifecycle, specification, governance rules. The Project(ActionHash) in AgentEntityType bridges them. Neither face replaces the other — they are ontologically distinct.

A collective entity — a project-as-organisation, a cooperative, an open value network — has two distinct ontological faces in the Nondominium model. These faces are different roles the same real-world entity plays, and they must not be collapsed into one.

The agent face is the AgentContext carrying the relevant AgentEntityType variant (Collective, Project, Network). Through this face the collective participates in economic events as provider or receiver, holds commitments, accumulates reputation, and may be the primary_accountable on shared resources. Collective agents of this kind are composed agents or group agents: their actions may require N-of-M authorisation from individual member agents (multi-signature pattern — forward design, post-MVP). This is how REA-ontology-compliant collective economic agency works — it is distinct from the physical thing the collective creates or represents.

The resource face is the NondominiumIdentity — the collective's digital twin as a Nondominium Object. NDOs are Resources, and the resource face of a collective carries its permanent identity anchor, property regime, lifecycle stage, specification (what the collective IS — its mission, assets, rules of participation), and governance rules (how agents interact with it). The resource face does not have agency; it records which agents are associated and under what terms.

The ActionHash inside AgentEntityType::Project(ActionHash) and AgentEntityType::Network(ActionHash) links the agent face to the resource face: it points to the NondominiumIdentity that is the collective's digital twin. The two faces are thus connected by this hash reference.

An individual agent can hold a PersonRole in both their own profile and in a collective's governance. Cross-agent capability grants enable a collective's AgentContext to act on behalf of its members (with appropriate authorisation).

A Collective(String) agent (e.g. a working group or committee) may not yet have an associated NDO — its agent face exists independently of any resource face. Attaching a resource face (creating an associated NondominiumIdentity) is optional and done when the collective's digital representation as a Resource becomes useful.

When a collective does have an associated NDO, the NDO's three-layer structure (Identity + Specification + Process) applies to the collective's resource face — not to the collective as an agent:

• NDO Identity layer = the collective's permanent identity anchor (name, regime, nature, creation record)
• NDO Specification layer = the collective's documented form (mission, assets, governance rules for how agents interact with it)
• NDO Process layer = the economic activity around the collective as a resource (contributions, agreements, events involving the collective-as-resource)

The LifecycleStage at registration can be any non-suspend, non-terminal stage (Ideation through Active) so the resource face can anchor an already mature or in-use NDO (e.g. a stable shared tool), not only an emerging project. Profiles or wizards may suggest a narrower subset for specific organisation types — for example a short-lived working group often stays in emergence — but that is UX guidance, not an ontology constraint on NondominiumIdentity. Hibernating, Deprecated, and EndOfLife remain transition-only after creation. The PropertyRegime and ResourceNature fields on NondominiumIdentity remain applicable to the collective's resource face: a working group's shared knowledge base is a Commons/Digital NDO; a collectively owned workshop maps to a Collective or Pool physical NDO in the UI's seven-regime model.

3.2 CapabilitySlot on Agent Identity

The NDO CapabilitySlot surface (from ndo_prima_materia.md) can be extended to agent identities: an agent's Person entry hash becomes a stigmergic attachment point for external applications — credential wallets, reputation oracles, DID documents, professional networks — without modifying the core Person entry. This is the agent-level equivalent of the resource-level CapabilitySlot.

Flowsta Auth (ndo_prima_materia.md Section 6.7) is the first specified implementation: a FlowstaIdentity CapabilitySlot from the Person entry hash to an IsSamePersonEntry (dual-signed attestation: NDO agent key + Flowsta Vault key), yielding a W3C DID (did:flowsta:uhCAk...) without changing the Person schema. Full architecture, two-tier identity authority, and integration phases are summarised in Section 3.5 below.

3.3 Composable Profile Aggregator

A post-MVP AgentProfile view that composes:

• Person (public identity)
• ReputationSummary (derived from PPRs)
• PersonRole list
• Participation statistics (economic event counts by category)
• Capability slot attachments (external credentials, DIDs)

This view is not stored as a new entry type — it is computed from existing DHT data. But exposing it as a queryable composite is the key step toward the OVN individual profile model.

3.4 Credential Portability via Holochain Membrane Proofs

Post-MVP: a mechanism to export cryptographically signed summaries of an agent's role assignments and ReputationSummary that can be verified by other Holochain networks. This implements the OVN requirement for portable identity: a person's contribution track record in one community should be recognisable in another.

Flowsta agent linking provides a cross-app identity anchor (DID) so ReputationSummary and participation history can be attributed across Flowsta-linked apps; full PortableCredential structures (this document, Section 6.5) remain the NDO-native export path — the two are complementary (ndo_prima_materia.md Section 6.7, PPR cross-app attribution).

3.5 Flowsta Integration (flowsta-integration.md)

Decentralized identity and authentication for Holochain apps: agent linking commits IsSamePersonEntry on this DNA via flowsta-agent-linking zomes; FlowstaIdentity CapabilitySlot on the agent's Person entry hash points to that attestation. Tier 1 (Flowsta Phase 1): permissionless self-attestation (trust signal; REQ-NDO-CS-12/CS-13). Tier 2 (Flowsta Phase 3): governance can require a valid Flowsta link for sensitive transitions (e.g. PrimaryAccountableAgent promotion, high-value custody) via IdentityVerification-style rules (REQ-NDO-CS-14/CS-15). Flowsta Vault: BIP39 recovery, encrypted auto-backups, CAL-aligned export — addressing the gap between permanent Person/PPR anchors and real-world key loss. OAuth-only path (@flowsta/auth): consistent DID across web apps while the app keeps its own Holochain keys (Flowsta docs "Option 1"); Vault path ("Option 2") is the one that produces IsSamePersonEntry on the NDO DHT. See ndo_prima_materia.md Section 6.7 and Section 11.6; see also resources.md Section 3.8 for resource-ontology cross-links.

4. OVN Agent Ontology: 15 Years of Practice

4.1 Agent Type Taxonomy

The OVN wiki classifies agents into four primary types:

In the REA model used by Sensorica, economic agents can represent:

• An individual
• A project/venture (another network or autonomous open business unit)
• Another network (cross-OVN interactions)
• A traditional organisation (partner, supplier, funder)

The NDO currently only models the individual case. For the generic NDO to support Sensorica-style operations, at minimum group/collective and project/venture agent types are needed.

Complexity economics note: The omission of collective agents is not just an inconvenience — it makes it impossible to model the actual economic events in many commons-based peer production contexts. When Sensorica licenses a sensor to a university, the economic agents are Sensorica (a network) and the university (a traditional organisation), not individual humans. Without collective agent types, the economic model is systematically misrepresented.

4.2 The Affiliation Spectrum

Five states: UnaffiliatedStranger → CloseAffiliate → ActiveAffiliate (governance gate, requires AffiliationRecord signing) → CoreAffiliate (algorithmically determined from PPR rate) → InactiveAffiliate (contribution history preserved). Re-engagement via new contributions. AffiliationState is derived from DHT data — never stored.

The OVN wiki defines five affiliation states that capture the long tail of participation:

Unaffiliated: anonymous; accesses public information only; no obligations; not known by affiliates.

Close affiliate: not yet contributed in a trackable way; known by some affiliates; can access database and some activities; no formal obligations but respects OVN's assets.

Active affiliate: has logged contributions in the NRP-CAS AND is recognised by the community; has access to OVN infrastructure, governance, and production assets; must adhere to the Benefit Redistribution Algorithm and affiliation conditions.

Core affiliate: algorithmically selected from active affiliates based on contribution + reputation; special privileges within specific projects or ventures; status is dynamic (in/out based on contribution; can expire through inactivity).

Inactive affiliate: previously contributed, currently inactive; access to some activities; can re-engage by contributing again.

Formal affiliation: becoming an active affiliate formally consists of:

1. Acknowledging the Affiliate Handbook
2. Acknowledging the Nondominium & Custodian agreement
3. Signing the "Acknowledgement of Knowledge Commons" agreement
4. Signing the Benefit Redistribution Algorithm agreement

The NDO currently has only two states: joined (has a Person entry) and not joined. There is no modelling of engagement depth, affiliation conditions, formal affiliation agreements, or the core/active/close/inactive spectrum. This means the system cannot algorithmically determine who should participate in a governance decision (active affiliates only? core affiliates? anyone with a Person entry?), cannot manage the onboarding process, and cannot track affiliation lifecycle.

4.3 The Individual Profile as Composable Aggregate

The OVN wiki defines the individual profile as "a digital environment that aggregates information and data about Agents." Key properties:

Composable: can contain roles, reputation, contributions, artifacts, social relations, network affiliations, credentials, available assets, needs/wants.

Standard format: portable across contexts.

Non-transferable: cannot be reassigned from one individual to another (analogous to soul-bound tokens). The link to the physical self must be unique.

Portable: "An individual can participate in more than one OVN simultaneously... enables the individual to transport his/her reputation and credentials from one cluster of economic activities to another."

Owner-controlled: the agent controls what is shared, with whom, for what purpose, and for how long. But crucially: some parts are write-protected — "applications can write data about contributions, roles, and reputation, which cannot be deleted by the affiliate in question." This is exactly what the NDO implements with immutable Person entries and private-but-signed PPRs. The profile owner cannot delete their contribution history, but controls what they reveal.

Predictive: "can be used as a predictive tool, to judge if a future action or relation would be beneficial."

Agency-extended: "The individual profile can even have agency in the digital world. It can be AI-enhanced to act on behalf of the real agent in some circumstances, sign contracts based on predefined rules."

The NDO currently splits what should be the individual profile across at least four separate concepts: Person, PrivatePersonData, ReputationSummary, and PersonRole. These are correct building blocks but lack the composable aggregation layer that would make the profile a genuine OVN individual profile.

4.4 Identity Architecture: SSI, DIDs, VCs, ZKP

The OVN wiki synthesises the state of the art in decentralised identity:

Self-Sovereign Identity (SSI): The individual controls their own identity data; no third party can revoke or modify it without the individual's consent. Roles in the SSI ecosystem: issuer (issues credentials), wallet (stores and provides), validator (requests and obtains), revoker.

Decentralised Identifiers (DIDs): W3C-standardised unique identifiers for individuals and organisations that are independent of any centralised registry, resolved through decentralised systems. DIDs enable "a direct, encrypted channel for p2p communication" and portability from one transport or security context to another.

Verifiable Credentials (VCs): "Sets of claims about an agent of which the provenance and immutability can be proved." ZKP-compatible: an agent can prove "I have a credential that satisfies condition X" without revealing the credential's full contents.

Soul-bound tokens: non-transferable, non-sellable reputation tokens. The OVN wiki references these as one potential mechanism for non-transferable credentials. The NDO's Person entries (non-deletable) and PPRs (bilaterally signed, private) are soul-bound-like, but not interoperable with external VC/DID ecosystems.

Portability challenge: "I can gain some credentials based on activities in one organization/context and have that, or only a part of it, being recognized in another context." This is the core portability requirement. The technical path: ZKP-based proofs from Holochain source chains that can be verified by other Holochain networks or other distributed systems.

Near-term bridge — Flowsta: Flowsta supplies W3C DIDs and dual-signed agent linking (IsSamePersonEntry on the NDO DHT, ndo_prima_materia.md Section 6.7) so the same human can be recognised across Holochain conductors without shared DNA. PrivateParticipationClaim entries remain non-transferable and bound to the local AgentPubKey; reputation summaries can nevertheless be attributed to a DID for cross-app trust — the same distinction as resources.md Section 4.6 (attribution portability is not claim transferability). REQ-NDO-AGENT-08 positions the Flowsta DID as the cross-network identity anchor for portable credentials. ZKP/VC layers remain the longer-term path for minimally revealing proofs at scale.

The identity insurance alternative: the OVN wiki cites Vinay Gupta's proposal that what P2P systems need is not reputation but restorative justice — insurance that compensates you if an agent acts in bad faith. "If I present you with proof that I am insured against bad conduct, and you trust my insurer will pay, REPUTATION is suddenly a whole bunch less important." This is a provocative alternative to the PPR approach: rather than tracking reputation to prevent bad actors, use economic backstops to make bad acting unprofitable. The NDO's Unyt Smart Agreement integration could potentially implement this pattern.

4.5 Privacy vs Network Efficiency

The OVN wiki frames this as a genuine tension with no universal solution: an agent's contribution history can improve network efficiency (matching to tasks, governance access, trust in new interactions) but also creates a privacy risk (triangulation of physical identity, de-platforming vulnerability).

The OVN wiki's resolution: "the agent must be given the choice, allow an individual profile to be formed from past activity or not, weighing the pros and cons, the benefits and the potential harm." The NDO's private-but-derivable PPR system partially implements this: agents sign PPRs (opting into accountability) but control how their ReputationSummary is shared. The gap is that there is currently no mechanism for an agent to participate partially — all PPRs follow the same model.

A more complete implementation would allow agents to choose their privacy level per interaction:

• Full anonymity: no PPRs, no reputation accumulation, no access to governance
• Pseudonymous: PPRs linked to a persistent pseudonym, not to physical identity
• Named: PPRs linked to public Person entry

This spectrum maps to the OVN's individual/person identity model: individual-level participation (anonymous), person-level participation (reputation-accumulating), and fully identified participation (legal accountability for high-trust processes).

4.6 Agent Profile and Network Wealth

An agent participating in Sensorica, a Fab Lab, and a Research Collective simultaneously is a bridge node — carrying trust, information, and potential collaboration across network boundaries. Multi-membership and cross-network reputation (via FlowstaIdentity DID) are themselves a form of network wealth.

The OVN wiki's individual profile description includes something not present in most technical systems: network affiliations as a form of organisational wealth. "The information about affiliations can be used... to assess the organic reach into other organisational contexts, beyond the immediate zone of influence of the context. This allows surfacing of a new form of network wealth, its influence or degree of connectivity with other networks within the ecosystem, provided by the number of relations extending from the context network to other networks, through agents."

An agent who participates in multiple OVNs is a bridge node — a carrier of information, trust, and potential collaboration across network boundaries. This agent's profile is not just a personal record; it is a piece of the network's connective tissue. Making this visible makes the network's resilience and reach legible.

The NDO currently has no social graph and no multi-network affiliation model. An agent is either in this network or not. The generic NDO should model the OVN's insight that agents are simultaneously nodes in multiple overlapping networks, and that this multi-membership is itself a form of value.

5. Gap Analysis

5.1 Mapped — OVN concepts implemented or planned in NDO

5.2 Partial — concepts present in OVN and partially covered in NDO

5.3 Missing — OVN concepts not yet planned in NDO

6. Forward Map: Generic NDO Agent Architecture

6.1 Agent Type as Configuration, Not Hard-Code

Rather than adding parallel code paths for each agent type, the generic NDO should treat agent type as a configuration property:

#![allow(unused)]
fn main() {
pub enum AgentEntityType {
    Individual,                    // Human participant
    Collective(String),            // Group/working group (name/description)
    Project(ActionHash),           // Project NDO this agent represents
    Network(ActionHash),           // Network NDO this agent represents
    Bot { capabilities: Vec<String>, operator: AgentPubKey }, // AI/bot with declared capabilities
    ExternalOrganisation(String),  // Traditional org (name, for partner modelling)
}

pub struct AgentContext {
    pub agent_type: AgentEntityType,
    pub person_hash: Option<ActionHash>,   // None for bots/external orgs
    pub created_at: Timestamp,
    pub network_seed: String,              // Which NDO network this context belongs to
}
}

Individual agents have AgentEntityType::Individual with a linked Person. Collective agents (working groups, projects) reference an NDO hash. Bots have no Person but have declared capabilities and a responsible operator.

6.2 Affiliation State as a Derived Property

Rather than storing affiliation state (which would need maintenance and could become inconsistent), derive it algorithmically from existing DHT data:

affiliation_state(agent) = f(
    person_exists(agent),                   // Boolean
    contributions_count(agent),             // From economic events
    last_contribution_timestamp(agent),     // Recency from economic events
    reputation_summary.total_claims,        // From PPRs
    affiliation_record_exists(agent),       // Has the agent signed the ToP?
    governance_claims_count(agent)          // From PPRs
)

→ UnaffiliatedStranger | CloseAffiliate | ActiveAffiliate | 
  CoreAffiliate | InactiveAffiliate

CoreAffiliate is algorithmically determined: an active affiliate whose PPR contribution rate in the past N days exceeds a configurable threshold becomes a core affiliate. This implements the OVN governance equation: governance access as benefit derived from contribution activity.

6.3 Composable AgentProfile View

The aggregated individual profile, computed on demand:

#![allow(unused)]
fn main() {
pub struct AgentProfile {
    // Identity layer
    pub agent_pub_key: AgentPubKey,
    pub person: Option<Person>,
    pub affiliation_state: AffiliationState,
    
    // Capability layer
    pub roles: Vec<PersonRole>,
    pub capability_level: String,           // member/stewardship/coordination/governance
    pub capability_slots: Vec<CapabilitySlotInfo>,  // External credential attachments; includes FlowstaIdentity → IsSamePersonEntry; optional resolved flowsta_did for UI (`ndo_prima_materia.md` Section 6.7)
    
    // Reputation layer (derived, selectively shared)
    pub reputation_summary: Option<ReputationSummary>,
    pub economic_reliability_score: Option<f64>,    // For Unyt credit limit
    
    // Participation layer
    pub active_commitments_count: u32,
    pub economic_events_count: u32,
    pub resource_custodianships_count: u32,
    
    // Social layer (optional, agent-controlled)
    pub network_affiliations: Vec<NetworkAffiliation>,
    pub peer_vouches: Option<u32>,          // Number of vouches from trusted peers
    
    // Temporal
    pub joined_at: Option<Timestamp>,
    pub last_active_at: Option<Timestamp>,
}
}

This profile is not an entry type — it is a query result, composed from existing entries. The agent controls which sections are exposed by granting access to the constituent entries.

6.4 Affiliation Record — The Terms of Participation Bridge

A lightweight mechanism to record formal affiliation:

#![allow(unused)]
fn main() {
pub struct AffiliationRecord {
    pub agent: AgentPubKey,
    pub network_id: String,                    // Which NDO network
    pub documents_acknowledged: Vec<DocumentAck>,  // Hash + title of each ToP document
    pub signed_at: Timestamp,
    pub signature: Signature,                  // Agent signs the affiliation record
    pub witness: Option<AgentPubKey>,          // Optional vouching agent
}

pub struct DocumentAck {
    pub document_hash: String,         // Hash of the document text
    pub document_title: String,
    pub document_version: String,
}
}

When an agent creates their first Person entry, the UI prompts them to acknowledge the network's Terms of Participation. The acknowledgement is cryptographically signed and stored as an AffiliationRecord. This bridges the OVN's formal affiliation ceremony with the NDO's digital infrastructure.

6.5 Portable Credential Summary

A structure that can be shared with other Holochain networks as proof of contribution and capability:

#![allow(unused)]
fn main() {
pub struct PortableCredential {
    pub issuing_network: String,               // DNA hash of the issuing network
    pub agent: AgentPubKey,
    pub credential_type: PortableCredentialType,
    pub claims: PortableCredentialClaims,
    pub issued_at: Timestamp,
    pub valid_until: Option<Timestamp>,
    pub issuer_signature: Signature,           // Signed by a Primary Accountable Agent
    pub agent_signature: Signature,            // Countersigned by the agent
}

pub enum PortableCredentialType {
    RoleCredential(String),                    // "Accountable Agent in network X"
    ReputationCredential,                      // Aggregated reputation score
    CompetencyCredential(String),              // "Certified 3D printer operator"
    AffiliationCredential,                     // "Active affiliate of network X since date"
}
}

A receiving network can verify the issuer_signature against the issuing network's DNA hash, establishing a cryptographic chain of trust without requiring centralized credential issuers.

Receiving networks may correlate credentials with a Flowsta DID when the issuer also records a FlowstaIdentity link on the agent's Person hash — improving interoperability without making PPR entries themselves transferable.

7. Complexity Economics Justification: Why Each Agent Concept Matters

Agent type taxonomy matters because economic models must faithfully represent economic actors. In Sensorica's actual operations, the entities performing actions are networks, ventures, and partner organisations — not just individuals. Flattening these to individual-human agents produces systematically inaccurate economic accounting. Benkler's P2P advantage — that P2P systems can process more information and model more finely-grained reality — is lost when the agent model is coarser than the actual social structure.

The affiliation spectrum matters because governance decisions made by binary "in/out" membership are weaker than those made by graded participation-aware membership. The governance equation (contribution history → governance access) requires a nuanced engagement model as input. If everyone is either "in" or "out," the governance equation reduces to "everyone who joined gets an equal vote," which ignores the 1-9-90 engagement reality. The result is either oligarchy (the 1% who do all the work decide everything while the 90% technically could override them) or paralysis (decisions require the majority of a population that mostly isn't paying attention).

ZKP capability proofs matter because the current privacy-accountability model forces a false binary: either share raw data (low privacy, high accountability) or share nothing (high privacy, no accountability). Zero-knowledge proofs break this binary. An agent can prove "I have at least 10 completed maintenance commitments" without revealing who the counterparties were, what the resources were, or what the exact performance scores were. This is the technical foundation for privacy-preserving meritocracy — governance access based on contribution without requiring surveillance.

Credential portability matters because the value of contribution data is severely limited if it only functions within a single application instance. An experienced Sensorica contributor who joins a new OVN should be able to leverage their track record. Without portability, every new commons requires starting from zero, creating massive friction to growth of the P2P ecosystem. Benkler's model of the peer production advantage assumes information flows across organisational boundaries — credential portability is the mechanism that makes this flow possible.

Cross-app identity (Flowsta) matters for the same reason credential portability matters: agents who participate in multiple OVNs or hApps are bridge nodes (Section 4.6). Without a verifiable same-person link across conductors, every network treats them as a stranger; sybil pressure and cold-start friction repeat. Flowsta's permissionless Tier 1 keeps overhead low for casual participants; Tier 2 lets communities demand verified identity only where Bar-Yam-style complexity matching says it is worth the coordination cost (high-trust governance, high-value custody).

The composable individual profile matters because an agent's full profile — their roles, contributions, social relations, affiliations, capabilities — is the information substrate for most governance and economic decisions in the commons. If this information is scattered across disconnected entries with no composable view, the information cost of making well-informed decisions is high. Bar-Yam's complexity matching principle: the governance system's access to information about participants must match the complexity of the participation patterns it is trying to govern.

Collective agent types matter because commons-based peer production is fundamentally about collectives. Modelling it as a collection of individual agents without collective agency misses the emergent properties of collaboration. A working group is not just the sum of its members — it has its own identity, its own resource access, its own reputation, and its own governance. Without collective agent types, the NDO cannot model the holonic structure of OVNs: the fact that every entity is simultaneously a whole and a part of a larger whole.

This is a living document. Section 5.3 should be converted into formal requirements as the generic NDO project begins. Section 6 describes design directions, not final specifications. The OVN wiki pages at Agent, Identity, Individual profile, and Organizational structure remain authoritative references for agent design in peer production systems.

Resources: Ontology, Implementation, and Forward Map

Type: Archive / Knowledge Base Document
Created: 2026-03-11
Last updated: 2026-06-16 (synced with NDO Layer 0 + federation code)
Relates to: ndo_prima_materia.md, versioning.md, digital-resource-integrity.md, unyt-integration.md, flowsta-integration.md, IMPLEMENTATION_STATUS.md
Sources: MVP code (zome_resource, zome_gouvernance), shared types (crates/shared/src/types.rs), NDO coordinator (dnas/nondominium/zomes/coordinator/zome_resource/src/ndo_identity.rs), federation modules (zome_gouvernance hard_link.rs, contribution.rs, agreement.rs), post-MVP design documents, OVN wiki — Resource, OVN wiki — Resource type

Purpose

This document maps the three states of Resource understanding in this Nondominium / NDO project:

1. Implemented — what exists today in the MVP zome_resource and zome_gouvernance codebases (including NDO Layer 0 and federation extensions)
2. Planned — what is designed in the post-MVP requirements documents
3. Remaining — what the OVN wiki's 15 years of commons-based peer production practice contains that NDO does not yet plan to implement, and which should inform the generic NDO design

The goal is to ensure that the generic NDO — which will be built as a standalone hApp and then instantiated by Nondominium and other projects — represents a complete and principled resource ontology, not an accidental by-product of a single use-case.

1. Conceptual Foundation: Resources in P2P Complexity Economics

Before mapping what is and is not implemented, it is necessary to establish what a Resource is in the theoretical context this project operates within. The OVN wiki defines resources from the REA (Resources, Events, Agents) ontology and extends it through 15 years of Sensorica practice. The NDO builds further on this.

1.1 Beyond REA Primitives

In standard REA accounting, a Resource is simply an entity that has economic value and can be tracked as it flows through Events performed by Agents. This is a correct but minimal definition — adequate for accounting, inadequate for governance.

In peer production, a resource is also:

• An information carrier: it encodes design intent, provenance, contribution history, and quality evidence
• A coordination node: agents discover it, express intent to use it, negotiate access, and coordinate around it
• A trust anchor: its history of use (how it has been treated, maintained, transacted) is evidence about the agents who interacted with it
• An economic attractor: governance rules embedded in a resource determine who can access it (to improve / develop use, maintain it), and therefore shape the economic topology of the network around it.

This richer conception changes the design requirements fundamentally. A Resource is not merely a record in a ledger — it is a socially embedded DHT object with its own identity, governance constitution, and economic role.

1.2 The Tragedy of the Commons Solved by Embedded Governance

Hardin's "tragedy of the commons" (1968) argued that shared resources are inevitably depleted because individual agents have incentives to overuse. His solution was privatisation or central regulation. Ostrom's work (Governing the Commons, 1990) empirically refuted this: communities have sustainably governed shared resources for centuries through embedded, peer-enforced rules — without privatisation and without central authorities.

The NDO is, architecturally, an implementation of Ostrom's finding. The GovernanceRule entries embedded in ResourceSpecifications are exactly the "locally evolved institutions" that Ostrom identified as the mechanism of successful commons governance. The peer validation of economic events, PPR generation, and role-based access control are the "monitoring and sanctioning" mechanisms she observed.

This theoretical grounding is not academic decoration. It justifies specific design choices: governance rules must be embedded in the resource (not in a separate administrative system), enforcement must be peer-based (not authority-based), and participation in governance must generate reputational stake for participants.

1.3 Rivalrous vs. Non-Rivalrous: The Governance Fork

Benkler (The Wealth of Networks, 2006) identifies the rivalry or non-rivalry of a resource as the primary determinant of optimal governance strategy:

• Non-rivalrous resources (digital designs, methods, documentation, software): can be copied and shared at near-zero marginal cost. Restricting access does not preserve the resource — it only reduces total value creation. Default governance: open access, attribution-based, copy-left.
• Rivalrous resources (physical tools, equipment, spaces, materials): use by one agent excludes others. Restricting access is necessary to prevent overuse and ensure maintenance. Default governance: Ostromian embedded rules, reputation-gated access, stewardship requirements.

This distinction has profound implications for NDO Resource modeling. A resource's governance defaults, access rules, lifecycle requirements, and Unyt integration patterns should all differ based on rivalry. The current implementation does not model rivalry explicitly — this is a fundamental gap. - ToDo

1.4 Complexity Matching: Governance Overhead Must Match Resource Complexity

Bar-Yam's complexity matching principle states that the governance complexity of a system must match the complexity of the challenges it manages. Applied to resources:

• A simple idea (Layer 0 only, Ideation lifecycle stage) requires near-zero governance overhead
• A design file shared across a network requires moderate governance (attribution, versioning, integrity)
• A physical CNC machine used by 50 agents requires substantial governance (access rules, maintenance scheduling, custody chains, reliability tracking)

The NDO's three-layer model (ndo_prima_materia.md) directly implements this principle. LifecycleStage on Layer 0 is implemented (10 stages, integrity-validated transitions); governance overhead can now be matched to maturity for NDO identity. This document still argues the forward map needs further refinement — OperationalState split, rivalry/scope classification, and Layers 1 & 2 activation — to model the full spectrum of resource types in practice.

1.5 Resources as Social Infrastructure

The OVN wiki goes further than REA in recognising intangible resources: social capital, trust, community sense, governance knowledge, competencies, synergy. These are not commodifiable — they cannot be transferred, traded, or priced. But they are inputs to productive processes and outputs of participation.

In complexity economics terms: these intangibles are the emergent properties of the social system. They cannot be designed in; they arise from the right conditions. But they can be cultivated, protected, and damaged. A governance system that only models material and digital resources is blind to a large fraction of the actual value that flows in peer production communities.

The NDO does not need to track intangible resources in the same way it tracks a bicycle or a CAD file. But it must be aware of them — as a category of resource type — to avoid designing governance mechanisms that damage them.

1.6 Source: the Third Category

The REA ontology that underpins ValueFlows operates with two primitives: Agent and Resource. The resource classification work in sections 1.1–1.5 implicitly accepts this duality. But 15 years of OVN practice and a growing literature on socio-ecological systems accounting reveal a case where neither primitive is adequate: generative ecological systems — watersheds, rivers, forests, fisheries, atmospheric assimilation capacity — that yield resources, receive ecological effects, and condition future possibilities without being ownable, intentional, or inventoriable in the standard sense.

The academic paper source-ndo-paper.md demonstrates with Occam's razor that modelling a watershed under Nondominium governance without a Source primitive requires three active ontological fictions and leaves four economic relations inexpressible. Adding one new primitive removes all seven distortions.

Source is a third ontological category: a generative, non-ownable, partially unknowable system that:

• yields Resources (a river yields cubic metres of water when abstracted)
• receives ecological effects (a river receives heavy-metal discharge)
• conditions other Sources (a forest conditions river flow and resilience)
• accumulates a historical ledger of boundary events for adaptive governance

Sources are represented in the Nondominium architecture as Source-NDOs: NondominiumIdentity entries with PropertyRegime::Nondominium (or CommonPool), a linked SourceProfile extension for condition indicators, and a stewardedBy relation instead of primaryAccountable. No agent owns a Source; stewards carry obligations to maintain the event ledger and adapt governance rules as the source ledger grows.

This is the cybernetic governance loop: boundary events accumulate → stewards interpret conditions → governance rules adapt → access affordances change → future events are conditioned. It extends the governance-as-operator pattern from complicated (rule-evaluable) to complex (adaptive, signal-based) governance contexts.

Normative requirements for Source-NDO are in source-ndo-requirements.md. This subsection is an ontological framing note; the detailed data model, governance patterns, and ValueFlows extension (vf:Source) are in that document.

2. Current Implementation (MVP)

2.1 Entry Types in zome_resource Integrity

The MVP implements four entry types in zome_resource integrity, plus shared NDO enums in crates/shared/src/types.rs (imported by both integrity and coordinator zomes):

NondominiumIdentity (NDO Layer 0 — ✅ implemented, PR #80/#84)

#![allow(unused)]
fn main() {
pub struct NondominiumIdentity {
    pub name: String,
    pub initiator: AgentPubKey,
    pub property_regime: PropertyRegime,
    pub resource_nature: ResourceNature,
    pub lifecycle_stage: LifecycleStage,
    pub created_at: Timestamp,
    pub description: Option<String>,
    pub successor_ndo_hash: Option<ActionHash>,   // set once on Deprecated (REQ-NDO-LC-06)
    pub hibernation_origin: Option<LifecycleStage>, // set on → Hibernating; cleared on resume
}
}

The original create_ndo action hash is the stable Layer 0 identity for all time. property_regime, resource_nature, and lifecycle_stage live on Layer 0 (not on ResourceSpecification or EconomicResource). Only lifecycle_stage, successor_ndo_hash (once), and hibernation_origin (Hibernating transitions) may change after creation; all other fields are integrity-validated as immutable. Deletes are always invalid (permanent tombstone at EndOfLife).

Coordinator API: create_ndo, get_ndo, get_all_ndos, get_my_ndos, update_lifecycle_stage, get_ndos_by_lifecycle_stage, get_ndos_by_nature, get_ndos_by_property_regime — see ndo_identity.rs.

Shared enums on Layer 0 (defined in crates/shared/src/types.rs):

#![allow(unused)]
fn main() {
pub enum LifecycleStage {
    Ideation, Specification, Development, Prototype,
    Stable, Distributed, Active,
    Hibernating, Deprecated, EndOfLife,
}

pub enum PropertyRegime {
    Private, Commons, Collective, Pool, CommonPool, Public, Nondominium,
}

pub enum ResourceNature {
    Physical, Digital, Service, Hybrid, Information,
}
}

Doc/code consistency: PropertyRegime has seven canonical variants in Rust and the UI (Private, Commons, Collective, Pool, CommonPool, Public, Nondominium). See §2.6. ResourceNature in code adds Service and Information beyond the three-variant design in ndo_prima_materia.md; forward-map variants Space, Method, and Currency (§6.2) are not yet in code.

ResourceSpecification (Layer 1 — ✅ activated, PR #132)

#![allow(unused)]
fn main() {
pub struct ResourceSpecification {
    pub name: String,
    pub description: String,
    pub category: String,
    pub image_url: Option<String>,
    pub tags: Vec<String>,
    pub is_active: bool,
    /// Visibility / discovery scope. Project-scoped specs skip the global anchor.
    pub scope: ResourceScope,
    /// Immutable pointer to the Layer 0 NondominiumIdentity this spec activates.
    pub ndo_identity_hash: ActionHash,
    /// The NDO action the author observed when activating Layer 1. Integrity
    /// cannot walk an update chain forward deterministically, so the author names
    /// the state they saw and validation resolves it backward to the identity.
    pub ndo_state_hash: ActionHash,
}
}

This is the knowledge layer in ValueFlows terminology: the type or template of a resource. It corresponds to the OVN concept of "Resource Type" — an abstract representation that groups interchangeable concrete instances.

EconomicResource

#![allow(unused)]
fn main() {
pub struct EconomicResource {
    pub quantity: f64,
    pub unit: String,
    pub custodian: AgentPubKey, // TODO (G1, REQ-AGENT-02): replace with AgentContext post-MVP
                                // to support Collective, Project, Network, and Bot agents as
                                // Primary Accountable Agents. Currently assumes individual agent.
    pub current_location: Option<String>,
    pub operational_state: OperationalState,
}
}

This is the observation layer: a specific instance of a resource at a point in time, held by a specific custodian.

GovernanceRule (typed as of PR #132)

#![allow(unused)]
fn main() {
pub struct GovernanceRule {
    pub rule_data: RuleData,         // tagged enum, replaces the rule_type/rule_data string pair
    pub enforced_by: Option<String>, // role required to enforce this rule
    /// Direct pointer to Layer 0 — required for constraint evaluation context.
    pub ndo_identity_hash: ActionHash,
    /// Denormalized from Layer 0 (immutable source) — enables zero-DHT-read validation.
    pub property_regime: PropertyRegime,
    pub resource_nature: ResourceNature,
    pub rivalry_override: Option<Rivalry>,
}

pub enum RuleData {
    AccessRequirement(AccessRequirementData),
    UsageLimit(UsageLimitData),
    TransferCondition(TransferConditionData),
    MaintenanceSchedule(MaintenanceScheduleData),
}
}

Economic rules governing access and use. The former untyped rule_type: String / rule_data: String pair is gone: RuleData is a tagged enum with a typed payload per variant, and GovernanceRuleType is derived from the discriminant rather than stored. Rules are checked against their NDO's classification by the predicates in crates/shared/src/constraints.rs — Hard violations are rejected at integrity, Soft violations return as advisory warnings. Definitions: crates/shared/src/rule_data.rs.

OperationalState (enum on EconomicResource) — ✅ implemented (REQ-NDO-OS-01)

PendingValidation | Available | Reserved | InTransit | InStorage | InMaintenance | InUse

LifecycleStage is implemented on NondominiumIdentity (see above). Operational condition cycles on the instance independently of lifecycle maturity — e.g. an Active-stage NDO can have an InMaintenance economic resource instance.

2.2 Link Graph

The link types model resource discovery and navigation:

Legacy resource/spec links (zome_resource):

• Anchor links for global discovery (AllResourceSpecifications, AllEconomicResources, AllGovernanceRules)
• Hierarchical links (SpecificationToResource, SpecificationToGovernanceRule)
• Agent-centric links (CustodianToResource, AgentToOwnedSpecs, AgentToManagedResources)
• Faceted search links (SpecsByCategory, ResourcesByLocation, ResourcesByOperationalState, RulesByType)
• Governance links (ResourceToValidation)
• Update chain links (for Holochain's append-only update pattern)

NDO Layer 0 links (✅ implemented, PR #80/#84):

• AllNdos — global anchor at path "ndo_identities" → all NondominiumIdentity action hashes
• AgentToNdo — initiator AgentPubKey → NDOs they created
• NdoByLifecycleStage — path "ndo.lifecycle.{Stage}" → NDOs at that stage (moved on transition)
• NdoByNature — path "ndo.nature.{Nature}" → NDOs of that nature (immutable after creation)
• NdoByPropertyRegime — path "ndo.regime.{Regime}" → NDOs under that regime (immutable after creation)
• NdoToSuccessor — deprecated NDO → successor NondominiumIdentity (REQ-NDO-LC-06)
• NdoToTransitionEvent — NDO → triggering EconomicEvent action hash (REQ-NDO-L0-05; link only, cross-zome event validation deferred)

Layer 1 activation (✅ implemented, PR #132): NdoToSpecification — NDO identity hash → ResourceSpecification, created on every create_resource_specification.

Not yet implemented: NDOToProcess (Layer 2 activation per ndo_prima_materia.md §4).

2.3 What the MVP Does Well

• Permanent Layer 0 identity anchor — NondominiumIdentity with field-level immutability and integrity-validated lifecycle state machine (forward chain, Hibernating resume, Deprecated + successor, EndOfLife tombstone)
• Faceted NDO discovery — global, per-agent, and categorization anchors by lifecycle stage, nature, and property regime
• Clean separation of specification (type/template) from resource (instance) — consistent with ValueFlows Knowledge/Observation layering
• Single-custodian model is appropriate for the current Artcoin/simple sharing use case
• GovernanceRule linked to ResourceSpecification rather than EconomicResource is architecturally correct: rules belong to the type, not the instance
• The anchor link pattern enables permissionless discovery
• Cross-NDO federation primitives — typed hard links, peer-validated contributions, and benefit-redistribution agreements in zome_gouvernance (PR #103; see §2.5)

2.4 Known Gaps in the MVP

2.5 Federation, versioning & contribution layer (zome_gouvernance, ✅ PR #103)

Beyond zome_resource, the governance zome implements NDO federation and contribution primitives that partially address versioning, composability, and OVN contribution tracking:

NdoHardLink — typed cross-NDO (cross-DNA) relationships:

#![allow(unused)]
fn main() {
pub enum NdoLinkType { Component, DerivedFrom, Supersedes }

pub struct NdoHardLink {
    pub from_ndo_identity_hash: ActionHash,
    pub to_ndo_dna_hash: DnaHash,
    pub to_ndo_identity_hash: ActionHash,
    pub link_type: NdoLinkType,
    pub fulfillment_hash: ActionHash, // EconomicEvent backing this link
    // ...
}
}

Partial coverage of the versioning DAG (versioning.md): DerivedFrom and Supersedes map to evolution/supersession relations; Component supports composable/fractal resource architecture. Not a full DAG (no ForkedFrom, MergedFrom, RepairedFrom, etc.).

Contribution — peer-validated work on an NDO (ValueFlows Work/Modify semantics):

#![allow(unused)]
fn main() {
pub struct Contribution {
    pub provider: AgentPubKey,
    pub action: VfAction,
    pub ndo_identity_hash: ActionHash,
    pub validated_by: Vec<AgentPubKey>, // min 1 AccountableAgent
    pub effort_quantity: Option<f64>,
    // optional cross-DNA WorkLog reference (Group DNA)
    // ...
}
}

Agreement — benefit redistribution clauses on an NDO (partial Unyt/BRD primitive):

#![allow(unused)]
fn main() {
pub struct Agreement {
    pub ndo_identity_hash: ActionHash,
    pub version: u32,
    pub clauses: Vec<BenefitClause>,
    pub primary_accountable: Vec<AgentPubKey>,
    // ...
}
}

Coordinator modules: hard_link.rs, contribution.rs, agreement.rs. Sweettest coverage in dnas/nondominium/tests/src/governance/mod.rs. Not yet wired to Unyt RAVE validation or full upstream contribution propagation.

2.6 Doc/code consistency notes (reconciliation recommended)

3. Post-MVP Roadmap

The following improvements are designed in the post-MVP documentation. Items marked ✅ Implemented are live in the codebase; others remain planned or partial. Full specifications are in the referenced documents.

3.1 NDO Three-Layer Model (ndo_prima_materia.md)

The most significant architectural change. Replaces the flat ResourceSpecification + EconomicResource model with a progressive three-layer structure:

• Layer 0 — NondominiumIdentity: ✅ Implemented (PR #80/#84). A permanent, immutable identity anchor. The genesis entry whose action hash becomes the stable identifier for the resource across its entire existence. Contains name, description, initiator, property_regime, resource_nature, lifecycle_stage, created_at, successor_ndo_hash, hibernation_origin. Never voided — serves as the tombstone at end of life.
• Layer 1 — ResourceSpecification (activated by the NdoToSpecification link): ✅ Implemented (PR #132). The form of the resource — design, typed governance rules, scope. create_resource_specification writes the link and the spec carries ndo_identity_hash / ndo_state_hash, so a spec can no longer exist without an NDO parent. Activation is gated to lifecycle stages Specification through Active. Digital asset manifests (REQ-NDO-L1-06) remain post-MVP.
• Layer 2 — Process (activated by NDOToProcess link): 🔄 Not started. The activity around the resource — EconomicEvents, Commitments, Claims, PPRs. Activated when multi-agent coordination begins. ValueFlows cycle exists in zome_gouvernance but is not yet linked to NDO identity via NDOToProcess.

This model directly implements the complexity matching principle: coordination overhead grows with actual social complexity, not at resource creation. The three-layer structure describes the resource face of any entity — including collective entities. When a collective (project-organisation, cooperative, network) has an associated NDO, that NDO is its digital twin as a Resource: its permanent identity, lifecycle, specification, and governance. The collective also has an agent face (AgentContext) through which it participates in economic events. These are distinct — see agent.md §3.1 for the dual-face model.

3.2 Property Regime and Resource Nature

✅ Implemented on NondominiumIdentity (shared crate + integrity validation). Canonical Rust definitions:

#![allow(unused)]
fn main() {
pub enum PropertyRegime {
    Private,        // Full rights bundle; individual ownership
    Commons,        // Non-rivalrous shared resource; governance via licensing/attribution
    Collective,     // Cooperative/collective ownership
    Pool,           // Pool of shareables: rivalrous shared resources; custody/scheduling/maintenance
    CommonPool,     // Rivalrous consumable resource; governance via quota/depletion rules
    Public,         // Public/governmental stewardship; open-access; non-alienable by the public body
    Nondominium,    // Uncapturable by design; contribution-based access; no alienation permitted
}

pub enum ResourceNature {
    Physical,     // Material objects, equipment, consumables
    Digital,      // Software, data, design files, documents
    Service,      // Software services, knowledge assets (extends spec's 3-variant set)
    Hybrid,       // Digital twin of a physical resource
    Information,  // Knowledge assets, data sets (extends spec's 3-variant set)
}
}

These enums are part of NondominiumIdentity (Layer 0) — they classify the resource at creation and remain stable across its lifecycle (integrity-enforced). The PropertyRegime enum is reconciled from the OVN property regime taxonomy (§4.4.3) — see §4.4.6 for the full analysis.

Consistency: Protocol and UI both expose all seven PropertyRegime variants. Regime-driven governance enforcement (transfer-rights, no-alienation guards) is Phase B — see §4.4.4–§4.4.5 and implementation_plan.md.

3.3 LifecycleStage and OperationalState

LifecycleStage — ✅ Implemented on NondominiumIdentity (10 stages, integrity-validated state machine, initiator-only updates in MVP):

Ideation → Specification → Development → Prototype →
Stable → Distributed → Active →
Hibernating → Deprecated → EndOfLife

Hibernating records hibernation_origin and resumes to that stage. Deprecated requires successor_ndo_hash (REQ-NDO-LC-06). EndOfLife is terminal.

OperationalState — ✅ Implemented on EconomicResource (7 states; update_operational_state, get_resources_by_operational_state). Governance-zome transition enforcement (REQ-NDO-OS-02–03) remains deferred.

Each lifecycle transition should be governance-validated (the governance zome as state transition operator), generate an economic event, and create a lifecycle history audit trail (REQ-NDO-LC-02/03). Today: integrity zome validates transitions; automatic EconomicEvent generation and governance-as-operator evaluation are deferred.

3.4 Versioning (versioning.md)

🔄 Partially implemented via NdoHardLink (NdoLinkType: Component, DerivedFrom, Supersedes) in zome_gouvernance (PR #103). Cross-DNA hard links support federation-scale composition and supersession.

Full DAG-based version graph (typed relations: EvolvedFrom, ForkedFrom, MergedFrom, RepairedFrom, AugmentedFrom, PortedToPlatform) and OVN-compliant contribution propagation upstream through the version graph remain planned — see versioning.md.

3.5 Digital Resource Integrity (digital-resource-integrity.md)

Cryptographic integrity verification for digital resources: SHA-256 content addressing per 64KB chunk, Merkle tree structure for selective verification, composable/fractal resource architecture (atomic → component → composite), supply chain transparency.

3.6 Many-to-Many Flows (many-to-many-flows.md)

Extension of the single-custodian model to shared custody with weights and roles, one-to-many/many-to-one/many-to-many custody transfers, resource pools, co-custodian delegation.

3.7 Unyt Integration (unyt-integration.md)

🔄 Planned (post-MVP). Economic settlement layer via Unyt Smart Agreements and RAVEs. EconomicAgreement GovernanceRule type, RAVE validation as state transition precondition, PPR↔RAVE provenance chain, reputation-derived credit limits.

Partial primitive: Agreement + BenefitClause entries exist in zome_gouvernance (PR #103) as a benefit-redistribution data model on NDO identity hashes. Not yet wired to Unyt cells, RHAI scripts, or RAVE validation.

3.8 Flowsta Integration (flowsta-integration.md)

🔄 Planned (post-MVP). Decentralized identity and authentication layer via Flowsta agent linking. FlowstaIdentity CapabilitySlot on Person entry hash, providing W3C DID (did:flowsta:uhCAk...) without modifying the Person entry schema. Two-tier identity authority: Tier 1 (permissionless attestation via CapabilitySlot link) and Tier 2 (governance-enforced identity verification for role promotions and high-value transitions). Flowsta Vault provides BIP39 key recovery and auto-backup for agent data resilience (CAL-compliant). PPR ReputationSummary becomes attributable to a cross-app DID, enabling portable reputation across Flowsta-linked Holochain apps.

4. OVN Resource Ontology: 15 Years of Practice

The OVN wiki (Resource, Resource type) represents the distilled understanding of commons-based peer production at Sensorica. This section synthesises its key concepts in the context of NDO design, with complexity economics justifications.

4.1 Resource Primitives (Greg Cassel / OVN)

The OVN wiki adopts Greg Cassel's resource primitive taxonomy: mental resources, identity, physical resources, and media resources. This is broader than REA.

Mental resources — thoughts, feelings, ideas, knowledge that exists in agents' minds. Cannot be modelled directly in a DHT system (they are in the agent's head, not on a public ledger), but they are inputs to productive processes. In NDO terms: mental resources become visible when an agent creates an Ideation-stage NDO (Layer 0 only), which is the externalization of a mental resource into a public intent. The Ideation lifecycle stage is precisely the mechanism by which mental resources enter the observable network.

Identity — the capacity to distinguish agents and resources. In NDO terms: the NondominiumIdentity entry is the identity resource for every NDO object. Agent identity is handled by zome_person.

Physical resources — material objects with physical properties. NDO's Physical nature classification and the full custody/maintenance/transport/repair process suite cover this category.

Media resources — information superimposed on mediums: signs, signals, streams, messages, items, channels. This maps to NDO's Digital nature classification but is richer: the OVN taxonomy distinguishes between a design file (media item) and the channel through which it is shared (media channel). NDO currently does not make this distinction — a Digital resource could be either.

Complexity economics note: Mental resources and media resources are both non-rivalrous. Their governance implications differ from physical resources. Encoding this distinction at the resource type level is prerequisite to correct governance defaults.

4.2 Value Chain Maturity

The OVN wiki characterises resources by their stage of development:

The NDO LifecycleStage enum covers and extends this taxonomy with the addition of post-operational stages (Hibernating, Deprecated, EndOfLife) that OVN implies but does not formally enumerate. The NDO model is thus more complete in this dimension.

Complexity economics note: A resource's governance complexity should match its value-chain maturity. An Ideation-stage resource (someone's declared intent) requires near-zero governance. A Stable design that is being distributed for fabrication requires full governance, integrity verification, and versioning. The NDO's pay-as-you-grow layer activation model directly implements this — it is why the three-layer model is correct.

4.3 Production Process Resource Types

The OVN wiki classifies what production processes need:

The most significant gaps here are Method (documented processes, recipes, protocols) and Space (physical locations with governance, scheduling, and access control needs). Both are important in commons-based peer production settings.

Method resources are particularly interesting in the NDO context: a fabrication method (how to assemble a CNC machine) is a non-rivalrous digital resource — it can be copied freely. But it is also a governance-bearing resource: it defines the conditions under which physical resources should be used, encoding safety requirements, quality standards, and attribution requirements. In NDO terms, a Method would be a Digital NDO whose Layer 1 specification includes both the documented process and governance rules referencing it.

Space resources are rivalrous (only one person can use the CNC machine bay at a time) and require scheduling/booking mechanics that the current NDO does not model. A future generic NDO should be able to express temporal availability as a dimension of resource governance.

4.4 Property Regimes

4.4.1 What Property Is

The OVN wiki opens its treatment of property with a definition that reorients the entire concept away from legal formalism: "Property is about the relationship between agents and things. These relationships are institutionalized, meaning that they are codified as norms or rules or laws, are made public and are widely accepted by everyone in a social setting."

Property is not an object — it is a bundle of rights and obligations connecting a subject (agent) to an object (resource). Bentham identified four key classes of stakeholder rights in this bundle:

These four rights are not always bundled together. A Simple Agent may have Use rights without Management rights. A maintenance specialist has Custody rights for the duration of a repair without having Management rights. The NDO's role system and GovernanceRule architecture partially implements this unbundling, but without explicit modelling of which rights each role confers.

4.4.2 Goods Typology: The Excludability × Rivalry Matrix

Ostrom's four quadrants: Common-Pool Resources (high rivalry, low excludability → CommonPool regime), Private Goods (high/high → Private), Public Goods (low/low → Commons/Nondominium), Club/Toll Goods (low rivalry, high excludability → Collective/Pool). Goods type describes intrinsic characteristics; PropertyRegime describes the chosen governance arrangement.

Before classifying property regimes, Ostrom (following Samuelson) establishes a goods typology based on two independent axes:

• Excludability: can non-payers or non-members be excluded from use?
• Rivalry (subtractability): does one agent's use reduce availability for others?

Critically: goods types exist independently of property regimes. A common-pool resource (high subtractability, low excludability) can be owned as government property, private property, community property, or no-one's property. The goods type characterises the resource's physical or informational nature; the property regime characterises the social arrangement governing it.

This distinction matters for the NDO: ResourceNature and Rivalry describe the intrinsic characteristics of the resource. PropertyRegime describes the chosen governance arrangement. They are orthogonal fields.

4.4.3 The Full Property Regime Taxonomy

The OVN wiki distinguishes more regime types than the current NDO plan. All are important for the generic NDO:

The critical distinctions for the NDO:

Commons ≠ Pool of Shareables: The OVN wiki makes an important distinction. Commons are immaterial (non-rivalrous) resources — sharing a design file costs nothing and excludes no one. Pool of Shareables are material (rivalrous) — sharing a 3D printer requires scheduling, maintenance, and custody transfer. These have different governance requirements and should map to different PropertyRegime variants.

Commons ≠ Public: Commons are community-governed shared resources that can be captured through governance capture. Public denotes resources under public/governmental stewardship — open-access and non-alienable by policy of the stewarding public body, but not cryptographically uncapturable. A municipal library catalog or a publicly stewarded workshop is Public; a community knowledge commons is Commons.

Commons ≠ Nondominium / Public ≠ Nondominium: In the OVN model:

• Commons: governed resources with shared stewardship; theoretically, governance capture could privatise a commons (a bad actor could modify the governance rules to extract exclusive control)
• Public: public-body stewardship with open-access and non-alienation by policy; the stewarding body remains a social/legal actor, not a cryptographic guarantee
• Nondominium: uncapturable by design — no one can assert ownership, no organisation can enclose them. The property regime exists independently of governance rules: even if governance rules were to declare individual ownership, the cryptographic architecture makes it technically unenforceable

The NDO's architecture (append-only DHT, no admin key, agent-centric source chains) is a Nondominium implementation at the infrastructure level. This should be formally reflected in the data model.

Nondominium is defined by cost of capture, not by intent: The OVN wiki is precise — "The conditions for it to exist is to have extremely high costs of control, making it virtually uncontrollable by any entity, not even by nation states." This is a technical condition, not a legal or normative one. The NDO's PropertyRegime::Nondominium variant should encode a validation constraint: a resource declared as Nondominium must have governance rules that do not permit ownership assignment or transfer, and the system should reject GovernanceRule updates that attempt to add such rules. Phase A exposes semantic helpers (is_uncapturable, permits_ownership_transfer); Phase B wires these into the governance operator.

4.4.4 Property Regime Determines Possible Economic Models

The OVN wiki makes a point that is central to the NDO's relationship with Unyt: "once the property regime is fixed, only a limited number of motivation and incentive models are possible on top of that (call it economic model or business model). In turn, this determines people's values and behaviour within that organization."

This has direct architectural implications:

The PropertyRegime on NondominiumIdentity should therefore be a hard constraint on which GovernanceRules and Unyt Smart Agreements are valid for that resource. The governance zome should enforce this: an attempt to attach a sale Smart Agreement to a Nondominium resource must be rejected.

4.4.5 Property and Distribution — Transfer Rights

Seven PropertyRegime variants × four transfer types (Ownership, Custody, Use Rights, Benefit). Nondominium blocks ownership transfer architecturally. Public blocks ownership transfer by public-stewardship policy. Pool allows temporary custody scheduling. Commons blocks ownership but allows stewardship. Enforced by governance zome validation (Phase B).

The OVN wiki observes: "Distribution is a change in status, a transfer of rights and obligations associated with that thing... Distribution is not possible without the notion of property."

In the NDO, different property regimes enable different types of transfers:

The current NDO models custody transfer well (through EconomicResource.custodian and TransferCustody VfAction). It does not model ownership transfer, benefit transfer, or the regime-specific restrictions on which transfers are valid. The governance zome should enforce regime-appropriate transfer restrictions.

4.4.6 OVN Analysis and NDO PropertyRegime Reconciliation

The OVN wiki identifies eight property regime types (§4.4.3 table). The NDO forward map (§6.3) selects the seven regimes that are architecturally relevant to the generic NDO:

#![allow(unused)]
fn main() {
pub enum PropertyRegime {
    Private,        // Full rights bundle; individual ownership
    Commons,        // Non-rivalrous shared resource; governance via licensing/attribution
    Collective,     // Cooperative/collective ownership
    Pool,           // Pool of shareables: rivalrous shared resources; custody/scheduling/maintenance
    CommonPool,     // Rivalrous consumable resource; governance via quota/depletion rules
    Public,         // Public/governmental stewardship; open-access; non-alienable by the public body
    Nondominium,    // Uncapturable by design; contribution-based access; no alienation permitted
}
}

Mixed is removed — mixed regimes should be expressed as compound governance rules on top of a primary regime, not as a separate enum variant (which conveys no information about what the mix contains). Individual is renamed to Private to align with OVN property vocabulary. Public is included so publicly stewarded assets (libraries, parks, municipal infrastructure) can be modelled without collapsing them into Commons or Nondominium. Condominium and TollGoods are omitted from the initial generic NDO — they can be added as future variants if communities require them.

Complexity economics note: The OVN wiki states: "Property regime is not merely a legal classification, it shapes the entire economic topology of flows. A resource under the Nondominium regime cannot be enclosed, which is a stronger guarantee than a Commons resource (which can theoretically be privatised through governance capture)." This is precisely the Bar-Yam complexity matching principle applied to governance: the information requirements for different property regimes are vastly different. A Private resource can be governed by simple bilateral contracts. A Public resource requires non-alienation under public stewardship without claiming cryptographic uncapturability. A Nondominium resource requires cryptographic enforcement of uncapturability — human agreements are insufficient. The NDO's Holochain DHT architecture provides the technical foundation for Nondominium governance at scale; encoding the regime explicitly in the data model closes the loop between the technical guarantee and the social norm.

4.5 Accessibility, Availability, and Rivalry

The OVN wiki provides three orthogonal classification axes that NDO does not yet model:

Accessibility (who can access the resource):

• Free: public, no restrictions
• Protected/regulated: requires credentials — skill, role, reputation, or payment. In the NDO, "credentialed" access encompasses:
  • Role-based: existing RoleType membership, enforced by GovernanceRule enforced_by field
  • AffiliationState-based (post-MVP, TODO G2): derived from participation history via AffiliationRecord entries — e.g. ActiveAffiliate or CoreAffiliate tier. Not declared but computed; harder to game than assigned roles
  • PortableCredential-based (post-MVP, TODO G8): cross-network verifiable claims from allied networks, enabling recognition of contribution history that happened elsewhere
  • ZKP-based (post-MVP, TODO G7): privacy-preserving proofs of the form "I have ≥ N claims of type T" without revealing raw scores, counterparties, or timestamps — prerequisite for governance access without surveillance
  • FlowstaIdentity-based (post-MVP): cross-app identity via FlowstaIdentity CapabilitySlot on the agent's Person entry hash pointing to a dual-signed IsSamePersonEntry (Vault agent linking). Tier 1 (REQ-NDO-CS-12/CS-13) is a voluntary trust signal; Tier 2 (REQ-NDO-CS-14/CS-15) lets governance require a valid link for high-value or high-risk resource access — sybil resistance and cross-network accountability without revealing private PPR data
• Formally restricted: requires formal approval procedures

This maps to governance rule patterns in NDO but is not a first-class property. Encoding it explicitly would allow the system to set appropriate governance defaults and UI affordances automatically.

Availability (how much is there):

• Abundant: near-zero marginal reproduction cost (ideas, designs, documents)
• Scarce: high marginal reproduction cost (physical tools, equipment, materials)

And the related distinction:

• Rivalrous: access by one agent excludes others
• Non-rivalrous: multiple agents can access simultaneously without exclusion

This is the most critical missing dimension in the NDO plan. Rivalry determines optimal governance strategy more directly than any other property. Non-rivalrous resources should default to open access (information wants to be free); rivalrous resources require access scheduling, usage tracking, and maintenance governance. The generic NDO should model rivalry explicitly as a first-class EconomicResource property.

Complexity economics note: Benkler's entire argument for commons-based peer production rests on the distinction between rivalrous and non-rivalrous resources. A P2P governance system that does not formally model this distinction will produce governance rules that are either too restrictive for non-rival resources (inefficient) or too permissive for rival resources (destructive).

4.6 Transferability

The OVN wiki makes an important observation: allowing non-transferable assets (like reputation) to be transferred would destroy their value — "allowing this would in fact destroy the reputation system, as its meaning would be called into question." This is why Nondominium PPRs are cryptographically linked to the generating agent's key pair and cannot be assigned to another agent.

Flowsta's FlowstaIdentity CapabilitySlot introduces an important nuance: PPR reputation becomes attributable across apps (via a verified W3C DID) without becoming transferable. The DID is a stable cross-app reference key — other Flowsta-linked apps can verify that a given reputation history belongs to a specific cross-app identity — but the underlying PrivateParticipationClaim entries remain cryptographically bound to the generating agent's key pair on this DHT. Attribution portability and claim transferability are orthogonal: the former enables cross-network trust signals; the latter remains forbidden to preserve the integrity of the reputation system.

Complexity economics note: Transferability determines what kind of market or exchange system applies to a resource. Non-transferable resources require non-market coordination mechanisms (gifting, contribution tracking, reputation systems). The NDO already enforces non-transferability of PPRs at the cryptographic level. Extending this concept to other resources (should a method always be shareable? should equipment ever be non-transferable? these are governance questions) requires transferability to be a formal property.

4.7 Scope

The OVN wiki classifies resources by the domain they can affect:

This dimension is completely absent from the current NDO data model. Its importance for the generic NDO is significant: visibility, discovery, and governance rules for a network-scoped resource should differ from those of a public resource. A public design file should be discoverable globally; a project-scoped resource should only be visible to project participants.

4.8 Source

The OVN wiki tracks resource provenance:

In the NDO, this is modelled as a ResourceSource enum on NondominiumIdentity (Layer 0, see §6.1). It matters for governance (a purchased resource may still be owned by its buyer and not be a true nondominium) and for attribution (OVN-sourced resources carry contribution history; purchased resources do not).

4.9 Reliability

The OVN wiki identifies reliability as a property of material usables — distinct from, but analogous to, agent reputation:

"Material resources, mostly usables, should have a parameter of reliability, which is related to the risk associated with their use... Is that piece of equipment going to break during the fabrication process? Is that sensor going to present accurate data?"

This is currently absent from the NDO model. A resource can have high-quality custodians (good PPR scores) but be itself unreliable (it breaks frequently, produces defective outputs, or presents safety risks). Resource reliability should be:

• Accumulated from economic events: repair events, usage incidents, quality validation failures
• Independent of custodian reputation: a reliable agent can custody an unreliable tool
• A governance input: unreliable resources may require pre-access inspection, reduced access frequency, or mandatory insurance

Complexity economics note: In information theory, reliability is a measure of signal-to-noise ratio. A governance system that cannot distinguish reliable from unreliable resources is processing high-noise information — it cannot direct maintenance effort, access restrictions, or replacement decisions to where they are most needed.

4.10 Intangibles as Resources

The OVN wiki provides the most extensive taxonomy in the entire resource ontology for intangibles, identifying:

• Brand (network and deliverable identity)
• Social capital (opening markets, driving campaigns)
• Group dynamics (energising and animating a community)
• Member/customer loyalty
• Synergy (linking ventures in value systems)
• Internal structure and relationships (weaving agent networks)
• Incentive systems (designing and embedding incentives)
• Competencies (individual skill, group know-how)
• Cultural values (maintaining and evolving culture)
• Governance resources (decision-making knowledge and mechanisms)
• Trust (trust by members in the network, in its metrics, in its fairness)
• Sense of community

These cannot be traded, transferred, or precisely measured. But they are:

• Outputs of participation (being part of a well-functioning community increases social capital)
• Inputs to production (communities with high trust and good governance outperform those without)
• Destroyable by bad governance (surveillance capitalism, governance capture, and unfair systems all erode intangibles)

For the generic NDO, the implication is: do not model intangible resources as DHT entries. Instead, design the system's governance and participation architecture so that positive interactions generate intangibles as emergent properties. The PPR system, the reputation-credit loop, the transparent governance architecture, the permissionless access — these are design choices that cultivate social capital, trust, and community sense without attempting to track them as assets. The NDO should be consciously designed as an intangible resource producer, not just a material resource tracker.

5. Gap Analysis

5.1 Mapped — OVN coverage implemented or planned in NDO

5.2 Partial — concepts present in OVN and partially covered in NDO

5.3 Missing — OVN concepts not yet planned in NDO

These represent the forward agenda for the generic NDO design:

6. Forward Map: Generic NDO Resource Ontology

Based on the gap analysis, the generic NDO should extend its resource classification to the following model. This is a design proposal, not a requirements document — it will be refined as the generic NDO project begins.

6.1 Extended NondominiumIdentity (Layer 0)

Implementation status: Core Layer 0 fields (name, description, initiator, property_regime, resource_nature, lifecycle_stage, created_at, successor_ndo_hash, hibernation_origin) are ✅ implemented. Classification fields below marked NEW are forward-map additions not yet in code.

#![allow(unused)]
fn main() {
pub struct NondominiumIdentity {
    // Existing fields
    pub name: String,
    pub description: Option<String>,
    pub initiator: AgentPubKey,
    pub lifecycle_stage: LifecycleStage,
    pub created_at: Timestamp,

    // Classification fields (drive governance defaults)
    pub property_regime: PropertyRegime,  // existing
    pub resource_nature: ResourceNature,  // extended
    pub rivalry: Rivalry,                 // NEW
    pub scope: ResourceScope,             // NEW
    pub source: ResourceSource,           // NEW
    pub accessibility: Accessibility,     // NEW
    pub transferability: Transferability, // NEW
}
}

6.2 Extended ResourceNature

Implementation status: Code implements Physical, Digital, Service, Hybrid, Information (see §2.1). Forward-map variants Space, Method, and Currency below are not yet in code.

#![allow(unused)]
fn main() {
pub enum ResourceNature {
    Physical,   // ✅ Material objects: tools, equipment, consumables
    Digital,    // ✅ Software, data, design files, documents
    Service,    // ✅ Software services, knowledge assets (in code, not in original forward map)
    Hybrid,     // ✅ Digital twin of a physical resource
    Information,// ✅ Knowledge assets, data sets (in code, not in original forward map)
    Space,      // 🔄 Physical or virtual locations with temporal availability
    Method,     // 🔄 Documented process, recipe, protocol
    Currency,   // 🔄 Symbolic value exchange system (including Unyt Alliance Base Units)
    // Note: Mental resources are represented by Ideation-stage NDOs, not a separate type
}
}

6.3 Extended PropertyRegime

Implementation status: All seven variants below are ✅ in Rust (crates/shared/src/types.rs) and ✅ exposed in the UI (packages/shared-types, creation form, filters, badges).

#![allow(unused)]
fn main() {
pub enum PropertyRegime {
    Private,        // Full rights bundle; individual ownership (renamed from Individual per OVN vocabulary)
    Commons,        // Non-rivalrous shared resource; governance via licensing/attribution
    Collective,     // Cooperative/collective ownership
    Pool,           // Pool of shareables: rivalrous shared resources; custody/scheduling/maintenance
    CommonPool,     // Rivalrous consumable resource; governance via quota/depletion rules
    Public,         // Public/governmental stewardship; open-access; non-alienable by the public body
    Nondominium,    // Uncapturable by design; contribution-based access; no alienation permitted
}
}

6.4 New Classification Enums

#![allow(unused)]
fn main() {
pub enum Rivalry {
    Rivalrous,    // Use by one agent excludes others; access governance required
    NonRivalrous, // Multiple agents can access simultaneously; open access preferred
}

pub enum ResourceScope {
    Project,  // Benefits mostly the specific project/venture team
    Network,  // Benefits the entire organisational network
    Public,   // Commons accessible to the entire world
}

pub enum ResourceSource {
    Network,   // Created within the network (OVN/nondominium)
    Partner,   // Contributed by allied networks (may have use restrictions)
    Purchased, // Acquired through market exchange
    Donated,   // Gifted with conditions
}

pub enum Accessibility {
    Free,       // Open access, no restrictions
    Credentialed, // Requires role, reputation, or demonstrated skill
    Gated,      // Requires formal application and approval
}

pub enum Transferability {
    Transferable,    // Ownership can change (exchange, gifting)
    NonTransferable, // Cannot be exchanged or gifted (reputation, social capital)
    Shareable,       // Pool/commons items: shared without ownership transfer
}
}

6.5 Resource Reliability (Layer 2 derived property)

Resource reliability should be derived from Layer 2 EconomicEvents rather than stored as a static field — it is an emergent property of the resource's history, not a declared attribute:

reliability_score ← derived from:
  - Repair event frequency (more repairs = lower reliability)
  - Maintenance completion rate (scheduled vs. emergency maintenance ratio)
  - Incident reports (damage, failure, safety events)
  - Quality validation results (passed vs. failed inspections)

This score accumulates over time and is queryable from the governance zome alongside the custodian's ReputationSummary. A resource reliability score and a custodian reputation score together give a complete picture of a resource interaction's risk profile.

6.6 Governance Defaults from Classification

Three classification axes (ResourceNature, Rivalry, PropertyRegime) determine which governance rule templates apply. Digital + NonRivalrous + Commons → open access + copy-left. Physical + Rivalrous + Pool → credentialed access + custody transfer + maintenance schedule. Defaults are starting points overridable by community GovernanceRule entries on Layer 1.

The power of explicit resource classification is that it enables automatic governance defaults. The generic NDO should define a GovernanceDefaultsEngine that derives appropriate starting governance rule templates from the classification:

These defaults are starting points — communities override them through the GovernanceRule entries on Layer 1. But having well-considered defaults dramatically reduces the governance design burden for community members setting up new resources.

TODO (G2, G7, G8 — post-MVP): The Credentialed access defaults shown for Pool (Physical/Rivalrous/Pool) and Nondominium rows above will eventually support three additional credential dimensions beyond role membership:

• AffiliationState-based gating (G2): the governance operator queries zome_person for the requesting agent's derived affiliation tier and compares it to the min_affiliation condition in GovernanceRule.rule_data
• PortableCredential acceptance (G8): governance rules can declare which external credential types they accept, enabling cross-network access without re-joining
• ZKP-compatible evaluation (G7): reputation proofs are verified without revealing raw PPR scores or counterparties
• FlowstaIdentity Tier 1 (Flowsta Phase 1; REQ-NDO-CS-12, REQ-NDO-CS-13): Agents can attach a FlowstaIdentity slot on their Person hash to a valid IsSamePersonEntry (Vault dual-signed attestation), making a DID discoverable and enabling cross-app attribution of reputation — without AffiliationRecord, PortableCredential, or ZKP infrastructure. The governance zome does not enforce Tier 1 (ndo_prima_materia.md Section 6.7).
• FlowstaIdentity Tier 2 (Flowsta Phase 3; REQ-NDO-CS-14, REQ-NDO-CS-15): Governance rules can require a valid Flowsta link (per REQ-NDO-CS-15 checks) for credentialed access to resources that need sybil resistance or cross-network accountability — same phase and pattern as Unyt governance-operator enforcement (ndo_prima_materia.md Section 6.7).

The AffiliationState, PortableCredential, and ZKP dimensions above require the AffiliationRecord entry type (REQ-AGENT-05), cross-zome AffiliationState queries, and/or ZKP proof infrastructure — all post-MVP. Flowsta Tier 1 is the exception among trust signals: voluntary linking can ship in Flowsta Phase 1 without those dependencies. Flowsta Tier 2 enforcement requires Flowsta Phase 3 (zome_gouvernance changes), not Phase 1.

7. Complexity Economics Justification: Why Each Classification Matters

Rivalry matters because it determines the fundamental economic logic. Non-rivalrous resources exhibit positive sum dynamics — sharing them creates more value, never less. Rivalrous resources exhibit zero-sum dynamics in the short term — access by one agent genuinely prevents access by another. Conflating these in a governance system produces either over-restriction (damaging information flows) or under-restriction (depleting physical commons). No other classification has more direct governance consequences.

Scope matters because it determines information propagation. Benkler's analysis of networked information environments shows that scope determines who needs to know about a resource for it to produce value. A method that benefits the entire world should propagate globally; a specialised tool scoped to one project should not create noise in the global discovery layer. Scope-driven discovery anchors reduce the information overhead of the global DHT.

Property regime matters because it encodes the relationship between the resource and its community. A Nondominium resource cannot be captured, enclosed, or removed from the commons — this is a hard guarantee built into its governance validation rules. A Commons resource can be governed into restriction by its stewards. Individual-owned resources can be withheld. The economic consequences of each regime are profound and should be permanent attributes of the resource's identity, not mutable governance settings.

Reliability matters because it is information. In a P2P system with no central quality control, agents making decisions about which resources to access, which tools to borrow, which methods to follow, need reliable information about the track record of those resources. A resource with a high failure rate imposes hidden costs on the network — missed deadlines, wasted materials, unsafe working conditions. Making reliability visible and queryable converts hidden costs into explicit governance inputs.

Resource nature and method resources matter because the governance architecture for a documented protocol is fundamentally different from the governance architecture for a physical tool. A method (recipe, process, protocol) is non-rivalrous, can be forked and adapted, should be versioned and attributed, and its quality affects every physical process it governs. Modelling methods as first-class resources enables the network to track method provenance, quality, and evolution — and to connect method quality to the physical resource outcomes produced using those methods.

Intangibles matter negatively — as a design constraint. The OVN wiki's extensive treatment of intangibles is a warning: governance systems that ignore social capital, trust, and community sense will inadvertently destroy them through surveillance, commodification, or capture. The NDO's design choices (peer validation rather than central authority, private PPRs rather than public scoring, permissionless access rather than gatekeeping) are intangible-preserving choices. They should be recognised as such, so that future design decisions are evaluated against the same standard.

Source as third ontological category matters because omitting it makes ecological commons invisible to the economic ledger. Without Source, depletion events appear as raise (resource-from-nowhere), ecological loading disappears entirely, and the false fiction of an owning agent must be maintained for every watershed and fishery under Nondominium governance. The governance-as-operator architecture is exactly suited to Source-NDOs: the event ledger accumulates boundary signals, stewards interpret them, governance rules adapt, and future access is conditioned by source health — a cybernetic loop that implements adaptive governance for complex ecological systems. This matters because the single most important use case for the Nondominium property regime in natural commons is ecological: fisheries, watersheds, forests. A governance system that cannot model these without distortion is unsuitable for the most important commons of all.

This is a living document. As the generic NDO project begins, the gap analysis in Section 5.3 should be converted into formal requirements. The forward map in Section 6 should be reviewed against the actual NDO project scope and prioritised accordingly. The OVN wiki at ovn.world remains the authoritative reference for community-validated resource ontology concepts.

Governance: Ontology, Implementation, and Forward Map

Type: Archive / Knowledge Base Document
Created: 2026-03-11
Relates to: ndo_prima_materia.md, unyt-integration.md, flowsta-integration.md, resources.md, agent.md
Sources: MVP code (zome_gouvernance, zome_person), post-MVP design documents, OVN wiki — Governance

Purpose

This document maps the three states of Governance understanding in the Nondominium / NDO project:

1. Implemented — what exists today in the MVP zome_gouvernance and zome_person codebases
2. Planned — what is designed in post-MVP requirements documents
3. Remaining — what the OVN wiki's 15 years of commons-based peer production practice contains that NDO does not yet plan to implement

The goal is to ensure that the generic NDO — built as a standalone hApp — represents a principled, complete governance architecture that can support diverse communities and use cases through configuration, not custom code.

1. Conceptual Foundation: Governance in P2P Complexity Economics

1.1 What Governance Is (and Is Not)

The OVN wiki defines governance as "a means of direct influence for an organization." More structurally, it has three core functions:

• Selection — choosing among alternatives; decision-making
• Enforcement — enacting and reinforcing choices
• Adaptation — sensing, feedback, and evolving the rules

In traditional organisations, governance is largely concentrated: a small group selects, enforces, and adapts. In P2P open networks, all three functions must be distributed across a large, permeable, changing set of participants — without centrally controlled bottlenecks. This is not a political preference; it is an information-theoretic necessity. Bar-Yam's complexity matching principle: the governance system's complexity must match the organisational complexity it manages. As the network grows and its challenges diversify, only distributed governance can keep pace.

1.2 Embedded Governance and Stigmergy

The most important governance concept for the NDO is embedded governance: engineering the environment so that desirable behaviour is facilitated and undesirable behaviour is made impossible or costly, rather than relying on policing.

The OVN wiki describes this precisely: "Embedded governance (or immanent governance) is about engineering the environment in which actions are deployed to direct, channel or shape action, to take away the possibility of undesirable or less desirable action alternatives."

In practice: instead of writing a rule "you must not transfer a resource without a validated custodian," make it technically impossible to record a custody transfer without a prior commitment accepted by an accountable agent, based on enbedded rules, following validation. The rule is in the architecture, not in a policy document that humans can ignore.

This is also stigmergy in the complexity economics sense: governance through environmental modification. Ants do not follow written rules — their collective behaviour emerges from pheromone trails (environmental signals) that individual agents respond to locally. The NDO's capability slot surface (Layer 0 stigmergic attachment) is exactly this: governance emerges from what agents choose to attach to resources, without central coordination.

The same stigmergic attachment pattern applies to agent identity anchors: a FlowstaIdentity capability slot on the agent's Person entry hash (ndo_prima_materia.md Section 6.5 defines the Person attachment surface; Section 6.7 specifies Flowsta). Tier 1 is permissionless at the DHT level; Tier 2 is when a community turns that signal into a hard governance precondition via typed GovernanceRule mechanisms (Flowsta Phase 3).

The distinction between soft and hard embedded governance matters:

• Hard embedded: cryptographic impossibility of the prohibited action (Holochain validation rules, capability tokens)
• Soft embedded: social norms encoded as discoverable defaults (GovernanceRules marked as required, reputation consequences)

The NDO primarily uses hard embedded governance (Holochain integrity zomes are cryptographic) with soft embedded governance at the application layer (GovernanceRules are data that agents must choose to enforce in their coordinator logic).

1.3 Governance as Signal Processing, Not Rule Enforcement

The OVN wiki makes a critical distinction: OVN governance is not "rules-based, but rather signal-based, as norms emerge in real time from agent preferences, in context." Rules assume a known, closed world. Signals are the governance of complex, open, evolving systems.

In complexity economics terms: the adjacent possible (Kauffman) is never fully knowable. Rules written today cannot anticipate tomorrow's edge cases. The governance architecture must support emergence — agents should be able to propose and enact new norms through their behaviour, not just comply with pre-written rules.

This has direct implications for NDO design: the governance layer should expose proposing, voting, and adapting mechanisms as first-class capabilities, not just enforcement mechanisms. The current MVP focuses almost entirely on enforcement. Adaptation is barely present. Proposal is absent.

1.4 The REA Governance Parallel

The OVN wiki makes a structural proposal with deep implications: "Architecture governance in a way that it becomes compatible with the organizational and economic model architecture. REA is used to model the economic reality of the network, use the same structure to describe governance."

This means: governance events are EconomicEvents. Governance policies are Resources. Governance actors are Agents. The Policy/Scheduling/Accountability layers of REA are the governance architecture, not just the economic architecture.

The implication: the NDO's zome_gouvernance — which already models EconomicEvents, Commitments, and Claims — should be the natural home for governance events as well. A decision to grant a role is a governance EconomicEvent. A governance proposal is a Commitment. The decision outcome is a Claim. This unification is not complete in the current codebase but is architecturally supported.

1.5 Holonic Multi-Scale Governance

The OVN is fractal: ventures nest in networks, networks nest in networks-of-networks. Each level has its own governance concerns, while sharing protocols and standards. The NDO, as a holon (simultaneously whole and part), needs governance that is self-similar across scales — the same primitives should work at the instance level, the network level, and the federation level.

The OVN wiki defines three governance layers:

• Network-of-networks (ecosystem): protocols, standards, interoperability
• Network (commons community): shared resources, roles, benefit distribution
• Venture (project): specific work, specific benefit distribution

Currently the NDO implements only resource-level governance (single resource interactions, agent roles, process validation). Network and federation-level governance are absent.

1.6 Ostrom's Principles as NDO Architecture

Elinor Ostrom's 8 principles for governing commons (Governing the Commons, 1990) provide a design checklist for the NDO governance architecture:

2. Current Implementation (MVP)

2.1 Governance-as-Operator Architecture

The most important architectural choice in the MVP is the separation of data from governance logic:

• zome_resource: pure data model — creates and stores ResourceSpecification, EconomicResource, GovernanceRule entries without enforcing any business logic
• zome_gouvernance: state transition operator — the resource zome requests transitions, the governance zome evaluates the applicable rules and approves or rejects them

This is the REQ-ARCH-07 design. It means governance logic can evolve without touching the data model, different governance schemes can be applied to the same resource types, and governance is independently testable.

This architecture is the NDO's most principled contribution to governance design — it directly implements the OVN insight that governance must be compatible with the economic model (REA), because governance and economics are handled by the same zome operating on the same entry types.

2.2 VfAction System (16 Actions)

The VfAction enum defines all possible economic actions, and by extension, all possible governance-relevant state transitions:

Standard ValueFlows actions: Transfer, Move, Use, Consume, Produce, Work, Modify, Combine, Separate, Raise, Lower, Cite, Accept

Nondominium-specific extensions: InitialTransfer (first transaction by a Simple Agent, triggering role promotion), AccessForUse (access request triggering governance evaluation), TransferCustody (custody-specific transfer preserving nondominium property regime)

Each action has semantic methods: requires_existing_resource(), creates_resource(), modifies_quantity(), changes_custody(). This is the deontic layer — actions are typed by their governance implications.

2.3 Commitment / EconomicEvent / Claim Cycle

The MVP implements the core ValueFlows observation cycle:

Commitment (intent + obligation)
  └─ EconomicEvent (what actually happened)
       └─ Claim (link: this event fulfills that commitment)

This is the planning → observation bridge. Commitments are governance artifacts: they are the declared intent of an agent, time-bound, linking provider and receiver for a specific VfAction on a specific resource. The claim verifies fulfillment. The entire chain is auditable on the DHT.

This cycle is both governance and economics — consistent with the OVN wiki's REA governance parallel.

2.4 Validation System

ValidationReceipt: a peer-issued record that a specific item (resource, event, agent identity) was validated by a specific agent, with an approval decision, type, notes, and timestamp.

ResourceValidation: a multi-agent validation workflow for a specific resource, with configurable schemes ("2-of-3", "simple_majority", "N-of-M"). Tracks current vs. required validator counts and aggregate status.

The validation system implements the monitoring and graduated sanction aspects of Ostrom's principles: it is the mechanism by which the community collectively validates that resources, agents, and processes meet the network's standards before they gain access to higher-trust activities.

Validation functions in the coordinator:

• validate_new_resource: validates a resource being added to the network
• validate_agent_identity: validates an agent's private identity data for role promotion
• validate_specialized_role: validates a request for Transport, Repair, or Storage roles
• create_resource_validation: creates a multi-agent validation workflow
• check_validation_status: queries whether required validators have approved

2.5 The PPR System: 16 Categories, Bilateral Cryptographic Signatures

The Private Participation Receipt (PPR) system is the most complete governance mechanism in the MVP. It generates cryptographically signed, private receipts grounded in ValueFlows commitments and events.

In the MVP, each recorded economic interaction uses a single provider and a single receiver on the DHT (one-to-one ValueFlows pattern). For that interaction, the PPR model is pairwise bilateral: each party holds a receipt that names the other as counterparty, and two coordinated receipts capture the same underlying event from both sides (private-participation-receipt.md — “two receipts per action”). This is bilateral accountability per interacting pair, not a single shared “group receipt.”

Broader participation topologies (one-to-many, many-to-one, and many-to-many custody transfers, shared co-custodianship, resource pools, and delegation among co-custodians) are specified as post-MVP extensions to EconomicEvent / Commitment and to how PPRs are issued and attributed when several providers or receivers are involved (post-mvp/many-to-many-flows.md §1–2, Phase 5, REQ-MMF-19–22). Until that work lands, interactions that socially involve more than two agents must still be represented as sequences or combinations of one-to-one events and pairwise PPRs, or omitted from structured monitoring (see gaps in Sections 2.8 and 6 of this document and implementation_plan.md (many-to-many / AgentContext)).

PrivateParticipationClaim entry structure:

#![allow(unused)]
fn main() {
pub struct PrivateParticipationClaim {
    pub fulfills: ActionHash,           // References the Commitment
    pub fulfilled_by: ActionHash,       // References the EconomicEvent
    pub claimed_at: Timestamp,
    pub claim_type: ParticipationClaimType,   // One of 16 categories
    pub performance_metrics: PerformanceMetrics,
    pub bilateral_signature: CryptographicSignature, // Both parties sign
    pub counterparty: AgentPubKey,
    pub resource_hash: Option<ActionHash>,
    pub notes: Option<String>,
}
}

The 16 ParticipationClaimType categories across 5 groups:

PerformanceMetrics structure with weighted components:

• timeliness (weight 0.25)
• quality (weight 0.30)
• reliability (weight 0.25)
• communication (weight 0.20)
• overall_satisfaction (additional signal)

Bilateral cryptographic signatures: for each pairwise PPR, the issuing agent's view and the counterparty's agreement are both reflected in the receipt design (mutual attestation to the claim). This is not merely authentication — it is mutual accountability for that two-party slice of the interaction. Multi-party flows will need extended signing and distribution rules (see many-to-many-flows.md Phase 3 and §4.5).

ReputationSummary: a derived, privacy-preserving aggregate that agents can selectively share. Counts by category, average performance, time period. The agent controls what they reveal; the summary proves they have a track record without revealing individual interactions.

The PPR system is the NDO's most direct implementation of Ostrom's monitoring principle. It is also the input to the governance equation (access to governance = f(contribution history)).

2.6 Role System and Capability-Based Access

RoleType enum: SimpleAgent, AccountableAgent, PrimaryAccountableAgent, Transport, Repair, Storage

The first three are governance tiers (graduated trust levels). The last three are functional roles (validated competencies for specific processes).

Role assignment is tracked in PersonRole entries (in zome_person), created by assigned_by agents with appropriate governance tier. Role transitions (SimpleAgent → Accountable, Accountable → Primary) require:

1. Private identity validation by existing AccountableAgents
2. Completion of first validated transaction (for Simple → Accountable)
3. PPR milestones and specialist role validation (for Accountable → Primary)

Capability-based access (Holochain native): capability tokens gate cross-zome calls and agent-to-agent requests. The NDO extends this with:

• PrivateDataCapabilityMetadata: tracks field-level access grants with 30-day maximum expiry
• RevokedGrantMarker: explicit revocation record (Holochain capability revocation does not leave a trace by default)

This is the access control layer of the deontic ontology: permissions are cryptographically issued and cryptographically revoked, not relying on runtime checks.

TODO (G1, REQ-AGENT-01, REQ-AGENT-02 — post-MVP): The role system and all governance workflows assume AgentPubKey as the requestor. Specifically: RoleType is assigned to individual agents only; ValidationReceipt.validated_by is a single AgentPubKey; PPR counterparty is an AgentPubKey; and GovernanceTransitionRequest.requesting_agent is an AgentPubKey. Collective, Project, Network, and Bot agents (AgentEntityType from agent.md §6.1) cannot currently hold roles, participate in validation schemes, sign PPRs, or act as governance requestors. Post-MVP, role assignment must accept AgentContext (a union of individual and collective agent references). Delegation rules for collective signing authority must be defined — e.g., a designated PrimaryAccountableAgent representative key for the collective NDO, or an N-of-M multi-sig from its member agents. See implementation_plan.md §3 [G1+Resource] and agent.md §3.1.

2.7 What the MVP Does Well

• Governance-as-operator is the correct architectural pattern: clear separation of data model and governance logic, enabling swappable governance
• VfAction semantics — typed actions with governance implications — are a principled approach to deontic governance encoding
• Pairwise bilateral cryptographic PPRs are a novel and strong accountability mechanism; stronger than reputation systems that rely on one-sided ratings
• Multi-scheme validation ("2-of-3", "N-of-M") supports configurable collective decisions at the resource validation level
• Graduated role tiers implement Ostrom's "clearly defined boundaries" principle
• Private-yet-derivable reputation (PPR → ReputationSummary) correctly addresses the privacy/accountability tension

2.8 Known Gaps in the MVP

3. Post-MVP Roadmap

3.1 Governance-as-Operator Extended to LifecycleStage

The prima-materia model introduces two orthogonal state dimensions, both governed by the governance zome acting as state transition operator:

• LifecycleStage (10 stages on NondominiumIdentity): the maturity/evolutionary phase of the resource. Each transition requires a valid economic event and a role-authorized request. Examples: Prototype → Stable (peer validation), Active → EndOfLife (challenge period).
• OperationalState (7 states on EconomicResource): the current process acting on a resource instance. Transitions are triggered by process events: a transport Move event sets InTransit; its completion clears it back to Available. Transport, storage, and maintenance are processes — they do not advance LifecycleStage.

Both dimensions generate auditable lifecycle history via EconomicEvent entries, extending the governance-as-operator pattern to cover the complete resource state model.

3.2 EconomicAgreement GovernanceRule Type (Unyt Integration)

The EconomicAgreement GovernanceRule type (see unyt-integration.md) adds programmable economic governance to the existing rule set. Unyt Smart Agreements (RHAI scripts) become governance rules — specifying not just who may act but what economic consequence follows. This is a direct implementation of the OVN's connection between governance and the economic model.

Identity verification for cross-app identity follows the same structural pattern: a discoverable CapabilitySlot (Tier 1) plus an enforceable GovernanceRule (Tier 2) — detailed in Section 3.7 (Flowsta).

3.3 NDO Capability Slot Surface (Stigmergic Governance)

The CapabilitySlot surface (Section 6 of ndo_prima_materia.md) enables stigmergic governance at the NDO level. Any agent can attach governance tools (a GovernanceDAO slot, a dispute resolution hApp, a voting tool) to any NDO's Layer 0 identity hash without modifying the NDO entry. Governance infrastructure attaches to resources, not the other way around.

That same ndo_prima_materia.md Section 6 also defines the Person entry hash as a capability surface for agents (e.g. FlowstaIdentity); as rules mature, the governance operator may read both resource Layer 0 attachments and agent identity attachments when evaluating transitions — without prescribing every MOSS tool in the DNA.

3.4 Many-to-Many Governance Consent

Multi-custodian consent mechanisms (from many-to-many-flows.md): when a resource has multiple custodians, governance decisions that affect it require multi-party consent. This brings network-level governance down to the resource level.

3.5 Reputation-Weighted Governance (via Unyt)

The PPR → Unyt credit limit feedback loop (unyt-integration.md Section 7) is the governance equation in practice: contribution history determines economic access, and economic access determines which governance interactions are available. This is not yet explicit governance weighting, but it creates the data foundation for it.

When both Unyt and Flowsta are adopted, a Flowsta DID (via a valid Tier 1 FlowstaIdentity slot and IsSamePersonEntry) can anchor cross-app attribution of the same reputation signals that inform Unyt credit limits (ndo_prima_materia.md Section 6.7, Section 11.6).

3.6 Agent Ontology Impacts on Governance-as-Operator (Post-MVP)

The expanded agent ontology from agent.md introduces three structural changes to the governance-as-operator architecture that must be addressed in the post-MVP generic NDO:

3.6.1 AgentContext as Requestor (TODO G1, REQ-AGENT-02)

The GovernanceTransitionRequest.requesting_agent: AgentPubKey field (see governance-operator-architecture.md §2.1) must be extended to requesting_agent: AgentContext post-MVP. AgentContext is a union that accommodates Individual, Collective, Project, Network, Bot, and ExternalOrganisation agent types (see agent.md §6.1). The governance evaluation functions validate_agent_permissions and validate_agent_for_promotion must be extended to handle each type. For Bot and collective agents, the signing authority is the operator: AgentPubKey declared in AgentEntityType::Bot, or the designated PrimaryAccountableAgent representative of the collective NDO. Multi-sig patterns (N-of-M from collective NDO members) are an alternative for high-stakes governance actions. See Section 6.6 of this document for the full collective agent governance pattern.

3.6.2 AffiliationState as Governance Condition (TODO G2, REQ-AGENT-03, REQ-AGENT-05)

The governance operator must support min_affiliation conditions in GovernanceRule.rule_data. When a GovernanceRule contains a min_affiliation field (e.g. "min_affiliation": "ActiveAffiliate"), the operator must:

1. Cross-zome call zome_person to retrieve the requesting agent's AffiliationRecord entries
2. Derive the agent's current AffiliationState (UnaffiliatedStranger | CloseAffiliate | ActiveAffiliate | CoreAffiliate | InactiveAffiliate)
3. Compare the state against the min_affiliation threshold and block the transition if the agent does not meet it

This is the mechanism by which the governance equation (Section 4.4, Section 6.4) becomes operationally enforceable — not merely a conceptual aspiration. Without this cross-zome query, the governance equation has no runtime implementation. See resources.md §5.3 (Affiliation-gated resource access) and implementation_plan.md §3 [G2+Resource].

3.6.3 AffiliationRecord as Governance Ceremony (TODO G6, REQ-AGENT-05)

Signing an AffiliationRecord — the formal Terms of Participation ceremony — is itself a governance event in the ValueFlows sense. Using the existing Commitment/EconomicEvent cycle:

• The agent creates a Commitment entry: "I commit to the Terms of Participation, Nondominium & Custodian agreement, and Benefit Redistribution Algorithm"
• The act of signing the AffiliationRecord entry with the agent's key constitutes the fulfilling EconomicEvent
• A Claim links the two, creating an auditable on-chain record of the affiliation ceremony

The AffiliationRecord entry hash then becomes the evidence that the agent's AffiliationState function returns ActiveAffiliate. This is what transitions the agent from CloseAffiliate (knows the network, not yet committed) to ActiveAffiliate (has formally committed, gains governance access). No separate "activation" function is needed — the AffiliationState derivation reads the presence or absence of the AffiliationRecord directly from the DHT.

3.7 Flowsta Integration — Identity Verification Governance (flowsta-integration.md)

Parallel to Unyt (ndo_prima_materia.md Section 6.6 vs 6.7): Unyt combines a UnytAgreement capability slot with an endorsed EconomicAgreement GovernanceRule and, at full enforcement, a RAVE proof on the transition request. Flowsta combines a FlowstaIdentity capability slot on the agent's Person entry hash (target: an IsSamePersonEntry action hash committed by flowsta-agent-linking zomes) with an endorsed IdentityVerification rule (or equivalent typed rule): transitions that the rule scopes (e.g. PrimaryAccountableAgent promotion, high-value TransferCustody) are blocked unless Tier 2 validation passes (REQ-NDO-CS-15: slot present, IsSamePersonEntry includes requestor key, not revoked).

Tier 1 — permissionless attestation (REQ-NDO-CS-12, REQ-NDO-CS-13): FlowstaIdentity is a SlotType variant; any agent may attach a slot pointing at a valid IsSamePersonEntry. The governance zome does not require this for baseline participation.

Tier 2 — governance requirement (REQ-NDO-CS-14, REQ-NDO-CS-15): When an applicable rule is in force, evaluation shall verify: (a) a FlowstaIdentity capability slot exists from the requestor's Person hash; (b) the referenced IsSamePersonEntry includes the requestor's AgentPubKey as one of the two signing parties; (c) the link has not been revoked via the Flowsta coordinator's revoke_link (ndo_prima_materia.md Section 6.7).

Implementation locus (planned, not MVP): In ndo_prima_materia.md, Flowsta Phase 3 extends the same governance-operator / evaluate_transition_request story as Unyt Phase 3 — unified transition evaluation that reads typed rules and cross-zome / cross-cell evidence. Today's MVP stores GovernanceRule as rule_type / rule_data strings in zome_resource (no enum yet) and uses separate coordinator paths such as validate_agent_for_promotion and validate_agent_for_custodianship for private-field checks, without Flowsta or IdentityVerification enforcement. Tier 2 identity checks are specified to fold into that unified evaluation as the generic NDO matures.

PPR and reputation: With a verified slot, ReputationSummary is attributable to a cross-app DID (REQ-NDO-AGENT-08; prima Section 6.7). Attribution (same person across apps) is not claim transferability (PrivateParticipationClaim entries remain bound to local keys) — the same distinction as resources.md §4.6.

Complementarity: Flowsta answers who is who; Unyt answers who owes what. Communities may adopt one, both, or neither (ndo_prima_materia.md Section 6.7, Flowsta and Unyt). See resources.md §3.8 for resource-ontology cross-links and agent.md §3.5 for the agent-facing tier summary.

Traceability: ndo_prima_materia.md Section 11.6 (Flowsta integration in the requirements matrix).

3.8 Adaptive Governance for Source-NDOs (source-ndo-requirements.md)

Status: 🔄 Post-MVP — designed. No Rust implementation yet. See source-ndo-requirements.md for normative requirements; source-ndo-paper.md for academic justification.

The governance-as-operator pattern meets complex ecological systems. For project-type NDOs, governance rules are fixed at design time and evaluated on each transition request. For Source-NDOs — watersheds, rivers, fisheries, forests — rules must adapt as the source's condition changes. This is not a relaxation of governance rigor; it is a deeper application of it.

The cybernetic governance loop:

Boundary events (extraction, discharge, restoration)
  ↓ accumulated on Source Layer 0 hash as EconomicEvent entries
Ecological interpretation (scientists, stewards, monitoring systems)
  ↓ update SourceProfile.regime_state, resilience, tipping_threshold
Governance rule adaptation (GovernanceRule entries revised or replaced)
  ↓ evaluated by governance-as-operator on subsequent transition requests
Access affordances (extraction quotas, discharge limits, monitoring obligations)
  ↓ condition future events
(loop)

This loop extends — but does not break — the governance-as-operator architecture. The governance zome still evaluates rules on transition requests; the new dimension is that rules can change via a validated rule-revision process (REQ-SOURCE-GOV-01), and the rule evaluation also reads SourceProfile.regime_state to apply precautionary blocks near tipping_threshold (REQ-SOURCE-GOV-03).

Black-box epistemics. Unlike complicated resource governance (where rules can be fully specified from adequate knowledge), complex ecological governance must operate on partial information. The complex_interior: true flag on SourceProfile makes this epistemological stance machine-readable: the governance system governs observable peripheral events (what crosses the source boundary) rather than claiming to model the interior. This is Ashby's law of requisite variety applied to governance: the complexity of the governance system must match the complexity of the system it regulates — but for a complex system, matching that complexity means acknowledging and operating with irreducible uncertainty.

New governance concepts introduced:

Ostrom's principles applied to Source governance. Source-NDO governance implements all eight of Ostrom's design principles for commons governance (see §1.6 of this document), extending them to complex ecological systems:

Relation to existing governance architecture. Source-NDO governance does not introduce a new governance engine. It extends the existing governance-as-operator architecture with:

1. An additional evaluation input: SourceProfile.regime_state (cross-entry read by governance zome).
2. A new GovernanceRule class: monitoring obligation rules.
3. A rule-revision governance process: multi-validator approval required for GovernanceRule updates on Source-NDOs.
4. A new functional role: Steward (alongside the existing governance tiers).

All existing mechanisms — PPRs, capability tokens, validation receipts, ValueFlows events — apply unchanged to Source-NDO interactions.

Traceability: source-ndo-requirements.md §5 (REQ-SOURCE-GOV-01 through REQ-SOURCE-GOV-08).

4. OVN Governance Ontology: 15 Years of Practice

4.1 Governance Layers

The OVN wiki defines three governance layers, each with different concerns:

Network-of-networks layer (ecosystem governance):

• Protocols and standards for cross-network interoperability
• Role and reputation portability across organisational boundaries — planned: W3C DIDs plus FlowstaIdentity / IsSamePersonEntry as a near-term cross-network identity anchor (REQ-NDO-AGENT-08, ndo_prima_materia.md Section 6.7), with Verifiable Credentials and ZKP proofs as longer-term depth (see agent.md §4.4)
• Content management standards enabling effective cross-network documentation
• Custodian agreements, exchange firm mandates

Network layer (commons community governance):

• Resource access governance (tools, spaces, brand, infrastructure)
• Access to network-level governance participation
• Benefit distribution algorithm and governance equation
• Protocols for contribution accounting and transactions within the network

Venture layer (project governance):

• Benefit distribution for specific projects (regulated by benefit redistribution algorithm)
• Autonomous governance within the network's meta-rules

The NDO currently implements only venture-layer governance. The generic NDO must support all three, using the same primitives at each scale.

Complexity economics note: Multi-scale governance that uses self-similar primitives is not just architecturally elegant — it is functionally necessary. A governance system that only works at one scale cannot adapt to the fractal structure of real OVN communities. The holonic NDO structure (each NDO is both a whole and a part) requires holonic governance.

4.2 Governance Components

Governing bodies: Committees, offices, working groups. The OVN wiki notes that functions like "leadership," "coordination," and "accountability" should be seen as processes that can be distributed or embodied, not as roles necessarily held by specific individuals. The NDO's role system partially addresses this, but does not model governing body structures.

Registries: Formal lists used in governance processes — list of affiliates, list of events, list of legitimate funding proposals, list of ventures, list of digital services. Registries enable algorithmic governance: "only those included in the registry of affiliates will be considered for participating" in a decision. The NDO has anchor-based discovery links but no governance-specific registries.

Decision making: The OVN wiki lists multiple decision-making mechanisms: Free initiative, Red flag, Lazy democracy, Advice process, Voluntary subordination. None of these are implemented in the NDO beyond binary approval/rejection in validation schemes.

Body of agreements: Smart contracts + paper contracts + hybrid. Currently the NDO has GovernanceRules (programmable, onchain) and Commitments (onchain). Missing: integration with paper/legal agreements (even as hash references), and the hybrid model between onchain enforcement and offchain human processes.

People, environment, purpose: The OVN draws on constitutional theory: People (who is in and how they interact), Environment (external pressures on the organisation), Purpose (the attractor that orients governance). In NDO terms: People = agent system; Environment = DHT and surrounding ecosystem; Purpose = the nondominium property regime embedded in the DNA. These are correct architecturally but not explicitly modeled as governance artifacts.

4.3 Governance Processes

The OVN wiki lists five governance processes for how decisions get made:

The processes are not mutually exclusive. Different types of decisions warrant different processes. The generic NDO should support configurable governance process assignment per decision type.

4.4 Access to Governance and the Governance Equation

The OVN wiki identifies a key design problem in open systems: the long tail distribution of participation. A typical OVN has a 1-9-90 structure: 1% are core participants (entrepreneurial, high commitment), 9% are active contributors, 90% are occasional participants. The governance system must be sensitive to this — it cannot treat all participants equally without producing either governance paralysis (too inclusive) or oligarchy (too exclusive).

The governance equation maps contribution history to governance access:

governance_access = f(past_contributions, future_commitments)

Past contributions are measured through contribution accounting (PPRs in NDO). Future commitments are pledges of future work (Commitments in NDO). Access to governance is seen as a benefit — one of the outputs of participation in the commons, alongside economic benefits and social benefits.

The OVN affiliation spectrum (agent.md §4.2) is the operational definition of this equation — the concrete mechanism by which participation depth maps to governance tier:

• UnaffiliatedStranger / CloseAffiliate → individual-level access only: permissionless DHT reads, basic VfActions; no governance participation
• ActiveAffiliate → governance participation unlocked: validation, proposal submission, dispute resolution
• CoreAffiliate → elevated governance weight: rule amendment, role promotion, registry management; algorithmically determined from PPR contribution rate above a configurable threshold
• InactiveAffiliate → reduced access: prior contributions preserved and visible; governance weight suspended until re-engagement

The AffiliationRecord entry (G6) is the formal on-ramp that transitions an agent from CloseAffiliate to ActiveAffiliate. It is a governance event in the ValueFlows sense: the agent creates a Commitment (I commit to the Terms of Participation, the Nondominium & Custodian agreement, and the Benefit Redistribution Algorithm), fulfils it by signing the AffiliationRecord entry on-chain, and a Claim links the two. From that moment, the agent's AffiliationState derivation function (which reads DHT data, not a stored field) returns ActiveAffiliate, and the governance gate opens.

Post-MVP, ZKP proofs (G7) enable agents to prove their affiliation tier to other governance participants without revealing which network they are affiliated with, their full contribution history, or the identity of their counterparties. An agent can prove "I am at least an ActiveAffiliate with ≥ N governance claims" without disclosing the raw PPR data. This is the privacy-preserving meritocracy design: governance access based on contribution without requiring surveillance of the agent's full history.

Flowsta and complexity matching: Tier 1 (permissionless FlowstaIdentity attestation) keeps friction low for the long tail of occasional participants. Tier 2 (REQ-NDO-CS-14, ndo_prima_materia.md Section 6.7) lets communities require Tier 2–validated Flowsta linking only where Bar-Yam-style complexity matching justifies the coordination cost — e.g. PrimaryAccountableAgent promotion or high-stakes custody — without mandating Flowsta for every agent.

Non-binary decision making: The OVN wiki proposes mechanisms beyond yes/no voting: conviction voting (continuous preference posting, updated over time), quadratic voting (cost of additional votes grows quadratically, preventing concentration), rank choice (preference ordering across alternatives). These are described as composable — basic decision-making patterns that can be combined into more complex governance recipes.

Complexity economics note: The governance equation is an application of Benkler's observation that P2P systems can process more granular information than market or hierarchical systems. Instead of binary in/out, the governance system can weight participation based on the richness of contribution history, producing governance decisions that reflect actual contribution patterns rather than crude majority rules.

4.5 Embedded Governance — Onchain and Offchain

The OVN wiki's most practically important governance insight for NDO: the distinction between:

• Governance of the OVN: meta-rules about how the network behaves; control resides outside/above the automated system
• Governance through the OVN: automated execution through smart contracts, self-enforcing agreements

This maps to:

• Offchain governance (governance of): the community's agreements about rules, maintained in documents and social processes; what the DNA is designed to implement
• Onchain governance (governance through): the actual HDI validation rules, capability tokens, GovernanceRules; what the DNA implements and enforces automatically

The OVN wiki is explicit: "What cannot be automated? Human issues: interpersonal problems, emotions, etc. cannot be automated." Metagovernance — discussions about the rules, proposals for new rules, architectural decisions — requires human process. The NDO should provide hooks for metagovernance without trying to automate it.

Sensorica's current governance is described as "mostly offchain (written in documents), although some governance aspects are embedded within the infrastructure." The NDO project represents the transition toward more onchain governance, with Nondominium as "the resource transfer and flow engine... designed as an organization-agnostic system that embeds governance rules directly within resource definitions."

Complexity economics note: The question of how much to automate is itself a governance decision. Full automation produces a rigid, brittle system that cannot adapt to unforeseen situations. Full human process is slow and expensive. The optimal point depends on the community and context — which is why the NDO should support configurable automation depth, not hard-code a single approach.

4.6 Stigmergy and Governance

The OVN wiki treats stigmergy as a governance mechanism, not just an implementation pattern. "Stigmergic governance relies on embedded governance, meaning that the effect of these fundamental principles are complemented by the properties of the environment."

The key insight: governance can be reduced to a small number of principles embedded in the environment, with complex collective behaviour emerging from individual responses to environmental signals. Ants build nests of extraordinary complexity without written rules — just a few genetic principles and an environment they modify collectively.

For the NDO: the fundamental governance principles should be encoded into the DHT structure (Holochain validation rules, capability tokens, the VfAction semantics). The specific governance recipes for different communities should emerge from how those communities configure and extend the environment (GovernanceRules, CapabilitySlot attachments, role definitions). The system should not need a comprehensive rulebook — it needs a well-designed environment.

The OVN's description of stigmergy as "governance focused on attention — governing our collective attention" is relevant: capability slots and anchor links are both mechanisms for directing agents' attention to what is relevant, allowing them to coordinate without central direction.

4.7 Deontic Ontology

The OVN wiki explicitly calls for a deontic ontology integrated with REA: "Fundamental concepts and relations that allow us to speak about decisions, rules, norms, obligation and permission." The core operators are Obligation and Permission, from which Access (to benefits or resources) can be derived.

In NDO terms:

• Permission → capability tokens + role-gated validation + GovernanceRule enforced_by
• Obligation → Commitment entries (a declared obligation to perform a VfAction by a due date)
• Access → derived: agent has capability token AND meets GovernanceRule conditions → access granted

The current NDO implements these concepts but does not name them using deontic vocabulary. The generic NDO should formalise the deontic layer as first-class governance entries, not as implicit properties of other entry types.

A deontic governance entry might look like:

#![allow(unused)]
fn main() {
pub struct DeonticRule {
    pub operator: DeonticOperator,  // Obligation | Permission | Prohibition
    pub applies_to: AgentRole,      // Who this rule applies to
    pub regarding: ActionOrResource, // What action or resource it concerns
    pub conditions: Vec<Condition>, // Preconditions for the rule to apply
    pub enforced_by: GovernanceLayer, // Venture | Network | Federation
    pub expires_at: Option<Timestamp>,
}
}

This would replace the current untyped GovernanceRule with a formally typed deontic structure.

Planned first typed rule families alongside that migration include EconomicAgreement (Unyt settlement / RAVE path) and IdentityVerification (Flowsta FlowstaIdentity + IsSamePersonEntry path) — both specified in ndo_prima_materia.md Sections 6.6–6.7 while MVP code still uses rule_type / rule_data strings in zome_resource.

4.8 Temporal Governance

The OVN wiki identifies several temporal dimensions of governance:

• Decision expiry: decisions can have expiration dates, not just single-moment validity
• Evaluation triggers: decisions can include evaluation conditions that, if triggered, initiate review or revision
• Past-looking and forward-looking governance access: both contribution history and future commitments count
• Preference voting as continuous process: agents update preferences over time, building an ongoing governance profile

The NDO currently has only one temporal governance mechanism: capability grant expiry (30-day maximum for private data access grants). This is correct but minimal. The generic NDO should support temporal governance more broadly.

4.9 Constitution and the Governance of Governance

The OVN wiki discusses whether OVNs should have constitutions. Its conclusion: traditional constitutions (for closed, bounded organisations) don't map well to open, fractal networks. But the concept of a constitutive infrastructure — "all of that organization's implementations of the constitutive function" — is useful.

The constitutive infrastructure of an NDO community is:

• The DNA validation rules (hard-coded, very difficult to change)
• The global GovernanceRules (encoded in the DHT, updatable through governance)
• The community agreements (offchain, referenced but not enforced by the DNA)

The governance surface — the mechanisms through which the constitutive infrastructure can be modified — is a critical design element. In the OVN model, this includes: who can propose a rule change, what deliberation process applies, how changes are ratified, and how they are recorded.

The NDO has no formal governance surface. Rule changes require developer intervention (DNA upgrades) or are limited to per-resource GovernanceRule updates (controlled by role-gated validation). This is a fundamental gap for any community that needs to evolve its own rules.

5. Gap Analysis

5.1 Mapped — OVN concepts implemented or planned in NDO

5.2 Partial — concepts present in OVN and partially covered in NDO

5.3 Missing — OVN concepts not yet planned in NDO

6. Forward Map: Generic NDO Governance Architecture

6.1 Governance as REA — The Unified Model

The most important design principle for the generic NDO: governance events are EconomicEvents. The unified model:

GovernanceRule  (knowledge layer)    → ResourceSpecification analog
GovernanceRecord (planning layer)    → Commitment analog  
GovernanceDecision (observation layer) → EconomicEvent analog

This means:

• Proposing a rule change = creating a GovernanceRecord (a Commitment-like intent)
• Deliberation = Commitments from affected agents (support/oppose)
• Decision = GovernanceDecision (EconomicEvent-like outcome)
• Implementation = updated GovernanceRule entries
• Accountability = ValidationReceipt on the implementation + PPR for governance participants

This is not a new subsystem — it is the existing ValueFlows cycle applied to the governance domain. The governance zome already handles this cycle for resource governance. Extending it to meta-governance is architecturally natural.

6.2 Governance Process as Configurable Entry

#![allow(unused)]
fn main() {
pub struct GovernanceProcess {
    pub name: String,                   // "lazy_democracy", "advice_process", etc.
    pub applies_to: GovernanceScope,    // Venture | Network | Federation
    pub decision_type: DecisionType,    // RuleAmendment | RoleGrant | ResourceAccess | ...
    pub participation_required: Vec<ParticipantSpec>, // Who must participate
    pub quorum: QuorumSpec,             // Minimum participation threshold
    pub threshold: ThresholdSpec,       // What counts as a decision (majority, supermajority, etc.)
    pub timeline: GovernanceTimeline,   // Deliberation + decision + implementation windows
    pub veto_period: Option<Duration>,  // Optional lazy democracy reversal window
    pub expires_at: Option<Timestamp>,  // Sunset clause
}
}

Communities configure which governance process applies to which decision type. The generic NDO provides a library of composable process patterns (from the OVN vocabulary); each NDO instantiation selects and configures its governance recipe.

6.3 Registry Model

Registries are governance-managed lists. They are themselves NDO resources (a registry is a resource with its own governance rules):

#![allow(unused)]
fn main() {
pub struct Registry {
    pub name: String,               // "ValidatedAgents", "ActiveVentures", "LegitimateProposals"
    pub scope: GovernanceScope,     // Which governance layer manages this registry
    pub entry_type: RegistryEntryType, // What kind of entries it contains
    pub admission_process: GovernanceProcess, // How entries are added
    pub removal_process: GovernanceProcess,  // How entries are removed
    pub is_public: bool,            // Whether the registry is publicly readable
}
}

The registry mechanism enables algorithmic governance: "only agents in the ValidatedAgents registry may participate in the next decision." This moves governance from relying on per-decision ad hoc membership determination to managed, auditable lists.

6.4 Participation-Weighted Governance (The Governance Equation)

The OVN governance equation implemented as a cross-zome computation:

governance_weight = f(
    affiliation_state,                            // PREREQUISITE GATE (from agent.md §6.2)
                                                  //   < ActiveAffiliate  → weight = 0 (blocked)
                                                  //   = ActiveAffiliate  → weight computed normally
                                                  //   = CoreAffiliate    → weight × core_multiplier
                                                  //   = InactiveAffiliate → weight = 0 (suspended)
    reputation_summary.average_performance,       // quality of past contributions
    reputation_summary.governance_claims,         // governance participation depth
    reputation_summary.custody_claims,            // resource stewardship depth
    unyt_credit_capacity,                         // economic standing in commons
    active_commitments_count                      // forward-looking engagement
)

The affiliation_state input is derived (not stored) from existing DHT data by zome_person using the formula in agent.md §6.2:

affiliation_state(agent) = f(
    person_exists(agent),
    affiliation_record_exists(agent),   // AffiliationRecord (G6) signed on-chain?
    contributions_count(agent),         // from EconomicEvents
    last_contribution_timestamp(agent), // recency window check
    reputation_summary.total_claims,
    governance_claims_count(agent)
)

The affiliation_state gate ensures that the governance equation's contribution data is only evaluated after the formal affiliation ceremony (AffiliationRecord, G6) is complete. An agent with high PPR scores but no signed AffiliationRecord remains at CloseAffiliate and cannot participate in governance — they must formally commit to the network's terms before their contributions are recognised as governance standing. This prevents incidental interactions (browsing the DHT, casual transactions) from accumulating governance weight without commitment.

This weight determines:

• Vote weight in non-binary decision mechanisms
• Thresholds for initiating certain governance processes
• Access to higher-trust governance functions (dispute resolution, rule amendment)

Critically: the weight function is itself a GovernanceRule, configurable by communities. Different communities weight contribution dimensions differently. The core_multiplier and the recency window for InactiveAffiliate detection are also governance-configurable parameters.

Note: the inclusion of unyt_credit_capacity as an input creates a feedback loop (PPR → reputation → Unyt credit → governance weight → more governance participation → more PPRs). To prevent runaway accumulation, the weight function should apply dampening — e.g., logarithmic scaling of the credit capacity input — so that marginal increases in credit produce diminishing governance weight returns.

Communities may also (configurably) treat Tier 2–validated FlowstaIdentity (or simply presence of a Tier 1 DID link for softer signals) as an additional input for high-trust governance processes — aligned with PPR reputation attributable to a DID (ndo_prima_materia.md Section 6.7) — without requiring a new field in the sketch above.

6.5 Offchain Governance Bridge

A minimal mechanism for linking offchain human decisions to the onchain governance record:

#![allow(unused)]
fn main() {
pub struct GovernanceRecord {
    pub document_hash: String,           // Hash of the offchain document (PDF, markdown, etc.)
    pub document_uri: Option<String>,    // Where to find the document
    pub record_type: OffchainRecordType, // Agreement | Policy | Decision | Constitution
    pub ratified_by: Vec<AgentPubKey>,   // Agents who have ratified this record
    pub effective_at: Timestamp,
    pub supersedes: Option<ActionHash>,  // Previous version of this record
    pub scope: GovernanceScope,
}
}

This is the bridge between the OVN's offchain governance reality (most governance today is documents and social processes) and the onchain aspiration. Agents ratify offchain documents by signing GovernanceRecord entries — creating a cryptographic commitment to the offchain text without requiring full onchain implementation of its processes.

6.6 Collective Agent Governance Patterns (Post-MVP)

The expanded agent ontology (agent.md §3.1, §4.1`) enables working groups, projects, networks, and bots to act as governance participants. Three structural patterns cover the main cases:

Pattern 1 — Collective agents as NDOs

A working group, project, or network is itself an NDO with its own governance layer (Identity + Specification + Process). When a collective NDO participates in external governance — signing a ValidationReceipt, acting as a GovernanceTransitionRequest.requesting_agent, or being a PPR counterparty — it does so through a designated representative: the PrimaryAccountableAgent of the collective NDO, whose AgentPubKey acts on the collective's behalf. Governance decisions affecting the collective (e.g., approving a resource access request it submitted) require internal governance within that collective NDO before the external signature is issued. This nests governance holonically: venture → network → federation, all using the same VfAction/Commitment/EconomicEvent primitives.

Pattern 2 — Multi-sig validation for collective actors

When a governance process requires approval from a collective agent (e.g., a working group must validate a new resource), the ResourceValidation scheme must support AgentContext references in its required_validators field. Two implementation options:

• Designated operator: the collective NDO has nominated a single PrimaryAccountableAgent whose signature counts as the collective's approval. Simple but creates a governance bottleneck at the operator.
• Member threshold: the governance scheme accepts approval from N-of-M individual agents who are current active members of the collective NDO. More resilient but requires the validator set to be dynamically resolved from the collective NDO's membership links at validation time.

Both options require the GovernanceProcess entry (Section 6.2) to declare which pattern applies per decision_type. The ResourceValidation.required_validators field transitions from Vec<AgentPubKey> to Vec<AgentContext> post-MVP.

Pattern 3 — Bot / AI agent governance scope

Bot agents (AgentEntityType::Bot { capabilities, operator }) can participate in governance only within the scope declared in their capabilities vector. Examples:

• A bot may be authorised to sign ValidationReceipt entries for automated integrity checks (e.g., a digital resource hash validation bot) — but not for role promotions or rule amendments, which require human judgment.
• A bot may be authorised to issue EconomicEvent entries for automated processes (e.g., a scheduler bot recording that a storage commitment has been fulfilled on time) — but not for dispute resolution.

The operator: AgentPubKey in the Bot type is the governance-responsible party: all bot actions are attributed to the operator for accountability purposes, and any PPRs generated by bot interactions list the operator as the accountable counterparty. Bot governance_claims in the ReputationSummary do not contribute to the operator's affiliation_state — they are tracked separately under the bot's own AgentContext with a governance_weight = 0 gate (bots cannot accumulate governance standing independent of their human operator).

TODO (G1, G11 — post-MVP): Implement AgentContext type, extend GovernanceTransitionRequest, ValidationReceipt, and PPR counterparty fields to accept AgentContext. Define Bot delegation scope enforcement in the governance operator's validate_agent_permissions function. See implementation_plan.md §3 [G1+Resource] and agent.md §5.3 (DelegatedAgent).

7. Complexity Economics Justification: Why Each Governance Concept Matters

Governance layers matter because the OVN is fractal. A governance architecture that only works at one scale (venture) cannot coordinate the network-level and federation-level decisions that determine the ecosystem's evolution. Governance without scale awareness will centralise at whichever scale is most powerful, undermining the decentralisation that makes peer production competitive with capitalist alternatives.

Decision processes (advice process, lazy democracy, etc.) matter because different types of decisions have different optimal deliberation speeds. Time-sensitive operational decisions need fast, local authority (free initiative). Rule-changing decisions need wide deliberation and consent. Treating all decisions equally produces either paralysis (everything goes through full deliberation) or autocracy (important decisions get made without consultation). The composable governance process library is the infrastructure for decision-appropriate governance.

Non-binary decision making matters because voting aggregates preferences by throwing away information. A community where 60% support a proposal and 40% strongly oppose it is very different from one where 60% support and 40% mildly prefer an alternative. Binary voting cannot distinguish these — it just says "60% win." Conviction voting (continuous preference updating), quadratic voting (cost-weighted expression), and rank choice (preference ordering) all recover more information from the deliberation process. In complexity economics terms: higher-resolution preference aggregation produces better decisions because it uses more of the information that participants possess.

Registries matter for the same reason that formal membership distinctions matter in Ostrom's commons governance: without a clear definition of who is in the community, governance processes cannot be bounded, quorums cannot be calculated, and the accountability chain cannot be closed. The OVN's long tail distribution means that simple "everyone who has ever participated" definitions produce governance bodies so large and diffuse that decisions become impossible. Algorithmically managed registries — updated by governance, not by developer deployment — solve this.

The governance equation matters because access to governance should not be arbitrary (cooptation, seniority, formal appointment) in a P2P system. Benkler's observation about peer production's information advantage is applicable: distributed contribution data is richer than any centralised assessment of "who is a responsible governance participant." The PPR system generates this data as a byproduct of ordinary participation. Using it to weight governance access converts participation history into governance standing automatically — without administrative overhead.

The offchain bridge matters because full onchain governance is a fiction. Human communities have always and will always need spaces for informal conversation, emotional resolution, and contextual judgment that no smart contract can replicate. The OVN wiki is explicit: "Human issues: interpersonal problems, emotions, etc. cannot be automated." A governance architecture that ignores its own offchain complement will be gamed by agents who understand that the informal layer always overrides the formal. Acknowledging and linking the offchain layer makes the full governance stack legible, auditable, and improvable.

Temporal governance matters because all rules become outdated. A GovernanceRule written for a community of 10 becomes inappropriate for a community of 1000. A decision made under one set of conditions may be harmful under new conditions. Sunset clauses and evaluation triggers are the governance equivalent of software unit tests: they force the community to consciously re-evaluate whether rules still serve their purpose, rather than allowing dead rules to accumulate and complicate the governance landscape.

Cross-app identity (Flowsta) matters for governance for the same reason credential portability and network-layer reputation matter in the OVN model: agents who participate in multiple OVNs or hApps are bridge nodes between networks. Without a verifiable same-person link across conductors, each network treats them as a stranger and must re-derive trust from zero; sybil pressure and cold-start friction repeat at every boundary. Flowsta Tier 1 keeps overhead low for casual participants; Tier 2 applies Flowsta link validation only where complexity matching says the coordination cost is justified (ndo_prima_materia.md Section 6.7, REQ-NDO-CS-14).

This is a living document. The gap analysis in Section 5.3 should be converted into formal requirements as the generic NDO project begins. The forward map in Section 6 describes design directions, not final specifications. Major external capability integrations (Unyt, Flowsta) are traced in ndo_prima_materia.md Sections 6.6–6.7 and Sections 11.5–11.6. The OVN wiki at ovn.world remains the authoritative reference for peer production governance practice.

Nondominium Prima Materia

Status: Normative architecture document — Layer 0 implemented in MVP; Layers 1–2, capability slots, and full governance-as-operator lifecycle remain post-MVP targets
Created: 2026-03-10
Last updated: 2026-06-16
Authors: Nondominium project
Relates to: post-mvp/many-to-many-flows.md, post-mvp/ndo-versioning.md, post-mvp/digital-resource-integrity.md, post-mvp/unyt-integration.md, post-mvp/flowsta-integration.md, lobby-dna.md, post-mvp/project-type-ndo-specifications.md, post-mvp/source-ndo-requirements.md
Implementation reference: documentation/IMPLEMENTATION_STATUS.md (NDO Layer 0 ✅ PR #80; NDO DNA extensions ✅ PR #103; Layers 1 & 2 ❌)

Table of Contents

1. What is the Prima Materia?
2. Complexity Economics as Architectural Foundation
3. Complexity Oriented Programming
4. The Three-Layer Model: The Prima Materia
5. Resource State Model — Lifecycle & Operational State
6. The Surface of Attachment — Capability Slots
7. Design Patterns
8. DHT Data Structures
9. Requirements (including §9.0 Implementation Status)
10. Migration from Current Architecture
11. Relationship to Other Post-MVP Work

1. What is the Prima Materia?

In medieval alchemy, the prima materia is the primordial, undifferentiated substance that underlies all matter — the formless potential from which everything is made. Before a substance becomes gold, lead, or salt, it passes through the prima materia: an essential, minimal state that carries the capacity to become anything. The alchemists were not simply mystifying chemistry. They were describing a pattern: complex things begin as nearly nothing, and their nature reveals itself progressively through process.

This document borrows that metaphor deliberately. A Nondominium Object (NDO) is the prima materia of the Nondominium system: a minimal DHT structure that carries the potential to become any kind of resource — digital or physical, simple or composite, idea or fabricated artifact — and that grows in structure and function as the resource it represents grows in complexity and social embeddedness.

1.1 The Gap in the Legacy Model — and What Remains

The original flat resource model consisted of two primary entry types:

• ResourceSpecification — the type or template of a resource: name, description, category, governance rules
• EconomicResource — an instance of a resource: quantity, unit, custodian, location, state

That model is well-grounded in the ValueFlows standard and works well for resources that already exist in a stable, operational form. Its fundamental limitation was that it represented being, not becoming: there was no first-class object for a resource from ideation through archival memory — no placeholder for an idea not yet designed, a project in active development, a design under peer review before any physical instance exists, an artifact in hibernation (distinct from end-of-life), or a record that persists as institutional memory after activity has ceased.

Partially addressed — Layer 0 (MVP, implemented PR #80): NondominiumIdentity is the permanent Layer 0 anchor. It carries LifecycleStage (Ideation through EndOfLife, including Hibernating and Deprecated), PropertyRegime, and ResourceNature. An NDO can be created at Ideation with name and intent only; lifecycle transitions are integrity-validated and discoverable by stage, nature, and regime. The UI implements Lobby → Group → NDO creation and lifecycle transition against this entry type. See documentation/IMPLEMENTATION_STATUS.md §NDO Layer 0.

Still outstanding (this document remains the normative target for these gaps):

• Layer 2 not activated: process entries are not yet linked to Layer 0 via NDOToProcess. Layer 1 is activated (#132): create_resource_specification writes an NdoToSpecification link and the spec carries its Layer 0 pointers, so a spec can no longer be created without an NDO parent. Specification assets are still not attached via DigitalAsset capability slots (REQ-NDO-L1-06).
• Specification richness: Structured project-type know-how bundles (post-mvp/project-type-ndo-specifications.md) are post-MVP requirements only — the MVP ResourceSpecification entry remains a thin summary (name, description, category, tags).
• ResourceState conflation: On EconomicResource Resolved (data layer): EconomicResource.operational_state uses OperationalState; lifecycle maturity lives on NondominiumIdentity.lifecycle_stage. Governance-zome transition ownership (REQ-NDO-OS-02/03) remains deferred.
• Governance-as-operator for lifecycle: MVP allows only the NDO initiator to call update_lifecycle_stage. Governance-validated transitions, role authorization per Section 5.3, and automatic EconomicEvent generation on each transition (REQ-NDO-LC-02, REQ-NDO-LC-03) remain deferred.

The three-layer prima materia model closes the original gap progressively: Layer 0 addresses identity and lifecycle becoming; Layers 1 (form) and 2 (process) will complete the model when linked and enriched as specified in Sections 4 and 9.

1.2 The Intent of the Prima Materia

The prima materia defines a minimal DHT object that:

1. Exists as a placeholder from the moment of conception — before the lifecycle phases of design, specification, as well as before any physical instantiation
2. Grows in structure progressively — gaining specification, governance rules, assets, and process infrastructure as the resource matures
3. Carries a permanent, stable identity — a content-addressed anchor that persists through all transformations, including end-of-life
4. Provides a surface of attachment for capabilities that cannot be anticipated in advance — external hApps, governance tools, fabrication queues, issue trackers
5. Represents the full lifecycle — from the first spark of an idea to archival tombstone

1.3 The Key Example: Nondominium Itself

The Nondominium hApp is itself an NDO, of a digital type (a computer program). It began as an idea (Ideation), passed through design (Specification), prototype implementation (Development → Prototype), and is now moving toward its first stable release. Its assets are code on GitHub (the location). Its process is the collaborative work of contributors. Its governance rules will be embedded in the code. Its identity is stable across all versions.

When someone starts a hardware design project for a shared CNC machine, they create an NDO (the identity first). When they publish design files and documentation for distributed fabrication (3D models, bill of materials, manuals, etc.), Layer 1 (Specification) is activated. When contributors begin working, Layer 2 (Process) is activated. When the design is mature and being fabricated by many, all three layers are fully active. When the design becomes obsolete, Layers 1 and 2 are archived, but the NDO identity remains — a permanent record that the thing existed, who created it, and what happened to it.

MVP today: Group-scoped create_ndo creates Layer 0 only. Layer 1 and Layer 2 activation links are not yet in the codebase; lifecycle stage on Layer 0 can still advance independently (see §5.3). Know-how bundle requirements for project-type NDOs are specified in post-mvp/project-type-ndo-specifications.md.

2. Complexity Economics as Architectural Foundation

The three-layer design of the NDO is not an arbitrary architectural preference. It is a direct consequence of applying complexity economics to the problem of representing resources in a decentralized peer-to-peer system. Three theoretical pillars justify the design.

2.1 Bar-Yam: Complexity Matching

Yaneer Bar-Yam's central thesis in Complexity Rising is that a system's behavioral complexity must match the complexity of the challenges it faces. When the environment's complexity exceeds a system's adaptive capacity, the system fails. Hierarchical command-and-control structures have cognitive ceilings — there is only so much complexity a centralized decision-maker can handle. As the environment grows more complex, decentralized, networked systems with distributed decision-making become necessary.

Applied to DHT data design, this principle has a direct corollary: do not pre-classify a resource at creation time. At the moment a resource is conceived, its full lifecycle complexity is unknowable. A project started as a personal experiment may become a global standard. A community tool may be adopted and fabricated by thousands of people, communities and networks. A hardware design may spawn dozens of forks and regional variants. Committing to a fixed classification at t=0 is the data equivalent of hierarchical overreach — assuming a knowledge of the future that no agent possesses.

The OVN computational model (ovn.world) demonstrates this formally: Finite State Machines, the computational model underlying most fixed-classification systems, require a number of states that grows exponentially with social complexity — quickly reaching numbers exceeding the atoms in the observable universe for even modestly complex communities. FSMs are not inadequate; they are categorically incompatible with governing complex human systems. A resource data model built on fixed state at creation is an FSM in disguise.

The solution is the adjacent possible (Kauffman): at any moment, only the next step is visible. The NDO model respects this by making layer activation a response to rising environmental complexity, not a commitment made at genesis.

2.2 Benkler: Information Opportunity Costs

Yochai Benkler's analysis of commons-based peer production (Coase's Penguin, 2002; The Wealth of Networks, 2006) identifies the primary economic advantage of P2P coordination as lower information opportunity costs. Markets and managerial hierarchies are informationally lossy — they filter, aggregate, and approximate the rich information available in a distributed network. P2P systems process this information with lower loss because agents at the edges of the network can sense and act on local information directly, without routing it through central aggregators.

In the NDO context, this principle justifies the pay-as-you-grow structure of layer activation. Each layer carries a coordination overhead:

• Layer 0 (Identity) has near-zero coordination cost: one agent creates one entry.
• Layer 1 (Specification) has moderate cost: governance rules must be written, assets attached, peer review coordinated.
• Layer 2 (Process) has the highest cost: economic events must be recorded, commitments tracked, PPRs issued, multi-agent consent coordinated.

In a hierarchical system, all resources would bear the full overhead of the richest representation, regardless of their current needs. Benkler's insight says this is wasteful — it imposes coordination costs that exceed the information value returned. The NDO model matches coordination cost to actual coordination demand: a tool lent between neighbors needs no Process layer; a shared fabrication standard being actively developed by a distributed network needs all three.

2.3 Morin: The Seven Principles of Complexity

Edgar Morin's seven principles of complex thought, applied in the Sensorica complexity economics framework, provide a philosophical grounding for the NDO's structure. Each principle finds direct expression in the design:

2.4 Holonic Structure

The NDO is a holon in the sense used by the OVN model: an entity that is simultaneously a whole in itself and a part of a larger whole. Arthur Koestler coined the term holon to describe systems where every level of organization is both complete and a component. Holonic systems are characteristic of living organisms, ecosystems, and complex economies.

An NDO is:

• A whole: it has its own identity, specification, and process — it is a complete self-describing object
• A part: it is embedded in networks of other NDOs. for example, a project-type NDO contains Resource NDOs, which contain Design NDOs, which reference Component NDOs

This recursive self-similarity is what makes the NDO fractal. Each NDO carries the same structural potential; the difference between a sub-component and a top-level project is only one of social context and activation state, not of structural type.

See fractal composablity and fractal-composable-resource-architecture.md

3. Complexity Oriented Programming

The NDO's design embodies a programming paradigm that does not yet have a formal name but is emerging in practice. We call it Complexity Oriented Programming (COP).

3.1 The Reductive Paradigm and Its Limits

All dominant programming paradigms share a common epistemological assumption: complexity is a problem to be eliminated through abstraction.

• Object-Oriented Programming (OOP) encapsulates complexity behind interfaces, hiding internal state
• Functional Programming (FP) eliminates side effects, reducing programs to pure transformations
• Procedural programming linearizes execution, replacing concurrency with sequence

These strategies are powerful for building closed, bounded systems where the programmer can anticipate all relevant states in advance. But they break down when applied to open, complex, emergent systems — precisely the kind of systems that P2P infrastructure must support.

The failure mode is always the same: the abstraction boundary becomes a wall that the system's actual complexity cannot respect. Side effects leak through interfaces. State escapes encapsulation. The linear pipeline encounters a feedback loop it was not designed to handle. The FSM reaches a state it was not designed to represent.

3.2 Complexity Oriented Programming: The Inversion

COP inverts the reductive assumption. Instead of hiding complexity through abstraction, COP models complexity faithfully and works with it as the primary material. The vocabulary shifts:

The epistemological shift is from programmer as god (designs a closed, fully known system) to programmer as ecologist (designs conditions, observes what arises). The system is never fully knowable from the source code alone.

3.3 Where COP Already Exists

COP is not invented here — it is being discovered simultaneously in several places:

• Holochain's agent-centric model: there is no global state machine. Each agent runs local validation rules, and global coherence emerges from the aggregate of local actions. The DHT is not designed; it arises.
• ValueFlows/REA: the economic model is not a state machine but a flow of events. Resources do not "have states" in the FSM sense — they accumulate economic events that describe what has happened to them. The past is permanent; the present is an interpretation of the past.
• Actor model concurrency: concurrent entities with private state communicating through asynchronous messages — the distributed system coordinates without shared mutable state.
• Reactive/dataflow systems (FRP, signals): time and context are primary, not afterthoughts. Computation is driven by the flow of values through a graph, not by sequential instruction execution.
• Cellular automata: global patterns emerge from purely local rules. Complexity at the macro level is not programmed; it is grown.

3.4 The NDO as a COP Primitive

The NDO is the fundamental COP primitive in the Nondominium system. Its design embodies COP in every structural choice:

• Layer activation is not a state machine transition — it is a response to rising environmental complexity, designed to allow emergence rather than constrain it
• Capability slots are not predefined interfaces — they are typed relational events that flow through the DHT link graph, allowing unforeseen tools to attach without modifying the NDO entry
• Lifecycle transitions are not deterministic state machine edges — they are feedback arcs driven by economic events (agents' actions feeding back into the resource's representation of itself)
• The tombstone at end of life is not a deletion — it is the permanent memory that the system was alive, respecting the append-only nature of the DHT as a feature, not a constraint

The honest challenge of COP, noted in the complexity_oriented_programming archive: tooling. Debuggers, type systems, and unit tests all assume reducibility. COP requires new verification paradigms — closer to simulation and formal methods than conventional testing. The Nondominium testing strategy relies on Sweettest (Rust, multi-agent) for backend validation; legacy Tryorama tests in tests/ are deprecated.

4. The Three-Layer Model: The Prima Materia

The prima materia is realized in the NDO as a three-layer structure, where each layer corresponds to a different register of complexity and is activated independently in response to the resource's current context.

Layer 0 (NondominiumIdentity) is always present — implemented in MVP. Layer 1 (ResourceSpecification via NDOToSpecification) and Layer 2 (Process via NDOToProcess) are normative targets not yet wired in code; each layer adds overhead only when the environment demands it.

4.1 The Brain Architecture Analogy

The triune brain evolved in layers: brainstem (always active) → cerebellum (coordination) → cortex (higher cognition, optional). The NDO mirrors this: Layer 0 (permanent anchor) → Layer 1 (specification) → Layer 2 (process). Each layer adds complexity only when the environment demands it.

The human brain provides the most vivid structural analogy. It did not evolve as a single organ — it evolved in layers, each built on and coupled to the previous:

• The brainstem handles vital functions: breathing, heartbeat, arousal. It is always active. The organism cannot survive without it. It is the oldest evolutionary layer.
• The cerebellum handles coordination, posture, and procedural memory — the form of the body's activity. It evolved on top of the brainstem and is coupled to it, but can be understood as a distinct functional layer.
• The cortex handles higher cognition, agency, and deliberate action. It evolved on top of the cerebellum and is the most recently evolved layer. It is situational — not all cognitive tasks require cortical engagement.

This is also a manifestation of path dependency in evolution.

These layers do not replace each other. They are coupled and co-active. The cortex does not work without the brainstem. But the brainstem can sustain basic life without the cortex (as in the case of brain death with brainstem function preserved). And at death, the cortex goes first.

The NDO mirrors this exactly:

┌─────────────────────────────────────────────────────────────────┐
│ Layer 2 — PROCESS                                               │
│ (cortex: agency, higher cognition, multi-agent economic work)   │
│ Activated situationally. Deactivated at hibernation / EOL.      │
├─────────────────────────────────────────────────────────────────┤
│ Layer 1 — SPECIFICATION                                         │
│ (cerebellum: coordination, form, replication)                   │
│ Activated when form needs to be shared. Archived at EOL.        │
├─────────────────────────────────────────────────────────────────┤
│ Layer 0 — IDENTITY                                              │
│ (brainstem: vital functions, always on, the tombstone)          │
│ Always active. The last thing standing. Never voided.           │
└─────────────────────────────────────────────────────────────────┘

4.2 Layer 0: Identity — The Permanent Anchor

Layer 0 is the prima materia in its most essential form. It is the minimum viable NDO — the smallest structure that gives a resource a stable, cryptographically-anchored identity in the DHT.

Status: ✅ Implemented in MVP (zome_resource integrity + coordinator ndo_identity.rs; UI via Group-scoped NDO creation and lifecycle transition modals). Layers 1 and 2 remain post-MVP (see §1.1).

Structure (as implemented in dnas/nondominium/zomes/integrity/zome_resource/src/lib.rs):

#![allow(unused)]
fn main() {
pub struct NondominiumIdentity {
    pub name: String,
    pub initiator: AgentPubKey,
    pub property_regime: PropertyRegime,
    pub resource_nature: ResourceNature,
    pub lifecycle_stage: LifecycleStage,
    pub created_at: Timestamp,
    pub description: Option<String>,
    /// Set once when entering `Deprecated` (REQ-NDO-LC-06); also linked via `NdoToSuccessor`.
    pub successor_ndo_hash: Option<ActionHash>,
    /// Set on → `Hibernating` (records pre-pause stage); cleared on resume from hibernation.
    pub hibernation_origin: Option<LifecycleStage>,
}
}

Shared enums live in crates/shared/src/types.rs. PropertyRegime has seven variants (Private, Commons, Collective, Pool, CommonPool, Public, Nondominium); ResourceNature includes Physical, Digital, Service, Hybrid, and Information. The UI (packages/shared-types and creation/filter controls) exposes all seven PropertyRegime options.

Key properties:

• The original create_ndo action hash is the permanent, stable Layer 0 identity — a namespace that future layers and capability slots link to (REQ-NDO-L0-02).
• It is never deleted — integrity validation rejects all deletes (validate_delete_nondominium_identity); Holochain's append-only model plus explicit validation ensures the identity remains readable as a tombstone at EndOfLife (REQ-NDO-L0-03, REQ-NDO-L0-06).
• Immutable after creation: name, initiator, property_regime, resource_nature, created_at, and description cannot change on update. This is stricter than a free-text “living description”; editorial history belongs in Layer 1 or process records post-MVP.
• Mutable on lifecycle update only:
  • lifecycle_stage — integrity-validated state machine (§5.3); forward chain is monotonic (no skipping stages); Hibernating and terminal transitions (Deprecated, EndOfLife) have special rules.
  • successor_ndo_hash — set exactly once when entering Deprecated; must reference an existing DHT record (REQ-NDO-LC-06).
  • hibernation_origin — set when entering Hibernating, cleared when resuming to the recorded origin stage.
• Authorization (MVP): only the initiator may call update_lifecycle_stage. Full governance-as-operator role checks (REQ-NDO-LC-07) and automatic EconomicEvent generation per transition (REQ-NDO-LC-03) are deferred; NdoToTransitionEvent links exist for future wiring.
• Discovery: global and faceted anchors — AllNdos, AgentToNdo, NdoByLifecycleStage, NdoByNature, NdoByPropertyRegime (REQ-NDO-L0-07). The Lobby/Group UI browses and filters NDOs on these dimensions.

When Layer 0 exists alone (typical today — Layers 1 & 2 not yet linked):

• A stub registration at Ideation: “this thing exists; I intend to develop it” (UI default initial stage).
• An identity carrying full classification (property_regime, resource_nature, lifecycle_stage) before any linked ResourceSpecification or process entries.
• A tombstone at EndOfLife (or archived identity at Deprecated with successor): Layer 0 remains; upper layers are design targets, not yet activated in code.
• The minimal representation of an idea that has not yet been designed — sufficient for discovery and lifecycle progression without Layer 1 assets.

4.3 Layer 1: Specification — The Form

Status: 🔄 Post-MVP (not activated in code). Legacy ResourceSpecification entries exist in zome_resource but are not linked to Layer 0 via NDOToSpecification. Project-type know-how bundles are specified in post-mvp/project-type-ndo-specifications.md.

Layer 1 is activated when a resource has a form that needs to be communicated to others — when the resource is ready to be described, shared, peer-reviewed, or replicated.

Activation mechanism: Creation of an NDOToSpecification link from the Layer 0 identity hash to a ResourceSpecification entry.

Layer 1 carries:

• Design intent and description (what the resource is)
• Governance rules (who can access it and how)
• Assets: files, 3D models, code references, digital integrity manifests, documentation links
• Tags and categories for discovery

When to activate Layer 1:

• The resource has a design worth sharing with others
• Distributed fabrication is intended (the spec is the product)
• Peer review or validation of the design is needed
• The resource needs to be discoverable by category or tag

When Layer 1 becomes dormant:

• The resource enters hibernation or end of life
• The specification is archived (is_active: false)
• The NDOToSpecification link remains readable (DHT is append-only), but no new updates are made to the spec

The design file as the product: In the distributed fabrication context (cosmolocal production), the Layer 1 specification is the product in the most meaningful sense. When a hardware design reaches Stable lifecycle stage, anyone with a 3D printer and the fabrication spec can produce a local instance. The spec is not documentation for a product — it is the shareable, replicable artifact. This is the nondominium model's most radical departure from capitalist product logic.

4.4 Layer 2: Process — The Activity

Status: 🔄 Post-MVP (not activated in code). EconomicEvent, Commitment, and Claim exist in zome_gouvernance but are not linked to NDO identity via NDOToProcess. Federation extensions NdoHardLink, Contribution, and Agreement (#103) provide partial cross-NDO process semantics; see §11.7.

Layer 2 is activated when there is active multi-agent economic work around the resource — when contributions are being tracked, custody is being transferred, use events are being recorded, or commitments are being made.

Activation mechanism: Creation of an NDOToProcess link from the Layer 0 identity hash to a ValueFlows Process entry.

Layer 2 carries:

• EconomicEvent records of all actions taken on or with the resource
• Commitment records of agents' intentions to perform future actions
• Claim records linking commitments to fulfilling events
• PrivateParticipationClaim (PPR) records issued to participants
• Labor contribution tracking for OVN-compliant attribution

When to activate Layer 2:

• A second agent becomes involved (multi-agent coordination begins)
• Development work begins in earnest and contributions need to be tracked
• Custody transfers are required
• Use events or resource access need to be recorded
• PPRs need to be issued (any economically accountable interaction)

When Layer 2 becomes dormant:

• The process concludes: all commitments are fulfilled or cancelled, all events are finalized
• The resource enters hibernation (process paused, not terminated)
• End of life: process is formally concluded with terminal events

4.5 Layer Composition Across the Lifecycle

graph TD
    L0["Layer 0: Identity\n(always active)"]
    L1["Layer 1: Specification\n(activated when form exists)"]
    L2["Layer 2: Process\n(activated for active work)"]

    subgraph ideation ["Ideation"]
        L0_i[Layer 0 only]
    end

    subgraph design ["Specification / Design"]
        L0_d[Layer 0]
        L1_d[Layer 1 activated]
        L0_d --> L1_d
    end

    subgraph dev ["Development / Active"]
        L0_v[Layer 0]
        L1_v[Layer 1]
        L2_v[Layer 2 activated]
        L0_v --> L1_v --> L2_v
    end

    subgraph hib ["Hibernation"]
        L0_h[Layer 0]
        L1_h["Layer 1 (dormant)"]
        L2_h["Layer 2 (dormant)"]
        L0_h --> L1_h -.-> L2_h
    end

    subgraph eol ["End of Life"]
        L0_e["Layer 0 (tombstone)"]
        L1_e["Layer 1 (archived)"]
        L2_e["Layer 2 (concluded)"]
        L0_e --> L1_e -.-> L2_e
    end

    ideation --> design --> dev --> hib --> eol

5. Resource State Model: Two Orthogonal Dimensions

Implementation snapshot (MVP): LifecycleStage is implemented on NondominiumIdentity (10 stages, integrity-validated transitions, initiator-only authorization in the coordinator). OperationalState is implemented on EconomicResource (7 states, custodian-initiated updates via update_operational_state, faceted discovery via ResourcesByOperationalState). Governance-zome ownership of operational transitions (REQ-NDO-OS-02/03) remains deferred.

The legacy ResourceState enum conflated two independent dimensions. The NDO requires their explicit separation:

• LifecycleStage — the maturity or evolutionary phase of the resource as an artefact. Advances rarely and (mostly) irreversibly, driven by significant events (design completion, peer validation, fabrication, end-of-life declaration). Lives on the NondominiumIdentity (Layer 0).
• OperationalState — what process is currently acting on a specific resource instance. Cycles frequently as processes begin and end. Managed by the governance zome. Lives on the EconomicResource instance (Layer 2).

The key distinction: transport, storage, and maintenance are processes that can apply to a resource at any lifecycle stage. A Prototype can be InTransit (moved between R&D labs). An Active resource can be InStorage, InTransit, or InMaintenance simultaneously with its lifecycle stage. These are not lifecycle milestones — they are transient operational conditions.

5.1 LifecycleStage Enum

Lives on NondominiumIdentity. Describes what the resource has become, not what is happening to it right now.

#![allow(unused)]
fn main() {
pub enum LifecycleStage {
    // --- Emergence Phase ---
    Ideation,       // Placeholder: name and intent only. Layer 0 alone.
    Specification,  // Design/requirements being written. Layer 1 activating.
    Development,    // Active construction, prototyping. Layers 0+1+2 active.
    Prototype,      // PoC exists, not production-ready. Layers 0+1+2 active.

    // --- Maturity Phase ---
    Stable,         // Production-ready, design is replicable. All layers active.
    Distributed,    // Being actively fabricated/used across the network.

    // --- Operation Phase ---
    Active,         // In normal use. All layers active.

    // --- Suspension ---
    Hibernating,    // Not end-of-life — dormant. Layers 1+2 dormant, L0 active.

    // --- Terminal ---
    Deprecated,     // Superseded by a newer version. Links to successor.
    EndOfLife,      // Concluded. L0 tombstone, L1 archived, L2 concluded.
}
}

Note: Maintenance and Reserved are not lifecycle stages — they describe transient operational conditions and belong in OperationalState (Section 5.4).

5.2 Lifecycle → Layer Activation Table

Normative target: Layer activation via NDOToSpecification / NDOToProcess links is not yet enforced in code. Today, lifecycle stage advances on Layer 0 independently; the table below describes intended coupling once Layers 1 and 2 are wired.

At any stage from Development onward, the OperationalState (Section 5.4) may be any value independently of the lifecycle stage.

5.3 Lifecycle Transitions and Governing Events

Each transition between lifecycle stages shall be driven by a VfAction economic event, validated by the governance zome acting as state transition operator (REQ-ARCH-07). MVP today: transitions are validated in the integrity zome (validate_update_nondominium_identity); the initiator may call update_lifecycle_stage without a cross-zome governance evaluation. Optional transition_event_hash creates an NdoToTransitionEvent link when provided, but the referenced EconomicEvent is not yet validated cross-zome. Role-based authorization in the table below is target behaviour (REQ-NDO-LC-07), not current enforcement.

stateDiagram-v2
    [*] --> Ideation : "NondominiumIdentity created"

    %% Forward maturity chain (monotonic, no skipping)
    Ideation --> Specification : "Produce (spec created)"
    Specification --> Development : "Work (contributions begin)"
    Development --> Prototype : "Produce (PoC delivered)"
    Prototype --> Stable : "Accept (peer validated)"
    Stable --> Distributed : "Transfer (first fabrication)"
    Distributed --> Active : "Use (operational)"

    %% Suspend — any non-terminal stage may enter Hibernating
    Ideation --> Hibernating : "Lower"
    Specification --> Hibernating : "Lower"
    Development --> Hibernating : "Lower"
    Prototype --> Hibernating : "Lower"
    Stable --> Hibernating : "Lower"
    Distributed --> Hibernating : "Lower"
    Active --> Hibernating : "Lower (activity paused)"

    %% Resume — always returns to the stage that was paused (hibernation_origin)
    Hibernating --> Ideation : "Raise (to origin)"
    Hibernating --> Specification : "Raise (to origin)"
    Hibernating --> Development : "Raise (to origin)"
    Hibernating --> Prototype : "Raise (to origin)"
    Hibernating --> Stable : "Raise (to origin)"
    Hibernating --> Distributed : "Raise (to origin)"
    Hibernating --> Active : "Raise (to origin)"

    %% Terminal — any non-terminal stage may deprecate or end
    Hibernating --> Deprecated : "Cite (successor declared)"
    Active --> Deprecated : "Cite (superseded)"
    Deprecated --> EndOfLife : "Consume (formally concluded)"
    Active --> EndOfLife : "Consume (formally concluded)"

Hibernating is a memory-preserving pause. The hibernation_origin field records the stage that was active before entering Hibernating. On resume ("Raise"), the resource returns to exactly that stage — not necessarily Active. This means a resource paused at Specification resumes at Specification, preserving the integrity of the maturity chain.

The Mermaid above shows representative "Raise" arrows; in practice, the valid resume target is always hibernation_origin, enforced by the integrity zome.

Transition authorization by role (target — REQ-NDO-LC-07; MVP: initiator only):

5.4 OperationalState Enum

Status: ✅ Implemented (data layer). EconomicResource.operational_state uses OperationalState. ResourcesByOperationalState replaces legacy ResourcesByState. Lifecycle faceting remains on NdoByLifecycleStage (Layer 0). Governance-zome transition rules (REQ-NDO-OS-02/03) remain deferred.

Lives on EconomicResource (Layer 2). Describes what process is currently acting on a specific resource instance. Set and cleared by the governance zome when processes begin and end.

#![allow(unused)]
fn main() {
pub enum OperationalState {
    // Default — no active process.
    Available,

    // A Commitment exists for a future process; no active Event yet.
    // Cleared when the Event is created or the Commitment is cancelled.
    Reserved,

    // A transport process is active (a TransferCustody or Move Event is open).
    // Valid at any LifecycleStage (a Prototype may be InTransit between labs).
    InTransit,

    // A storage service commitment is active.
    // Valid at any LifecycleStage.
    InStorage,

    // A repair or maintenance process is active (a Modify Event is open).
    // Valid at any LifecycleStage; does NOT advance the lifecycle.
    InMaintenance,

    // Actively being used (a Use Event is open).
    InUse,

    // Awaiting peer validation before becoming Available.
    // Initial state for newly created EconomicResource instances.
    PendingValidation,
}
}

OperationalState transitions (governed by the governance zome, triggered by EconomicEvents):

OperationalState transitions do not advance LifecycleStage. A resource that completes a repair cycle returns to OperationalState::Available at the same LifecycleStage it had before.

6. The Surface of Attachment — Capability Slots

Implementation snapshot: CapabilitySlot links and the SlotType enum are not yet in zome_resource. Federation extensions NdoHardLink, Contribution, and Agreement (#103) in zome_gouvernance provide a partial cross-NDO attachment and process record — related in purpose but structurally distinct from the stigmergic CapabilitySlot pattern defined here. Unyt and Flowsta integrations (§6.6–6.7) remain post-MVP.

A central requirement of the NDO is that it must not need to anticipate all future capabilities at design time. Like Discord channels to which anyone can add integrations, or like the MOSS Weave Interaction Pattern where hApps can link to any Weave Asset, the NDO must provide a surface of attachment for capabilities that do not yet exist.

6.1 The COP Principle of the Attachment Surface

Any agent freely attaches capability slots (GovernanceDAO, UnytAgreement, FlowstaIdentity, custom operators) to the NDO's Layer 0 identity hash without modifying the NDO entry itself — pure stigmergy: coordination through environmental modification, not central authority.

In COP terms: you cannot design the attachment surface in advance. The DHT link space is the surface. Any agent, any hApp, any future tool that knows the Layer 0 identity hash can create a link from that hash to whatever it needs to attach. The NDO entry itself does not change.

This is stigmergy in the complexity economics sense: indirect coordination through the environment. Ants coordinate the construction of a nest not by communicating plans but by leaving pheromone trails (environmental modifications) that other ants respond to. The NDO's Layer 0 hash is the pheromone trail — any agent can respond to it by attaching capabilities.

6.2 Stigmergic Link Channels

The attachment mechanism uses typed DHT links with structured link tags:

NDO_identity_hash →[LinkType: CapabilitySlot, tag: { slot_type, author, attached_at }]→ capability_target_hash

Predefined slot type vocabulary (extensible):

6.3 MOSS / Weave Integration

The Weave Interaction Pattern defines an open standard for creating, searching, linking, and organizing "social space units" — precisely what an NDO is. MOSS integration works as follows:

1. The NDO is declared as a Weave Asset by creating a WeaveWAL capability slot pointing to the asset's WAL
2. Other MOSS tools (issue trackers, document editors, governance DAOs, fabrication queues) can attach to the NDO's Layer 0 hash via the Weave protocol without modifying the NDO entry
3. As the NDO gains lifecycle stages, MOSS tools can respond to those transitions — a fabrication queue tool might automatically activate when the NDO reaches Stable

6.4 Governance of the Attachment Surface

Status: ❌ Not implemented for CapabilitySlot trust filtering. The rules below describe target governance behaviour once capability slots land in zome_resource.

The stigmergic surface is permissionless at the DHT level — any agent can create a capability link. But the governance layer determines which links are trusted and surfaced to other agents, versus which are ignored or filtered:

• Links created by the initiator or custodians are trusted by default
• Links created by Accountable Agents are conditionally trusted
• Links created by unknown agents are filtered until governance validation
• The governance zome can validate capability attachments using the same validate_new_resource pattern already in place

This mirrors the approach taken in the wider complex systems literature: edge-based sensing and attachment is permissionless (lower information opportunity costs), while trust propagation and filtering happens through distributed consensus rather than centralized gatekeeping.

6.5 CapabilitySlot on Agent Identity (Post-MVP)

TODO (G15 — Agent CapabilitySlot): The stigmergic attachment pattern described in this section applies equally to agent identities. The Person entry hash is itself a stable, permanent identity anchor — analogous to the NondominiumIdentity Layer 0 hash — and should serve as a surface of attachment for external capabilities:

• DID documents (W3C Decentralised Identifiers)
• Verifiable Credential wallets
• Reputation oracles from other networks
• Professional credential registries
• Social graph exports

An agent's Person entry hash → CapabilitySlot → external capability target, using the same CapabilitySlotTag / SlotType pattern defined in Section 8.3. This enables credential portability and DID interoperability without modifying the core Person entry schema.

See documentation/archives/agent.md §3.2 and REQ-AGENT-11.

Flowsta Auth (Section 6.7) provides the first concrete implementation of this pattern: a FlowstaIdentity capability slot linking the Person hash to an IsSamePersonEntry — a dual-signed cryptographic attestation that the agent's NDO key and their Flowsta Vault key belong to the same person. This gives every agent a W3C DID (did:flowsta:uhCAk...) without modifying the Person entry schema.

6.6 Economic Agreement Slots — Unyt Integration

A detailed analysis of the UnytAgreement slot type, its relationship to the governance layer, and the three-phase integration path.

Why Unyt Is a Capability, Not a Layer

Simple resources (Ideation/Specification) need zero economic overhead. Moderate resources (Active, distributed) benefit from GovernanceRules and custody tracking. Complex, high-value rivalrous resources justify Unyt Smart Agreements and RAVE proofs. Pay-as-you-grow.

The prima materia model has three structural layers. It might seem natural to propose a fourth — an "Economic Layer" — for payment and value-flow infrastructure. This would be the wrong architecture.

The COP principle of pay-as-you-grow is explicit: impose only the coordination overhead that the resource's current social complexity demands. Not all resources need payment infrastructure. A bicycle lent between neighbours does not need a Unyt Smart Agreement. A shared CNC machine used by fifty contributors under a usage-fee model does. Imposing economic infrastructure at NDO creation — making it structural — would repeat the reductive paradigm mistake that the three-layer model was designed to avoid. It would be a fixed classification at t=0 of a future that no agent can know.

Unyt belongs in the capability surface for the same reason that governance DAOs, fabrication queues, and issue trackers do: it is an economic operator that some resources need and others do not, and its attachment should emerge from the network's actual practice rather than be prescribed by the programmer.

The UnytAgreement slot type has one property that other slot types do not: it is governance-enforceable. A Documentation link is informational — the governance zome does not condition state transitions on it. A UnytAgreement link, when endorsed through a GovernanceRule of type EconomicAgreement, becomes a precondition for transition approval. This makes it a hybrid: permissionless at the attachment surface, authoritative at the governance layer.

Two-Tier Economic Authority

The UnytAgreement capability slot operates at two tiers.

Tier 1 — Permissionless Proposal (CapabilitySlot)

Any Accountable Agent can attach a Unyt Smart Agreement to any NDO by creating a CapabilitySlot link of type UnytAgreement. This is an assertion: "I believe this agreement should govern interactions with this resource." The governance zome does not enforce it. Other agents can read it as a proposal, a community suggestion, or a pricing signal. Multiple competing proposals may coexist.

This tier respects the stigmergic principle: lower information opportunity costs, permissionless economic expression, no gatekeeping on proposals.

Tier 2 — Governance Endorsement (GovernanceRule)

When the NDO's custodian — or a community governance process — formally endorses a Unyt Smart Agreement by creating a GovernanceRule entry of type EconomicAgreement, the agreement becomes enforceable. State transitions that trigger it (Access, CustodyTransfer, service processes) require the requesting agent to provide a valid Unyt RAVE as proof of economic settlement before the governance zome approves the transition.

The capability slot (Tier 1) and the governance rule (Tier 2) are independent but complementary: the slot makes the agreement discoverable; the rule makes it mandatory.

graph TD
    Agent["Any Accountable Agent"]
    Custodian["Custodian / Governance Process"]
    NDO["NDO Identity Hash (Layer 0)"]
    Unyt["Unyt Smart Agreement\n(on Unyt DHT)"]
    GovRule["GovernanceRule\n(EconomicAgreement type)\n— Layer 1 asset —"]
    Transition["State Transition Request\n(AccessForUse, CustodyTransfer, etc.)"]
    GovZome["Governance Zome\n(state transition operator)"]
    RAVE["Unyt RAVE\n(proof of settlement)"]
    PPR["PrivateParticipationClaim (PPR)\n+ settlement_rave_hash"]

    Agent -->|"CapabilitySlot link\n(Tier 1: permissionless proposal)"| NDO
    NDO -.->|"links to"| Unyt
    Custodian -->|"GovernanceRule\n(Tier 2: endorsed terms)"| GovRule
    GovRule -->|"linked from ResourceSpecification\n(Layer 1)"| NDO

    Transition -->|"includes rave_hash"| GovZome
    GovZome -->|"validates EconomicAgreement rule"| GovRule
    GovZome -->|"validates RAVE against Unyt DHT"| RAVE
    GovZome -->|"on approval, issues"| PPR
    PPR -->|"settlement_rave_hash"| RAVE

Unyt Smart Agreement as Economic GovernanceRule

The current GovernanceRule entry in zome_resource carries rule_type, rule_data (JSON-encoded), and an optional enforced_by role requirement. The Unyt integration adds a new rule_type variant and a corresponding structured rule_data schema:

#![allow(unused)]
fn main() {
// New variant in GovernanceRuleType enum (zome_resource integrity)
pub enum GovernanceRuleType {
    // ... existing rule types ...
    EconomicAgreement, // rule_data: JSON-serialized EconomicAgreementRuleData
}

// rule_data schema for EconomicAgreement rules
#[derive(Serialize, Deserialize)]
pub struct EconomicAgreementRuleData {
    pub unyt_alliance_id: String,          // Network seed of the Unyt Alliance
    pub smart_agreement_hash: String,       // Entry hash of the Unyt Smart Agreement
    pub trigger_actions: Vec<VfAction>,     // Which VfActions trigger this agreement
    pub settlement_window_secs: u64,        // Max time between RAVE execution and transition request
    pub note: Option<String>,               // Human-readable description of the economic terms
}
}

When the governance zome encounters an EconomicAgreement rule during a state transition evaluation, it executes the following validation sequence:

1. Confirms that the transition's VfAction is in the rule's trigger_actions list
2. Requires a rave_hash field in the transition request payload
3. Queries the Unyt DHT (via cross-DNA call()) to retrieve and validate the RAVE
4. Confirms the RAVE was executed within the declared settlement_window_secs
5. Confirms the RAVE's inputs match the transition context (resource identity, provider, receiver, quantity or duration)
6. Only then approves the state transition and issues the PPR

This makes the governance zome's approval conditional on cryptographic proof of economic settlement — the resource does not move (physically, digitally, or in custody) until the agreed value has flowed.

Value Flow Patterns

Four standard patterns map the most common resource-interaction economics onto Unyt's Smart Agreement library:

These map directly to the Smart Agreement templates in the Unyt Smart Agreement Library. The Conditional Forward template is the workhorse for access and custody patterns; Aggregate Payment and Proof of Service serve billing and revenue distribution.

The templates use RHAI scripting — the same logic that currently drives Unyt's DePIN billing (Log → Invoice → Agreement → Settlement). For Nondominium, the "log" is the Nondominium Commitment + Claim + ValidationReceipt chain; the invoice is implicit in the EconomicAgreementRuleData; the settlement is the RAVE.

PPR and RAVE: A Complete Provenance Chain

When a state transition is approved with a valid RAVE, the PrivateParticipationClaim generated for the interaction carries the RAVE hash as an optional field:

#![allow(unused)]
fn main() {
pub struct PrivateParticipationClaim {
    // ... existing fields ...
    pub settlement_rave_hash: Option<String>, // Unyt RAVE hash, if economic settlement occurred
}
}

This creates a complete, cross-verifiable provenance chain:

Commitment
  └─ (fulfilled by) EconomicEvent
       └─ (generates) PrivateParticipationClaim (PPR)
            └─ settlement_rave_hash → Unyt RAVE
                 └─ (verifiable on Unyt DHT: inputs, outputs, agreement, executor)

The PPR is the participation proof: who did what, at what quality, in which role. The RAVE is the economic proof: what value flowed, to whom, under what rules, verified by Unyt peers. Together, they constitute a full, mutually-reinforcing record of a resource interaction that neither system alone can provide.

This linkage also feeds back into the credit system: agents whose PPRs consistently carry RAVEs (meaning they reliably execute their economic obligations) earn higher reputation scores, which in turn increases their Unyt credit limits (see post-mvp/unyt-integration.md). Reputation and credit become two readings of the same underlying participation data.

The Resource as Economic Actor

When an NDO has an endorsed EconomicAgreement governance rule, it becomes a self-pricing, self-settling economic actor. No platform intermediary determines what the resource costs, no rent is extracted by infrastructure owners, and no contract enforcement requires a legal system. The community that embedded the rule in the resource's Layer 1 specification determines the economic terms, and Unyt enforces them cryptographically among peers.

This is the nondominium model's deepest departure from platform economics. Platform platforms capture value by positioning themselves between resource and user — Airbnb between host and guest, Uber between driver and passenger. In the NDO model, the "platform" is the DHT itself: owned by no one, accessible to everyone, governed by the rules the community wrote into the resource. The resource is simultaneously a physical or digital artifact, a governance system, and an economic agent.

In complexity economics terms: the resource has become a holon with economic agency. Not only does it exist within the economic web (participating in ValueFlows events), it actively shapes the economic flows that run through it — enforcing its own terms, rewarding its stewards, and settling its debts, all without human intermediation.

Integration Path

The Unyt integration is structured as three independent phases, each delivering immediate value and requiring no rollback of prior work.

Phase 1 — Capability Surface Extension (no zome structural changes required)

Add UnytAgreement(String) to the SlotType enum. Any Accountable Agent can now attach a proposed Unyt Smart Agreement to any NDO. The governance zome does not enforce these links — they are informational, discoverable proposals. This phase delivers: economic expression in the network (market pricing signals without enforcement), tooling foundations (UIs can surface proposed payment terms), and community standard-setting (the network can develop shared pricing conventions before enforcement is added).

Phase 2 — Governance Rule Extension (zome_resource changes only)

Add EconomicAgreement to the GovernanceRuleType enum and define the EconomicAgreementRuleData schema. Custodians can now formally endorse a Unyt Smart Agreement by creating a GovernanceRule entry. The governance zome reads these rules but does not yet enforce them at transition time — Phase 2 makes the endorsement discoverable and legible to the network without yet conditioning transitions on RAVEs. This phase delivers: governance-layer economic declarations, tooling for custodians to set and communicate official payment terms, and the data structure foundation for Phase 3.

Phase 3 — Governance Zome Integration (zome_gouvernance changes)

The governance zome's evaluate_transition_request function is extended to: (a) check for EconomicAgreement governance rules when processing relevant VfAction events; (b) require a rave_hash in transition requests when such a rule exists; (c) validate the RAVE via cross-DNA call to the Unyt cell; (d) link the RAVE hash into the generated PPR via settlement_rave_hash. This phase delivers: full enforcement, automatic settlement, and the complete PPR↔RAVE provenance chain. The NDO becomes a fully self-pricing economic actor.

6.7 Identity and Authentication Slots — Flowsta Integration

A detailed analysis of the FlowstaIdentity slot type, its relationship to the agent identity surface (Section 6.5), and the three-phase integration path.

Tier 1: any agent voluntarily attaches a FlowstaIdentity slot (permissionless trust signal). Tier 2: governance rules can require a valid Flowsta link for high-trust transitions (e.g. PrimaryAccountableAgent promotion). The dual-signed IsSamePersonEntry on the NDO DHT yields a W3C DID without modifying the Person entry schema.

Why Flowsta Is a Capability, Not a Layer

The prima materia model has three structural layers. It might seem natural to propose cross-app identity as a mandatory component of Layer 0 — to require every agent to complete Flowsta Vault linking before they can participate. This would be the wrong architecture.

The COP principle of pay-as-you-grow is explicit: impose only the coordination overhead that the resource's current social complexity demands. Not all communities need cross-app identity. A neighbourhood tool-sharing network may operate perfectly well with Holochain-native AgentPubKey identifiers and locally-earned PPR reputation. A multi-network fabrication coalition spanning multiple Holochain apps — where contributors participate in design, fabrication, logistics, and economic settlement across separate DHTs — needs verifiable cross-app identity to prevent sybil fragmentation and enable reputation portability.

Imposing Flowsta at agent registration — making it structural — would repeat the reductive paradigm mistake that the three-layer model was designed to avoid. It would be a fixed classification at t=0 of a future that no agent can know: whether this particular agent will ever need cross-app identity, whether this particular community will ever span multiple networks.

Flowsta belongs in the capability surface for the same reason that Unyt does: it is an identity operator that some communities need and others do not, and its attachment should emerge from the network's actual practice rather than be prescribed by the programmer.

IsSamePersonEntry: The Cross-App Attestation

Flowsta's agent linking mechanism creates a cryptographic attestation — IsSamePersonEntry — on the NDO's DHT that proves two Holochain agent keys belong to the same person. The attestation is committed via the flowsta-agent-linking zomes (flowsta-agent-linking-integrity and flowsta-agent-linking-coordinator), which are added to the NDO's DNA manifest.

The 78-byte signing payload:

• Bytes 0–38: First agent public key (39 bytes: 3-byte prefix + 32-byte Ed25519 key + 4-byte checksum)
• Bytes 39–77: Second agent public key (same format)
• Both keys are sorted lexicographically for canonical ordering
• Both agents sign this payload: the NDO agent key signs via the local conductor, and the Flowsta Vault agent key signs via the Vault's lair keystore

Verification properties:

• Purely cryptographic: Ed25519 signature verification on the dual-signed payload — no shared DNA, no API dependency, no central authority needed for verification
• Any agent on the NDO DHT can verify the attestation by checking both signatures against the embedded public keys
• Purpose-specific: Flowsta Vault computes the signing payload itself and displays it to the user for approval — apps cannot trick the Vault into signing arbitrary data
• Revocable: either party can revoke the link via the revoke_link zome function
• Each Flowsta user carries a W3C DID: did:flowsta:uhCAk... (or did:key:z6Mk...), providing a standards-compliant cross-app identifier

Two-Tier Identity Authority

The FlowstaIdentity capability slot operates at two tiers, paralleling the Unyt two-tier model (Section 6.6).

Tier 1 — Permissionless Attestation (CapabilitySlot)

Any agent can link a Flowsta identity to their Person entry by creating a CapabilitySlot link of type FlowstaIdentity, pointing to the IsSamePersonEntry action hash. This is an assertion: "I have completed Vault agent linking (dual-signed attestation)." The governance zome does not enforce it at Tier 1. Other agents can read it as a trust signal — a voluntarily disclosed cross-app identity. Multiple agents may have Flowsta links; some may not.