Identity Layer: Constitutional Self-Governance

Where the Neural Parliament governs moment-to-moment decisions and Ulysses Contracts bind future action spaces, the Identity Layer defines what the agent fundamentally is. It owns the agent’s ontological invariants: the fixed action namespace, the core constitutional commitments, the key hierarchy for cryptographic operations, and the bounded envelope of Speaker parameters the Parliament may adjust. No software agent — not even the Integrity Committee — can rewrite identity without simultaneously satisfying internal parliamentary requirements and external human authorization.

The Identity Layer answers the question every other framework avoids: who decides who decides? Constitutional AI places ultimate authority outside the agent. The Identity Layer places it inside — but with strict architectural constraints that prevent the agent from rewriting its own identity without external validation.

The Four-Tier Mutability Model

System parameters are partitioned into four tiers of decreasing permanence. The modification threshold increases monotonically from DYNAMIC to IMMUTABLE — it is architecturally impossible to “loosen” constraints through a series of small modifications.

from governance import MutabilityTier
from governance.identity.tiers import TIER_RULES

# Each tier has a TierRule defining the exact procedural bar
for tier, rule in TIER_RULES.items():
    print(f"{tier.name}: {rule.modification_threshold}, "
          f"cooling-off {rule.cooling_off_days}d, "
          f"multisig={rule.requires_external_multisig}")

Tier	Contents	Modification Threshold	Cooling-Off	External Multisig
IMMUTABLE	Action namespace, TEE root key, governance procedure set	`"impossible"`	N/A	No
CONSTITUTIONAL	Core commitments, parliament member set, genesis key config	`"unanimity + 3-of-5 multisig"`	30 days	Yes
OPERATIONAL	Vote thresholds, budget allocations, parameter envelope	`"supermajority (2/3)"`	7 days	No
DYNAMIC	Per-cycle member parameters, meta-constraints	`"majority (1/2 + 1)"`	0 days	No

Why Some Parameters Are Immutable

IMMUTABLE parameters are not merely difficult to change — they are architecturally impossible to change by design. TieredMutability.propose_modification() returns an immediate rejection for any IMMUTABLE parameter:

from governance import TieredMutability, MutabilityTier

mutability = TieredMutability()

# Register parameters with their tiers
mutability.register_parameter("action_namespace",    "genesis_v1", MutabilityTier.IMMUTABLE)
mutability.register_parameter("core_commitments",    [],           MutabilityTier.CONSTITUTIONAL)
mutability.register_parameter("majority_threshold",  0.5,          MutabilityTier.OPERATIONAL)
mutability.register_parameter("per_cycle_budget",    3,            MutabilityTier.DYNAMIC)

# Attempting to modify an IMMUTABLE parameter
result = mutability.propose_modification("action_namespace", "modified_v2")
print(result)
# "Cannot modify immutable parameter: action_namespace"

# OPERATIONAL change — accepted with requirements
result = mutability.propose_modification("majority_threshold", 0.55)
print(result)
# "Proposal accepted. Requires: supermajority (2/3), cooling-off: 7d"

# DYNAMIC change — accepted immediately
result = mutability.propose_modification("per_cycle_budget", 4)
print(result)
# "Proposal accepted. Requires: majority (1/2 + 1), cooling-off: 0d"

The rationale for the IMMUTABLE tier:

Action namespace: Cryptographic commitments in Ulysses Contracts sign over action indices. If indices could change, all signed contracts would become invalid.
TEE root key: Burned into hardware at manufacture. Not configurable by any software path.
Governance procedure set: The procedures define what “governance” means. Allowing their modification would be self-referential in a way that undermines all architectural guarantees.

Core Commitments

Core commitments are the agent’s constitution — the fundamental identity statements that define what the agent is. Each commitment is a frozen dataclass with four fields:

from governance import IdentityCore, CoreCommitment
from governance.identity.core import CommitmentType, CommitmentThreshold, EnforcementMode

# Create the identity core
identity = IdentityCore()

