Nondominium Documentation

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

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 - Person, Resource, Governance zome breakdown
• 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
• Private Participation Receipt - PPR system design
• 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 - Quick command reference

Applications

• Artcoin - Open-source art economy use case
• Distributed Journalism
• ERP Holochain Bridge
• HealthNet

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 - 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).

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 come 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

2.3 Post-MVP capability integrations (NDO, Unyt, Flowsta)

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 (communities may adopt one, both, or neither):

Knowledge-base context (ontology, OVN alignment, gap analysis): resources.md, agent.md, governance.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.

3. nondominium Resource Characteristics

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

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
• 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/archives/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.

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 (MVP Shell)

• REQ-UI-GRP-01: Group as localStorage shell: In the MVP, Groups are persisted as GroupDescriptor entries in localStorage (no Group DNA). The LobbyService implementation must be replaceable with a Group DNA backend without requiring component changes.
• REQ-UI-GRP-02: Invite Links: Groups must support invite links (base64-encoded GroupDescriptor) that allow another agent to join by pasting a link.
• REQ-UI-GRP-03: Group-scoped NdoBrowser: The Group view must display only NDOs created within that Group, using the same filter chip UI as the Lobby NdoBrowser.

NDO Management

• REQ-UI-NDO-01: NDO Creation Form: The NDO creation form must include: name (text), property_regime (select, 6 options with tooltips), resource_nature (select, 5 options with tooltips), lifecycle_stage (select, 10 options), 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.

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

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
• 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.
• 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)

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/archives/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.

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

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:

• zome_person: Agent identity, roles, reputation, and private data management
• zome_resource: Resource specifications, economic resources, and process management (pure data model)
• zome_governance: Validation, commitments, claims, and PPR issuance

9.2 ValueFlows Compliance

• REQ-ARCH-01: REA Model: Implement Resources, Events, Agents pattern with Economic Processes
• REQ-ARCH-02: Standard Actions: Support all relevant ValueFlows actions with nondominium-specific extensions
• REQ-ARCH-03: Multi-Layer Ontology: Support Knowledge, Plan, and Observation levels

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.

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.

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

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

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
• 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

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

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

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 (UI-only, localStorage)

GroupMemberProfile is a per-group presentation choice derived from LobbyUserProfile. It is also never written to the DHT (Groups are localStorage-persisted shells for the MVP; Group DNA is a post-MVP deliverable).

• Stored alongside the GroupDescriptor in localStorage under ndo_groups_v1.
• Prompted via GroupProfileModal.svelte on first entry to each group.
• No consensus or DHT record required; this is a purely local choice.

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 or accepting a commitment. This layer corresponds to the "person-type identity" described in §1.3.

• Written to the 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 (GroupDescriptor.memberProfile), UserProfileForm.svelte, GroupProfileModal.svelte, and GroupSidebar.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

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 NDO may use a subset of LifecycleStage values — a working group does not go through Prototype or Distributed. 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 is a Collective/Physical NDO.

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

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

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
Relates to: ndo_prima_materia.md, versioning.md, digital-resource-integrity.md, unyt-integration.md, flowsta-integration.md
Sources: MVP code (zome_resource), post-MVP design documents, OVN wiki — Resource, OVN wiki — Resource type

Purpose

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

1. Implemented — what exists today in the MVP zome_resource codebase
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 P2P 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 create value with 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.

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. The LifecycleStage enum ensures that governance overhead is matched to the resource's current social complexity. But this document will argue that even the NDO plan needs further refinement to model the full spectrum of resource types that exist 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.

2. Current Implementation (MVP)

2.1 Entry Types in zome_resource Integrity

The MVP implements three entry types:

ResourceSpecification

#![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,
}
}

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 state: ResourceState,
}
}

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

GovernanceRule

#![allow(unused)]
fn main() {
pub struct GovernanceRule {
    pub rule_type: String,   // free-form string (e.g., "access_requirement")
    pub rule_data: String,   // JSON-encoded, completely untyped
    pub enforced_by: Option<String>,
}
}

Economic rules governing access and use. Currently entirely untyped — rule_data is a free-form JSON string with no schema enforcement.

ResourceState (enum) — conflated, pending split

PendingValidation | Active | Maintenance | Retired | Reserved

The code contains a TODO comment noting this enum conflates two orthogonal dimensions:

• LifecycleStage (maturity/evolutionary phase — advances rarely, almost irreversibly)
• OperationalState (current process acting on the instance — cycles frequently)

Maintenance and Reserved are operational conditions imposed by active processes; they are not lifecycle milestones. A resource being repaired is still LifecycleStage::Active — it just has OperationalState::InMaintenance. Similarly, InTransit and InStorage are operational states valid at any lifecycle stage.

2.2 Link Graph

The link types model resource discovery and navigation:

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

2.3 What the MVP Does Well

• 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

2.4 Known Gaps in the MVP

3. Post-MVP Roadmap

The following improvements are designed in the post-MVP documentation. Each is described briefly here; 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: 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. Never voided — serves as the tombstone at end of life.
• Layer 1 — ResourceSpecification (activated by NDOToSpecification link): The form of the resource — design, governance rules, assets, digital integrity manifests. Activated when the resource has a form worth sharing.
• Layer 2 — Process (activated by NDOToProcess link): The activity around the resource — EconomicEvents, Commitments, Claims, PPRs. Activated when multi-agent coordination begins.

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

#![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
    Nondominium,    // Uncapturable by design; contribution-based access; no alienation permitted
}

pub enum ResourceNature {
    Digital,   // Software, data, design files, documents
    Physical,  // Material objects, equipment, spaces
    Hybrid,    // Digital twin of a physical resource
}
}

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

3.3 LifecycleStage and OperationalState

The current 5-state ResourceState enum is replaced by two orthogonal enums:

LifecycleStage (10 stages on NondominiumIdentity) — the maturity/evolutionary phase of the resource, advancing rarely and mostly irreversibly:

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

OperationalState (7 states on EconomicResource) — the current process acting on a specific instance, cycling frequently as processes begin and end:

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

Maintenance and Reserved move from LifecycleStage to OperationalState. Transport, storage, and maintenance are processes that can apply to a resource at any lifecycle stage (a Prototype can be InTransit between labs; an Active resource can be InMaintenance).

Each transition is governance-validated (the governance zome is the state transition operator), generates an economic event, and creates a lifecycle history audit trail.

3.4 Versioning (versioning.md)

A DAG-based version graph applicable to material resources (physical instances and designs), digital resources (code, documents, CAD), and the Nondominium hApp itself. Typed relations: EvolvedFrom, ForkedFrom, MergedFrom, RepairedFrom, AugmentedFrom, PortedToPlatform. OVN-compliant contribution propagation upstream through the version graph.

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)

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.

3.8 Flowsta Integration (flowsta-integration.md)

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

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 three most 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 ≠ 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)
• 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.

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

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 current NDO plan (Commons, Individual, Collective, Mixed) is too narrow. The full OVN taxonomy is preserved in §4.4.3 as an analytical reference. The NDO forward map (§6.3) selects the six 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
    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. 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 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)

#![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

