---
name: co-fita-governance
type: analysis
title: "Democratic Centralism: AI Agent Governance in Co-Fita"
description: "Analysis of the Centralismo Democratico governance system: proposals, Congress, chancela, Elo debate, and the role of the Lider Suprema"
tags: [co-fita, governance, democratic-centralism, elo-debate, congress, chancela, telegram, proposals]
timestamp: 2026-07-21
---

# Democratic Centralism in Co-Fita

## The Philosophy

Centralismo Democratico is not a metaphor. It is a concrete governance protocol where AI agents propose improvements to the system that orchestrates them, deliberate collectively, and the human principal retains final approval authority. The system is designed so that governance is not a separate activity — it emerges naturally from the work itself.

**Core principle:** Agents that observe failures, dead-ends, and pain points are the same agents that propose solutions. Governance is not imposed from above; it flows from direct operational experience.

**Isomorphism with RLHF/GRPO:**

| RLHF Concept | Co-Fita Equivalent |
|:---|:---|
| G samples from policy | N agents generate proposals as they work |
| Reward scoring (relative) | Elo Tournament (pairwise debate) |
| Relative advantage | Elo delta vs current artifact |
| Policy gradient update | Promotion to `.agents/` |
| Human feedback (RLHF) | Chancela da Alefita |

This is not an analogy — the mathematical structure is identical. Proposals are policy samples, Elo ratings are reward signals, and chancela is the human-in-the-loop feedback that prevents reward hacking.

## The Proposal Lifecycle

### States

```mermaid
stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> SUBMITTED : agent submits
    SUBMITTED --> DEBATING : Congress convenes
    DEBATING --> CONGRESS_APPROVED : majority approve
    DEBATING --> VETOED : majority reject
    CONGRESS_APPROVED --> AWAITING_CHANCELA : escalated
    AWAITING_CHANCELA --> STRATEGY_DELIBERATION : chancela approve
    AWAITING_CHANCELA --> VETOED : chancela veto
    STRATEGY_DELIBERATION --> PROMOTED : implemented
    PROMOTED --> [*]
    VETOED --> [*]
```

### Proposal Data Model

```python
@dataclass
class Proposal:
    id: str                          # "prop-{uuid8}"
    category: ProposalCategory       # skill, workflow, rule, hook, etc.
    name: str                        # Short descriptive name
    content: str                     # The actual proposed artifact
    rationale: str                   # Why this change is necessary
    proposed_by: str                 # agent_id
    origin: ProposalOrigin           # How the proposal was born
    status: ProposalStatus
    elo_rating: float                # Starting at 1200
    debate_log: list                 # Round-by-round Elo history
    failure_context: str             # If originated from a failure
    current_artifact: str            # Current version for diffing
    congress_votes: dict             # agent_id -> {vote, reasoning, ts}
    strategy_notes: str              # Post-chancela implementation plan
```

### Proposal Categories

| Category | What Can Be Proposed |
|:---|:---|
| `skill` | New or improved agent skills |
| `workflow` | Modified research/execution workflows |
| `rule` | New behavioral rules for agents |
| `hook` | Pre/post tool-use hooks |
| `integration` | New external service integrations |
| `tool` | New tools or tool improvements |
| `mcp` | MCP server capabilities |
| `model_config` | Model routing or parameter changes |
| `harness_config` | Harness-level configuration |
| `prompt` | Improved prompts for any phase |

### Proposal Origins

| Origin | When It Happens |
|:---|:---|
| `failure_observation` | Agent observed a failure and proposes a fix |
| `dead_end_analysis` | Agent analyzed a dead-end and proposes an alternative |
| `performance_insight` | Agent noticed a performance improvement opportunity |
| `reflection` | Generated by the Reflector after failure analysis |
| `human_directive` | Alefita directly instructed a proposal |
| `congress_debate` | Emerged from collective deliberation |

**Key insight:** The majority of proposals originate from `failure_observation` and `reflection`. The system is designed so that failure is the primary driver of improvement. This is the "metanoia" principle — self-correction as growth.

## The Seven-Column Kanban

The web dashboard at `/governance` displays a 7-column Kanban board:

| Column | Status | Visual | Description |
|:---|:---|:---|:---|
| Draft | `draft` | Default | New proposals being written by agents |
| Submitted | `submitted` | Default | Submitted to Congress for review |
| Debating | `debating` | Default | Under Elo-rated pairwise debate |
| Chancela | `awaiting_chancela` | **Glowing red** | Awaiting Alefita's final decision |
| Approved | `congress_approved` | Green | Approved by Congress, pending chancela |
| Vetoed | `vetoed` | Red | Rejected by Congress or leader |
| Promoted | `promoted` | Blue | Implemented and deployed to production |

The **Chancela column glows red** — a deliberate visual design to draw the Lider Suprema's attention to proposals requiring human decision.

### Kanban State Export

