Name the Interface; Compose the Commons

How four simple interfaces connect diverse systems

I started my life’s work as a teenager in computer science, where “interfaces” were the handshake between modules and humans - the menus you click, the functions you call. As I branched into high energy physics, I met a different interface: operators and generating functions transforming states through space and time. Later, in econophysics and then at Grassroots Economics, I realized these worlds all rhyme: once you can name the interface, you can compose very different parts into working wholes.

That’s the entire point of commitment pooling. It’s not a system to adopt; it’s a protocol any system can speak; a shared language for coordination with four minimal interfaces. When the interfaces are explicit, buses, gift cards, unpaid invoices, energy delivery, trade credit, savings circles, city services, and digital vouchers stop being siloed “programs” and become composable components of a broader commons.

“Write programs to work together… using a universal interface.” - Doug McIlroy (Unix philosophy)

Remember as well simplicity in the previous article:

“Simplicity is prerequisite for reliability.” - Edsger W. Dijkstra

Simple, clear, shared interfaces let independent parts plug together. This is exactly why naming interfaces between systems / commons unlocks composability.

n.b. Composability is a system design principle where a complex system is built by combining smaller, interchangeable components that can be assembled in various combinations to create different solutions

n.b. A commitment is a redeemable promise: who will deliver what (unit/quantity) to whom, when/where, and under what proof and fallback. In practice it’s recorded as a voucher/token on a ledger (paper or digital) with clear metadata (issuer, scope, unit, quantity, window, location/channel, proof-of-fulfillment, expiry, reissuance/revocation policy, and guarantor/backstop). The commitment pooling protocol enables interoperability between commitments within a pool and among pools.

four minimal stewardship functions → four minimal protocol interfaces

Before we tour real-world examples, hold this map in your head.

• Curation → Commitment Registry: List/delist vouchers; set clear redemption terms and metadata.

• Valuation → Value Index Registry: Define pricing/units (static table, oracle feed, or governance rule).

• Limitation → Swap Limiter: Set per-voucher/account/global caps & windows; prevent runs/arbitrage; shape flow.

• Exchange → Treasury (seed/swap executor, with optional fees): Custody assets; execute seed/swap and fees only if curation, valuation, and limitation checks pass; emit immutable receipts.

This is both human and technical:

stewards exercise Curation/Valuation/Limitation/Exchange;

digital or non-digital ledger systems expose the matching registries, indices, limiters, and a treasury that enforces them.

Peter Salus (on Unix): “Write programs that do one thing well; write programs to work together.”

Specialize the module (your system), standardize the interface; systems and communities can mix and match when those interfaces are explicit.

What is an “interface,” really?

For people: it is generally how you tell a system what you want - forms, tickets, Ledger pages, a phone number to call, a button. For machines: it’s an explicit agreement - these fields, this function, that receipt.

In our context, the “thing” moving through interfaces is a commitment - a clearly specified, redeemable promise that can be represented formally as a gift card/voucher/token.

In both cases, an interface sets expectations. If I can recognize “this is the registry,” “that is the index,” “here are the limits,” “there’s the treasury,” I know how to plug in - no matter whether the medium is paper, a spreadsheet, or a smart contract.

“Modules hide (complex) decisions; their interfaces reveal as little (minimal) as possible (needed for communication).” David Parnas

Strong boundaries don’t block composition - they enable it; once the interface is named, implementations can vary and still connect.

Seeing the interfaces in the wild

Let’s walk through some familiar contexts. In each, we’ll point to the four functions and show how the “pool” is already there—sometimes in paper form, sometimes digital. The lesson: different systems can speak the same protocol.

In each example below, first spot the commitment (the redeemable promise), then the four interfaces that make it composable.

1) Mutual credit (net-to-zero balances)

• Commitment: member accepts X units against future provision up to limit L within window W.”

• Curation / Registry: Who’s in the circle? On paper or a ledger, members are listed with terms (limits, role).

• Valuation / Index: Unit of account (often 1 unit = 1 national currency unit or 1 hour).

• Limitation / Limiter: Per-account credit/debit ceilings, velocity windows.

• Exchange / Treasury: The ledger (book or software) that posts debits/credits and issues receipts; settlement is the posting itself.

Composition: Mutual credit plugs into other pools when its unit and limits are mapped. A city service (bus rides) can accept MC units if the index and limits are respected. Now you can route: MC → bus tokens, MC → food vouchers, etc.

For a deeper dive on mutual credit go here:

2) Savings-and-loan group (even with paper books)

• Commitment: group redeems shares/loans per schedule and rules.

• Curation: Member roll and share schedule written in the book.

• Valuation: Share price (often fixed per meeting), interest rules.

• Limitation: Loan caps (e.g., up to 3× shares), delinquency windows.

• Exchange: The cash box and the ledger: contributions, loans, repayments, fines—each with a receipt line.

Composition: You can treat the group as a pool that issues a voucher - a claim on future cash at a schedule. A municipal transit pool could accept those vouchers at a discount if limits/index are mapped (or the group buys transit vouchers as treasury assets). That’s interface-level interop - no stack wars required.

3) A simple personal loan

• Commitment: borrower repays principal/interest by date—proof is payment receipt; fallback may be collateral.
  Curation: The loan contract: parties, amount, maturity.

• Valuation: Principal/interest schedule or discount rule.

• Limitation: Collateral terms, payment windows, late caps.

• Exchange: Disbursement and repayment events, with receipts.

