ifp

Garden Patch Home · Inquiries

Group Deliberation Mechanism

Thesis

The [[Delegated Decision Authority Spectrum]] defines a “group-deliberative” zone where decisions require collective process — amending governance boundaries, establishing new protocols, publishing shared artifacts, resolving inquiry questions marked with directed_at::. But the architecture describes the philosophy (Polis Play — rules about who gets to play and what moves they can make) without specifying the mechanism.

When an LLM agent traversing the garden identifies a decision that falls in the group-deliberative zone, what does it actually do? The current guidance says “recognize, present context, frame the decision, wait.” But wait how? Through what channel? In what format? The gap between “this requires group input” and “here is how group input is gathered” remains unspecified.

Current State

The architecture currently handles this through the directed_at:: predicate on inquiry nodes, which flags questions requiring a specific person’s or group’s judgment. This is a marking mechanism, not a deliberation mechanism. It tells the agent who needs to decide but not how the decision process works.

In practice within this vault, group-deliberative decisions have not yet arisen — the garden has a single owner. The question becomes urgent when:

Open Questions

  1. What artifact does the agent produce? When an agent reaches a group-deliberative boundary, should it generate a structured proposal (context, options, recommendation, request for decision)? An agenda item? A new inquiry node with directed_at:: predicates? The output format determines how the decision enters the group’s workflow.

  2. How does the decision return to the garden? Once a group deliberates and decides, the result needs to be recorded as a decision node (or a case, if the deliberation itself is the narrative). Who writes this — the agent, the group facilitator, the gardener? What approval gate ensures the recorded decision accurately reflects the group’s intent?

  3. Does protocol form fill this gap? The architecture defines Protocol as “how independent parties coordinate reliably.” A group deliberation process is a protocol — multiple parties following agreed rules to reach a decision. Perhaps the answer is not a new mechanism but a specific protocol form documenting how deliberation works in this garden.

  4. What about asynchronous deliberation? Not all group decisions happen in real-time meetings. Some require async review (pull request model), some require voting, some require facilitated discussion. The mechanism needs to accommodate different deliberation modes without prescribing a single approach.

Sources

Relations