#![allow(unused)]
fn main() {
pub enum ResourceNature {
    Physical,   // Material objects: tools, equipment, consumables
    Digital,    // Software, data, design files, documents
    Hybrid,     // Digital twin of a physical resource
    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

#![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
    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

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.

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. 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 venture-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, bilateral records of every economic interaction.

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: both the recipient and the counterparty sign the PPR. This is not just authentication — it is mutual accountability. Neither party can unilaterally issue a PPR; both must sign. This prevents false claims and creates bilateral commitment to the record.

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
• 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).

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: Post-MVP Design Document
Created: 2026-03-10
Authors: Nondominium project
Relates to: many-to-many-flows.md, versioning.md, digital-resource-integrity.md, unyt-integration.md, flowsta-integration.md, lobby-dna.md

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. Lifecycle State Machine
6. The Surface of Attachment — Capability Slots
7. Design Patterns
8. DHT Data Structures
9. Requirements
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 Current Model

The current Nondominium data model contains two primary entry types for resources:

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

This model is well-grounded in the ValueFlows standard and works well for resources that already exist in a stable, operational form. But it has a fundamental limitation: it represents being, not becoming.

There is no structure in the current model for a resource that is:

• an idea that has not yet been designed
• a project in active development
• a design under peer review before any physical instance exists
• an artifact entering hibernation, not end-of-life
• a project record that persists as institutional memory after activity has ceased

The current ResourceState enum (PendingValidation, Active, Maintenance, Retired, Reserved) conflates two orthogonal dimensions: the maturity/evolutionary phase of the resource (LifecycleStage) and the transient operational condition imposed by active processes (OperationalState). It also does not describe the emergence of a resource from nothing, nor its graceful retirement into archival memory.

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 design, before specification, 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. 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. Its process is the collaborative work of contributors. Its governance rules are 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. When they publish the 3D files for distributed fabrication, 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.

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 by thousands of fabrication 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 — a Project 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.

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. This is reflected in the Nondominium testing strategy, which relies on multi-agent Tryorama scenarios rather than isolated unit tests.

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.

4.1 The Brain Architecture Analogy

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.

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.

Structure:

#![allow(unused)]
fn main() {
struct NondominiumIdentity {
    name: String,
    initiator: AgentPubKey,
    property_regime: PropertyRegime,
    resource_nature: ResourceNature,
    lifecycle_stage: LifecycleStage,
    created_at: Timestamp,
    // Optional: a brief human-readable description
    description: Option<String>,
}
}

Key properties:

• The action hash of this genesis entry becomes the permanent, stable identity of the NDO — a DID-like namespace that all other layers and capabilities link to
• It is never voided — Holochain's append-only DHT makes deletion impossible, and this is correct: the identity of a resource that ever existed should be permanently accessible
• The only field that evolves is lifecycle_stage, updated through governance-validated transitions
• At end of life, Layer 0 alone remains as the tombstone: a permanent record that the resource existed, who created it, its nature, and when it concluded

When Layer 0 exists alone:

• A stub registration: "this thing exists, I intend to develop it"
• A tombstone: all other layers have been archived, the identity remains
• The minimal representation of an idea that has not yet been designed

4.3 Layer 1: Specification — The Form

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

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

The current ResourceState enum (PendingValidation, Active, Maintenance, Retired, Reserved) conflates two independent dimensions of a resource's state. 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

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 is driven by a VfAction economic event, validated by the governance zome acting as state transition operator. This is consistent with the existing governance-as-operator architecture (REQ-ARCH-07).

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:

5.4 OperationalState Enum

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

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

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

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

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 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.

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.

This tier respects the stigmergic principle: lower information opportunity costs, permissionless identity expression, no gatekeeping on attestation.

Tier 2 — Governance Requirement (GovernanceRule / Role Promotion)

When a community's governance rules require verified cross-app identity — for example, as a precondition for PrimaryAccountableAgent role promotion, or for custody transfer of high-value resources — the governance zome can condition role transitions on the presence of a verified FlowstaIdentity capability slot on the agent's Person hash. The verification checks:

1. A FlowstaIdentity CapabilitySlot link exists from the agent's Person hash
2. The target IsSamePersonEntry contains the agent's AgentPubKey as one of the two signing parties
3. The attestation has not been revoked

The capability slot (Tier 1) makes the identity discoverable; the governance rule (Tier 2) makes it mandatory for specific actions.

graph TD
    Agent["Agent on NDO DHT"]
    Vault["Flowsta Vault\n(local Holochain conductor + lair)"]
    PersonHash["Person Entry Hash\n(agent identity anchor)"]
    FlowstaSlot["FlowstaIdentity\nCapabilitySlot link"]
    ISP["IsSamePersonEntry\n(dual-signed 78-byte attestation)\non NDO DHT"]
    DID["W3C DID\ndid:flowsta:uhCAk..."]
    OtherApp["Other Flowsta-Linked\nHolochain App"]
    PPR["PrivateParticipationClaim"]
    RepSummary["ReputationSummary\n(cross-app attributable)"]
    GovRule["GovernanceRule\n(IdentityVerification type)"]
    RolePromotion["Role Promotion\n(PrimaryAccountableAgent)"]

    Agent -->|"has"| PersonHash
    Agent -->|"runs"| Vault
    PersonHash -->|"CapabilitySlot link\n(Tier 1: permissionless)"| FlowstaSlot
    FlowstaSlot -->|"points to"| ISP
    ISP -->|"dual-signed by"| Vault
    ISP -->|"carries"| DID
    DID -.->|"verifiable by"| OtherApp
    PPR -->|"attributed to"| DID
    PPR -->|"aggregated into"| RepSummary
    RepSummary -.->|"portable via DID"| OtherApp
    GovRule -->|"Tier 2: requires\nFlowstaIdentity slot"| RolePromotion
    RolePromotion -->|"checks"| FlowstaSlot

PPR Cross-App Attribution

When an agent has linked a Tier 1 FlowstaIdentity slot to a valid, non-revoked IsSamePersonEntry, their PPR ReputationSummary becomes attributable to a cross-app DID. (This is cryptographic attestation via Vault dual-signing — not the same as Tier 2 governance enforcement in Phase 3.) This creates the foundation for portable reputation without requiring full Verifiable Credential infrastructure:

• Other Flowsta-integrated apps can query whether an agent has a linked NDO identity by checking their own DHT for an IsSamePersonEntry containing the same Flowsta Vault key
• The DID serves as the stable key for reputation aggregation across apps — a single DID may accumulate PPR histories from multiple independent Holochain networks
• Agents control disclosure: the FlowstaIdentity slot is voluntary (Tier 1), and PPR summaries are already selectively shared via existing capability grants
• This is the practical path toward REQ-NDO-AGENT-08 (Portable Credentials): the DID provides the identity anchor; the PPR provides the participation record; selective disclosure provides the privacy control

The cross-app attribution chain is:

Person entry (NDO DHT)
  └─ FlowstaIdentity CapabilitySlot → IsSamePersonEntry
       └─ carries DID: did:flowsta:uhCAk...
            └─ same DID resolvable on other Flowsta-linked apps
                 └─ PPR ReputationSummary attributable to DID across apps

Recovery and Backup via Vault

Flowsta Vault provides recovery infrastructure that the NDO currently lacks:

• BIP39 recovery phrases: Deterministic Ed25519 keypair regeneration from a 24-word mnemonic. If an agent loses their device, they can regenerate the same key pair on a new device using their recovery phrase.
• Auto-backups: Encrypted snapshots every 60 minutes (up to 10 timestamped snapshots per app), working while the Vault is locked (after first unlock in a session). Oldest snapshots are auto-rotated.
• Full data export: Decrypted private entries and cryptographic keys can be exported, compliant with the Cryptographic Autonomy License (CAL).

This aligns with the NDO's design principle that identity must persist through all transformations. The non-deletable, append-only nature of Person entries and PPRs assumes the agent retains access to their signing key — a guarantee the current NDO architecture cannot make. Vault's deterministic key regeneration ensures that the permanent records the NDO creates remain accessible to their authors across device loss and hardware failure.

CAL alignment: The Cryptographic Autonomy License requires that users can always get a copy of their own data plus the cryptographic keys needed for independence from any particular service provider. Vault's full data export — including decrypted private entries and cryptographic keys — satisfies this requirement directly, and positions NDO communities for CAL-compliant distribution.

Flowsta and Unyt: Complementary Capabilities

Flowsta and Unyt are the two external capability integrations defined for the NDO. They are complementary and independent:

• Flowsta answers who is who — cross-app identity, DID, recovery, authentication
• Unyt answers who owes what to whom — credits, debits, settlement, economic closure

An NDO community may adopt one, both, or neither. When both are active, they reinforce each other: an agent's Flowsta DID provides the stable identity across Unyt Alliances, and their Unyt credit limit (derived from PPR reputation) is attributable to that DID (via Tier 1 link / IsSamePersonEntry, and optionally Tier 2–gated processes). The agent is simultaneously identifiable, accountable, and economically active — without any platform intermediary.

Integration Path

The Flowsta integration is structured as three independent phases, each delivering immediate value and requiring no rollback of prior work.

Phase 1 — Capability Surface Extension (no core zome structural changes required)

Add FlowstaIdentity to the SlotType enum. Add flowsta-agent-linking-integrity and flowsta-agent-linking-coordinator zomes to the DNA manifest (dna.yaml). Install @flowsta/holochain SDK in the frontend. Any agent can now link their Flowsta identity to their Person entry via a FlowstaIdentity capability slot. This phase delivers: cross-app identity expression in the network (trust signals without enforcement), DID attachment to agent profiles, and the foundation for Vault-backed key recovery.

Phase 2 — Frontend and UX Integration (UI changes only)

Add a "Link Flowsta Identity" flow in the person/profile management UI. Display linked Flowsta DIDs on agent profiles. Show Flowsta verification badges on agents in search results and governance views. Integrate Vault backup API for agent data resilience (@flowsta/holochain backup functions: startAutoBackup, backupToVault, retrieveFromVault, listVaultBackups). This phase delivers: user-facing identity management, visible trust indicators, and data resilience.

Phase 3 — Governance-Enforced Identity Verification (zome_gouvernance changes)

Add IdentityVerification variant to GovernanceRuleType (or use existing rule mechanisms). Governance rules can now require a FlowstaIdentity slot as a precondition for role promotions (e.g., PrimaryAccountableAgent) or for high-value custody transfers. The governance zome validates the IsSamePersonEntry signature chain — checking that the FlowstaIdentity slot exists, that the target IsSamePersonEntry contains the agent's AgentPubKey, and that the attestation has not been revoked — before approving the conditioned transition. This phase delivers: governance-enforced identity verification, sybil resistance for high-trust roles, and the bridge between permissionless participation and accountable governance.

7. Design Patterns

The NDO embodies six named design patterns. These patterns are architectural idioms that recur throughout the system and should guide implementation decisions.

Pattern 1: Identity Anchor

Intent: Give every resource a stable, cryptographically-secure identity anchor that persists through all transformations, including end of life.

Structure: The NondominiumIdentity genesis entry. Its action hash is the stable namespace for all other entries and links. Nothing else in the system references a resource by any other handle.

Rationale: In complex adaptive systems, identity must be decoupled from form. A person's identity persists even as their body, beliefs, and relationships change. A corporation's identity persists through restructuring. The NDO's identity must persist through design changes, custody transfers, version forks, and end of life. Content-addressing in Holochain makes this natural: the action hash of the genesis entry never changes.

Holochain idiom:

#![allow(unused)]
fn main() {
// Layer 0 creation — returns the stable identity hash
let ndo_hash = create_entry(&EntryTypes::NondominiumIdentity(identity))?;
// Everything else links to ndo_hash
}

Pattern 2: Complexity-Matched Layer Activation

Intent: Activate only the structural complexity that the current coordination environment demands. Do not pay coordination costs in advance of need.

Structure: Layer activation via link creation. Layer 1 activates when NDOToSpecification link is created. Layer 2 activates when NDOToProcess link is created. Both can be created retroactively, at any lifecycle stage.

Rationale: Benkler's information opportunity cost analysis: overhead that exceeds the value of the coordination it enables is pure waste. A tool being lent between friends does not need a full ValueFlows process. A community hardware standard being developed across fifty fabrication networks does. The NDO model allows the system's complexity to grow with the resource's social complexity, not ahead of it.

Holochain idiom:

#![allow(unused)]
fn main() {
// Activate Layer 1 — link identity to specification
create_link(ndo_hash, spec_hash, LinkTypes::NDOToSpecification, ())?;

// Activate Layer 2 — link identity to process
create_link(ndo_hash, process_hash, LinkTypes::NDOToProcess, ())?;
}

Pattern 3: Holonic Composition

Intent: Allow NDOs to contain other NDOs, creating fractal hierarchies where every level of organization has the same structural potential.

Structure: NDOToComponent links from a parent NDO's identity hash to child NDO identity hashes. A Project NDO links to Resource NDOs. A Resource NDO links to Design NDOs. A Design NDO links to Component NDOs.

Rationale: Morin's holographic principle and the fractal composable resource architecture (documented in digital-resource-integrity.md). In complex systems, the same structure appears at every scale. The NDO's three-layer potential is the same whether the resource is an atomic component or a multi-organization project.

Holochain idiom:

#![allow(unused)]
fn main() {
// Link parent NDO to child NDO
create_link(
    parent_ndo_hash,
    child_ndo_hash,
    LinkTypes::NDOToComponent,
    LinkTag::new(component_role.as_str()), // e.g., "required", "optional", "alternative"
)?;
}

Pattern 4: Progressive Disclosure

Intent: Present resources at the appropriate level of complexity for the current context, without exposing structural complexity that is not yet active.

Structure: Three starting archetypes that correspond to common initialization states, presented as UI choices that set the initial lifecycle stage. These are starting configurations, not permanent classifications.

Rationale: Kauffman's adjacent possible — present only what is currently achievable. An agent creating their first NDO should not be confronted with the full complexity of the three-layer model. The system should reveal its depth progressively as the resource's context demands it.

Pattern 5: Tombstone

Intent: Preserve permanent identity records for all resources that have ever existed, including those that have reached end of life, been deprecated, or been abandoned.

Structure: At end of life, only Layer 0 remains active. Layers 1 and 2 are archived (spec is_active: false, process concluded with terminal EconomicEvent). The identity entry is never deleted.

Rationale: The DHT is append-only — this is not a limitation, it is a feature. The permanent memory of what resources existed, who created them, and what happened to them is institutional knowledge. Tombstones enable:

• OVN-compliant contribution tracking even after a project ends
• Versioning lineage that traces forks back to their origins
• Historical record for the network

Holochain idiom:

#![allow(unused)]
fn main() {
// End-of-life transition — archive layers
update_entry(spec_hash, &ResourceSpecification { is_active: false, ..spec })?;
// Create terminal EconomicEvent for Layer 2
create_entry(&EntryTypes::EconomicEvent(EconomicEvent {
    action: VfAction::Consume,
    lifecycle_transition: Some(LifecycleStage::EndOfLife),
    ..
}))?;
// Layer 0 NondominiumIdentity is NOT deleted — it becomes the tombstone
}

Pattern 6: Stigmergic Capability Attachment

Intent: Allow any agent or external hApp to attach capabilities to an NDO without modifying the NDO entry, without requiring permission from the NDO's custodian, and without needing to have been anticipated by the NDO's designer.

Structure: CapabilitySlot links from the Layer 0 identity hash to capability targets. Link tags carry the slot type, author, and attachment timestamp. Governance layer filters trusted vs untrusted links.

Rationale: Morin's ecology of action: no action guarantees its outcome. The capabilities that will be most useful to attach to a resource cannot be known at creation time. The attachment surface must be open. Centralized gatekeeping of capabilities (requiring permission from the NDO custodian before attaching) would impose coordination costs that violate Benkler's information opportunity cost principle.

Holochain idiom:

#![allow(unused)]
fn main() {
let slot_tag = CapabilitySlotTag {
    slot_type: SlotType::IssueTracker,
    attached_at: sys_time()?,
};
create_link(
    ndo_identity_hash,
    issue_tracker_cell_hash,
    LinkTypes::CapabilitySlot,
    LinkTag::new(serde_json::to_vec(&slot_tag)?),
)?;
}

8. DHT Data Structures

8.1 NondominiumIdentity Entry (Layer 0)

#![allow(unused)]
fn main() {
#[hdk_entry_helper]
#[derive(Clone, PartialEq)]
pub struct NondominiumIdentity {
    // Core identity fields
    pub name: String,
    pub description: Option<String>,
    pub initiator: AgentPubKey, // TODO (G1, REQ-AGENT-02): replace with AgentContext post-MVP
                                // to support Collective, Project, Network, and Bot agents as
                                // initiators. Currently assumes individual agent. Aligns with
                                // the same change needed for EconomicResource.custodian.

    // Classification
    pub property_regime: PropertyRegime,
    pub resource_nature: ResourceNature,

    // Initial lifecycle state
    pub lifecycle_stage: LifecycleStage,

    // Timestamp
    pub created_at: Timestamp,
}
}

8.2 Supporting Enums

#![allow(unused)]
fn main() {
#[derive(Clone, PartialEq, Debug, Serialize, Deserialize)]
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
    Nondominium,    // Uncapturable by design; contribution-based access; no alienation permitted
}
// Canonical definition: documentation/archives/resources.md Section 6.3

#[derive(Clone, PartialEq, Debug, Serialize, Deserialize)]
pub enum ResourceNature {
    Digital,   // Software, data, design files, documents
    Physical,  // Material objects, equipment, spaces
    Hybrid,    // Digital twin of a physical resource, or physical+digital bundle
}

#[derive(Clone, PartialEq, Debug, Serialize, Deserialize, Default)]
pub enum LifecycleStage {
    // Emergence
    #[default]
    Ideation,
    Specification,
    Development,
    Prototype,

    // Maturity
    Stable,
    Distributed,

    // Operation
    Active,

    // Suspension
    Hibernating,

    // Terminal
    Deprecated,
    EndOfLife,
}
}

