Regenerate Skagit: Watershed Ledger Conceptual White Paper

Introduction

The purpose of this white paper is to outline a conceptual framework for the Watershed Ledger System. Unlike traditional accounting, this system models resource flows in a regenerative, ecological, and community-centric way. It is designed to support transparency, stewardship, and participation across multiple resource types, from funds and labor to materials and knowledge.

This document expands on the core concepts introduced in the proposal, defining each term, clarifying relationships, and providing a foundation for both technical implementation and cultural adoption.

Crucially, the ledger is a write-only log of all events and contributions within Regenerate Skagit. Its power lies in transparency: everything that has happened is captured and cannot be deleted or overwritten, creating a durable record of circulation.

Longer term, the ledger could link to other watersheds, allowing flows and impacts to be visualized across multiple regions. Initiatives like Regenerate Cascadia talk about flow funding conceptually; this system documents and visualizes those flows in practice, recognizing that watersheds do not exist in isolation.

Core Concepts and Definitions

Flow Events

Definition: Flow events are the atomic unit of movement within the system. Each flow event represents a resource moving from one entity to another at a specific point in time. Shows the flow of the resources in the system.

Attributes:

• Source Entity: The origin of the flow.

• Destination Entity: The recipient of the flow; can be a person, organization, project, or pool.

• Resource Type: Money, labor, materials, food, tools, knowledge, etc.

• Quantity: Measured in appropriate units for the resource type. Predefined units.

• Timestamp: When the flow occurred.

• Narrative/Context: Optional description or story around the flow.

• Visibility: Public, group, or private (to be refined; could be replaced with role-based access or derived from entity visibility).

Notes:

• Flow events are directional but not transactional. They do not imply debt, exchange, or obligation.

• Atomicity ensures clarity and allows aggregation without losing granularity.

• Once recorded, flow events are permanent, supporting a transparent ledger.

Entities (Nodes)

Definition: The actors or containers through which flows move.

Types:

• Person: Individual contributors.

• Organization: Formal or informal groups participating in projects or resource sharing.

• Project/Event: Temporary or ongoing initiatives within the watershed.

• Pool/Account: Physical or conceptual reserves of resources, e.g., buildings, tool libraries, shared kitchens, car-sharing fleets, bank accounts.

Notes:

• Entities are first-class nodes in a directed graph.

• New entities can emerge dynamically; the system does not require predefining tributaries.

• Avoid a catch-all “Commons” label in practice; each resource should be associated with a specific entity or pool.

Pools/Accounts

Definition: Reserves of resources held for future use or sharing.

Examples: Buildings, tool libraries, shared kitchens, financial accounts, transportation fleets.

Attributes:

• Current Balance: Derived from sum of inflows and outflows.

• Resource Type: Indicates what kind of resource is held.

• Stewardship Metadata: Optional notes on intended use or stewardship plan.

Notes:

• Pools act like lakes in a watershed; they are necessary for resilience but should be monitored for stagnation.

• Stagnation is not failure but a signal for stewardship attention.

• Balances are computed from flows; the ledger itself only records movement.

Main Branches and Tributaries

Definition: Conceptual distinctions in the flow network derived from the graph of flow events.

Main Branch: Entity or pathway with high throughput and significant downstream influence.

Tributary: Entity or pathway contributing inflows to a larger branch.

Notes:

• These are emergent properties, not pre-defined.

• High-degree nodes or nodes with multiple inbound/outbound edges naturally appear as main branches or tributaries.

• The ledger itself records only flows, while tools and analytics build the graph to visualize upstream and downstream impacts.

Example Ledger Snapshot

| Flow ID | Timestamp | Resource Type | Quantity | Source Entity | Destination Entity | Narrative |

| ------- | ---------- | ------------- | -------- | ---------------- | ------------------ | ------------------- |

| 001 | 2026-03-01 | Hours | 5 | Volunteer Team A | Community Garden | Prep soil beds |

| 002 | 2026-03-01 | Plants | 30 | Nursery Pool | Community Garden | Native seedlings |

| 003 | 2026-03-02 | Dollars | 500 | Community Fund | Tool Library | Purchase hand tools |

| 004 | 2026-03-03 | Meals | 20 | Kitchen Pool | Workshop Event | Shared lunch |

This example illustrates how flows capture movement between entities and pools and remain permanent entries for transparency.

API Concept Sketch

The ledger system exposes an API for reading flows and retrieving entity information, supporting both integration and analytics.

GET /ledger

Purpose: Retrieve flow events.

Query Parameters (optional):

• timeframe_start, timeframe_end

• pool_uuid

• resource_type_slug

• entity_uuid (source or destination)

Response:

[ { flow_id, timestamp, resource_type, quantity_value, quantity_string, from_entity, to_entity, notes } ]

POST /flow

Purpose: Record a new flow event.

Payload:

{

	 from: UUID,

	 to: UUID,

	 resource_type: "__SLUG__",       // Human-readable identifier

	 quantity_string: "Unit description",

	 quantity_value: number,           // e.g., hours, dollars

	 timestamp: ISO8601,

	 notes: string,

	 visibility: string               // TBD, could be refined or replaced by derived access rules

}

GET /entity/{UUID}

Purpose:* Retrieve entity details and related flows.

Response:

{
	 uuid: string,
	 details: { ... },
	 latest_flows: [ ... ],
	 aggregated_metrics: { velocity, inflow, outflow, diversity, etc. },
	 connections: [ { entity_uuid, total_flows, resource_types } ]

}

Notes

• Visibility is a sensitive concept; consider replacing explicit visibility with role-based access or derived permissions based on entity associations.

• OpenAPI specification is recommended for formalizing endpoints, payloads, and data types.

• All POST operations append to the ledger; no modification or deletion is allowed.

• GET endpoints are read-only and support analytics and graph building.

Implementation Considerations

• Directed Graph Structure: Nodes represent entities; edges represent flow events.

• Derived Graphs and Analytics: Tools build the network from the ledger to visualize upstream and downstream impacts, including inter-watershed flows.

• Derived Balances: Pools calculate current reserves from flows; the ledger itself does not track balances directly.

• Flexible Schema: Resource types and entities can be added without changing core schema.

• UI Design: Quick-add modals, smart defaults, and minimal required fields to support field teams.

Expected Outcomes

• Durable, permanent log of all flows in the watershed.

• Clear visibility of resource movement and circulation within and across watersheds.

• Emergent understanding of main branches and tributaries.

• Identification of stagnant pools for stewardship intervention.

• Cultural reinforcement of generosity and collaboration.

• Tools and visualizations built on top of the ledger highlight upstream and downstream impacts regionally.

Next Steps

1. Align the team on conceptual definitions.

2. Identify core entities and resource types for initial tracking.

3. Prototype schema for flow events, entities, and pools.

4. Develop basic UI for quick contribution logging.

5. Build graph-based visualizations to analyze flows and impacts, including inter-watershed connections.

6. Formalize the API using OpenAPI specifications.

7. Iterate based on field testing and feedback.