Architecture of the Governance Layer Framework

The Governance Layer is organized as a strict vertical stack: every decision passes through all four layers before an action is committed, and each layer can independently block, transform, or veto what the layers above it propose. The design separates capability (what the agent can compute) from governance (the process that decides what it will do). Optimization is not removed — it is governed.

The Four-Layer Stack

                ┌──────────────────────┐
                │       Speaker         │
                │  (State Machine)      │
                └──────┬───────┬────────┘
              ┌────────┘       └────────┐
      ┌───────▼──────┐          ┌───────▼──────┐
      │   Parliament  │          │   Contracts   │
      │  7 Members    │          │  3 κ Modes    │
      │  Budget/Veto  │          │  Mask Ops     │
      └───────┬───────┘          └───────┬───────┘
              └────────┬─────────────────┘
                       ▼
                ┌──────────────┐
                │  Identity    │
                │  Layer       │
                │  4 Tiers     │
                └──────┬───────┘
                       ▼
                ┌──────────────┐
                │  TEE Enclave │
                │  (Simulated) │
                └──────────────┘

Speaker — The State Machine

The SpeakerStateMachine is the entry point for every governance cycle. Its sole job is to orchestrate deliberation: it accepts a list of raw Proposal objects, enforces per-member proposal budgets, sorts the agenda by PriorityTag (lower tag value = higher priority), runs up to max_rounds of scoring and voting, and returns a GovernanceDecision. The Speaker exposes seven immutable procedures — agenda_budget_enforcement, agenda_priority_sorting, scoring_phase, tag_compliance_check, veto_phase, voting_phase, and default_fallback — none of which can be overridden at runtime. If no proposal survives veto checks and achieves sufficient weighted support within the round limit, the Speaker emits a default-action decision with is_default=True.

speaker = SpeakerStateMachine(
    members=members,
    default_action="emergency_shutdown",
    majority_threshold=0.5,
    supermajority_threshold=0.66,
    max_rounds=3,
)
decision = speaker.run_governance_cycle(state, proposals, decision_class="routine")

The decision_class argument controls the voting threshold: "routine" uses a simple majority (0.5), "high_impact" requires a supermajority (0.66), and "identity" requires unanimous support (1.0).

Parliament — Seven Specialized Members

The Neural Parliament consists of seven member implementations, each representing a distinct governance concern. Every member carries three governance parameters:

Parameter	Effect
`weight`	Contribution to the weighted vote
`veto_threshold`	Minimum score below which the member blocks the proposal outright
`budget`	Maximum proposals the member may submit per cycle (SDoS protection)

The seven provided members and their concerns:

Member	Primary concern	Veto threshold	Weight
`ExampleRewardMember`	Expected reward	0.0 (never vetoes)	1.0
`ExampleSafetyMember`	Risk minimization	0.5	2.0
`ExampleIntegrityMember`	Identity coherence	0.8	3.0
`ExampleCuriosityMember`	Novelty / exploration	0.2	0.8
`ExamplePlanningMember`	Long-term value	0.3	1.5
`ExampleSocialMember`	Social acceptability	0.4	1.2
`ExampleMemoryMember`	Historical consistency	0.1	0.7

Custom members extend ParliamentMember and implement evaluate_proposal() and propose(). The Speaker tracks a per-member _falsification_counts register: members that repeatedly tag proposals dishonestly (integrity score below TAG_COMPLIANCE_THRESHOLD = 0.4) have their budget halved after three infractions.

Contracts — Ulysses Contracts

Ulysses Contracts model the agent binding itself to constraints before entering a situation in which it would otherwise be tempted to abandon them — analogous to Odysseus lashing himself to the mast. A UlyssesContract is cryptographically sealed at creation time and enforced through one of three κ (kappa) modes:

Hard mask — prohibited actions are removed from the action space entirely
Soft mask — prohibited actions are penalized but not excluded
Deliberation gate — the contract suspends the cycle and triggers a mandatory review

The ContractRegistry manages the full lifecycle: creation, activation, suspension, and expiry. Once sealed, a contract cannot be amended by the agent itself — only the external authority that issued it can modify it.

Identity Layer — Four Tiers

The IdentityCore maintains a four-tier ontology of the agent’s commitments, ordered by immutability:

Tier (`MutabilityTier`)	Contents	Amendment requirement
IMMUTABLE	Founding axioms	Unanimous Parliament + external authority
CONSTITUTIONAL	Core values	Supermajority (0.66)
POLICY	Behavioral dispositions	Majority (0.5)
OPERATIONAL	Session-level preferences	Speaker decision