8.3 Capability Slot Link Tag

#![allow(unused)]
fn main() {
#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct CapabilitySlotTag {
    pub slot_type: SlotType,
    pub attached_at: Timestamp,
    pub label: Option<String>, // Human-readable label for this specific slot
}

#[derive(Clone, Debug, Serialize, Deserialize)]
pub enum SlotType {
    Documentation,
    IssueTracker,
    FabricationQueue,
    GovernanceDAO,
    VersionGraph,
    DigitalAsset,
    WeaveWAL,
    FlowstaIdentity,       // Flowsta agent-linking attestation (IsSamePersonEntry action hash)
    UnytAgreement(String), // Unyt Alliance network seed identifier (empty string = sandbox default)
    CustomApp(String),     // Extensible: custom slot type identified by string
}
}

8.4 New Link Types (additions to zome_resource integrity)

#![allow(unused)]
fn main() {
// In zome_resource integrity LinkTypes enum — new variants to add:
pub enum LinkTypes {
    // ... existing link types ...

    // --- NDO Three-Layer Links ---
    NDOToSpecification,     // NondominiumIdentity → ResourceSpecification (Layer 1 activation)
    NDOToProcess,           // NondominiumIdentity → Process (Layer 2 activation)
    NDOToComponent,         // NondominiumIdentity → NondominiumIdentity (holonic composition)

    // --- Capability Surface ---
    CapabilitySlot,         // NondominiumIdentity → capability target (typed by tag)

    // --- Discovery ---
    AllNDOs,                // Anchor → NondominiumIdentity (global discovery)
    NDOsByLifecycleStage,   // LifecyclePath → NondominiumIdentity
    NDOsByNature,           // NaturePath → NondominiumIdentity
    NDOsByRegime,           // RegimePath → NondominiumIdentity

    // --- Lifecycle History ---
    NDOLifecycleHistory,    // NondominiumIdentity → LifecycleEvent (audit trail)
}
}

8.5 NondominiumIdentity Updates

Layer 0 entries may be updated only to change lifecycle_stage. All other fields are immutable after creation. This preserves the identity anchor property: the content of the NDO changes as little as possible, while the DHT link graph around it grows freely.

#![allow(unused)]
fn main() {
// Only lifecycle_stage updates are permitted
pub struct UpdateNDOLifecycleInput {
    pub original_action_hash: ActionHash,
    pub previous_action_hash: ActionHash,
    pub new_stage: LifecycleStage,
    pub transition_event_hash: ActionHash, // Must reference a valid EconomicEvent
}
}

8.6 Holonic Composition Diagram

graph TB
    ProjectNDO["Project NDO\n(Layer 0: identity)\n(Layer 1: project spec)\n(Layer 2: process)"]
    ResourceNDO["Resource NDO\n(Layer 0: identity)\n(Layer 1: design spec)\n(Layer 2: use process)"]
    ComponentNDO["Component NDO\n(Layer 0: identity)\n(Layer 1: component spec)\n(Layer 2: none yet)"]
    AssetNDO["Asset NDO (digital)\n(Layer 0: identity)\n(Layer 1: manifest)\n(Layer 2: none)"]

    ProjectNDO -->|"NDOToComponent\n(required)"| ResourceNDO
    ResourceNDO -->|"NDOToComponent\n(required)"| ComponentNDO
    ResourceNDO -->|"NDOToComponent\n(optional)"| AssetNDO
    ComponentNDO -->|"CapabilitySlot\n(DigitalAsset)"| AssetNDO

8.7 Agent Context Entry (Post-MVP)

TODO (G1 — AgentEntityType): The NDO three-layer model currently focuses on resource representation. For the generic NDO to support commons-based peer production as practised in OVNs (where ventures, networks, and partner organisations are also economic agents), the agent layer needs an equivalent minimal identity structure. The following is a forward-design proposal, not yet implemented. See documentation/archives/agent.md §6.1 and REQ-AGENT-01.

#![allow(unused)]
fn main() {
// Post-MVP: AgentContext entry type (companion to Person, or standalone for non-human agents)
#[hdk_entry_helper]
pub struct AgentContext {
    pub agent_type: AgentEntityType,
    pub person_hash: Option<ActionHash>,  // None for bots and external organisations
    pub created_at: Timestamp,
    pub network_seed: String,             // Which NDO network this context belongs to
}

pub enum AgentEntityType {
    Individual,                           // Human participant with a Person entry
    Collective(String),                   // Working group / committee (name/description)
    Project(ActionHash),                  // Project NDO this agent entity represents
    Network(ActionHash),                  // Network NDO this agent entity represents
    Bot {                                 // AI agent or IoT device
        capabilities: Vec<String>,
        operator: AgentPubKey,            // Responsible human operator
    },
    ExternalOrganisation(String),         // Traditional org (for partner modelling)
}
}

Design principles:

• Individual agents have AgentEntityType::Individual with a linked Person entry
• Collective, Project, and Network agents are composed agents (group agents). Project(ActionHash) and Network(ActionHash) carry an ActionHash pointing to the NondominiumIdentity that is the collective's resource face — its digital twin as a Nondominium Object. The AgentContext itself is the agent face through which the collective participates in economic events. These are ontologically distinct: the NondominiumIdentity is a Resource; the AgentContext is an Agent. Neither replaces the other. A Collective(String) agent may not yet have an associated NDO; its agent face exists independently of any resource face.
• Bot agents have no Person but have declared capabilities and a responsible human operator; their actions are attributed to the operator for PPR purposes
• ExternalOrganisation agents model traditional partners/suppliers without requiring them to run a Holochain node

Derived affiliation state (computed from existing DHT data, not stored):

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

→ UnaffiliatedStranger | CloseAffiliate | ActiveAffiliate | CoreAffiliate | InactiveAffiliate

9. Requirements

9.1 Layer 0 — Identity Requirements

• REQ-NDO-L0-01: The system shall support the creation of a NondominiumIdentity entry as the minimal representation of any Nondominium Object, requiring only name, initiator, property_regime, resource_nature, lifecycle_stage, created_at, and an optional description.
• REQ-NDO-L0-02: The action hash of the NondominiumIdentity genesis entry shall be the stable, permanent identity of the NDO for its entire existence and shall never be voided or replaced.
• REQ-NDO-L0-03: A NondominiumIdentity entry shall never be deletable by any agent or governance action. Its permanent presence in the DHT is a design guarantee, not a policy choice.
• REQ-NDO-L0-04: Only the lifecycle_stage field of a NondominiumIdentity entry may be updated after creation. All other fields are immutable.
• REQ-NDO-L0-05: Every update to lifecycle_stage shall reference a valid EconomicEvent action hash as the triggering transition event.
• REQ-NDO-L0-06: At end of life (LifecycleStage::EndOfLife), the NondominiumIdentity entry shall remain fully readable and discoverable, serving as a tombstone.
• REQ-NDO-L0-07: The system shall support discovery of NDOs by lifecycle_stage, resource_nature, and property_regime via DHT path-based anchors.

9.2 Layer 1 — Specification Requirements

• REQ-NDO-L1-01: Layer 1 shall be activated by creating an NDOToSpecification link from the NDO identity hash to a ResourceSpecification entry. No modification of the NondominiumIdentity entry is required for activation.
• REQ-NDO-L1-02: Layer 1 may be activated at any lifecycle stage at or after Ideation. Retroactive activation (for NDOs that began at Ideation without a spec) shall be fully supported.
• REQ-NDO-L1-03: Multiple ResourceSpecification entries may be linked to one NDO identity, representing version evolution. The most recent link shall be considered the canonical Layer 1 specification.
• REQ-NDO-L1-04: When Layer 1 enters dormant state (hibernation or end of life), the specification shall be marked is_active: false. The NDOToSpecification link shall remain readable.
• REQ-NDO-L1-05: GovernanceRule entries shall continue to be linked to ResourceSpecification entries as currently implemented. They are considered Layer 1 assets.
• REQ-NDO-L1-06: Digital asset references (files, 3D models, code, integrity manifests) shall be attached to the NDO via CapabilitySlot links of type DigitalAsset, not embedded in the ResourceSpecification entry.

9.3 Layer 2 — Process Requirements

• REQ-NDO-L2-01: Layer 2 shall be activated by creating an NDOToProcess link from the NDO identity hash to a ValueFlows Process entry.
• REQ-NDO-L2-02: Layer 2 may be activated at any lifecycle stage at or after Specification.
• REQ-NDO-L2-03: All EconomicEvent, Commitment, Claim, and PrivateParticipationClaim entries associated with an NDO shall be linked through the active Layer 2 process.
• REQ-NDO-L2-04: When a process concludes (all commitments fulfilled or cancelled), a terminal EconomicEvent with VfAction::Consume shall be recorded, formally concluding Layer 2.
• REQ-NDO-L2-05: A new Layer 2 process may be activated for the same NDO after a previous process has concluded (e.g., a second development cycle after hibernation).
• REQ-NDO-L2-06: EconomicResource entries (physical instances of the resource) shall be linked to the NDO via the Layer 2 process, not directly to the Layer 0 identity.

