ARSENIJE.GARDEN
Case Study 03 — Product / Systems / Software Design

RHIZOME NODE

Designing an organizational memory and sensing substrate that helps groups coordinate without concentrating context, judgment, and decision-making in managers.

Role Founder / Product & Systems Designer
Type Coordination infrastructure / organizational software
Focus Product model, software architecture, organizational memory
Status Early-stage / prototyping
01 — Problem

Managers often become the hidden database of the organization.

In many teams, critical coordination capacity is concentrated in a small number of people. They remember why decisions were made, know who owns what, sense emerging tensions, connect context across projects, and decide what deserves attention next.

When organizations try to distribute authority without distributing those capacities, the result is often not autonomy but ambiguity, duplicated work, invisible dependencies, and renewed dependence on founders or managers.

Rhizome Node explores a different approach: make the organizational memory and coordination substrate explicit enough that the group can carry more of it together.

The product question: what information and coordination capacities must become infrastructure if management is no longer a person?
02 — Unbundle the manager

The role is a bundle of capacities, not a single function.

Rather than treating hierarchy as only command and control, I decomposed the managerial role into capabilities that a self-governing group still needs.

01

Sensing & context

What is happening? What changed? What signals matter now?

02

Authority & ownership

Who can act, decide, commit resources, or represent the group?

03

Prioritization & coordination

What matters next, and how do dependent efforts stay coherent?

04

Memory & accountability

What was decided, why, by whom, and what happened afterward?

03 — Product model

A shared substrate for seeing, remembering, and coordinating.

Rhizome Node is conceived as the infrastructure underneath a group's day-to-day coordination. It does not replace human judgment. It makes the information needed for judgment more visible, persistent, and queryable.

Organizational
memory as infrastructure

Events, decisions, responsibilities, tensions, commitments, and relationships become structured objects rather than fragments spread across meetings, chats, documents, and individual memory.

01

Observe

02

Structure

03

Connect

04

Query

05

Act

04 — Core objects

Turn invisible coordination into explicit product objects.

The system starts from a small number of durable objects that can be connected into a living map of the organization.

Field object
A generic unit of organizational context: issue, signal, tension, proposal, commitment, role, decision, resource, or relationship.
Why it matters: creates a shared primitive that different coordination tools can build on.
Node
A structured object with identity, attributes, history, and connections to other objects.
Why it matters: lets context accumulate instead of disappearing into documents or chat threads.
Relationship
A typed connection: owns, depends on, affects, decided by, belongs to, blocked by, informed by.
Why it matters: reveals dependencies and authority that are often implicit.
Event / change
A timestamped update to an object or relationship.
Why it matters: creates organizational memory and makes change inspectable over time.
05 — Coordination loop

The node supports a loop, not a one-shot query.

The system is designed around a recurring coordination loop: capture signals, connect them to existing context, surface relevant patterns, and support a human decision or action that becomes new shared memory.

Sense
Decide
Remember
Coordinate
Shared
context
01 — Sense

Capture what changed

New information enters as structured signals rather than remaining trapped in conversation.

02 — Orient

Connect it to context

Relationships reveal what the signal affects, who is involved, and what prior decisions matter.

03 — Act

Support judgment

The system surfaces relevant context; people still make consequential choices.

04 — Learn

Make action become memory

Decisions, outcomes, and changed responsibilities become part of the shared record.

06 — Software architecture

AI is an interface to the memory, not the owner of it.

A core architectural principle is that the organization's knowledge remains in an explicit data model. An AI layer can interpret requests, retrieve context, propose operations, and explain patterns — but the underlying memory and permissions stay inspectable outside the model.

Input

Human request

Question, update, decision, or coordination need.

Interpreter

Local / connected AI

Understands intent and proposes which tools or queries are needed.

Capability

Rust functions

Typed operations for reading, writing, linking, validating, and querying data.

Memory

Rhizome Node

Structured objects, relationships, history, permissions, and organizational state.

Result

Human-visible action

Answer, map, proposed change, or a confirmed operation.

Principle: tools should extend agency, not replace it. The AI helps navigate the system; authority remains explicit and human-governed.
07 — Product principles

Design for sovereignty, legibility, and distributed judgment.

01

Memory should outlive the manager

Critical context belongs to the group, not to whoever happens to remember it.

02

Authority must be queryable

People should be able to see who can decide or act without relying on informal lore.

03

AI cannot become hidden management

Recommendations and tool use should remain inspectable rather than silently substituting machine judgment for human authority.

04

Mismatch is a diagnostic

When stated roles, actual decisions, resource flows, and lived responsibility diverge, the system should help make that difference visible.

Suggested portfolio visual 01
ORGANIZATIONAL MAP

Show nodes + relationships:
roles · decisions · tensions · commitments · resources
The strongest visual here would show how invisible organizational context becomes navigable.
Suggested portfolio visual 02
QUERY / AGENT INTERFACE

“What changed this month?”
→ tool calls → evidence → proposed action
Show that AI retrieves and acts through explicit capabilities rather than owning the source of truth.
08 — Build path

Start with the substrate, then layer intelligence on top.

The implementation path is intentionally incremental: first create a durable object model, then storage and query, then higher-level coordination tools and AI-assisted workflows.

P0
FieldObject
Define the smallest useful organizational primitive.
P1
Node + relationships
Give objects identity, history, attributes, and typed connections.
P2
Storage + query
Persist the group's memory and make it inspectable.
P3
Coordination instruments
Diagnostics, authority mapping, decision composition, and tension protocols.
P4
AI tool loop
Natural-language access to typed capabilities without making the model the source of truth.
09 — Outcome & direction

The goal is not smarter management. It is more distributed capacity to self-govern.

Rhizome Node reframes organizational software from a system that reports upward into a system that helps context circulate across the group.

The deeper product hypothesis is that groups become less dependent on managerial hierarchy when the capacities hierarchy was carrying — memory, sensing, authority, prioritization, coordination, and accountability — become visible, learnable, and shared infrastructure.

The work is still early. The value of the case study is the product architecture: a clear model for turning organizational dynamics into software without collapsing judgment, authority, or responsibility into the software itself.

Before publishing: add verified build evidence. Good additions: current Rust repository status, implemented objects/functions, tests, CLI screenshots, example queries, prototype videos, or one real organizational workflow modeled end-to-end.
Previous case study

HYPHA