ARSENIJE.GARDEN
Case Study 02 — Product & Systems Design

HYPHA

Designing modular governance as a fractal system: each space carries its own agreements, members, and treasury — and the same pattern can repeat at every scale.

Role Product & Organizational Systems Designer
Type Governance / coordination platform
Focus System architecture, workflows, roles, permissions
Period 2022–2025
01 — Problem

Decentralization creates a design problem: where does governance live?

Traditional organizations concentrate many governance functions in managers, departments, policies, and central administration. When those structures are removed or distributed, the work does not disappear.

Groups still need to know who belongs, what has been agreed, how resources are held, how decisions are made, and how participation can end.

The product challenge was to make those functions explicit without recreating a single central authority — and without forcing every group to invent governance from scratch.

The core question became: what is the smallest complete unit of governance that can repeat?
02 — Core model

A space is the basic governance cell.

Instead of treating governance as one organization-wide layer, I modeled it as a repeatable unit. Every space contains the same three core primitives: agreements, members, and treasury.

01

Agreements

What is this space for? What rules, commitments, and boundaries define participation?

+
02

Members

Who belongs here? What roles, rights, responsibilities, and permissions do they carry?

+
03

Treasury

What resources does this space steward, and under what authority can they move?

Repeatable primitive

SPACE

A bounded governance context with its own agreements, membership, resources, and decision process. A space can also contain other spaces.

03 — Fractal structure

The same governance pattern can exist at every scale.

A project team, working circle, local chapter, or whole organization can each be represented as a space. The structure does not change when the scale changes; only the context does.

Organization space
Team space
Project space
agreements
members
treasury
01 — Local autonomy

Govern close to the work

Each space can define its own operating context rather than inheriting every decision from a central layer.

02 — Shared grammar

Repeat the structure, not the rules

Spaces share a common product model while their agreements and participation conditions can differ.

03 — Composability

Spaces can contain spaces

Governance becomes modular: smaller units can be nested inside larger contexts without losing their own identity.

04 — Participation lifecycle

Every space needs a clear way to enter, decide, and exit.

The next step was to model participation as three reusable modules. These modules give each space a complete lifecycle rather than treating membership as a static permission.

Module 01

Enter

Make the boundary of the space explicit: what someone needs to understand, accept, or receive before becoming a member.

Discover / invite01
Read agreements02
Request / accept03
Membership created04
Module 02

Decide

Give members a legible path for turning an issue into a recorded decision without hiding who has authority.

Raise / propose01
Context / deliberate02
Decide03
Record / enact04
Module 03

Exit

Treat leaving as a designed transition: clarify obligations, permissions, resources, and what remains in the shared record.

Initiate exit01
Resolve commitments02
Settle access / resources03
Membership closed04
05 — Decision architecture

A decision is a stateful object, not just a vote.

The decision module makes the path from question to consequence visible. Rather than starting with a voting interface, the system begins with the lifecycle of a decision.

01

Signal

02

Proposal

03

Deliberation

04

Decision

05

Effect / record

The design principle: make authority and consequence visible before adding participation mechanics.
06 — Product principles

Design governance as infrastructure, not ceremony.

01

Local rules, shared grammar

Different spaces can govern differently while remaining understandable through the same product structure.

02

Membership is a relationship

Joining a space creates rights, obligations, permissions, and access — not just a user record.

03

Treasury follows authority

Resource movement should be legible in relation to who can decide, under which agreement, and on behalf of which space.

04

Exit is part of governance

A system is incomplete if it explains how people join and decide but not how responsibilities and permissions end.

Suggested portfolio visual 01
SPACE OVERVIEW

Add the strongest UI / prototype showing:
agreements · members · treasury · child spaces
This should become the primary product screenshot: one page that makes the governance model immediately understandable.
Suggested portfolio visual 02
DECISION MODULE

Proposal → context → authority → decision → record
Use annotations to show how product state and decision authority are made visible.
07 — Product model

Translate governance language into product entities.

A key design move was making the organizational model concrete enough to become software. The conceptual product model can be expressed through a small set of related entities.

Space
The governance context. Can belong to / contain other spaces.
Agreement
The explicit commitments, purpose, rules, or boundaries associated with a space.
Membership
The relationship between a person and a space, including role, status, and permissions.
Treasury
Resources stewarded by a space, connected to the authority required to move them.
Decision
A stateful record of an issue, proposal, decision path, outcome, and effect.
08 — Outcome & learning

The product became a grammar for composing governance.

The value of the model was not a single governance recipe. It was the ability to compose different governance contexts from the same understandable primitives.

The fractal structure creates a bridge between autonomy and coherence: each space can remain locally specific while still fitting into a larger system that people can navigate and understand.

The broader lesson for my product practice was that complex organizational behavior becomes designable when hidden relationships — membership, authority, resources, commitments, transitions — become explicit product objects.

Before publishing: add only verified implementation evidence. Useful additions could include which parts were prototyped or shipped, how many organizational contexts used the model, user/research feedback, team size, or one concrete governance workflow that improved because of this architecture.
Previous case study

BOXSPOT