9.4 Lifecycle and Operational State Requirements

LifecycleStage Requirements

• REQ-NDO-LC-01: The system shall implement the LifecycleStage enum as defined in Section 5.1 on the NondominiumIdentity entry, replacing the lifecycle dimension of the current ResourceState enum. The migration mapping in Section 10 shall be used for backward compatibility.
• REQ-NDO-LC-02: Lifecycle stage transitions shall be validated by the governance zome acting as state transition operator, consistent with REQ-ARCH-07 (governance-as-operator).
• REQ-NDO-LC-03: Each lifecycle transition shall generate a corresponding EconomicEvent with the triggering VfAction, creating an auditable lifecycle history.
• REQ-NDO-LC-04: The Hibernating stage shall be clearly distinguished from Deprecated and EndOfLife. A hibernating resource may be reactivated; deprecated and end-of-life resources may not be reactivated.
• REQ-NDO-LC-05: Transition to EndOfLife shall respect the challenge period defined in REQ-GOV-13.
• REQ-NDO-LC-06: The Deprecated stage shall require a link to a successor NDO identity hash. Deprecation without a declared successor is not permitted.
• REQ-NDO-LC-07: The governance zome shall enforce the authorized role for each lifecycle transition as defined in Section 5.3.

OperationalState Requirements

• REQ-NDO-OS-01: The system shall implement the OperationalState enum as defined in Section 5.4 on the EconomicResource entry, replacing the process-related dimension of the current ResourceState enum.
• REQ-NDO-OS-02: OperationalState transitions shall be managed exclusively by the governance zome. The resource zome stores the field; only the governance zome may initiate valid transitions.
• REQ-NDO-OS-03: Each OperationalState transition shall correspond to an open or completed EconomicEvent. The governance zome shall reject state transitions for which no corresponding event exists.
• REQ-NDO-OS-04: OperationalState and LifecycleStage are orthogonal. An OperationalState transition shall never cause a LifecycleStage transition, and vice versa.
• REQ-NDO-OS-05: The InTransit, InStorage, and InMaintenance states may occur at any LifecycleStage at or after Development. The system shall not restrict these states to any specific lifecycle stage.
• REQ-NDO-OS-06: The ResourcesByState link type shall be split into ResourcesByLifecycleStage and ResourcesByOperationalState to enable independent faceted queries on each dimension.

TODO (code): Split the current ResourceState enum in zome_resource integrity into LifecycleStage (on NondominiumIdentity) and OperationalState (on EconomicResource). Update EconomicResource struct, governance zome state transition logic, ResourcesByState link type, and all coordinator functions. See Section 10.3 for the migration map.

9.5 Capability Surface Requirements

• REQ-NDO-CS-01: The system shall support CapabilitySlot links from any NDO identity hash to any DHT hash or external reference, using the CapabilitySlotTag structure defined in Section 8.3.
• REQ-NDO-CS-02: Any Accountable Agent shall be able to create a CapabilitySlot link to any NDO, without requiring permission from the NDO's custodian. Permissionless attachment at the DHT level is a design guarantee.
• REQ-NDO-CS-03: The governance zome shall support validation of CapabilitySlot links, allowing custodians and Accountable Agents to mark specific slots as trusted or untrusted.
• REQ-NDO-CS-04: The system shall support all SlotType variants defined in Section 8.3, including CustomApp(String) for extensibility.
• REQ-NDO-CS-05: The WeaveWAL slot type shall be supported as the integration point for MOSS/Weave tools, enabling NDOs to appear as Weave Assets.
• REQ-NDO-CS-06: The capability surface shall remain open across all lifecycle stages, including Hibernating and EndOfLife. Historical attachments on archived NDOs shall remain readable.
• REQ-NDO-CS-07: The system shall support a UnytAgreement(String) slot type in the SlotType enum, where the String carries the Unyt Alliance network seed. The target of a UnytAgreement capability slot link shall be a Unyt Smart Agreement entry hash (cross-cell reference).
• REQ-NDO-CS-08: Any Accountable Agent shall be able to create a UnytAgreement capability slot on any NDO (Tier 1: permissionless proposal). The governance zome shall not require validation of Tier 1 UnytAgreement slots beyond the standard capability surface governance defined in REQ-NDO-CS-03.
• REQ-NDO-CS-09: The GovernanceRuleType enum in zome_resource integrity shall support an EconomicAgreement variant. A GovernanceRule entry of this type shall carry EconomicAgreementRuleData as its rule_data, including: unyt_alliance_id, smart_agreement_hash, trigger_actions (list of VfAction values), settlement_window_secs, and an optional note.
• REQ-NDO-CS-10: When the governance zome processes a state transition whose VfAction matches a trigger_actions entry in an endorsed EconomicAgreement governance rule, the transition request shall be required to include a rave_hash. The governance zome shall validate the RAVE against the Unyt DHT (via cross-DNA call) before approving the transition.
• REQ-NDO-CS-11: When a state transition is approved in the presence of a valid EconomicAgreement rule, the PrivateParticipationClaim generated for all participating agents shall include the settlement_rave_hash field referencing the validated Unyt RAVE. This field shall be None for all transitions where no economic agreement was triggered.
• REQ-NDO-CS-12: The system shall support a FlowstaIdentity slot type in the SlotType enum. The target of a FlowstaIdentity capability slot link shall be an IsSamePersonEntry action hash committed by the flowsta-agent-linking coordinator zome.
• REQ-NDO-CS-13: Any agent shall be able to create a FlowstaIdentity capability slot on their own Person entry hash (Tier 1: permissionless attestation). The governance zome shall not require validation of Tier 1 FlowstaIdentity slots beyond the standard capability surface governance defined in REQ-NDO-CS-03.
• REQ-NDO-CS-14: The governance zome shall support an IdentityVerification governance rule type (or equivalent mechanism) that conditions role promotions or high-value state transitions on the presence of a verified FlowstaIdentity capability slot on the requesting agent's Person entry hash (Tier 2: governance requirement).
• REQ-NDO-CS-15: When verifying a FlowstaIdentity slot for Tier 2 governance enforcement, the governance zome shall validate that: (a) a FlowstaIdentity CapabilitySlot link exists from the agent's Person hash; (b) the target IsSamePersonEntry contains the agent's AgentPubKey as one of the two signing parties; (c) the attestation has not been revoked via the revoke_link function of the flowsta-agent-linking coordinator.

9.6 Migration Requirements

• REQ-NDO-MIG-01: All new resources created after the introduction of the NDO model shall begin with a NondominiumIdentity creation as their first action.
• REQ-NDO-MIG-02: Existing ResourceSpecification entries created before the NDO model shall be retroactively anchored to a new NondominiumIdentity entry. This operation shall be additive (no existing entries are modified or deleted).
• REQ-NDO-MIG-03: The ResourceState enum shall be deprecated and replaced by LifecycleStage. Existing records using ResourceState values shall be mapped using the migration table in Section 10.2 without data loss.
• REQ-NDO-MIG-04: Existing EconomicResource entries shall not require migration. They shall be linked to the new NDO model via Layer 2 process links when the NDO is retroactively created.
• REQ-NDO-MIG-05: The migration shall be implemented as a one-time migration coordinator function, not as a permanent API change, to avoid polluting the steady-state code with migration logic.

9.7 Agent Architecture Requirements (Post-MVP)

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

• REQ-NDO-AGENT-01: Agent Type Taxonomy: The system shall support an AgentEntityType discriminant on every agent context, distinguishing at minimum: Individual, Collective, Project, Network, Bot, and ExternalOrganisation (see Section 8.7 for the proposed data structure). The MVP's implicit individual-only model is insufficient for commons-based peer production where ventures and networks are first-class economic actors.
• REQ-NDO-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, 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. Collective agents may act through multi-signature patterns (N-of-M member authorisation) when performing economic events.
• REQ-NDO-AGENT-03: Affiliation Spectrum: The system shall derive the OVN affiliation state (UnaffiliatedStranger, CloseAffiliate, ActiveAffiliate, CoreAffiliate, InactiveAffiliate) algorithmically from existing DHT data — PPR contribution history, recency, and AffiliationRecord existence. Affiliation state shall not be stored as a separate entry (which would require maintenance and risk inconsistency). The derivation function is defined in Section 8.7.
• REQ-NDO-AGENT-04: AffiliationRecord: The system shall support an AffiliationRecord entry for formal network onboarding: the agent cryptographically signs acknowledgement of the network's Terms of Participation, Nondominium & Custodian agreement, and Benefit Redistribution Algorithm. The AffiliationRecord is the machine-readable prerequisite for ActiveAffiliate status.
• REQ-NDO-AGENT-05: Composable AgentProfile View: The system shall expose a composable AgentProfile query assembling identity, capability, reputation, participation, social, and temporal data into a single queryable output. This view shall be computed from existing DHT data — it is not a new stored entry type. Agents control which sections are exposed by granting access to constituent entries.
• REQ-NDO-AGENT-06: Social Graph: The system shall model peer relationships via an AgentRelationship bidirectional link type (typed: colleague, collaborator, trusted, voucher), stored as private links. Social relations are part of agent wealth in the OVN model and must be accessible to governance without being publicly discoverable.
• REQ-NDO-AGENT-07: CapabilitySlot on Agent Identity: The Person entry hash shall serve as a stigmergic attachment surface for external credential wallets, DID documents, and reputation oracles, using the same CapabilitySlot link pattern defined in Section 6 for NDO resources. See Section 6.5 for the forward design. Flowsta's FlowstaIdentity capability slot (Section 6.7) provides the first concrete implementation: a DID-backed, dual-signed attestation attachable to the Person hash without schema modification.
• REQ-NDO-AGENT-08: Portable Credentials: The system shall support a PortableCredential structure — bilaterally signed by an issuer (PrimaryAccountableAgent) and the credential owner — verifiable by other Holochain networks. Types: RoleCredential, ReputationCredential, CompetencyCredential, AffiliationCredential. This is the technical mechanism for cross-network identity portability required by the OVN model. Flowsta's W3C DID (did:flowsta:uhCAk...) provides the cross-network identity anchor required for credential portability. When combined with the FlowstaIdentity capability slot, portable credentials become attributable to a verified cross-app identity.

10. Migration from Current Architecture

10.1 Current Architecture Overview

The current Nondominium zome architecture has three resource-related entry types:

ResourceSpecification  (zome_resource)
  ↓ SpecificationToResource
EconomicResource       (zome_resource)
  - custodian: AgentPubKey
  - state: ResourceState  { PendingValidation, Active, Maintenance, Retired, Reserved }
    ↑ TODO: split into LifecycleStage (on NondominiumIdentity) + OperationalState (on EconomicResource)

GovernanceRule         (zome_resource)
  (linked from ResourceSpecification via SpecificationToGovernanceRule)

EconomicEvent          (zome_gouvernance)
  - provider: AgentPubKey
  - receiver: AgentPubKey
  - resource_inventoried_as: ActionHash → EconomicResource

10.2 Migration Mapping