Composition: Wrap the loan as a voucher (“repay X by date Y”) listed in a pool. A neighborhood pool can buy a slice (with limits), converting a private obligation into a community-backed, rate-limited claim that can swap for other vouchers (e.g., energy credits) via the shared index.

4) A city public service with bus routes

• Commitment: Agency delivers N rides of class C within zones Z and dates D.

• Curation: Published routes and fare classes (student, senior, monthly).

• Valuation: Fare table or dynamic pricing.

• Limitation: Per-pass daily ride caps, transfer windows, fraud throttles.

• Exchange: Validators, tap-ins/out, and the city treasury settling pass usage.

Composition: A bus pass is a voucher. Once listed in a pool, it can be swapped for food or care vouchers via an agreed index. A savings group could seed a pass inventory; a housing commons could accept unused pass value as partial rent in a mapped window. Interfaces make this safe (limits), fair (index), and auditable (receipts).

5) Credit clearing among SMEs

• Commitment: participant honors netted obligations in unit U under exposure caps.

• Curation: Network membership and trust policies.

• Valuation: Unit-of-account (e.g., “1 = 1 GBP”), netting rules.

• Limitation: Per-account exposure caps; sector or bilateral gates.

• Exchange: The clearing engine nets chains and posts receipts.

Composition: Clearing systems are already a pool: listed participants, unit, limits, settlement. Add a food voucher pool with its own index and caps; now a restaurant can route its cleared credit into staple vouchers within policy windows - stabilizing cashflow without new debt.

6) Use-Credit Obligations (UCOs)

• Commitment: issuer delivers kWh/m²-month within redemption window; backstopped by revenue/escrow

• Curation: Issuer lists redeemable units (kWh, m²-month) with clear terms.

• Valuation: Denominated in “stuff,” optionally indexed to money for swaps.

• Limitation: Issue caps, per-holder caps, redemption windows.

• Exchange: Treasury escrows revenue/assets and honors redemptions, logging receipts.

Composition: UCOs are native to commitment pooling. They swap cleanly with mutual credit or clearing balances once units/indices are mapped and rate limits applied. Housing UCOs ↔ energy UCOs ↔ transit passes is just routing across named interfaces.

7) Ancient Mweria (ROLA) reciprocity

• Commitment: household supplies one day of labor in season S; witnessed by community as proof.

• Curation: Clan or neighborhood names who owes whom labor/harvest.

• Valuation: Days of work, seasons, or portions of yield as the unit.

• Limitation: Seasonal windows, age/ability norms, rotation rules.

• Exchange: Work parties and harvest sharing—each event witnessed and recorded in memory or marks.

Composition: Formalize Mweria as vouchers (“1 day dry-season labor”). A community pool lists them, sets seasonal windows and max draws, and a treasury logs fulfillment. Those vouchers can swap for school-meal vouchers if the index and caps are agreed. Tradition becomes legible to other pools—without losing its character.

In composable architecture components with well-defined interfaces can communicate and exchange information. (here that is value)

Whether it’s mutual credit, UCOs, or transit passes, composability is a property of the interface, not the tech stack (blockchain, programming language etc.)

Why naming matters (and what it unlocks)

When we argue “systems,” we get stuck in brand, stack, and ideology. When we name interfaces, we get movement!!!! :

• Discoverability: People can point and say, “Here’s what we value … here’s our registry; here are our limits.”

• Safety: Limits and receipts become first-class; runs and ambiguity get tamed.

• Interoperability: Different implementations can route value because the agreements are clear.

• Governance clarity: Stewardship verbs map to concrete controls; audits have places to look.

Here is the punchline:

If you can name the interface, you can compose it!

Put the stewardship verbs (Curation, Valuation, Limitation, Exchange) on the page, map them to their interfaces, and interoperation stops being theory and becomes practice.

From translation to routing: how pools talk

Pools can connect directly if they list a common voucher or share a reference index. If not, a tertiary pool can bridge - holding assets from each side and enforcing both sets of limits. Because each hop respects Curation → Valuation → Limitation → Exchange, multi-hop routes remain safe and auditable.

“Interfaces reveal only what’s necessary.” David Parnas (again)

That’s why a small town’s paper ledger can still interoperate with a city’s smart-card treasury and even national currency systems safely - if both expose the four functions clearly.

A language

Commitment pooling is a minimal protocol. It doesn’t compete with your favorite system; it names the four touchpoints that let all resource coordination systems collaborate. The work ahead is cultural as much as technical: helping communities recognize their existing registries, indices, limiters, and treasuries (sometimes on paper, sometimes on chain) and then composing them into a interoperable commons.

When we do, everything familiar (mutual credit, savings circles, public services, credit clearing, UCOs, even Mweria) becomes legible to everything else. And cooperation stops being a hope and starts being an common interface.

Again let’s take the great Dough McIlroy to heart:

“Write programs to work together… using a universal interface.”

Name the simplest interface, honor the practice

- then let our commons meet, translate, and move together.

~*~

For engineers: treat commitment pooling as an interface-first protocol, not a product - expose four minimal surfaces (registry, value index, limiter, treasury/settlement) with clear voucher metadata, deterministic pricing, enforceable rate limits/windows, and immutable receipts; make them composable (separable modules, stable APIs, audit logs, idempotent ops), and you can route value across very different systems without stack lock-in. For a reference implementation and patterns that put this into practice (contracts, services, and ops glue), see the example stack at http://software.grassecon.org/ also check out this wallet project!

Sarafu Wallet - Development Announcement