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

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

@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

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):

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.

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

@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):

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)

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)

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:

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