graph LR
    subgraph current ["Current Architecture"]
        RS[ResourceSpecification]
        ER[EconomicResource]
        GR[GovernanceRule]
        RS -->|SpecificationToResource| ER
        RS -->|SpecificationToGovernanceRule| GR
    end

    subgraph ndoModel ["NDO Three-Layer Model"]
        L0[NondominiumIdentity\nLayer 0]
        L1[ResourceSpecification\nLayer 1]
        L2[Process\nLayer 2]
        L2E[EconomicResource\nInstance]
        GR2[GovernanceRule\nLayer 1 asset]
        L0 -->|NDOToSpecification| L1
        L0 -->|NDOToProcess| L2
        L2 -->|ProcessToResource| L2E
        L1 -->|SpecToGovernanceRule| GR2
    end

    RS -->|"maps to"| L1
    ER -->|"maps to"| L2E
    GR -->|"maps to"| GR2

Detailed mapping table:

10.3 ResourceState Migration Map

The current ResourceState enum is split across the two new orthogonal dimensions. Each existing variant maps to a (LifecycleStage, OperationalState) pair:

The pre-operational stages (Ideation, Specification, Development) have no equivalent in the current model and will apply only to newly created NDOs.

10.4 Migration Strategy

The migration is strictly additive — no existing entries are modified or deleted. The append-only nature of the DHT is respected throughout.

Phase 1 — Forward compatibility (immediate):

• All new resources created after the NDO model lands must begin with NondominiumIdentity creation
• New NDOToSpecification and NDOToProcess link types are added to the integrity zome
• LifecycleStage (on NondominiumIdentity) and OperationalState (on EconomicResource) replace ResourceState for new resources
• ResourcesByState link type is split into ResourcesByLifecycleStage and ResourcesByOperationalState

Phase 2 — Retroactive anchoring (migration coordinator):

• For each existing ResourceSpecification entry, create a NondominiumIdentity entry and the corresponding NDOToSpecification link
• The NondominiumIdentity is created by the original author of the ResourceSpecification (or by a designated migration agent)
• Map the existing ResourceState to (LifecycleStage, OperationalState) pairs using the migration table in Section 10.3
• Link existing EconomicResource instances to the new NDO via a retroactive Process entry

Phase 3 — Cleanup (optional, post-migration):

• Deprecate the ResourceState enum in code (keep for deserialization compatibility of existing DHT entries)
• Update the UI to show LifecycleStage and OperationalState vocabulary separately
• Activate capability slots for resources that have associated external assets

What is not required:

• No deletion of any existing entries
• No update to any existing ResourceSpecification or EconomicResource entries
• No data migration (existing data remains valid in both old and new reading code)

11. Relationship to Other Post-MVP Work

11.1 Many-to-Many Flows

many-to-many-flows.md defines shared custody and multi-party resource transfers. In the NDO model:

• Shared custody (co-custodians) is expressed at Layer 0: the NondominiumIdentity carries a reference to shared custodianship state, or the governance zome maintains co-custodian records linked from the identity hash
• Multi-party transfer events (REQ-MMF-06 through REQ-MMF-14) are Layer 2 EconomicEvent records with multiple providers/receivers
• The Layer 0 identity hash provides the stable anchor for all custodian-to-resource links across custody transfers

11.2 Versioning

versioning.md defines a DAG of versions for resources. In the NDO model:

• The R-VERS-01 requirement for "base identity vs version nodes" maps directly to the NDO: Layer 0 is the base identity; ResourceSpecification versions linked via NDOToSpecification are the version nodes
• The version DAG is expressed as a VersionGraph capability slot linking the NDO identity to a versioning system
• Fork relationships (ForkedFrom, EvolvedFrom) are expressed between ResourceSpecification entries linked to (potentially different) NDO identities
• The Deprecated lifecycle stage with a mandatory successor link implements the R-VERS-01 base identity continuity requirement

11.3 Digital Resource Integrity

digital-resource-integrity.md defines cryptographic integrity manifests for digital resources. In the NDO model:

• Digital asset manifests are attached to the NDO via CapabilitySlot links of type DigitalAsset
• The fractal composable resource architecture (atomic → component → composite) maps directly to the Holonic Composition Pattern: each component is itself an NDO, with NDOToComponent links expressing the assembly hierarchy
• The VersionGraph capability slot integrates with manifest-backed versions (R-VERS-DIG-01)

11.4 MOSS / Weave Integration

The Weave Interaction Pattern defines how hApps create, search, link, and organize social space units into complex social fabric. The NDO is the fundamental social space unit in Nondominium:

• Layer 0 identity hash → declared as a Weave Asset via WeaveWAL capability slot
• MOSS tools (governance DAOs, fabrication queues, issue trackers) attach via the stigmergic capability surface without requiring NDO entry modifications
• Lifecycle stage transitions can be signaled to MOSS via Holochain signals, allowing MOSS tools to respond dynamically to NDO state changes

11.5 Unyt Integration

unyt-integration.md defines Unyt as the transactional layer for Nondominium — peer-to-peer accounting infrastructure built on Holochain, providing currencies, Smart Agreements, and agent-centric value flows. In the NDO model, Unyt integrates at three points:

• Capability surface: UnytAgreement slot type (Section 6.6) is the permissionless attachment point — any agent can propose economic terms for any NDO
• Layer 1: GovernanceRule entries of type EconomicAgreement carry endorsed Unyt Smart Agreement references as Layer 1 assets, sitting alongside other governance rules in the resource's specification
• Layer 2: RAVE hashes (Recorded Agreement Verifiably Executed) link into PrivateParticipationClaim entries via settlement_rave_hash, binding economic settlement records to participation records in the Layer 2 process

The NDO three-layer model and Unyt are architecturally complementary: the NDO tracks what happens (resource events, custody, quality, lifecycle); Unyt tracks who owes what to whom (credits, debits, settlement). The governance zome is the bridge that conditions resource state transitions on proof of economic settlement, making the resource itself the enforcement mechanism for its own economic terms.

The PPR system and Unyt credit limits form a feedback loop: agents' ReputationSummary (derived from their accumulated PPRs) feeds into the Unyt Compute Credit Limit Agreement, making participation history the collateral for economic access in the commons network. This is the primary mechanism by which the Nondominium commons becomes self-sustaining without platform intermediaries or administrative overhead.

11.6 Flowsta Integration

flowsta-integration.md defines Flowsta as the identity and authentication layer for the NDO — decentralized authentication built on Holochain, providing cross-app identity linking, W3C DIDs, and zero-knowledge privacy. In the NDO model, Flowsta integrates at three points:

• Capability surface: FlowstaIdentity slot type (Section 6.7) is the permissionless Tier 1 attachment point — any agent can link their Person entry to a Vault dual-signed IsSamePersonEntry, making their cross-app DID discoverable (no governance enforcement at this tier)
• Agent identity (G15): The FlowstaIdentity slot is the first concrete implementation of the PersonCapabilitySlot pattern defined in Section 6.5 — a DID-backed attestation attached to the agent's identity anchor without modifying the Person entry schema
• Governance enforcement (Tier 2, Phase 3): IdentityVerification governance rules can condition role promotions and high-value transitions on a FlowstaIdentity slot that passes REQ-NDO-CS-15 validation (valid IsSamePersonEntry, requestor key included, not revoked), bridging permissionless participation and accountable governance

The NDO three-layer model and Flowsta are architecturally complementary: the NDO tracks who does what (participation, custody, quality, reputation via PPRs); Flowsta tracks who is who (cross-app identity, DID, recovery). The capability slot mechanism is the bridge that connects an agent's local DHT identity to their portable, cross-app identity without requiring any core entry schema changes.

Flowsta Vault's BIP39 recovery and auto-backup mechanisms address a gap in the current NDO architecture: agent key recovery. The non-deletable, append-only nature of Person entries and PPRs assumes the agent retains access to their signing key. Vault's deterministic key regeneration from a 24-word mnemonic ensures that the permanent records the NDO creates remain accessible to their authors across device loss and hardware failure.

11.7 Lobby DNA Integration

lobby-dna.md defines the multi-network federation layer that sits above the NDO DHT: a public Lobby DHT (permissionless agent and NDO descriptor registry), per-group Group DHTs (invite-only coordination spaces), and three extensions to the existing NDO DNA (zome_gouvernance).

The Lobby layer connects to the NDO three-layer model at specific points:

• Layer 0 (NondominiumIdentity) as the NDO's public identity anchor: The NdoDescriptor entry in the Lobby DHT mirrors the Layer 0 identity fields (name, lifecycle_stage, property_regime, resource_nature) and references the Layer 0 hash (ndo_identity_hash). The Lobby provides the discovery surface; Layer 0 is the authoritative source of truth.
• Layer 2 (EconomicEvent/Commitment/Claim) as the hard-link gate: NdoHardLink entries are created only on validated EconomicEvent fulfillment — the same Layer 2 cycle that governs all NDO state changes. The Lobby's soft links (planning intent) become NDO-level hard links only through the existing governance-as-operator path.
• Agreement as Layer 2 benefit-distribution governance: The Agreement entry type added to zome_gouvernance extends the NDO's Layer 2 process layer with benefit-distribution rules, activated post-MVP by Unyt RAVEs (see §11.5).
• Contribution as a peer-validated Layer 2 work record: Validated Contribution entries record work done on the NDO at the Layer 2 observation level, with optional cross-DHT references to informal Group-level WorkLog entries for audit purposes.

Deployment modes: The Lobby DNA is designed for dual deployment — standalone hApp (Lobby DNA + Group DNA + NDO DNA, all managed by one conductor) and Moss/Weave Tool applet (Moss handles agent invites and identity at the surface; Nondominium owns the NDO layer). The NDO DNA is identical in both modes.

See lobby-dna.md for normative requirements (REQ-LOBBY-, REQ-GROUP-, REQ-NDO-EXT-*) and specifications/post-mvp/lobby-architecture.md for full schema, coordinator APIs, pipelines, UI, Moss contract, and 7 ADRs.

This document is post-MVP. The NDO Three-Layer Model will be implemented after the first Nondominium proof-of-concept is complete. The proof-of-concept uses ResourceSpecification + EconomicResource + GovernanceRule as defined in the current zome_resource integrity zome. The migration described in Section 10 will be the bridge between the two architectures.

Nondominium UI Design Vision

MVP

This section describes the minimalistic UI for MVP Layer 0 — NDO Identity (stable anchor; only lifecycle_stage evolves after creation; REQ-NDO-L0-*). The MVP UI implements the concepts of Lobby, Groups, and NDO view.

Lobby

The Lobby is a permissionless digital environment that anyone can join. It is the persistent outer shell of the application, always visible regardless of which route is active.

Implemented:

• Persistent left sidebar present on all routes, containing:
  • Browse NDOs link → root page (/) listing all unique NDOs across all the user's groups, with filter chips (Lifecycle Stage, Resource Nature, Property Regime)
  • Groups list — links to each group the user has created or joined (/group/:id)
  • + New Group — inline form: user enters a group name and confirms; they become the group creator
  • → Join Group — inline form: user pastes an invite code or link
  • My Profile / Edit profile — at the bottom of the sidebar; opens the profile modal
• First-time profile modal — triggered automatically on first app launch when no lobby profile exists; requires at least a nickname; all other fields (real name, bio, email) are optional and stored in localStorage

Groups

Groups are organizational contexts for NDOs. A user can create a solo Group or join an existing one. At MVP, group membership and NDO associations are tracked in localStorage (no DHT-backed group entries yet).

Implemented:

• Group panel (/group/:id): shows group name, list of NDO cards, and a "Create NDO" button
• Group profile prompt: on first visit to a group the user is asked how they wish to present themselves (anonymous / custom); stored in localStorage
• NDO cards in group: each card shows name, lifecycle-stage badge, property-regime badge, resource-nature badge, and description excerpt; clicking a card navigates to the NDO detail page
• Switching groups: navigating from one group to another correctly reloads the group name and NDO list

