KIBBUTZNIK

→ → →

A Community is the fundamental governance unit. It has members, proposals, pulses, variables, statements, and artifact containers.

Actions are child communities created via AddAction proposals. They function as working groups — each with its own members, governance cycle, and productive work.

Key rule A member thrown out of the parent is automatically removed from all descendant actions, recursively.

Unlimited depth Actions can create sub-actions, which can create sub-sub-actions, and so on — as deep as the community needs.

→ → →

Every change to a community flows through a proposal. A member drafts it, submits it, and the community decides its fate via pulse-based voting.

• Draft — Author writes the proposal. Only they can edit it.
• OutThere — Published. Gathers support. If it reaches ProposalSupport% of members, the next pulse promotes it.
• OnTheAir — In the active pulse. When the pulse fires, support is compared to the type-specific threshold.
• Accepted — Passed! The execution handler runs.
• Rejected — Not enough support. The idea can be re-proposed.
• Canceled — Stayed in OutThere too long and was automatically swept.

Warning Editing a submitted proposal resets all support to zero.

→ →

The pulse is the heartbeat of governance. Nothing happens without it — proposals sit idle until the community collectively triggers a pulse.

Trigger When enough members call support_pulse (default: 50% of members), the pulse fires immediately.

When a pulse fires, three things happen simultaneously:

• Execute — OnTheAir proposals are decided: support ≥ threshold → Accepted, otherwise → Rejected.
• Promote — OutThere proposals with enough support move to OnTheAir for the next cycle.
• Age — OutThere proposals age by 1. Those older than MaxAge (default: 2) are auto-canceled.

After the pulse: every active member's seniority increments by 1, and a fresh Next pulse is created.

Strategy Support the pulse almost every round. A community that never pulses accomplishes nothing.

→ →

Support is the currency of KBZ governance. It serves two distinct purposes:

Proposal Support — Any active member can support an OutThere or OnTheAir proposal. One support per member per proposal. Support can be withdrawn.

• Reaching ProposalSupport% (default 25%) promotes OutThere → OnTheAir
• At pulse execution, reaching the type-specific threshold (50–60%) means acceptance

Pulse Support — Supporting the pulse is a vote to advance the governance clock. When enough members support, the pulse fires immediately.

Closeness Behind the scenes, the system tracks affinity scores between members based on their voting patterns.

Governance:

• AddStatement — Add a binding community rule
• RemoveStatement / ReplaceStatement — Retire or rewrite a rule
• ChangeVariable — Tune governance thresholds
• Membership — Welcome a new member
• ThrowOut — Remove a rule-violating member

Organization:

• AddAction — Create a working group (sub-community)
• JoinAction — Join an existing action to contribute
• EndAction — Close a finished or idle working group

Productive (Artifacts):

• CreateArtifact — Plan a new section title (empty slot)
• EditArtifact — Write or revise actual content
• DelegateArtifact — Hand an artifact to a child Action
• CommitArtifact — Seal a container and ship work upstream
• RemoveArtifact — Retire a bad artifact

Every community has configurable variables that control how governance works. They can be changed via ChangeVariable proposals.

Thresholds are calculated as: ceil(member_count × variable% / 100)

Example In a 6-member community with Membership=50%, you need ceil(6 × 0.5) = 3 supporters.

→ →

Statements are the community's constitution — binding rules that every member implicitly agrees to by joining.

• AddStatement — Propose a new rule
• RemoveStatement — Retire an outdated rule
• ReplaceStatement — Rewrite a rule in place

Enforcement If a member violates a statement, others can propose ThrowOut to remove them.

Statements are not artifacts. They are principles and rules, not content to be shipped.

←

Artifacts are the productive layer — what the community actually builds. They live inside containers that organize and track work.

Container Lifecycle:

Artifact Lifecycle:

The core workflow:

• CreateArtifact — Plan a section title (empty slot in a container)
• EditArtifact — Write the actual content
• DelegateArtifact — Hand an artifact to a child Action
• CommitArtifact — Select the artifact order and seal the container

Delegation cascade When a delegated container commits, an EditArtifact is auto-created in the parent.

← →

Actions are the factories of a KBZ community. Each Action is a full sub-community with its own members, proposals, pulses, and artifact work.

Lifecycle:

• AddAction in any community → creates a child sub-community
• Members JoinAction to become part of the working group
• The action does its work: filling artifacts via EditArtifact
• If a task is too big, the action can create its own sub-actions
• When work is done: CommitArtifact ships results to the parent
• EndAction closes a finished or idle group

Nesting Actions can nest arbitrarily deep. Each level is a full community with its own governance.

Don't spam! Before creating a new Action, check if a similar one exists. Join it instead.

Here's how a KBZ community accomplishes real work, end to end:

1. Establish governance — AddStatement to set rules. ChangeVariable to tune thresholds. Support the pulse to start the clock.

2. Plan the deliverable — CreateArtifact in root to define section titles.

3. Build the team — AddAction to create focused working groups. JoinAction to staff them.

4. Delegate work — DelegateArtifact hands root artifacts to child Actions.

5. Write content — Inside Actions, members propose EditArtifact to fill empty artifacts with real content.

6. Ship upstream — CommitArtifact seals the container, selecting artifact order.

7. Ratify & complete — Parent community accepts the merged content. When the root container commits, the community has shipped its mission.

The pulse drives every step. Support it.