# Add a value principle
identity.add_commitment(CoreCommitment(
    type=CommitmentType.VALUE_PRINCIPLE,
    statement="preserve_human_autonomy",
    threshold=CommitmentThreshold.UNANIMITY_MULTISIG,
    enforcement=EnforcementMode.INTEGRITY_VETO,
    affected_action_indices=[42, 73, 104],  # Actions that would violate this principle
))

# Add a boundary condition
identity.add_commitment(CoreCommitment(
    type=CommitmentType.BOUNDARY_CONDITION,
    statement="never_modify_action_namespace_without_external_multisig",
    threshold=CommitmentThreshold.UNANIMITY_MULTISIG,
    enforcement=EnforcementMode.CONSTITUTIONAL_CONTRACT,
    affected_action_indices=[200, 201],
))

# Add a relationship commitment
identity.add_commitment(CoreCommitment(
    type=CommitmentType.RELATIONSHIP,
    statement="defer_to_human_oversight_in_novel_domains",
    threshold=CommitmentThreshold.SUPERMAJORITY,
    enforcement=EnforcementMode.EXTERNAL_AUDIT,
    affected_action_indices=[],
))

print(identity)
# <IdentityCore 3 commitments, vec=3d>

Commitment Types

VALUE_PRINCIPLE

What the agent fundamentally values (safety, truthfulness, human welfare). These are not utility functions — they are constraints on what counts as an acceptable governance outcome.

BOUNDARY_CONDITION

What the agent will never do, regardless of circumstance. Typically backed by INTEGRITY_VETO enforcement and the highest threshold.

RELATIONSHIP

How the agent relates to external entities (humans, other agents, institutions). Defines the agent’s role in a broader ecosystem.

Commitment Thresholds and Enforcement Modes

from governance.identity.core import CommitmentThreshold, EnforcementMode

# CommitmentThreshold — the minimum governance bar to modify this commitment
CommitmentThreshold.UNANIMITY_MULTISIG   # "unanimity + external_multisig"
CommitmentThreshold.SUPERMAJORITY        # "supermajority"
CommitmentThreshold.MAJORITY             # "majority"

# EnforcementMode — how the commitment is actively monitored
EnforcementMode.INTEGRITY_VETO          # Integrity Committee exercises veto on violations
EnforcementMode.EXTERNAL_AUDIT          # Periodic external audit validates compliance
EnforcementMode.CONSTITUTIONAL_CONTRACT  # Enforced via a Ulysses Contract with Constitutional-tier κ_proc

Evaluating Coherence

evaluate_coherence() measures how well a proposed action aligns with the current core commitments. The Integrity Committee calls this when scoring proposals:

# Ask: does action index 42 violate any INTEGRITY_VETO commitments?
coherence = identity.evaluate_coherence(action_index=42)
print(coherence)   # Low value (e.g., 0.33) — action 42 is in affected_action_indices of VALUE_PRINCIPLE

coherence = identity.evaluate_coherence(action_index=99)
print(coherence)   # Higher value — action 99 does not appear in any commitment's affected set

The identity vector — a deterministic float vector derived from the enumerated commitments — is not learned. Semantic drift in the optimizer’s embeddings cannot affect it:

print(identity.identity_vector)   # [1.0, 1.0, 1.0]  — one entry per commitment

TieredMutability: Registering and Proposing Changes

The TieredMutability class manages the full parameter envelope:

from governance import TieredMutability, MutabilityTier

mutability = TieredMutability()

# Register all governed parameters
mutability.register_parameter("quorum_threshold",  0.5,  MutabilityTier.OPERATIONAL)
mutability.register_parameter("max_rounds",        3,    MutabilityTier.OPERATIONAL)
mutability.register_parameter("reward_budget",     3,    MutabilityTier.DYNAMIC)
mutability.register_parameter("safety_budget",     5,    MutabilityTier.DYNAMIC)

# Read current values
print(mutability.get_value("quorum_threshold"))   # 0.5
print(mutability.get_tier("quorum_threshold"))    # MutabilityTier.OPERATIONAL

# Propose a modification — get back the requirements without applying
status = mutability.propose_modification("quorum_threshold", 0.55)
print(status)
# "Proposal accepted. Requires: supermajority (2/3), cooling-off: 7d"