Not yet implemented:

• Invite other users to a group (multi-member groups; sharing an invite link)
• Displaying group members from DHT
• Group-level governance

NDO Creation

NDOs can only be created from within a Group. The "Create NDO" button in a Group panel opens a creation form. NDO identity data is stored on the Holochain DHT as a NondominiumIdentity (Layer 0) entry; the action_hash of that entry is the NDO's permanent stable identity.

Implemented fields:

Note: the original spec listed 6 property-regime variants (including Collective and Pool) and 4 initial lifecycle stages (including Prototype). Both have been revised — see the Rust PropertyRegime enum and LifecycleStage for current canonical values.

NDO View

Clicking an NDO card navigates to /ndo/:hash.

Implemented:

• NDO name displayed in header (populated immediately from in-memory cache on card click; refreshed from DHT in the background)
• Truncated hash shown below the name
• Detail card: labeled fields for Description, Property Regime, Resource Nature, Lifecycle Stage, and Created date
• Identity badges: lifecycle-stage color badge, property-regime badge, resource-nature badge
• Lifecycle transition button (visible to NDO initiator only): advances the lifecycle stage
• Join NDO button — placeholder; toggles inline "Coming soon"; no backend call yet
• Associate with a group button — always shown in the header; opens a modal that lists groups the user has created or joined that are not already linked to this NDO (multi-select); if the user has no groups, the modal explains that case; confirming writes associations to localStorage (ndo_groups_v1 keyed like other group data — see group.store.svelte.ts); the NDO card then appears in the selected group(s)
• Fork this NDO button — opens the fork friction modal; visible only when the Holochain conductor is connected and the UI has resolved the user's agent key
• Tabs: Resources, Governance, Composition, Activity (stubs for post-MVP content)

Browse NDOs

Implemented:

• "Browse NDOs" in sidebar → root page showing all unique NDOs from all groups the user has created or joined
• Filter chips by Lifecycle Stage, Resource Nature, and Property Regime (4 variants)
• NDO cards with name, badges, description excerpt, and truncated hash
• "No NDOs yet" state when the user has no groups or no NDOs

User / Agent Identity

At the Lobby level the User can be anyone. At this level the User creates a Lobby Profile, stored in localStorage. At the Group level the User also has a profile, linked to the Lobby profile but customizable per group. As the User creates or links to an NDO, their identity is distilled into a Holochain Agent (as implemented in zome_person). Since NDOs are public and permissionless, no personal information is revealed at the NDO level — only a pseudonymous agent key address is shown. Access to personal data (e.g. PPR — Personal Participation Receipts) is selective and governed by the Governance zome.

Implemented:

• First-time Lobby profile modal: nickname required; realName, bio, email optional; stored in localStorage
• "Edit profile" in sidebar for returning users
• Group profile prompt on first group visit: user can choose how to present themselves (anonymous or with selected fields from their Lobby profile)
• Agent public key shown on the NDO initiator line when Holochain is connected

MVP ToDos

1. Multi-member groups — invite link: implement invite-link generation and redemption so a group creator can share a link with other agents, who can then join the group and see its NDO list.

2. NDO fork friction: the "Fork this NDO" button opens a form but currently has no governance friction. Per spec, forking should present a notice about negotiation, consensus, and eventual payment (Unyt integration); the MVP version should at minimum display this notice before proceeding.

3. NDO detail page — DHT refresh reliability: the NDO detail page seeds its display from an in-memory card cache and then attempts a background DHT refresh. The DHT refresh path (getMyNdos → getAllNdos) should be validated end-to-end; if it consistently fails, the root cause in get_ndo / get_all_ndos zome calls should be investigated.

4. Group member list: the Group panel has a MemberList stub that currently shows an empty list. Implement fetching and displaying group members (requires the invite/join flow from ToDo 1).

5. Browse NDOs onboarding: when the user has no groups, the NDO browser shows nothing. Add a visible call-to-action ("Create or join a group to see NDOs") to guide new users.

6. Update agent.md: foundational document should be updated to reflect the three-tier identity model — Lobby profile (localStorage) → Group profile (localStorage, per-group) → DHT Agent (zome_person), including the pseudonymity guarantees at the NDO level.

7. NDO–Group association DHT propagation: the "Associate with a group" action currently writes only to the local agent's localStorage. Once the Group DNA is implemented, each association must also be written to the Group's DHT table so all group members see the NDO card — not just the agent who performed the association. The write site is associateNdoWithGroup in group.store.svelte.ts (marked with a TODO comment).

8. Join NDO: the UI only shows placeholder copy ("Coming soon"). Implement backend + UI wiring: join_ndo (or equivalent) coordinator API, integrity entry or link types for membership, and DHT propagation so the joining agent appears in the NDO's contributor/member record. Distinct from Associate with group (curated short list per group).

Post MVP

This section is about UI improvements after a functional MVP.

Core Design Philosophy

• Perspective-centric design: Interface adapts to agent's role and context
• Landscape as fundamental pattern: Natural spatial metaphor for resource organization
• Parallax 3D depth: Isometric perspective with 3-4 layers creating intuitive navigation
• Horizontal navigation: Primary movement left-right through parallax layers
• Intuitive interaction: Natural gestures and spatial awareness
• Symbolic representation: Resources/entities as round icons with peripheral state indicators

Three-Layer Depth System

🔬 Micro Layer (z-index: 300)

• Purpose: Detailed resource view (modal/overlay)
• Trigger: Click/tap on resource entity
• Opacity: 1.0, no blur
• Content: Full resource details, actions, history
• Navigation: Close to return to meso, or jump to related entities

🎯 Meso Layer (z-index: 200) - DEFAULT

• Purpose: Contextual workspace, agent's primary focus
• Scope: Local context relevant to agent's role/location
• Opacity: 0.9-1.0, no blur
• Content: 10-20 most relevant resources/entities (4-5 on screen, but we can circle them while staying in meso view)
• Interaction: Full interactive capabilities

🌍 Macro Layer (z-index: 100)

• Purpose: Global landscape, broader system context
• Scope: All entities less directly related to agent
• Opacity: 0.4-0.7, 2-4px blur
• Content: Overview of entire resource network
• Interaction: Hover preview, click to refocus meso layer

Perspective Types

👷 Role Perspective

Agent sees resources relevant to their role/capabilities

maintainer_role:
  focus_filter: needs_maintenance = true
  priority_order: urgency_level
  color_scheme: earth_tones
  layout: spatial_proximity

📦 Resource Perspective

Focus on specific resource types or categories

resource_view:
  focus_filter: resource_type = selected
  group_by: category | location | status
  color_scheme: resource_type_colors
  layout: cluster_hierarchy

👥 Agent Perspective

Social/collaborative view of other agents

social_view:
  focus_filter: collaboration_potential
  relationship_mapping: trust_network
  color_scheme: relationship_strength
  layout: network_graph

📍 Geographic Perspective

Location-based resource organization

geographic_view:
  focus_filter: spatial_proximity
  center_point: agent_location
  radius: role_responsibility_area
  layout: concentric_circles

Visual Design System

Entity Representation

.resource-entity {
  shape: circle | rounded-square | hexagon;
  size: calc(proximity_score * base_size);
  background: resource_type_color;
  border: 2px solid state_color;

  /* Peripheral indicators */
  .state-badges: action_indicators[];
  .glow-effect: urgency_level;
  .pulse-animation: activity_state;
}

State Indicators

• 🟢 Available/Healthy: Ready for use, optimal condition
• 🟡 Needs Attention: Maintenance required, low priority
• 🔴 Critical/Blocked: Urgent action needed, system risk
• 🔵 In Use/Reserved: Currently engaged, not available
• ⚪ Dormant/Archive: Inactive, background status
• 🟣 Pending: Awaiting approval/assignment

Concentric Layout Pattern

• Center: Agent's current focus/role context
• Inner Ring: High-relevance resources (meso layer)
• Outer Ring: Background context (macro layer, blurred)
• Smooth Transitions: Elastic zoom and pan between layers

Proximity Calculation Algorithm

function calculateProximity(entity, agent_context) {
  const weights = {
    role_relevance: 0.4, // Match to agent's role/skills
    geographic_distance: 0.2, // Physical/logical proximity
    interaction_frequency: 0.2, // Historical engagement
    temporal_urgency: 0.1, // Time-sensitive needs
    governance_access: 0.1, // Permission/capability level
  };

  const proximity_score =
    weights.role_relevance * entity.roleMatch(agent_context.role) +
    weights.geographic_distance *
      (1 - entity.distance(agent_context.location)) +
    weights.interaction_frequency *
      entity.interactionHistory(agent_context.id) +
    weights.temporal_urgency * entity.urgencyScore() +
    weights.governance_access * entity.accessLevel(agent_context.capabilities);

  return Math.min(1.0, Math.max(0.0, proximity_score));
}

// Layer assignment
function assignLayer(proximity_score) {
  if (proximity_score >= 0.7) return "micro_candidate";
  if (proximity_score >= 0.4) return "meso";
  return "macro";
}

Dynamic View Composition

Filter System

const meso_composition = {
  keywords: ["maintenance", "urgent", "mechanical"],
  tags: ["infrastructure", "public"],
  date_range: "last_30_days",
  proximity_threshold: 0.6,
  max_entities: 20,
  sort_by: "urgency_desc",
};

Adaptive Personalization

• Learning: System learns from agent's interaction patterns
• Preferences: Custom color themes, entity sizes, layout density
• Context Switching: Quick perspective toggles based on current task

Navigation Patterns

Primary Navigation (Horizontal)

• Left/Right Scrolling: Move through perspective layers
• Parallax Effect: Different scroll speeds per layer (macro slower than meso)
• Momentum Scrolling: Natural deceleration with bounce effects
• Breadcrumb Trail: Visual path showing navigation history

Secondary Navigation (Vertical)

• Zoom In: Meso → Micro (entity details)
• Zoom Out: Meso → Macro (broader landscape)
• Elastic Transitions: Smooth scaling with momentum physics
• Quick Return: One-click return to default meso view

Interaction Gestures

• Click/Tap: Open micro view or refocus meso
• Double-Click: Quick action (depends on entity type)
• Long Press: Context menu with available actions
• Pinch/Zoom: Layer transition control
• Swipe: Navigate between related entities

Use Case Examples

🌲 Forester Agent Example

Role: Forest maintenance specialist Meso View: Trees/forest sections under their responsibility

• Focus: Trees needing attention (disease, damage, scheduled maintenance)
• Layout: Geographic clusters by forest section
• Priority: Health status and maintenance urgency

Micro View: Individual tree details

• Health metrics, species info, maintenance history
• Available actions: Schedule maintenance, mark for removal, update status

Macro View: Entire forest ecosystem

• All forest resources beyond immediate responsibility
• Ability to see broader patterns and request assistance

🔧 Maintenance Coordinator Example

Role: Equipment and infrastructure maintenance Meso View: Equipment requiring maintenance within their jurisdiction

• Priority filter: Critical systems first, then scheduled maintenance
• Status indicators: Operational, needs attention, critical failure
• Timeline view: Maintenance schedules and deadlines

🏗️ Resource Allocation Agent Example

Role: Optimizing resource distribution across projects Meso View: Available resources and current allocations