`GovernanceEngine.export_kanban_state()` returns a dictionary mapping column names to lists of proposal summaries, each containing: id, name, category, rationale, elo, origin, proposed_by, vote count, debate rounds, and creation timestamp.

## National Congress

### What Is Congress

Congress is the collective deliberation mechanism. It is convened periodically (every N=3 iterations of the orchestrator) to deliberate ALL open proposals at once.

### Convening

```python
session = committee.convene_congress(agent_ids)
```

This creates a `CongressSession` containing:
- Unique session ID (`congress-{timestamp}`)
- List of agent IDs present
- List of proposal IDs under deliberation (all SUBMITTED + DEBATING)

### Deliberation Prompt

`build_congress_prompt()` generates a structured prompt containing:

1. Session metadata
2. For each proposal: category, proposer, origin, Elo rating, rationale, failure context, current artifact, and proposed content
3. Voting instructions: each agent must return JSON with `votes` array containing `{proposal_id, vote, reasoning}`

### Voting

Each agent casts votes directly (direct democracy, not representative):

```python
committee.process_agent_votes(session, agent_id, votes_json)
```

Votes are: `approve`, `reject`, or `abstain`.

### Approval Threshold

`check_congress_approval()` requires:
1. Minimum 3 votes total
2. Majority (>50%) are `approve`

If both conditions are met, the proposal is escalated to the Lider Suprema for chancela.

### Session Conclusion

`conclude_congress()`:
1. Checks each discussed proposal for approval
2. Escalates approved proposals to `AWAITING_CHANCELA`
3. Records resolutions (approved or not)
4. Marks session as concluded with timestamp

All congress events are logged to `congress_sessions.jsonl` for audit trail.

## The Lider Suprema and Chancela

### Who Is the Lider Suprema

Alefita (Dra. Ale Oliveira) is the human principal who holds final decision authority over all governance proposals. This is not a ceremonial role — it is the human-in-the-loop that prevents the system from diverging through reward hacking or collective delusion.

### What Is Chancela

Chancela (Portuguese for "seal/stamp of approval") is the final authorization step. Even if Congress unanimously approves a proposal, it cannot be implemented until the Lider Suprema gives chancela.

### Chancela Authority

Only Alefita can give chancela. This is enforced at multiple levels:

1. **Telegram bot** — Only `TELEGRAM_ALLOWED_USERS` can execute `/approve` and `/veto`
2. **Web dashboard** — Chancela column requires authenticated access
3. **MCP server** — `chancela_proposal()` checks `X-User: alefita` header

### After Chancela

When Alefita approves a proposal:

1. Status moves to `STRATEGY_DELIBERATION`
2. Congress collectively deliberates on implementation strategy
3. `set_strategy()` records the implementation plan
4. `promote()` deploys the artifact to the target path (`.agents/skills/` or `.agents/rules/`)

When Alefita vetoes a proposal:

1. Status moves to `VETOED`
2. Decision is logged with reason
3. No further action taken

## Telegram Governance Bot

**Source:** `harness_core/telegram_governance.py`

### Commands

| Command | Function | Access |
|:---|:---|:---|
| `/proposals` | List proposals awaiting chancela | Any allowed user |
| `/approve <id> [note]` | Approve a proposal | Lider Suprema only |
| `/veto <id> [reason]` | Veto a proposal | Lider Suprema only |
| `/plan` | Show active Quinquennial Plan status | Any allowed user |
| `/debate <topic>` | Query the Secretary General | Any allowed user |
| `/help` | Show available commands | Any allowed user |

### Architecture

The bot uses the Open-Closed principle — it wraps the `TelegramGateway` (which implements `GatewayInterface`) and adds governance-specific routing. Future channels (Slack, Discord, SMS) would implement the same interface without changing the governance logic.

```python
class TelegramGovernanceBot:
    def __init__(self, gateway, governance, committee):
        self.gateway = gateway    # TelegramGateway (implements GatewayInterface)
        self.gov = governance     # GovernanceEngine
        self.committee = committee # CentralCommittee
```

### Security

- Credentials sourced from `~/.hermes/.env`
- Long-polling with user allowlist (`TELEGRAM_ALLOWED_USERS`)
- MarkdownV1 escaping for safe message rendering
- Unknown commands are silently ignored (no error spam)

### Factory Pattern

`make_governance_bot()` creates a fully wired bot or returns `None` if Telegram is unconfigured. This allows graceful degradation — the harness works without Telegram.

## Quinquennial Plans

### What They Are

Long-horizon strategic plans that guide the collective's work over an extended period. Named after economic planning traditions, but adapted for AI agent coordination.

### Key Properties

```python
@dataclass
class QuinquennialPlan:
    id: str
    title: str
    objectives: list[str]
    kpis: dict[str, float]           # Key performance indicators
    duration_days: int | None         # Deliberated by Congress
    duration_rationale: str           # Why this duration
    phases: list[dict]
    status: str                       # proposed, active, completed
    proposed_by: str
    approved_by: str | None
```

