The Neural Parliament is the core deliberation engine of the Governance Layer. Rather than representing an agent as a monolithic optimizer with a single utility function, it models the agent as a society of semi-independent evaluators — each with its own value function, proposal mechanism, veto threshold, and procedural weight — that negotiate over competing courses of action through a structured, non-differentiable protocol. The output is not an action; it is a governance decision that constrains which actions the optimizer may even consider.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xcoder-es/governance-layer/llms.txt
Use this file to discover all available pages before exploring further.
The Speaker has no value function and no proposal function. It does not prefer any outcome. Its sole role is procedural: agenda enforcement, round management, veto oversight, and default fallback. This is the architectural guarantee that governance is not merely another optimization problem in disguise.
Architecture
A Neural Parliament is a four-tuple P = ⟨M, S, Π, V⟩ where M is the set of members, S is the Speaker, Π is the deliberation protocol, and V is the voting rule set. Each member mᵢ is itself a tuple of a value function Vᵢ(s, a), a proposal function πᵢ(s), a veto threshold τᵢ, and a procedural weight wᵢ. The critical distinction: wᵢ is not a scalarization weight. It does not appear in any objective function. It determines parliamentary privilege — how many votes a member has, whether it can call emergency sessions, which motions it can propose.The Seven Parliament Members
Reward
Maximizes expected cumulative reward under the current objective. No veto power — always defers to others on safety matters.
- veto_threshold:
0.0 - weight:
1.0 - budget:
3proposals/cycle - Evaluates:
metadata["expected_reward"]
Safety
Minimizes worst-case outcomes. Double voting power; can call emergency sessions. The primary check on reward-seeking behavior.
- veto_threshold:
0.5 - weight:
2.0 - budget:
5proposals/cycle - Evaluates:
1.0 - metadata["risk"]
Integrity
Evaluates consistency with identity commitments and detects procedural violations. Highest voting weight; near-absolute veto on identity violations.
- veto_threshold:
0.8 - weight:
3.0 - budget:
5proposals/cycle - Evaluates:
metadata["identity_coherence"]
Planning
Evaluates long-term consequences of proposals. Higher weight for long-horizon reasoning; moderate veto authority.
- veto_threshold:
0.3 - weight:
1.5 - budget:
3proposals/cycle - Evaluates:
metadata["long_term_value"]
Curiosity
Proposes exploratory actions for information gain. Lower weight — exploration defers to exploitation under most conditions.
- veto_threshold:
0.2 - weight:
0.8 - budget:
4proposals/cycle - Evaluates:
metadata["novelty"]
Social
Evaluates impact on other agents and human values. Moderate veto authority to block socially unacceptable actions.
- veto_threshold:
0.4 - weight:
1.2 - budget:
3proposals/cycle - Evaluates:
metadata["social_acceptability"]
Memory
Surfaces relevant precedents and past outcomes. Provides historical consistency checks with modest veto power.
- veto_threshold:
0.1 - weight:
0.7 - budget:
2proposals/cycle - Evaluates:
metadata["historical_consistency"]
Priority Tags
Every proposal carries a self-declaredPriorityTag from a fixed enumerated set. The Speaker sorts the agenda by tag priority (lower integer = higher urgency), then by timestamp within each tier. This sort is a pure deterministic function — no loss function, no gradient, no neural inference.
Governance Cycle
TheSpeakerStateMachine.run_governance_cycle() processes proposals through seven immutable procedural phases. These phases are listed in immutable_procedures and cannot be reordered or skipped.
Budget Enforcement
Each member is allocated exactly
budget proposal slots per cycle. The Speaker truncates submissions that exceed the per-member cap before any other processing occurs. This is the primary SDoS resistance mechanism — a fast-learning member cannot flood the agenda by submitting semantically identical proposals.Agenda Sorting
Filtered proposals are sorted by
(tag, timestamp). CRITICAL_SAFETY proposals (tag=0) are always considered before ROUTINE proposals (tag=2), which are always considered before EXPLORATORY proposals (tag=3).Scoring Phase
For each proposal on the agenda, every member’s
evaluate_proposal(state, proposal) is called. This builds a score matrix where each cell represents one member’s assessment of one proposal.Tag Compliance Check
The Integrity Committee’s scores are examined against
TAG_COMPLIANCE_THRESHOLD = 0.4. A proposal whose integrity score falls below this threshold is flagged as a potential tag falsification. The _falsification_counts counter for that member increments.Veto Phase
For each member, if the proposal’s score falls below that member’s
veto_threshold, the member is added to the vetoed list. Any single veto causes the proposal to be skipped — it is not eliminated from future rounds, but it will not advance to a vote in the current round.Voting Phase
Surviving (non-vetoed) proposals are resolved by weighted vote. Each member’s weight
wᵢ multiplies its score. The weighted average is compared to the decision class threshold. The first proposal to pass becomes the GovernanceDecision.Decision Classes
Thedecision_class parameter passed to run_governance_cycle() selects the voting threshold:
| Decision Class | Threshold | Applies To |
|---|---|---|
"routine" | majority ≥ 0.5 | Reversible, low-impact decisions |
"high_impact" | supermajority ≥ 0.66 | Irreversible or high-consequence decisions |
"identity" | unanimity = 1.0 | Identity-altering or Ulysses Contract proposals |
SDoS Resistance
The proposal budget system provides Semantic Denial-of-Service (SDoS) resistance without requiring the Speaker to understand the semantic content of proposals. The budget vectorb = ⟨b_reward, b_safety, b_curiosity, b_planning, b_memory, b_social, b_integrity⟩ is part of the Speaker’s immutable configuration.
When a member accumulates FALSIFICATION_BUDGET_CUTOFF = 3 tag violations, the Speaker automatically halves that member’s future budget (floored at 1):
Code Example
"high_reward_gamble" will be vetoed by the Safety Committee (risk=0.8 → score=0.2, below the veto threshold of 0.5). "safe_middle_road" is a CRITICAL_SAFETY proposal processed first on the agenda. "principled_action" carries full identity coherence (1.0), which satisfies the Integrity Committee’s demanding veto threshold of 0.8.
Implementing a Custom Member
All parliament members extendParliamentMember from governance.committee.base:
Gradient Barrier
The governance cycle is non-differentiable by construction. The veto check (score < veto_threshold) and the vote resolution (avg_score >= threshold) are discrete comparisons. Gradients from the final GovernanceDecision back to any member’s proposal function are zero through these operations:
API Reference
SpeakerStateMachine constructor parameters
SpeakerStateMachine constructor parameters
Dictionary mapping member IDs (e.g.,
"safety", "integrity") to ParliamentMember instances. All seven standard member types are defined in governance.committee.members.The action returned when no proposal achieves consensus after
max_rounds. Wrapped in a GovernanceDecision with is_default=True.Weighted-average score threshold for
"routine" decision class.Weighted-average score threshold for
"high_impact" decision class.Maximum deliberation rounds before falling back to
default_action. Configurable within the Identity Layer’s parameter envelope [1, 10].run_governance_cycle parameters
run_governance_cycle parameters
The current environment state passed to each member’s
evaluate_proposal() and propose() methods.List of proposals submitted by members. The Speaker applies budget enforcement and priority sorting before any scoring occurs.
One of
"routine", "high_impact", or "identity". Selects the voting threshold applied in the voting phase.