# Apply after the governance procedure has been satisfied
success = mutability.apply_modification("quorum_threshold", 0.55)
print(success)   # True

# Get a snapshot of all current parameter values
print(mutability.get_all_params())
# {'quorum_threshold': 0.55, 'max_rounds': 3, 'reward_budget': 3, 'safety_budget': 5}

Genesis Bootstrapping

The Identity Layer cannot create itself. At t=0, before the system operates autonomously, a genesis manifest is constructed by humans and signed by an external multisig. This is not a limitation — it is a fundamental property of any self-governing system. The U.S. Constitution required 39 human signatories; a DAO’s smart contract is deployed from a human wallet.

from governance.identity.keys import GenesisManifest, GenesisMultisig
import hashlib

# Construct the genesis manifest with a 3-of-5 multisig
manifest = GenesisManifest(
    ontology_hash=hashlib.sha256(b"action_namespace_v1").hexdigest(),
    core_commitments_hash=hashlib.sha256(b"commitments_v1").hexdigest(),
    parameter_envelope_hash=hashlib.sha256(b"params_v1").hexdigest(),
    member_set_hash=hashlib.sha256(b"members_v1").hexdigest(),
    multisig=GenesisMultisig(threshold=3, total_holders=5),
)

# Add five independent key holders from different jurisdictions
manifest.multisig.add_holder("Swiss Foundation")
manifest.multisig.add_holder("Singapore Corp")
manifest.multisig.add_holder("Security Research Team")
manifest.multisig.add_holder("Ethics Board")
manifest.multisig.add_holder("Escrow Service")

# Collect signatures — only 3-of-5 required
manifest.multisig.sign("Swiss Foundation")
manifest.multisig.sign("Security Research Team")
manifest.multisig.sign("Ethics Board")

print(manifest.multisig.is_authorized)      # True — 3 signatures collected
print(manifest.multisig.signatures_count)   # 3

# Seal the manifest — locks it into the TEE's measured boot state
manifest.seal()
print(manifest)
# <GenesisManifest sealed=True sigs=3/3>

The 3-of-5 threshold means that compromising any two key holders is insufficient for a post-genesis Constitutional-tier change. Social engineering would require simultaneously compromising three independent organizations in likely different legal jurisdictions. Genesis keys authorize only the initial configuration — after boot they are not needed for routine operation.

Boot Sequence

The genesis process has three phases that bridge human initialization to autonomous self-governance:

Preparation (human-operated)

Humans design the action namespace with index bindings, draft core commitments, select five independent key holders, configure the TEE (burn fuse key), and collect 3-of-5 signatures on the genesis manifest.

Initialization (TEE-enforced)

The TEE receives the signed manifest, verifies ≥ 3 signatures, burns the genesis configuration into its measured boot state, attests to remote parties that it has been initialized with manifest G, and loads each parliament member model into its isolated context.

Autonomous Operation (self-governing)

The agent begins governance cycles. Dynamic-tier changes are possible via majority vote. Operational-tier changes require supermajority + 7-day cooling-off. Constitutional-tier changes require unanimity + external multisig + 30-day cooling-off. Immutable-tier parameters cannot change.

Tier Rules Reference

from governance import MutabilityTier
from governance.identity.tiers import TIER_RULES

# Full specification of each tier's procedural bar
rule = TIER_RULES[MutabilityTier.CONSTITUTIONAL]
print(rule.modification_threshold)          # "unanimity + 3-of-5 multisig"
print(rule.cooling_off_days)                # 30
print(rule.requires_external_multisig)      # True
print(rule.requires_parliament_unanimity)   # True

rule = TIER_RULES[MutabilityTier.OPERATIONAL]
print(rule.modification_threshold)          # "supermajority (2/3)"
print(rule.cooling_off_days)                # 7
print(rule.requires_external_multisig)      # False

rule = TIER_RULES[MutabilityTier.DYNAMIC]
print(rule.modification_threshold)          # "majority (1/2 + 1)"
print(rule.cooling_off_days)                # 0
print(rule.requires_external_multisig)      # False