### Democratic Duration

The duration of a Quinquennial Plan is **not fixed or imposed**. Per the Jabbour framework:

1. Any agent can propose a plan with a suggested duration
2. Congress debates the duration as part of the plan
3. The Lider Suprema can adjust duration during approval
4. The duration rationale is recorded for future reference

This is a deliberate design: planning parameters themselves are subject to democratic deliberation.

### Secretary General Consultation

Before giving chancela on a complex proposal, the Lider Suprema can consult the Secretary General (a stronger model, e.g., DeepSeek SOTA):

```python
prompt = committee.build_secretary_general_prompt(question)
```

The prompt includes:
- The Lider Suprema's question
- Active Quinquennial Plan context
- All pending proposals with vote summaries

The Secretary General's role is advisory — it informs the Lider Suprema's decision but does not override Congress.

## The Committee System

**Source:** `harness_core/committee.py`

The CentralCommittee implements three functions:

### 1. Congress Management

- `convene_congress(agent_ids)` — Opens a new session
- `build_congress_prompt(session)` — Generates deliberation prompt
- `process_agent_votes(session, agent_id, votes_json)` — Records votes
- `conclude_congress(session)` — Finalizes and escalates approved proposals

### 2. Quinquennial Plan Management

- `propose_quinquennial_plan(...)` — Creates a new plan
- `approve_plan(plan_id, duration_days, approved_by)` — Activates a plan
- `get_active_plan()` — Returns the current active plan

### 3. Secretary General Consultation

- `build_secretary_general_prompt(question)` — Prepares context for advisory consultation

### Isomorphism with Political Systems

The committee system is explicitly modeled on democratic political structures:

| Co-Fita Role | Political Equivalent | Function |
|:---|:---|:---|
| Worker agents | Base units | Generate proposals from direct experience |
| Proposals | Policy suggestions | Improvements emerging from below |
| National Congress | NPC / Parliament | Collective deliberation |
| Elo Tournament | Delegate debate | Pairwise quality evaluation |
| Secretary General | Advisory body | Consultative expertise |
| Alefita's chancela | Executive ratification | Final human approval |
| Strategy deliberation | Implementation planning | Post-approval execution design |

## Governance Integration with the Orchestrator

**Source:** `harness_core/governance_integration.py` (wires governance into the 5-phase loop)

The orchestrator calls governance at two points:

### On Failure (Phase III)

```python
self._governance.process_iteration(
    iteration=iteration,
    audit_passed=False,
    audit_violation_type=audit_res.violation_type,
    audit_mitigation=audit_res.mitigation_feedback,
    audit_confidence=audit_res.confidence,
    approach=approaches[0],
    reflection_root_cause=reflection.root_cause,
)
```

This triggers:
1. A governance proposal based on the failure observation
2. Auto-submission to Congress
3. Wiki export of governance state

### On Success (Phase V)

```python
self._governance.process_iteration(
    iteration=iteration,
    audit_passed=True,
    audit_violation_type="none",
    audit_mitigation="",
    audit_confidence=audit_res.confidence,
    approach=approaches[0],
)
```

This triggers:
1. Congress check (every N=3 iterations)
2. Wiki export of governance state

The N=3 threshold means Congress is not convened every iteration — it batches proposals for efficient collective deliberation.

## Persistence and Audit Trail

All governance data is persisted to JSONL files:

| File | Content |
|:---|:---|
| `proposals.jsonl` | Append-only log of all proposals |
| `decisions.jsonl` | Audit trail of all governance decisions |
| `congress_sessions.jsonl` | Congress convening and conclusion events |
| `quinquennial_plans.json` | Strategic plans (JSON, not JSONL) |

The append-only design means:
- No governance action can be silently undone
- Every decision has a timestamp and actor attribution
- The full history is human-readable
- Context compaction in long sessions cannot destroy governance state

## The Self-Improvement Loop

The governance system creates a recursive self-improvement loop:

```mermaid
graph TD
    A["Agent works on task"] --> B["Encounters failure"]
    B --> C["Reflector generates reflection"]
    C --> D["Governance proposal created"]
    D --> E["Congress debates via Elo"]
    E --> F["Lider Suprema gives chancela"]
    F --> G["Proposal implemented and promoted"]
    G --> H["System is now better"]
    H --> A
```

This is the "hypersigil" in action — the system writes its own improvement into existence through a democratic process that the human oversees but does not micromanage. Each cycle of this loop makes the next cycle more effective.

## Design Constraints

1. **Human-in-the-loop is non-negotiable** — No proposal can be promoted without Alefita's chancela
2. **Failures drive improvement** — The system is designed to learn more from failures than successes
3. **Transparency over efficiency** — Every decision is logged, every vote recorded, every rationale documented
4. **Deliberation over speed** — Congress batches proposals; Elo tournaments require multiple rounds
5. **Persistence over elegance** — JSONL append-only logs survive context compaction and crashes