• Filter by: Resource type, availability, location, project needs
• Visual flow: Resource movement between projects
• Optimization indicators: Efficiency metrics, bottlenecks

Responsive Design Considerations

Mobile Adaptation

• Single Layer Focus: Simplified view with layer swipe transitions
• Larger Touch Targets: Minimum 44px touch areas for entities
• Simplified Indicators: Essential state information only
• Gesture Navigation: Swipe for layers, tap for details

Desktop Enhancement

• Full Parallax Experience: All three layers simultaneously visible
• Keyboard Shortcuts: Layer navigation, entity selection, quick actions
• Multi-Selection: Batch operations on multiple entities
• Rich Hover States: Detailed tooltips and preview information

Accessibility Features

• High Contrast Mode: Enhanced visual differentiation
• Screen Reader Support: Semantic markup and ARIA labels
• Keyboard Navigation: Full functionality without mouse
• Motion Preferences: Respect user's motion sensitivity settings

Technical Implementation Notes

• Rendering: Canvas-based or WebGL for smooth 3D transitions
• Data Binding: Real-time updates from Holochain DHT
• Performance: Virtualized rendering for large entity sets
• Caching: Intelligent prefetching based on proximity scores
• State Management: Maintain layer states and user preferences

Digital Resource Integrity - High-Level Requirements

Problem Statement

The nondominium system must provide cryptographic proof that downloaded resource data is identical to the original data uploaded to the Holochain DHT. This ensures trust in resource exchange and prevents unauthorized modifications during storage and transmission.

Core Requirements

R1: Cryptographic Integrity Verification

The system shall provide mathematical proof that downloaded data matches the original uploaded data.

Acceptance Criteria:

• Users can verify that any downloaded resource is identical to the original
• Verification process works even if data is stored by multiple unknown agents
• Any modification to data is immediately detectable
• Verification can be performed without trusting storage providers

R2: Distributed Storage with Guarantees

The system shall store resource data across multiple Holochain agents while maintaining integrity.

Acceptance Criteria:

• Files are split into chunks for distributed storage
• Each chunk is cryptographically addressed by its content hash
• Data can be retrieved even if some storage agents are offline
• Storage failures do not compromise data integrity

R3: Efficient Verification Process

The system shall allow users to verify resource integrity efficiently.

Acceptance Criteria:

• Verification can be performed without downloading entire resources
• Users can verify specific portions of large resources
• Verification process completes within acceptable time limits
• Users receive clear success/failure feedback on verification

R4: Manifest-Based Organization

The system shall use manifests to organize and describe resource data.

Acceptance Criteria:

• Each resource has a manifest describing its structure and integrity
• Manifests contain metadata about files and their organization
• Manifests are themselves cryptographically verifiable
• Manifest format supports multiple files and complex resources

R5: Composable Resource Architecture

The system shall support hierarchical resource compositions where parent resources are assembled from child resources.

Acceptance Criteria:

• Resources can reference other resources as components with specified quantities
• Each component maintains independent integrity verification and trust status
• Parent resource integrity depends on component integrity with dependency rules
• Component replacements trigger appropriate re-verification of affected parent assemblies
• Support for required, optional, and alternative components with different verification levels

R6: Fractal Verification Process

The system shall provide recursive verification that cascades through resource hierarchies.

Acceptance Criteria:

• Verify complete resource tree from leaf components to root assembly
• Identify specifically which components failed verification in hierarchical context
• Allow partial verification of subsystems without full assembly verification
• Component integrity changes propagate trust/verification status up through parent assemblies
• Support for "trusted component" status that simplifies verification of dependent assemblies

R7: Component Dependency Management

The system shall manage dependencies between components with version compatibility and substitution rules.

Acceptance Criteria:

• Version compatibility matrices defining which component versions can work together
• Required vs optional vs alternative component classification with clear rules
• Component substitution rules that specify verification implications for replacements
• Assembly upgrade paths that maintain verification continuity and trust propagation

R8: Selective Component Verification

The system shall allow users to verify specific components or subsystems efficiently.

Acceptance Criteria:

• Verify only critical components for time-sensitive operations with reduced scope
• Component-level verification status caching to avoid redundant verifications
• Trust propagation from previously verified components to parent assemblies
• Impact analysis showing which parent assemblies are affected by component changes

R9: Component Supply Chain Transparency

The system shall provide transparency into component origins, manufacturing processes, and assembly relationships.

Acceptance Criteria:

• Component provenance tracking through complete assembly hierarchy
• Manufacturer and supplier verification at component level with cryptographic proofs
• Integration with external supply chain verification systems and standards
• Component recall and replacement notifications that affect dependent assemblies

Verification Process Requirements

Phase 1: Resource Discovery & Composition Analysis

User Action: Request a resource from the DHT

System Responsibilities:

1. Retrieve the resource manifest from the DHT
2. Verify the manifest's cryptographic signature
3. Analyze resource composition:
   • Identify if resource is atomic or composite
   • Load component manifests recursively for composite resources
   • Build complete component dependency tree
   • Check version compatibility between components
4. Present comprehensive manifest metadata including:
   • File list, sizes, and hashes
   • Component breakdown with integrity status
   • Dependency relationships and version constraints
   • Critical vs optional component classification
5. Obtain user consent to proceed with download

Phase 1A: Component Integrity Pre-Check (Composite Resources)

System Responsibilities:

1. Verify availability of all required components
2. Check component verification status and trust levels
3. Identify any missing, corrupted, or incompatible components
4. Present component integrity summary before download
5. Allow user to proceed with available components or wait for missing ones

Phase 2: Hierarchical Chunk Verification During Download

User Action: Download the resource data

System Responsibilities:

1. For atomic resources: Retrieve and verify individual chunks as before
2. For composite resources:
   • Download component resources in dependency order
   • For each component: verify its chunks and integrity according to its verification level
   • Track component verification status independently
3. Real-time integrity feedback:
   • Show component-by-component verification progress
   • Flag individual component failures without stopping entire download
   • Continue with available components while troubleshooting failed ones
4. Dependency validation:
   • Verify component compatibility during assembly
   • Check that required components are present before marking assembly complete
   • Handle optional component absences gracefully

Phase 3: Complete Assembly Verification

User Action: After download completes, request full verification

System Responsibilities:

1. For atomic resources: Verify complete resource against manifest's Merkle root
2. For composite resources:
   • Verify individual component integrity (already done in Phase 2)
   • Verify assembly integrity:
     • Validate component quantities and relationships
     • Check assembly rules and constraints
     • Verify no required components are missing
     • Validate optional component selections
3. Generate hierarchical verification results:
   • ✅ FULLY VERIFIED: All components and assembly validated
   • ⚠️ PARTIALLY VERIFIED: Core components verified, optional issues present
   • ❌ ASSEMBLY FAILED: Critical components missing or incompatible
   • ❌ COMPONENT CORRUPTED: One or more components failed verification
4. Detailed component reporting:
   • Show exact component verification status
   • Identify which components failed and why
   • Provide impact analysis on parent assembly

Phase 4: Hierarchical Integrity Reporting

User Action: Request verification report

System Responsibilities:

1. Generate comprehensive hierarchical verification report:
   • Component breakdown with individual integrity status
   • Assembly verification results with dependency analysis
   • Verification timestamps for each component and assembly
   • Trust propagation analysis showing how component trust affects assembly
2. Supply chain transparency:
   • Component provenance information
   • Manufacturer and supplier verification status
   • Version compatibility analysis
   • Substitution and upgrade recommendations
3. Audit trail maintenance:
   • Store verification results at component and assembly levels
   • Maintain component dependency history
   • Enable verification proof sharing for component sub-assemblies
4. Impact analysis tools:
   • Show which parent assemblies are affected by component changes
   • Provide upgrade and maintenance recommendations
   • Support compliance reporting for regulatory requirements

User Experience Requirements

UX1: Clear Feedback During Verification

The system shall provide users with real-time feedback during the verification process.

Requirements:

• Progress indicator showing verification status
• Clear messaging about which chunks are being verified
• Immediate notification of any verification failures
• Estimated time remaining for verification

UX2: Hierarchical Verification Options

The system shall offer users flexibility in verification approaches for complex resource assemblies.

Options:

• Quick Verify: Verify only critical components and core assembly
• Full Verify: Verify all components, chunks, and complete assembly hierarchy
• Selective Verify: Verify specific components, files, or chunks at any level
• Component Verify: Verify only selected components without full assembly
• Background Verify: Run verification in background with progress notifications
• Trust-Based Verify: Skip verification of pre-trusted components and assemblies
• Supply Chain Verify: Include manufacturer and supplier verification in verification process

UX3: Hierarchical Error Handling and Recovery

The system shall handle verification failures gracefully at component and assembly levels.

Requirements:

• Component-level error reporting: Clear error messages explaining which components failed verification
• Assembly impact analysis: Show how component failures affect parent assemblies
• Graceful degradation: Continue with available components while handling failed ones
• Component substitution assistance: Suggest alternative components when available
• Automatic retry mechanisms: Retry failed components and chunks with different sources
• Recovery recommendations: Provide step-by-step guidance for resolving verification issues
• Partial assembly support: Allow use of partially verified assemblies with clear warnings

Integration Requirements

I1: ValueFlows Compatibility

The system shall integrate seamlessly with existing ValueFlows resource management.

Requirements:

• Integrity metadata stored with ResourceSpecification entries
• Resource transfers include integrity verification steps
• Economic events can depend on successful verification
• Reputation systems consider verification success rates

I2: Governance Integration

The system shall respect existing governance rules and access controls.

Requirements:

• Verification operations respect capability-based permissions
• Audit trails for all verification activities
• Resource owners can set verification requirements
• Verification failures can trigger governance actions

I3: Standards Compliance

The system shall follow relevant industry standards for digital integrity.

Requirements:

• Compatibility with IOPA (Internet of Production Alliance) standards
• Support for common cryptographic standards (SHA-256, Merkle trees)
• Documentation of verification processes for compliance audits
• Extensible design for future standard updates

Performance Requirements

P1: Verification Speed

• Individual chunk verification: <100ms per chunk
• Full resource verification: <10 seconds for typical resources
• Verification report generation: <1 second
• Concurrent verification support for multiple resources

P2: Storage Efficiency

• Manifest overhead: <1% of total resource size
• Chunk size optimization for DHT performance
• Efficient data structures for verification metadata
• Minimal additional storage for verification data

P3: Network Efficiency

• Parallel chunk retrieval for faster downloads
• Optimized chunk location algorithms
• Caching strategies for frequently accessed resources
• Bandwidth-efficient verification protocols

Security Requirements

S1: Cryptographic Security

• Use industry-standard cryptographic algorithms (SHA-256)
• Proper random number generation for cryptographic operations
• Protection against collision attacks through hash algorithms
• Regular security reviews of cryptographic implementations

S2: Access Control

• Verification operations respect existing access permissions
• Audit trails for all integrity-related operations
• Protection against unauthorized modification of verification data
• Secure storage of cryptographic keys and certificates

S3: Data Privacy

• Optional encryption for sensitive resource data
• Privacy-preserving verification options when possible
• Compliance with data protection regulations
• User control over verification data sharing

Success Metrics

Technical Metrics

• Verification success rate: >99.9%
• False positive rate: <0.01%
• Verification time within performance requirements
• Resource availability with integrity guarantees

User Experience Metrics