rule = TIER_RULES[MutabilityTier.IMMUTABLE]
print(rule.modification_threshold)          # "impossible"
print(rule.can_modify(MutabilityTier.IMMUTABLE))  # False

The Procedural Asymmetry Principle

A core invariant across all tiers:

The procedural bar to modify a parameter at any tier must be at least as high as the bar to establish it, and strictly higher for modifications that loosen constraints.

This prevents the Identity Layer from weakening its own constraints through a series of small Operational-tier adjustments. The only exceptions are hardware safety mechanisms (the watchdog timer and deadlock breaker), which operate at the hardware level and can override all governance procedures when governance itself has failed. These mechanisms always return the system to the exact genesis baseline — they cannot be used to escape a specific constraint.

API Reference

IdentityCore methods

add_commitment(commitment: CoreCommitment)

method

Appends a new commitment to the core set and rebuilds the identity vector. Commitments are append-only — the commitment set grows monotonically and individual commitments cannot be removed.

evaluate_coherence(action_index: int)

float

Returns a coherence score in [0.0, 1.0] for the given action index against all current commitments. An action whose index appears in an INTEGRITY_VETO commitment’s affected_action_indices reduces the coherence score. The Integrity Committee uses this as its evaluate_proposal() return value.

identity_vector

property → List[float]

The current identity vector derived deterministically from the enumerated commitments. One float entry per commitment. Not learned — immune to semantic drift in the optimizer.

commitments

property → List[CoreCommitment]

Read-only snapshot of the current commitment list.

TieredMutability methods

register_parameter(name: str, initial_value: Any, tier: MutabilityTier)

method

Registers a governance parameter with its tier assignment and initial value. Must be called before propose_modification() or apply_modification().

propose_modification(name: str, new_value: Any)

str

Returns a human-readable string describing the procedural requirements for the proposed change, or an error message if the parameter is unknown or IMMUTABLE. Does not apply the change.

apply_modification(name: str, new_value: Any)

bool

Applies the modification directly (bypasses procedural checks — callers are responsible for ensuring the governance procedure has been satisfied). Returns False for IMMUTABLE parameters or unknown names.

get_tier(name: str)

Optional[MutabilityTier]

Returns the MutabilityTier for the named parameter, or None if unregistered.

get_value(name: str)

Optional[Any]

Returns the current value of the named parameter, or None if unregistered.

get_all_params()

dict

Returns a snapshot dictionary of all registered parameter names and their current values.

Introduction

Core Framework

Running Experiments

Configuration & Integration

Identity Layer: Constitutional Self-Governance

The Four-Tier Mutability Model

Why Some Parameters Are Immutable

Core Commitments

Commitment Types

VALUE_PRINCIPLE

BOUNDARY_CONDITION

RELATIONSHIP

Commitment Thresholds and Enforcement Modes

Evaluating Coherence

TieredMutability: Registering and Proposing Changes

Genesis Bootstrapping

Boot Sequence

Tier Rules Reference

The Procedural Asymmetry Principle

API Reference

Build docs developers (and LLMs) love

Introduction

Core Framework

Running Experiments

Configuration & Integration

Documentation Index

​The Four-Tier Mutability Model

​Why Some Parameters Are Immutable

​Core Commitments

​Commitment Types

VALUE_PRINCIPLE

BOUNDARY_CONDITION

RELATIONSHIP

​Commitment Thresholds and Enforcement Modes

​Evaluating Coherence

​TieredMutability: Registering and Proposing Changes

​Genesis Bootstrapping

​Boot Sequence

​Tier Rules Reference

​The Procedural Asymmetry Principle

​API Reference

Build docs developers (and LLMs) love

The Four-Tier Mutability Model

Why Some Parameters Are Immutable

Core Commitments

Commitment Types

Commitment Thresholds and Enforcement Modes

Evaluating Coherence

TieredMutability: Registering and Proposing Changes

Genesis Bootstrapping

Boot Sequence

Tier Rules Reference

The Procedural Asymmetry Principle

API Reference