Document Type: High-Level Requirements Version: 1.0 Last Updated: 2026-02-12 Related Documents:
This document defines the high-level requirements for bridging traditional Enterprise Resource Planning (ERP) systems with Nondominium's peer-to-peer resource-sharing infrastructure. The goal is to enable organizations using centralized ERP systems to participate in decentralized resource economies without abandoning their existing business infrastructure.
Key Principle: The bridge is designed as a reusable, ERP-agnostic Protocol Bridge that can serve multiple ERP systems (ERPLibre, Dolibarr, ERPNext, etc.), while ERP-specific integration logic resides in dedicated modules for each platform.
Organizations currently manage their inventory, equipment, and resources using centralized ERP systems (e.g., Odoo, SAP, ERPNext). While these systems excel at internal management, they create data silos that prevent resource sharing across organizational boundaries.
Current limitations:
| Limitation | Impact |
|---|---|
| No cross-organizational visibility | Organization A cannot see if Organization B has idle equipment that could be borrowed |
| Trust barriers | Ad-hoc resource sharing requires manual coordination, legal contracts, and trust-building overhead |
| Platform dependency | Centralized marketplaces extract rent and control access |
| Data sovereignty concerns | Organizations are reluctant to upload sensitive inventory data to third-party platforms |
Nondominium offers a peer-to-peer, organization-agnostic resource-sharing layer that can complement existing ERP systems:
- Resources can be selectively published from ERP inventory to Nondominium without migrating away from the ERP
- Organizations retain full sovereignty over their data and participation
- Reputation tracking (PPR system) replaces heavy legal contracts with cryptographic accountability
- Emergent coordination via stigmergy reduces the need for manual negotiation
- Enable Cross-Organizational Resource Discovery: Allow organizations to discover available resources from other organizations through Nondominium's DHT network
- Preserve Data Sovereignty: Organizations maintain full control over which resources they share and with whom
- Minimize Integration Overhead: Provide a simple, non-invasive bridge that doesn't require modifications to ERP core code
- Support Multiple ERPs: Design a reusable protocol bridge that works with any ERP system
| Criterion | Measure |
|---|---|
| Integration simplicity | Bridge deployable as separate service/container |
| Non-invasiveness | Zero modifications to ERP core code |
| Cross-org discovery | Resources from Org A visible to Org B within 1 minute of publication |
| Data mapping accuracy | 100% of ERP product data maps correctly to Nondominium format |
| Accountability | All resource transactions generate verifiable PPRs |
In this architecture, the organization is the Holochain agent, not individual end-users. This differs from typical Holochain applications where each person runs their own node.
Key distinctions:
| Aspect | Individual Agents (Typical Holochain) | Organization Agents (ERP Bridge) |
|---|---|---|
| Node operator | End-user | Organization's IT infrastructure |
| Identity | Personal keypair | Organizational keypair |
| End-user access | Direct to conductor | Mediated via ERP |
| Key management | User responsibility | IT administration |
| PPR accountability | Individual reputation | Organizational reputation |
- Organizational sovereignty: The organization controls its participation in the network
- Existing authentication: ERP handles employee authentication/authorization
- Single source of truth: One agent key per organization, not hundreds
- Operational simplicity: IT manages one node, not per-employee nodes
- PPR accountability: Reputation tied to organization, matching business relationships
The end-user delegates their participation to the organization. The organization is the accountable party in the peer-to-peer network.
End-user (employee)
│
│ Trusts organization (employment relationship)
▼
Organization's ERP System
│
│ Authenticates & authorizes actions
▼
Organization's Holochain Agent
│
│ Cryptographically signs all DHT actions
▼
Nondominium Network
│
│ PPR tracks organizational reputation
▼
Other Organizations
Nondominium's foundational identity layer is the zome_person zome, which separates cryptographic agent identity (Holochain AgentPubKey) from human/organizational identity (Person profile). As the base layer upon which resource management and governance are built, it is important for the ERP bridge because:
- Person profiles hold public metadata (name, bio, avatar) and private data (legal name, email, phone) — separate from the Holochain agent key
- Roles (
RoleType) define capability levels that gate governance actions:SimpleAgent→AccountableAgent→PrimaryAccountableAgent, plus specialized roles (Transport,Repair,Storage) - Capability-based sharing allows selective disclosure of private data to other agents, with time-limited grants (max 30 days)
- Multi-device support allows multiple Holochain agents (devices) to map to a single Person identity
- Cross-zome validation —
zome_gouvernancecallszome_personto validate agent identity before custody transfers and promotions
Capability Levels (derived from roles):
member— default for all agents (SimpleAgent)stewardship— Transport, Repair, Storage specialized rolescoordination— AccountableAgent (validated identity + first resource)governance— PrimaryAccountableAgent (highest authority)
Note: The Python bridge does not yet include a
zome_personmodule. As the foundational identity layer of Nondominium, bridgingzome_personis a priority for the next iteration. Until then, Person profile creation and role assignment must be done directly via Holochain or hc-http-gw. This is a prerequisite for end-to-end testing of custody transfers and agent promotion workflows.
| ID | Requirement | Priority | Description |
|---|---|---|---|
| FR-1 | Read ERP Inventory | Must Have | Read inventory data from ERPLibre via its API |
| FR-2 | Map to ResourceSpecification | Must Have | Map ERPLibre products to Nondominium ResourceSpecification entries |
| FR-3 | Publish EconomicResource | Must Have | Publish selected inventory items as EconomicResource entries in Nondominium |
| FR-4 | Discover Resources | Must Have | Query Nondominium for available resources from other organizations |
| FR-5 | Initiate Use Process | Done | Initiate a Use process in Nondominium for a discovered resource. Implemented via propose_commitment in zome_gouvernance. Bridge support: bridge/use_process.py |
| FR-6 | Record Events & PPRs | Done | Record the EconomicEvent and generate PPRs for both parties. Implemented via log_economic_event and issue_participation_receipts in zome_gouvernance. Bridge support: bridge/gateway_client.py |
For the current implementation status of each requirement, see Implementation Architecture — Section 6.
Summary: FR-1 (partial — mock ERP + Odoo addon in external repo), FR-2 (done), FR-3 (done), FR-4 (partial — discover_all() is a stub), FR-5 (done — bridge + zome), FR-6 (done — bridge + zome).
| ID | Requirement | Priority | Description |
|---|---|---|---|
| FR-7 | Person/Agent Identity Management | Should Have | Create and manage Person profiles, assign roles, and validate agent identity via zome_person. Prerequisite for custody transfers and agent promotion. |
| FR-8 | Bidirectional Sync | Should Have | Changes in Nondominium reflected back to ERP |
| FR-9 | Real-time Signals | Should Have | Push notifications for resource requests |
| FR-10 | Governance Rules | Could Have | Organizations set access rules via ERP UI |
| FR-11 | PPR Dashboard | Could Have | Display reputation scores in ERP |
| FR-12 | Multi-ERP Support | Should Have | Support for Dolibarr, ERPNext, etc. |
| ID | Requirement | Description |
|---|---|---|
| NFR-1 | Non-invasive Integration | The bridge should not require modifications to ERPLibre core code |
| NFR-2 | Containerized Deployment | The bridge should be deployable as a separate service/container |
| NFR-3 | Periodic Sync Acceptable | Real-time synchronization is not required (periodic sync is acceptable for PoC) |
| NFR-4 | Unidirectional Sync (PoC) | ERP → Nondominium sync only (bidirectional is a future requirement) |
| ID | Requirement | Description |
|---|---|---|
| NFR-5 | Security | Agent keys never exposed; all signing server-side |
| NFR-6 | Scalability | Support for 100+ concurrent organizations |
| NFR-7 | Reliability | 99.9% uptime for bridge service |
| NFR-8 | Performance | Resource discovery < 2 seconds |
- ERPLibre inventory reading via XML-RPC API (mock ERP for PoC; Odoo addon in external repo)
- Product → ResourceSpecification mapping
- Stock → EconomicResource mapping
- Cross-organizational resource discovery
- Custody transfer between organizations
- Use process initiation (commitments via
zome_gouvernance) - Economic event recording and PPR generation (via
zome_gouvernance) - HTTP Gateway (
hc-http-gw) as protocol bridge
| Item | Reason |
|---|---|
| Complex governance rules enforcement | Requires additional Nondominium features |
| Financial transactions or invoicing | Outside core resource-sharing scope |
| Multi-warehouse scenarios | Adds complexity beyond PoC needs |
| Full PPR reputation dashboard | UI enhancement for production |
| Multi-ERP support (Dolibarr, ERPNext) | PoC focuses on ERPLibre only |
| Real-time signals/webhooks | Requires Bun bridge (production) |
| ERP Concept | Nondominium Concept | Notes |
|---|---|---|
| Product Template | ResourceSpecification |
Defines what can be shared (uses category, tags, image_url, is_active) |
| Product Variant | EconomicResource |
Specific instance available for sharing (uses spec_hash, current_location, custodian, state) |
| Stock Location | Resource current_location field |
Where the resource is physically located |
| Available Quantity | quantity in EconomicResource |
How much is available |
| Stock Move | EconomicEvent (Transfer, Use) |
Mapped via log_economic_event in zome_gouvernance |
| ERPLibre Model | Purpose | Mapped To |
|---|---|---|
product.product |
Individual products | ResourceSpecification + EconomicResource |
stock.quant |
Available quantities per location | quantity field |
stock.move |
Movement history and planned transfers | EconomicEvent via log_economic_event |
stock.warehouse |
Physical locations | current_location field |
Demonstrate that inventory from two organizations running ERPLibre can be synchronized to Nondominium and made discoverable for sharing.
- Organization A has a 3D printer listed in its ERPLibre inventory
- Organization B has a laser cutter listed in its ERPLibre inventory
- Both organizations publish their available equipment to Nondominium
- Each organization can discover the other's equipment via Nondominium
- Organization B requests use of Organization A's 3D printer via
propose_commitment - The usage is recorded as an
EconomicEventin Nondominium vialog_economic_event, with PPR generation - (Future) The usage is reflected back to Organization A's ERPLibre as a "Loan" or "External Use" stock move
| Criterion | Verification Method |
|---|---|
| Products correctly mapped | Compare ERP data with Nondominium entries |
| Cross-org discovery works | Org B can see Org A's resources |
| Use process proposes commitment | Verify Commitment in DHT via propose_commitment |
| Use process records event | Verify EconomicEvent in DHT via log_economic_event |
| PPRs generated | Both parties have participation receipts via issue_participation_receipts |
Goal: Rapid prototyping using hc-http-gw
- Timeline: 4 weeks
- Protocol Bridge: hc-http-gw (pre-built HTTP gateway)
- Sync: Unidirectional (ERP → Nondominium)
- Real-time: No (periodic polling)
- ERP: ERPLibre only
Goal: Full-featured production deployment
- Protocol Bridge: Bun with
@holochain/client - Sync: Bidirectional
- Real-time: Yes (signals + webhooks)
- ERP: ERPLibre + Dolibarr + ERPNext
Goal: Enhanced capabilities
- ML-powered PPR scoring
- AI resource matching
- Predictive analytics
- Native Python client (if ML/AI becomes central)
| Term | Definition |
|---|---|
| AgentPersonRelationship | Many-to-many mapping between Holochain agents and Person profiles (supports multi-device) |
| DHT | Distributed Hash Table - the peer-to-peer data storage layer in Holochain |
| EconomicEvent | A ValueFlows concept representing an observed economic action |
| EconomicResource | A ValueFlows concept representing a specific instance of a resource |
| hc-http-gw | Holochain HTTP Gateway - exposes zome functions as REST endpoints |
| Person | A public identity profile in zome_person (name, bio, avatar) — distinct from the cryptographic Holochain agent |
| PersonRole | A role assignment linking a Person to a RoleType with capabilities |
| PPR | Private Participation Receipt - cryptographic proof of economic participation |
| ResourceSpecification | A ValueFlows concept defining the characteristics of a type of resource |
| RoleType | One of 6 role variants: SimpleAgent, AccountableAgent, PrimaryAccountableAgent, Transport, Repair, Storage |
| Zome | A Holochain module containing application logic |