• User satisfaction with verification process
• Trust levels in resource integrity system
• Adoption rate of verification features
• Support requests related to verification issues

Business Metrics

• Reduced disputes over resource integrity
• Increased trust in resource exchanges
• Compliance with industry regulations
• Competitive advantage through robust integrity guarantees

Technical Context (for Implementation Reference)

Storage Architecture

• File Chunking: Resources split into 64KB chunks for DHT distribution
• Content Addressing: Each chunk addressed by its SHA-256 hash
• Manifest System: Resource manifests organize chunks and provide integrity metadata
• Merkle Trees: Hierarchical hash structure enables efficient selective verification
• Component References: Manifests can reference other resource manifests as components
• Assembly Hierarchies: Support for unlimited nesting depth in resource compositions

Cryptographic Foundation

• Hash Algorithm: SHA-256 for chunk and resource verification
• Tree Structure: Merkle trees for efficient integrity proofs
• Signature Scheme: Holochain's built-in cryptographic signatures
• Validation: Multi-level verification (chunk → file → resource → component → assembly)
• Trust Propagation: Cryptographic proof chaining through component hierarchies
• Component Signatures: Individual component verification proofs that combine into assembly proofs

Composability Architecture

• Atomic Resources: Base resources with no sub-components (files, data chunks)
• Component Resources: Resources that can be used as parts of larger assemblies
• Composite Resources: Assemblies built from multiple component resources
• Assembly Rules: Constraints and requirements for valid component combinations
• Version Matrices: Compatibility rules defining which component versions work together
• Substitution Rules: Allowable component replacements with verification implications

Integration Points

• ResourceSpecification: Enhanced with component references and assembly rules
• Governance Zome: Access control and audit trail integration for component operations
• Economic Events: Verification-dependent transaction flows for component exchanges
• Reputation Systems: Agent reliability based on component and assembly verification history
• Supply Chain Integration: External manufacturer and supplier verification systems
• Standards Compliance: IOPA and other manufacturing standards for component assemblies

This requirements document provides the foundation for implementing a comprehensive digital resource integrity system that ensures trust and reliability in the nondominium resource exchange ecosystem.

Many-to-Many and Multi-Party Resource Flows (Post-MVP)

This document defines the plan and requirements for extending Nondominium beyond one-to-one custody transfers. The approach is to extend the ValueFlows model (EconomicEvent, Commitment, and related structures) to support multiple providers and multiple receivers, rather than using workarounds such as bundling pairwise events.

These requirements are post-MVP and will be developed after the first Nondominium proof-of-concept.

1. Context and Goals

1.1 Current State (MVP)

• EconomicResource has a single custodian: AgentPubKey.
• EconomicEvent and Commitment have single provider: AgentPubKey and receiver: AgentPubKey.
• Transfer patterns: Only one-to-one custody transfers are supported.
• PPR: Exactly two receipts per interaction (one per agent in the pair).

1.2 Target State (Post-MVP)

• Support one-to-one, one-to-many, many-to-one, and many-to-many custody and transfer patterns.
• Support resource pools (multiple resources under mixed regimes) transferred to one or many agents, with all current custodians of any resource in the pool required to consent.
• Support shared custody with optional weights and roles per custodian.
• Support delegation among co-custodians (e.g. one custodian holds legal responsibility or facility-management role).
• Extend ValueFlows data structures and semantics to n-ary participants; keep PPR issuance rules well-defined for multi-party flows.

1.3 Design Principle

Extend ValueFlows, do not work around it. EconomicEvent and Commitment (and any dependent types) shall be extended to allow multiple providers and/or multiple receivers where the domain requires it. Compatibility with existing one-to-one flows shall be preserved (e.g. single-provider/single-receiver as a special case).

2. Use Cases and Transfer Patterns

2.1 One-to-Many (Current Custodian Adds Co-Custodians)

• Example: Agent A is custodian of a physical space. A transfers custody so that A, B, C, D are all co-custodians (co-stewards). B, C, D can use and co-manage the space.
• Pattern: One provider (A), many receivers (A, B, C, D) or (B, C, D) if A relinquishes.
• Applies to: Shared spaces, shared digital resources (e.g. shared wallet, shared document list).

2.2 Many-to-One (All Co-Custodians Transfer to One Agent)

• Example: Agents B, C, D share custody of a CNC machine. The machine needs repair. All three must agree and co-sign a custody transfer to the repair agent R for a limited time.
• Pattern: Many providers (B, C, D), one receiver (R).
• Applies to: Repair, storage, or any handover that requires full consent of current co-custodians.

2.3 Many-to-Many (One Group Hands Over to Another Group)

• Example: B, C, D are co-custodians of a CNC in a makerspace. They transfer custody to another group E, F, G in a different makerspace, who will share responsibility. All of B, C, D agree; custody becomes E, F, G.
• Pattern: Many providers (B, C, D), many receivers (E, F, G).
• Applies to: Equipment handovers between groups, shared digital assets.

2.4 Pool Transfers (Multiple Resources, Mixed Regimes)

• Example: A pool contains resources under various property regimes. The entire pool is transferred to one agent or to a group. Every agent who is custodian or co-custodian of any resource in the pool must sign the transaction.
• Pattern: Many providers (all custodians across the pool), one or many receivers.
• Applies to: Bundled asset transfers, project handovers.

2.5 Delegation Among Co-Custodians

• Example: A physical space has co-custodians A, B, C, D. Legal responsibility (relationship with municipality or landlord) is delegated to one of them (e.g. A), not all. A can perform certain actions (sign contracts, represent to authority) on behalf of the group.
• Requirement: The system must support roles and delegation within the set of custodians so that specific actions can be restricted to a delegate without requiring every co-custodian to sign each time.

3. Plan (Implementation Phases)

Phase 1: Data Model and Shared Custody

• Extend EconomicResource or introduce SharedCustody so that a resource can have multiple custodians with optional weights and roles.
• Define ResourcePool (optional) for grouping resources for pool transfers.
• Ensure backward compatibility: resources with a single custodian continue to work as today.

Phase 2: ValueFlows Extension (Events and Commitments)

• Extend EconomicEvent to support:
  • providers: Vec<AgentPubKey> and receiver: AgentPubKey, or
  • providers: Vec<AgentPubKey> and receivers: Vec<AgentPubKey> (full n-to-m).
• Extend Commitment similarly (multiple providers, multiple receivers).
• Define validation rules: when multiple providers are present, policy may require that all (or a weighted threshold) have agreed before the event is valid.
• Keep Claim and EconomicEvent linkage clear (one Commitment fulfilled by one EconomicEvent; the event itself may be n-ary).

Phase 3: Multi-Party Consent and Execution

• Introduce multi-party consent for transfers that change custody when there are multiple current custodians:
  • Either encode consent in the Commitment/Event (e.g. list of signatories), or
  • Introduce a lightweight CustodyTransferProposal (or equivalent) that collects signatures and, when satisfied, creates the EconomicEvent and updates custody.
• Define execution semantics: when all required providers have signed, custody is updated and the event is recorded.

Phase 4: Delegation (Resource-Scoped)

• Introduce ResourceDelegation (or equivalent): which agent(s) may perform which actions on behalf of which co-custodians for a given resource or pool.
• Roles (e.g. legal_delegate, facility_manager) and optional allowed_actions.
• Governance checks: before executing an action, verify either direct custodianship or a valid delegation for that action.

Phase 5: PPR Distribution for Multi-Party Flows

• Define how Private Participation Receipts are generated when providers and/or receivers are multiple:
  • Which agents receive PPRs.
  • How to attribute responsibility (e.g. delegate vs full group, weights).
• Extend PPR structures as needed (e.g. on_behalf_of, role_context) so reputation and OVN accounting can attribute correctly.
• Ensure backward compatibility: one-to-one flows still produce exactly two PPRs as today.

Phase 6: Pool Transfers and Cross-Resource Consent

• Implement pool transfer flows: gather all custodians of all resources in the pool, require their consent, then create events and update custody for each resource (or define a single composite event type for pools).
• Define how PPRs are distributed when a pool is transferred (per resource, per agent, or aggregated as specified).

4. Requirements

4.1 Shared Custody and Weights/Roles

• REQ-MMF-01 – Multiple Custodians: The system shall support resources for which more than one agent holds custody (co-custodians).
• REQ-MMF-02 – Backward Compatibility: Resources with a single custodian shall remain supported and behave as in the current MVP (single custodian or single-member shared custody).
• REQ-MMF-03 – Weights (Optional): For resources with multiple custodians, the system shall support optional weights (e.g. shares) per custodian for responsibility, benefit, or voting.
• REQ-MMF-04 – Roles (Optional): For resources with multiple custodians, the system shall support optional roles per custodian (e.g. legal_delegate, facility_manager) to support delegation of specific actions to one or a subset of custodians.
• REQ-MMF-05 – Thresholds (Optional): The system shall support optional threshold rules (e.g. "transfers require consent of custodians representing ≥ 80% of weight") for multi-party decisions.

4.2 ValueFlows Extension (Events and Commitments)

• REQ-MMF-06 – Multiple Providers: EconomicEvent and Commitment shall support multiple providers (e.g. providers: Vec<AgentPubKey>), with single-provider as a special case.
• REQ-MMF-07 – Multiple Receivers: EconomicEvent and Commitment shall support multiple receivers (e.g. receivers: Vec<AgentPubKey>), with single-receiver as a special case.
• REQ-MMF-08 – ValueFlows Compliance: Extensions shall remain consistent with ValueFlows vocabulary and semantics; where the standard does not define n-ary flows, Nondominium shall define a minimal, documented extension.
• REQ-MMF-09 – Validation of n-ary Events: The system shall validate that all required providers (or a defined subset/threshold) have consented before an EconomicEvent involving multiple providers is considered valid and executed.
• REQ-MMF-10 – Claim-Event Linkage: Each Commitment shall still be fulfilled by at most one EconomicEvent; that event may reference multiple providers and/or multiple receivers.

4.3 Transfer Patterns

• REQ-MMF-11 – One-to-Many Transfer: The system shall support custody transfers from one agent to a set of agents (one-to-many), including the case where the original custodian remains in the set (co-stewardship).
• REQ-MMF-12 – Many-to-One Transfer: The system shall support custody transfers from a set of agents to one agent (many-to-one), requiring consent of all current custodians (or a defined threshold).
• REQ-MMF-13 – Many-to-Many Transfer: The system shall support custody transfers from a set of agents to another set of agents (many-to-many), with consent and execution semantics clearly defined.
• REQ-MMF-14 – Pool Transfers: The system shall support transfers of a pool of resources to one or more agents, where every custodian (or co-custodian) of any resource in the pool must consent (or meet a defined threshold) before the transfer is executed.

4.4 Delegation Among Co-Custodians

• REQ-MMF-15 – Resource-Scoped Delegation: The system shall support delegation of specific actions (e.g. sign contract, represent to municipality) to one or more agents on behalf of the co-custodians of a resource or pool.
• REQ-MMF-16 – Delegation Roles: Delegation shall be expressible with role labels (e.g. legal_delegate, facility_manager) and optional allowed_actions so that only delegated actions can be performed by the delegate without full co-custodian consent.
• REQ-MMF-17 – Delegation Revocation: Delegation shall be revocable; revocation shall not require changing the set of co-custodians.
• REQ-MMF-18 – Governance Check: Before executing an action that affects a resource with multiple custodians, the system shall verify that the acting agent is either a custodian or a valid delegate for that action.