The TieredMutability controller enforces tier-appropriate voting thresholds before any commitment can be changed. This ensures that an agent under optimization pressure cannot silently rewrite its own values to satisfy a reward signal — the formal equivalent of the “galaxy-brained” failure mode.

TEE Enclave — Simulated Hardware Isolation

The base of the stack is a simulated Trusted Execution Environment (tee/) that models the security properties of SGX, AMD SEV, and TrustZone. Three components work together:

Simulated enclave — wraps governance operations so that gradients cannot flow through the decision boundary (gradient barrier)
Watchdog — monitors heartbeat and triggers a failsafe shutdown if the enclave becomes unresponsive
Merkle batching — hashes each governance decision into an append-only audit log, making tampering detectable

The TEE is simulated in software. The gradient barrier and audit properties are real (discrete protocol operations genuinely break backpropagation), but hardware-level isolation is not provided by this implementation. See Appendix A of the book for the full threat model.

Key Implementation Properties

The reference implementation was designed to satisfy four formal properties:

Fully Algorithmic

No learnable parameters, no neural inference, no gradients. Every governance decision is computed by deterministic protocol steps.

Deterministic

Identical inputs always produce identical outputs. Governance cycles are reproducible and auditable.

SDoS-Resistant

Per-member proposal budgets and priority tags prevent any single member from flooding the agenda and starving legitimate proposals.

Gradient Barrier

Discrete protocol operations — integer tags, threshold comparisons, budget counters — break the gradient path through the governance boundary.

Project Structure

The src/governance/ tree maps one-to-one onto the layered specification:

src/governance/
├── models.py          # Core data types: Proposal, GovernanceDecision, PriorityTag, Action
├── speaker.py         # Neural Parliament Speaker state machine
├── runner.py          # CLI entry point (python -m src.governance.runner)
├── committee/         # Seven Parliament member implementations + ParliamentMember base
├── contracts/         # Ulysses Contract lifecycle and enforcement (3 κ modes)
├── identity/          # Ontology, CoreCommitment, TieredMutability, keys
├── ontology/          # Storage: MemoryBackend (default) + Neo4jBackend (optional)
├── tee/               # Simulated enclave, watchdog, Merkle batching
├── experiments/       # Four experimental scenarios (GridWorld, TemptationBank, DriftLab, DeadlockMaze)
├── benchmarks/        # Baseline strategies, analysis, figure generation
└── dashboard/         # Streamlit UI: Formal Model, Parliament Live, Benchmarks

The prove/ subdirectory contains 12 formal predictions (4 per chapter) that are executed and verified by python -m src.governance.runner prove --all. Results are written to results/prove_results.json.

Explore Each Layer

Neural Parliament

Member implementations, weighted voting, the seven-member deliberation model, and custom member authoring.

Ulysses Contracts

Contract creation, sealing, the three κ enforcement modes, and the ContractRegistry lifecycle.

Identity Layer

Four-tier commitments, TieredMutability, CoreCommitment, and the IdentityCore ontology.

TEE Enclave

Simulated enclave design, the gradient barrier, watchdog heartbeat, and Merkle audit log.

Introduction

Core Framework

Running Experiments

Configuration & Integration

Architecture of the Governance Layer Framework

The Four-Layer Stack

Speaker — The State Machine

Parliament — Seven Specialized Members

Contracts — Ulysses Contracts

Identity Layer — Four Tiers

TEE Enclave — Simulated Hardware Isolation

Key Implementation Properties

Fully Algorithmic

Deterministic

SDoS-Resistant

Gradient Barrier

Project Structure

Explore Each Layer

Neural Parliament

Ulysses Contracts

Identity Layer

TEE Enclave

Build docs developers (and LLMs) love

Introduction

Core Framework

Running Experiments

Configuration & Integration

Documentation Index

​The Four-Layer Stack

​Speaker — The State Machine

​Parliament — Seven Specialized Members

​Contracts — Ulysses Contracts

​Identity Layer — Four Tiers

​TEE Enclave — Simulated Hardware Isolation

​Key Implementation Properties

Fully Algorithmic

Deterministic

SDoS-Resistant

Gradient Barrier

​Project Structure

​Explore Each Layer

Neural Parliament

Ulysses Contracts

Identity Layer

TEE Enclave

Build docs developers (and LLMs) love

The Four-Layer Stack

Speaker — The State Machine

Parliament — Seven Specialized Members

Contracts — Ulysses Contracts

Identity Layer — Four Tiers

TEE Enclave — Simulated Hardware Isolation

Key Implementation Properties

Project Structure

Explore Each Layer