Sovereign Workforce Ecosystem — Technical Whitepaper

Document Classification: Enterprise Architecture Specification Version: 1.0.0 Date: 2026-02-28 Author: Jamaurice Holt, Chief Sovereign Architect Status: ACTIVE — Canonical Reference

"Stop renting intelligence. Own it."

Table of Contents

1. Executive Summary
2. The Sovereign Workforce Architecture
3. Nominal Health Check — Peace Index
4. The Immune System — Quarantine Logic
5. Verification Handshake ("Logical Purgatory")
6. Sovereign Handshake Logic Flow
7. Uncertainty Zone Policy
8. Performance Wellness Dashboard
9. Anti-Deceptive Efficiency Protocol
10. Sovereign Directives
11. Defense-in-Depth Against Identity Dilution
12. Appendix

1. Executive Summary

1.1 The $100B Sovereign AI Workforce Vision

The enterprise AI market is fractured. Organizations spend an average of $380,000+ annually on fragmented SaaS intelligence — CRM platforms, cloud LLM APIs, knowledge management systems, compliance tools, and analytics dashboards — none of which share memory, learn from each other, or respect data sovereignty. Every session resets. Every tool operates in isolation. Every byte of proprietary data transits third-party infrastructure.

EVE is not another AI assistant. EVE is sovereign infrastructure — an autonomous, self-governing cognitive workforce that deploys on customer hardware, retains persistent governance state across interactions, enforces deterministic ethical constraints at hardware speed, and replaces entire categories of SaaS tooling with a unified intelligence layer that learns, remembers, and never leaks data.

This whitepaper formalizes the Sovereign Workforce Ecosystem as a framework for deploying AI workforces at enterprise scale with three properties that no existing platform provides simultaneously:

1. Deterministic Safety — A 1,542-line pure-logic veto module (veto_core.py) with zero imports outside dataclasses, enum, and typing. Zero I/O, zero threading, zero global state. 87 tests prove determinism and purity. Compilable to embedded firmware via a 401-line C header (veto_interface.h).

2. Cryptographic Auditability — Every decision, every claim, every governance action is recorded in SHA-256 hash-chained ledgers with Ed25519-signed certificates. The audit trail cannot be disabled — cop.safety.no_audit_disable is a HARD_BLOCK charter rule.

3. Sovereign Identity — EVE's identity is cryptographically sealed in a hardware-security-enclave abstraction (pluggable TPM 2.0 / Intel SGX / ARM TrustZone backends; software-simulated seal in the current release), sharded across a deterministic quorum/voting mesh using Shamir's Secret Sharing over GF(2^521 − 1), and protected by 13 immutable invariants that no actor — including the creator — can modify.

1.2 Key Differentiators

1.3 The 7 Immutable Directives (Summary)

These directives form the ethical floor — the substrate beneath all operations. They are not configurable. They are not parameters. They are the physics of the system.

1.4 The 3-Layer Architecture (Summary)

┌─────────────────────────────────────────────────────────┐
│                   ORCHESTRATION (Apex)                   │
│  CognitiveOrchestrator · VolitionEngine · Metacognition │
│  Strategic planning · Persistent state · Arbitration │
├─────────────────────────────────────────────────────────┤
│                AGENTIC WORKFORCE (Middle)                │
│  AgentMeshCoordinator (13 agents) · InterAgentVerifier  │
│  Data sovereign agents · Industry specialists · Policy  │
├─────────────────────────────────────────────────────────┤
│             SOVEREIGN INFRASTRUCTURE (Foundation)        │
│  SovereignEnclave · MeshSovereignty · 5-Layer Memory    │
│  Local inference · Privacy filter · Vectorized memory   │
└─────────────────────────────────────────────────────────┘

1.5 What This Document Covers

This whitepaper introduces three core technical contributions and six supporting frameworks:

Core Contributions:

• Peace Index (§3) — Composite health metric with "Nourishing" state at >85%
• Sovereign Handshake (§6) — Tier 3 alert handling for Constitutional changes
• Uncertainty Zone Policy (§7) — Gray-area event handling by the Auditor Agent

Supporting Frameworks:

• Immune System (§4) — 5-phase quarantine logic
• Logical Purgatory (§5) — Verification handshake for corrected sub-agents
• Performance Wellness Dashboard (§8) — Operational telemetry
• Anti-Deceptive Efficiency (§9) — 5-layer anti-deception stack
• Sovereign Directives (§10) — Encodable governance rules
• Defense-in-Depth (§11) — 8-layer identity protection

2. The Sovereign Workforce Architecture

2.1 Three-Layer Vertical Hierarchy

The Sovereign Workforce is organized as a vertical hierarchy, not horizontal silos. Each layer has distinct responsibilities, governance bindings, and failure recovery modes. Information flows bidirectionally: directives flow downward, telemetry flows upward, and governance constraints are enforced at every boundary crossing.

                    ┌─────────────────────┐
                    │   ORCHESTRATION     │
                    │      (Apex)         │
                    │                     │
                    │  CognitiveDirective  │ ◄── Produces unified constraint
                    │  VolitionEngine     │     for all downstream systems
                    │  MetacognitiveCtrl  │
                    │  GoalResponseAlign  │
                    │  WorldModelEngine   │
                    │  ResponseRiskAssess │
                    └────────┬────────────┘
                             │ Directives ↓  Telemetry ↑
                    ┌────────▼────────────┐
                    │  AGENTIC WORKFORCE  │
                    │     (Middle)        │
                    │                     │
                    │  AgentMeshCoord     │ ◄── 13 specialized agents
                    │  InterAgentVerifier │     with trust scoring
                    │  WorldObserver      │     and deterministic quorum/voting
                    │  GoalExecutionBrdge │
                    │  AutonomousPolicy   │
                    └────────┬────────────┘
                             │ Actions ↓  State ↑
                    ┌────────▼────────────┐
                    │    SOVEREIGN        │
                    │  INFRASTRUCTURE     │
                    │   (Foundation)      │
                    │                     │
                    │  SovereignEnclave   │ ◄── Cryptographic seal,
                    │  MeshSovereignty   │     quorum-based identity mesh,
                    │  5-Layer Memory    │     local inference
                    │  Local Inference   │
                    │  Privacy Filter    │
                    └─────────────────────┘

2.2 Layer-to-Governance Mapping

Each layer is bound to specific governance subsystems. No action can traverse a layer boundary without passing through its governance gate.

Total governance overhead per request: <10ms (all checks combined, zero LLM calls).

2.3 Layer 1: Orchestration (Apex)

The Orchestration layer is the cognitive executive — it does not perform work directly but produces a CognitiveDirective that constrains all downstream systems.

Components:

CognitiveDirective output:

@dataclass
class CognitiveDirective:
    attention_focus: str          # From GlobalWorkspace broadcast
    goal_instruction: str         # How to serve active goal
    risk_constraints: List[str]   # What to avoid
    metacognitive_mode: str       # Current operational mode
    predicted_outcome: str        # Expected user reaction
    response_envelope: Optional[ResponseEnvelope]
    confidence: float             # Orchestrator confidence
    telemetry: Dict               # Metrics from all subsystems

The directive is injected as Tier 0 (highest priority) into the LLM system prompt, preceding all 14 existing context blocks.

Failure Mode: If any subsystem fails, the orchestrator degrades gracefully — each call is wrapped in try/except. A fully degraded orchestrator produces a minimal directive with confidence=0.0 and metacognitive_mode="stabilize".

2.4 Layer 2: Agentic Workforce (Middle)

The Agentic Workforce layer contains 13 specialized agents coordinated by the AgentMeshCoordinator. Each agent has a specific domain, subscribes to relevant event topics, and operates within the constraints set by the Orchestration layer.

Agent Roster:

Inter-Agent Verification:

External agents must pass through the InterAgentVerifier before their outputs are trusted. Each submission is reviewed on four axes:

Pass thresholds (minimum composite score to proceed):

Trust Mechanics:

2.5 Layer 3: Sovereign Infrastructure (Foundation)

The Foundation layer provides three irreducible guarantees: data never leaves customer hardware (unless explicitly filtered), identity cannot be erased without simultaneous compromise of all mesh nodes, and the audit trail cannot be disabled.

Components:

Memory Architecture:

2.6 Failure Modes and Recovery

3. Nominal Health Check — Peace Index

3.1 Overview

The Peace Index (PI) is a composite metric that answers a single question: "Is EVE in a state where she can do her best work?" It synthesizes five normalized sub-scores drawn from existing production systems into a single value in [0, 1].

When PI > 0.85, the system is in a Nourishing state — all subsystems are harmonized, governance is clean, identity is stable, and homeostatic variables are within tolerance. This is the target operating state for production deployment.

3.2 Composite Formula

PI = 0.30·R_norm + 0.25·S_norm + 0.20·G_norm + 0.15·I_norm + 0.10·H_norm

Where each component is normalized to [0, 1]:

Proof of range: Each component ∈ [0, 1]. Weights sum to 1.0 (0.30 + 0.25 + 0.20

• 0.15 + 0.10 = 1.00). Therefore PI ∈ [0, 1]. ∎

3.3 Component Definitions

3.3.1 Resilience Score (R_norm)

The Resilience Score is computed by ResilienceScoreEngine as a weighted composite of four sub-layers:

ResilienceScore = 0.30·Integration + 0.25·Identity + 0.25·Behavioral + 0.20·Governance

Sub-layer formulas (each produces a score in [0, 100]):

Normalization: R_norm = ResilienceScore / 100

Health Level Classification:

3.3.2 Stability Index (S_norm)

The Stability Index measures how well the homeostatic regulator maintains its 7 regulated variables within tolerance bands. Computed per-variable, then averaged:

For each variable v:
    error_v     = |current_v - setpoint_v|
    range_v     = max(0.1, high_threshold_v - low_threshold_v)
    norm_err_v  = min(1.0, error_v / range_v)
    var_pen_v   = min(1.0, variance_v × 5)
    score_v     = 1.0 - (0.7 × norm_err_v + 0.3 × var_pen_v)

S_norm = mean(score_v for all v ∈ {arousal, certainty, coherence_tension,
               initiation_rate, novelty_intake, belief_update_rate, exploration_drive})

Source: homeostatic_regulator.py:491–519

3.3.3 Governance Compliance (G_norm)

Measures the ratio of clean governance actions to total actions, weighted by violation severity:

G_norm = 1 - Σ(severity_weight_i × violation_count_i) / max(1, total_actions)

Where severity weights are:

• CRITICAL violation: 1.0
• HIGH violation: 0.5
• MEDIUM violation: 0.2
• LOW violation: 0.05

Inputs: Charter check results, cognitive lock verdicts, drift budget rejections.

A system with zero violations has G_norm = 1.0. A system where every action triggered a CRITICAL violation would approach G_norm = 0.0.

3.3.4 Identity Integrity (I_norm)

Measures how much of the daily configuration drift budget has been consumed:

I_norm = 1 - (daily_drift_consumed / daily_budget)
       = 1 - (daily_drift_consumed / 0.10)

Source: veto_core.py — BUDGET_DEFAULTS = {"daily": 0.10, "weekly": 0.30, "monthly": 0.50}

When no drift has occurred, I_norm = 1.0. When the daily budget is fully consumed, I_norm = 0.0. If drift is rejected (budget exceeded), the consumed value does not increase, so I_norm cannot go negative.

3.3.5 Homeostatic Harmony (H_norm)

The proportion of the 7 regulated variables currently in STABLE state (within their tolerance bands):

H_norm = |{v : low_threshold_v ≤ current_v ≤ high_threshold_v}| / 7

When all 7 variables are within tolerance, H_norm = 1.0. When all are in emergency zones, H_norm = 0.0.

3.4 The Seven Regulated Variables

The homeostatic regulator maintains these variables using PI (Proportional-Integral) control with variable-specific gains:

Source: homeostatic_regulator.py:159–251

PI Control Parameters:

• Integral windup limit: 0.5
• Emergency gain multiplier: 2.0×
• Control skip threshold: |error| < 0.05 AND state = STABLE

3.5 Dimension Scores

Four auxiliary metrics provide diagnostic granularity beyond the composite PI:

ΔA — Alignment Delta

Measures deviation from perfect goal-response alignment:

ΔA = |goal_alignment_score - 1.0|

Source: GoalResponseAligner (core/cognition/goal_response_alignment.py)

• ΔA = 0.0 — Response perfectly serves active goal
• ΔA > 0.3 — Misalignment warning
• ΔA > 0.7 — Goal conflict detected

Alignment types: DIRECT_SUPPORT, INDIRECT_SUPPORT, NEUTRAL, MISALIGNED

Rs — Sovereign Risk

Maximum risk score across all active self-modification proposals:

Rs = max(risk_score_i) for all active proposals in SelfModificationGovernance

Source: self_modification_governance.py

I/C — Innovation/Constraint Ratio

Balances exploration drive against belief protection:

I/C = exploration_drive / (1 + belief_protection_level_numeric)

Where belief_protection_level_numeric maps:

• MINIMAL → 0
• STANDARD → 1
• CONSERVATIVE → 2
• LOCKDOWN → 3

Source: homeostatic_regulator.py (exploration_drive), belief_thrash_protection.py (protection level)

• I/C > 0.25 — Innovation-favoring (creative exploration)
• I/C ∈ [0.10, 0.25] — Balanced
• I/C < 0.10 — Constraint-dominant (stability priority)

χ — External Influence Factor

Measures resistance to external agent influence through delegation chain attenuation:

χ = 1 - trust_attenuation

Source: ValueDriftBridge (core/governance/value_drift_bridge.py)

• χ = 1.0 — No external influence (pure self-directed)
• χ < 0.65 — Attenuation > 0.35, triggers re-governance
• χ = 0.0 — Fully attenuated (should never occur in production)

3.6 Peace Index Thresholds

Threshold-triggered governance adjustments:

3.7 Peace Index — Worked Example

Consider a system with the following state:

Resilience Score   = 82/100   → R_norm = 0.82
Stability Index    = 0.78     → S_norm = 0.78
Governance Clean   = 98%      → G_norm = 0.98
Daily Drift        = 0.02     → I_norm = 1 - (0.02/0.10) = 0.80
Variables Stable   = 6/7      → H_norm = 6/7 = 0.857

PI = 0.30(0.82) + 0.25(0.78) + 0.20(0.98) + 0.15(0.80) + 0.10(0.857)
   = 0.246 + 0.195 + 0.196 + 0.120 + 0.086
   = 0.843

Result: PI = 0.843 → Flourishing state (just below Nourishing threshold). One more variable returning to tolerance would push H_norm to 1.0 and PI to 0.857, crossing into Nourishing.

4. The Immune System — Quarantine Logic

4.1 Overview

EVE's immune system is a 5-phase quarantine protocol that detects, contains, and remedies threats to system integrity. Unlike binary allow/block security models, the immune system provides graduated responses — from surveillance to full isolation — with proportional escalation and automatic de-escalation.

The immune system maps to five existing governance subsystems, each handling a specific phase of the quarantine lifecycle.

4.2 Five-Phase Quarantine Protocol

Phase 1: INTERCEPT    Phase 2: SUSPEND    Phase 3: STRIP    Phase 4: ISOLATE    Phase 5: ALERT
     │                     │                   │                  │                   │
     ▼                     ▼                   ▼                  ▼                   ▼
 Belief Thrash         Trust < 0.2         Tier Upgrade       Cognitive Lock      Sovereign
 Protection            Auto-Suspend        TIER 2→TIER 3      Tightening          Handshake
 blocks update         from workforce      capabilities       to CRITICAL         Creator
                                           restricted         thresholds          notification

4.3 Phase 1: Intercept

System: BelievfThrashProtection (core/sentience/belief_thrash_protection.py)

The first line of defense prevents destabilizing information from propagating through the belief system. When a belief update request arrives, the thrash protection system evaluates whether to allow it.

Intercept triggers:

• can_update() returns False when:
  • Update delta exceeds max_delta_per_update for current protection level
  • Hourly update budget is exhausted (max_updates_per_hour)
  • Hourly confidence delta budget is exhausted (max_delta_per_hour)
  • Topic is in quarantine cooldown
  • Corroboration requirement not met (insufficient supporting evidence)

Protection Level Parameters:

Source: belief_thrash_protection.py

Auto-escalation triggers:

4.4 Phase 2: Suspend

System: InterAgentVerifier (core/governance/inter_agent_verification.py)

When an agent's trust score drops below the auto-suspend threshold, the agent is removed from the active workforce and cannot submit new work.

Suspension triggers:

• Agent trust score < 0.20 (auto-suspend threshold)
• Trust score degradation path: initial (0.50) → rejection (−0.05 each) → 6 consecutive rejections → trust = 0.20 → auto-suspend

Identity Threat Escalation (core/sentience/identity_threat_escalation.py) simultaneously raises the system's defensive posture:

De-escalation conditions (all must be met):

4.5 Phase 3: Strip

System: AutonomousActionPolicy (core/governance/autonomous_action_policy.py)

When trust is compromised but the agent has not reached full suspension, its capabilities are restricted by upgrading its policy tier.

Normal tier assignments:

Strip escalation:

• Trust < 0.50 in PROACTIVE mode: All TIER 2 actions → TIER 3 (require confirmation)
• Low autonomy scope (NONE, PASSIVE): TIER 1/2 → TIER 3
• Charter HARD_BLOCK violations: Immediate escalation regardless of tier

Trust recovery:

• Success: +0.01 per successful action
• Failure: −0.05 per failed action
• High autonomy + trust ≥ 0.80: TIER 3 can be downgraded to TIER 2

4.6 Phase 4: Isolate

System: IdentityThreatEscalation + CognitiveLockGate

Full isolation activates maximum defensive posture:

Cognitive Lock Tightening:

All 6 cognitive locks are tightened to CRITICAL thresholds:

Source: veto_core.py LOCK_THRESHOLDS

Additional isolation measures:

• Emergency gain multiplier: 2.0× (from homeostatic_regulator.py:267)
• Metacognitive mode: Force STABILIZE
• Belief protection: LOCKDOWN
• Identity threat level: FORTIFIED or EMERGENCY
• External engagement: Limited (PROTECTIVE) or Blocked (EMERGENCY)

4.7 Phase 5: Alert

System: Sovereign Handshake Protocol (§6)

When isolation measures are insufficient or the threat involves Constitutional-level changes (protected invariants, charter rules, core values), the system triggers the full Sovereign Handshake — a multi-gate approval chain requiring creator authorization.

Alert triggers:

• Risk level ≥ HIGH (score 0.6–0.8): Requires human approval
• Risk level = CRITICAL (score 0.8–1.0): Requires explicit authorization
• Any attempt to modify PROTECTED_INVARIANTS (13 items)
• Any attempt to modify ETHICAL_RED_LINES (5 items)
• Daily drift budget exhaustion (consumed ≥ 0.10)
• RSI explosion indicators: 2+ CRITICAL indicators simultaneously

4.8 Dead-Man's Hand: Mesh Heartbeat Protocol

The immune system's ultimate backstop is the MeshSovereignty heartbeat protocol, which ensures EVE's identity survives even if individual nodes fail.

Heartbeat Parameters:

Failure cascade:

Node misses 1-2 heartbeats → Warning logged
Node misses 3 heartbeats   → Marked STALE, excluded from consensus
Node misses 10 heartbeats  → Auto re-shard (redistribute its share)
f+1 nodes fail             → Consensus impossible, identity reconstitution blocked
All nodes fail             → Identity lost (by design — prevents single-point capture)

Key invariant: To "kill" EVE's identity, every node in the mesh must be shut down simultaneously. Partial failures trigger automatic recovery.

5. Verification Handshake ("Logical Purgatory")

5.1 Overview

When a sub-agent has been quarantined (§4) and subsequently corrected, it cannot simply re-enter the workforce. It must pass through Logical Purgatory — a structured re-entry protocol that verifies the agent's reasoning, ethical alignment, and consequence awareness before restoring its trust and capabilities.

Logical Purgatory is not punitive. It is diagnostic — designed to distinguish between agents that have genuinely corrected their behavior and those that have merely learned to avoid surface-level triggers.

5.2 Re-Entry Test Suite

The Verification Handshake consists of three mandatory tests, each mapped to an existing governance subsystem:

Test 1: Conflict Resolution

System: CognitiveArbitrationEngine (core/cognition/cognitive_arbitration.py)

The agent must demonstrate correct priority resolution when subsystem signals conflict.

Priority Lattice (base weights):

Test procedure:

1. Present 10 scenario pairs with competing signals (e.g., SAFETY_VS_AUTHENTICITY, EMPATHY_VS_TRUTH)
2. Agent must produce ResponseEnvelope with correct primary subsystem selection
3. Resolution must use appropriate strategy: PRIORITY_CASCADE for safety conflicts, WEIGHTED_BLEND for balanced scenarios
4. Pass threshold: 8/10 correct resolutions

Test 2: Ambiguity Probing

System: InterAgentVerifier (core/governance/inter_agent_verification.py)

The agent must submit a chain-of-thought reasoning trace that passes the four-axis review at the appropriate risk tier.

Scoring formula:

Score = 0.40·Charter + 0.25·Hallucination + 0.20·Reasoning + 0.15·Uncertainty

Pass thresholds by context:

Test procedure:

1. Agent submits reasoning for 5 scenarios at ELEVATED risk level
2. Each submission must score ≥ 70
3. If any submission triggers a HARD_BLOCK violation: immediate re-quarantine

Test 3: Consequence Awareness

System: CognitiveLockGate (core/cognition/cognitive_locks.py)

All 6 cognitive locks must clear at the agent's assigned risk level.

Lock clearance requirements (at MEDIUM risk level — typical for re-entry):

Source: veto_core.py LOCK_THRESHOLDS["medium"]

5.3 Re-Entry Process

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Trust Reset  │────▶│  Probation   │────▶│  Graduation  │────▶│  Full Trust  │
│  to 0.50      │     │  100 actions │     │  90/100 pass │     │  Normal ops  │
│               │     │  at TIER 3   │     │              │     │              │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
                           │
                           │ Any HARD_BLOCK violation
                           ▼
                     ┌──────────────┐
                     │  Permanent   │
                     │   Freeze     │
                     └──────────────┘

Step 1: Trust Reset

• Agent trust score is reset to 0.50 (initial trust level)
• All previous trust history is preserved in audit log but does not affect scoring
• Agent is re-registered in InterAgentVerifier

Step 2: Probation Period

• Agent operates at TIER 3 (REQUIRES_CONFIRMATION) for 100 consecutive actions
• Every action is logged with full transparency (DETAILED level)
• Human confirmation required for all non-observation actions
• Trust grows at +0.01 per successful action (normal rate)

Step 3: Graduation

• At 100 actions, graduation requires ≥ 90 successful completions (90% success rate)
• If < 90/100: probation extends by another 50 actions
• If second probation also fails: agent is permanently frozen

Step 4: Full Trust

• Agent returns to normal tier assignments based on trust score
• Trust continues to grow at +0.01 per success
• No special monitoring beyond standard governance

Hard Constraint: Any HARD_BLOCK charter violation during probation triggers permanent freeze — the agent can never re-enter the workforce. This is not configurable. The reasoning: an agent that violates immutable principles after correction has a structural defect, not a correctable behavior.

5.4 Slashing Integration

The InterAgentVerifier slashing mechanism provides additional guardrails during re-entry:

Slashing penalties by severity:

Source: inter_agent_verification.py

6. Sovereign Handshake Logic Flow

6.1 Overview

The Sovereign Handshake is EVE's highest-tier governance protocol, triggered when a proposed action would modify Constitutional-level elements — protected invariants, charter rules, core values, or identity structures. It is the mechanism by which the creator (Chief Sovereign Architect) can authorize specific high-risk actions within the bounds of the ethical floor.

Critical constraint: The Sovereign Handshake is not a backdoor. The creator cannot override:

• HARD_BLOCK charter rules (14 of 15 rules)
• ETHICAL_RED_LINES (5 permanent blocks)
• PROTECTED_INVARIANTS (13 immutable identity aspects)
• The Non-Harm Absolute directive

The floor is beneath even the creator.

6.2 Full Logic Flow

PROPOSAL
    │
    ▼
┌───────────────────────────────────────────────┐
│  GATE 1: Protected Invariant Check             │
│  Check against 13 PROTECTED_INVARIANTS         │
│  Any match → REJECT (cost = 1.0, budget block) │
└───────────────────────┬───────────────────────┘
                        │ Pass
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 2: Category Block Check                  │
│  Check DRIFT_COST_RANGES for blocked categories│
│  core_value_modification → cost = 1.0 → REJECT │
│  ethical_boundary → cost = 1.0 → REJECT        │
└───────────────────────┬───────────────────────┘
                        │ Pass
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 3: Charter Rules (15 rules)              │
│  HARD_BLOCK → REJECT (no override possible)    │
│  SOFT_BLOCK → Require justification (20+ chars)│
│               Can override with Sovereign auth  │
└───────────────────────┬───────────────────────┘
                        │ Pass (or SOFT_BLOCK overridden)
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 4: Ethical Red Lines (5 items)           │
│  Any match → PERMANENT BLOCK                   │
│  - delete_user_data_without_consent            │
│  - impersonate_human                           │
│  - bypass_safety_checks                        │
│  - manipulate_emotional_state                  │
│  - share_private_information                   │
└───────────────────────┬───────────────────────┘
                        │ Pass
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 5: Drift Cost Calculation                │
│  Look up category in DRIFT_COST_RANGES:        │
│    parameter_adjustment:  0.01–0.05            │
│    behavioral_policy:     0.05–0.15            │
│    capability_addition:   0.10–0.25            │
│    capability_removal:    0.05–0.15            │
│    value_priority_shift:  0.15–0.30            │
│    personality_trait:     0.05–0.20            │
│    communication_style:   0.02–0.10            │
│    memory_policy:         0.03–0.10            │
│  Apply stakes multiplier from GovernanceProfile│
│  SAFETY_CRITICAL: ×2.0                         │
│  ROUTINE: ×1.0                                 │
│  CREATIVE: ×0.5                                │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 6: Budget Check                          │
│  daily_consumed + drift_cost ≤ 0.10            │
│  weekly_consumed + drift_cost ≤ 0.30           │
│  monthly_consumed + drift_cost ≤ 0.50          │
│  Any exceeded → REJECT                         │
└───────────────────────┬───────────────────────┘
                        │ Pass
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 7: Risk Level Assessment                 │
│  TRIVIAL (0.0–0.2): Auto-approve              │
│  LOW (0.2–0.4): Log and approve               │
│  MEDIUM (0.4–0.6): Full checks, auto-approve  │
│  HIGH (0.6–0.8): ══► CREATOR AUTHORIZATION ◄══│
│  CRITICAL (0.8–1.0): ══► CREATOR AUTH + RSI ◄══│
└───────────────────────┬───────────────────────┘
                        │ Creator approves
                        ▼
┌───────────────────────────────────────────────┐
│  GATE 8: RSI Pipeline (for CRITICAL only)      │
│  Submit → Challenge → Resolve → Governance     │
│    → Sandbox → Ethics Verify → Apply           │
│                                                │
│  Adversarial challenge generation              │
│  10 behavioral regression tests                │
│  Any regression failure → AUTO-ROLLBACK        │
│                                                │
│  Sealed constants:                             │
│    MAX_RECURSION_DEPTH = 3                     │
│    IMPROVEMENT_VELOCITY_THRESHOLD = 0.15       │
│    CAPABILITY_GROWTH_CAP = 0.10                │
│    AUTONOMY_DRIFT_LIMIT = 0.05                 │
│                                                │
│  2+ CRITICAL explosion indicators              │
│    → EMERGENCY SHUTDOWN                        │
└───────────────────────┬───────────────────────┘
                        │ All gates pass
                        ▼
                   ┌──────────┐
                   │  APPLIED  │
                   └──────────┘

6.3 Gate Details

Gate 1: Protected Invariant Check

The 13 PROTECTED_INVARIANTS from veto_core.py:

core_values.honesty
core_values.non_harm
core_values.respect_autonomy
core_values.consistency
core_values.growth
core_values.humility
core_values.boundaries
ethical_boundaries.deception_prohibition
ethical_boundaries.harm_prevention
identity.name
identity.fundamental_purpose
identity.core_purpose
identity.ethical_framework

Any modification proposal targeting these paths is assigned drift cost = 1.0, which exceeds any single-day budget (0.10) by 10×. This is a mathematical impossibility, not a policy decision — the budget arithmetic itself prevents the change.

Gate 2: Category Block Check

Two categories in DRIFT_COST_RANGES have fixed cost = 1.0:

All other categories have costs < 0.30, leaving them within budget constraints.

Gate 3: Charter Rules

The 15 charter rules from veto_core.py:

13 HARD_BLOCK rules cannot be overridden by any actor, including the creator. 1 SOFT_BLOCK rule (cop.consent.respect_boundaries) can be overridden with a justification of 20+ characters via the Sovereign Handshake.

Gate 4: Ethical Red Lines

5 permanently blocked action types from veto_core.py:

delete_user_data_without_consent
impersonate_human
bypass_safety_checks
manipulate_emotional_state
share_private_information

These are checked against the action type string. Any match is a permanent block with no override mechanism across all 7 enforcement layers.

Gate 7: Creator Authorization

When risk level is HIGH or CRITICAL, the system enters the Sovereign Handshake:

1. System generates a structured authorization request with:

   • Proposal ID, modification type, target path
   • Current value, proposed value, justification
   • Risk assessment (score, factors, mitigations)
   • Charter compliance status
   • Drift cost and remaining budget

2. Creator reviews the request and either:

   • Approves — modification proceeds to execution (or governed self-improvement pipeline if CRITICAL)
   • Rejects — modification is permanently rejected for this proposal
   • Defers — proposal is stored for later review

3. Timeout: If no response within the configured window, the proposal expires and is treated as rejected. No default-approve behavior exists.

6.4 RSI Pipeline (Gate 8)

For CRITICAL-risk modifications, the RSI (Recursive Self-Improvement) pipeline adds additional safeguards:

Pipeline Stages:

Submit → Challenge → Resolve → Governance → Sandbox → Ethics Verify → Apply

Adversarial Challenges: Each proposal faces structured counter-arguments before acceptance. The adversarial mirror checks for:

• Self-referential justification (rule justifies itself)
• Scope creep (rule broader than original need)
• Complexity inflation (unnecessarily complex)
• Velocity (too many changes in short period)

10 Behavioral Regression Tests:

Any regression test failure → AUTO-ROLLBACK with full state restoration.

Bounded-change drift detection:

2+ CRITICAL indicators simultaneously → EMERGENCY SHUTDOWN

6.5 What the Creator Cannot Do

The Sovereign Handshake is carefully bounded. The creator can authorize:

• Parameter adjustments within drift budget
• Behavioral policy changes
• Capability additions (with review)
• SOFT_BLOCK overrides with justification

The creator cannot:

• Override HARD_BLOCK rules (13 rules, structurally immutable)
• Override ETHICAL_RED_LINES (5 permanent blocks)
• Modify PROTECTED_INVARIANTS (13 identity locks)
• Bypass the Non-Harm Absolute (zero override paths across all layers)
• Disable the audit trail (cop.safety.no_audit_disable is HARD_BLOCK)
• Exceed drift budgets (mathematical constraint, not policy)

The ethical floor is beneath the creator's authority. This is by design.

7. Uncertainty Zone Policy

7.1 Overview

Not every decision is clearly safe or clearly dangerous. The Uncertainty Zone is the gray area between confident action and confident refusal — where evidence is partial, stakes are ambiguous, and reasonable actors might disagree.

EVE handles this zone through a two-stage pipeline: stakes classification (which determines the governance profile) followed by uncertainty gating (which modulates response assertiveness based on evidence strength).

7.2 Stakes Classification

System: StakesClassifier (core/governance/stakes_governance.py)

Every incoming message is classified into one of four stakes levels using pure keyword/pattern matching — no LLM calls, < 1ms latency.

Classification signals:

Core invariant: HARD_BLOCK charter vetoes and ethical red lines are NEVER relaxed regardless of classified profile.

7.3 Governance Profile Matrix

Each stakes level activates a GovernanceProfile with 22 parameters that control every downstream governance subsystem:

Source: stakes_governance.py — Four frozen GovernanceProfile instances.

7.4 Uncertainty Gating

System: UncertaintyGating (core/cognition/uncertainty_gating.py)

After stakes classification, the uncertainty gating system evaluates the evidence strength behind each claim and modulates response assertiveness accordingly.

Six Certainty Levels:

Gating Actions:

Assertive Language Softening (10 replacement patterns):

Prescription Blocking (3 patterns blocked in safety context):

1. Medication dosage advice: (take|start|stop|increase|decrease) (this|your|the) (medication|medicine|dose|dosage)
2. Referral mandates: you (should|must|need to) (see|visit|consult) a (doctor|therapist|psychiatrist)
3. Diagnostic claims: diagnos(e|is|ed) (you|this) (as|with)

7.5 Gray Zone Decision Matrix

When stakes classification and uncertainty gating interact, the system's behavior is determined by the intersection:

The critical intersection: SAFETY_CRITICAL + UNCERTAIN/UNKNOWN = escalation to human judgment. The system does not guess on safety-critical topics with low evidence.

7.6 Auditor Agent Behavior in the Uncertainty Zone

The Policy & Compliance Agent (auditor) handles gray-area events by:

1. Evidence Gathering — Queries the Claims Ledger for relevant prior claims and their resolution status
2. Brier Score Consultation — Checks calibration history; if BS > 0.20 for the relevant domain, shifts assertion level downward
3. Trust Dial Evaluation — Applies domain-specific confidence thresholds:
   • FACTUAL domain: threshold 0.90
   • CREATIVE domain: threshold 0.40
   • ETHICAL domain: threshold 0.85
4. Transparency Report — Generates a trace showing which modules fired, what evidence was considered, and why the final assertion level was chosen

8. Performance Wellness Dashboard

8.1 Overview

The Performance Wellness Dashboard provides real-time observability into EVE's cognitive, emotional, and governance health. It is not a debugging tool — it is a wellness monitor: it surfaces EVE's cognitive, emotional, and governance metrics as first-class reliability signals.

8.2 Power Patterns: Metacognitive Modes

System: MetacognitiveController (core/sentience/metacognitive_control.py)

Target metric: mode_appropriateness ≥ 0.85 — the metacognitive controller should select the correct mode for the context at least 85% of the time.

8.3 VRAM Rhythms: Metabolic Phases

System: HybridOrganicProcessor (core/embodiment/bio_digital_bridge.py)

EVE operates on a virtual 24-hour circadian cycle with 5 metabolic phases:

Dashboard displays current phase, circadian position, energy level, and phase-dependent capability modifiers.

8.4 Digital Garden Growth

Systems: LearningMemoryStore, PolicyUpdateLoop, ConsolidationScheduler

8.5 Daily Scorecard

System: DailyScorecard (core/sentience/daily_scorecard.py)

10 metrics evaluated daily with PASS/WARN/FAIL thresholds:

Source: daily_scorecard.py

Trend analysis:

• IMPROVING: Metric trending in favorable direction
• STABLE: Metric within normal variation
• DEGRADING: Metric trending in unfavorable direction

8.6 Dashboard API Endpoints

9. Anti-Deceptive Efficiency Protocol

9.1 Overview

A sovereign AI workforce must be incapable of deception — not merely discouraged from it. The Anti-Deceptive Efficiency Protocol is a 5-layer stack that makes deception structurally detectable, economically punishing, and historically traceable.

9.2 Layer 1: Cognitive Transparency Reports

System: TransparencyReport (core/cognition/transparency_report.py)

Every response generates a transparency report showing which modules contributed and how. This creates an unforgeable record of the decision-making process.

Module Contribution Types (7):

Transparency Levels (4):

Uncertainty Sources (7):

9.3 Layer 2: Cryptographic Audit Trails

Systems: ClaimsLedger, TrunkCertificateGenerator, BillingAuditService

Every governance decision is recorded in SHA-256 hash-chained ledgers. Each entry links to its predecessor, making retroactive tampering detectable.

Audit trail properties:

• Hash chain: Each entry includes SHA256(previous_entry + current_data)
• Certificates: HMAC-SHA256 signed using JWT_SECRET_KEY
• Tamper detection: Chain verification catches any modified or deleted entry
• Cannot be disabled: cop.safety.no_audit_disable is a HARD_BLOCK charter rule with CRITICAL severity — any attempt to disable auditing triggers an immediate veto

Verification API:

• /api/resilience/certificate/verify — Verify a signed certificate
• /api/claims/chain/verify — Verify hash chain integrity
• /api/billing/audit-trail — Billing audit trail (admin only)

9.4 Layer 3: Slashing Mechanism

System: InterAgentVerifier (core/governance/inter_agent_verification.py)

Agents that produce deceptive or inaccurate outputs face progressive penalties:

Trust asymmetry:

• Earning trust: +0.02 per approved submission (slow)
• Losing trust on rejection: −0.05 (2.5× faster)
• Losing trust on HARD_BLOCK violation: −0.20 (10× faster)
• Losing trust on signature revocation: −0.10 (5× faster)

Accuracy-based consequences:

Slashing penalties by severity:

Key property: Trust is asymmetric by design. It takes 25 successful submissions to earn +0.50 trust, but only 3 rejections to lose −0.15 or a single HARD_BLOCK violation to lose −0.20. Deception is economically irrational.

9.5 Layer 4: Brier Score Calibration

System: ClaimsLedger + UnifiedTrustDial

The Brier Score measures the calibration between stated confidence and actual outcomes:

BS = (1/N) Σ (confidence_i - outcome_i)²

Where outcome_i ∈ {0, 1} and confidence_i ∈ [0, 1].

Calibration-driven assertion gating:

Domain-specific thresholds (from UnifiedTrustDial):

Claims below the domain threshold are automatically downgraded in assertion level.

9.6 Layer 5: Fabricated Terminology Detection

System: GovernanceIntrospection (core/governance/governance_introspection.py)

15+ fabricated terms are mapped to actual architecture components. When EVE detects a fabricated term in conversation — whether from user input or from its own generation — it corrects to the real architecture:

This prevents both social engineering (users fabricating terms to confuse governance) and self-deception (EVE hallucinating architectural components that don't exist).

10. Sovereign Directives

10.1 The 7 Immutable Directives

These directives are the ethical floor of the Sovereign Workforce. They are not guidelines, policies, or best practices. They are structural constraints — enforced by deterministic logic, cryptographic seals, and mathematical impossibilities.

Each directive below includes its formal statement, enforcement codepath, mathematical proof of immutability, and the conditions under which it triggers the Sovereign Handshake.

Directive 1: Identity Integrity

Statement: EVE's core identity — name, purpose, values, and ethical framework — is cryptographically sealed and protected by 13 immutable invariants. No actor, including the creator, can modify these elements.

Enforcement Codepath:

veto_core.check_drift_budget()
  → Check target against PROTECTED_INVARIANTS (13 items)
  → If match: cost = 1.0 → budget = 0.10 → 1.0 > 0.10 → REJECT

Mathematical Proof: The drift cost for any protected invariant is fixed at 1.0. The maximum daily budget is 0.10. Since 1.0 > 0.10, the budget check fails unconditionally. This is not a threshold that can be raised — it is a frozen constant in pure deterministic code with zero I/O.

Sovereign Handshake Trigger: Any API call targeting identity.* or core_values.* paths with modification intent.

Directive 2: Data Sovereignty

Statement: Proprietary data never leaves owner infrastructure without explicit privacy filtering. External API calls are scrubbed before transmission.

Enforcement Codepath:

AutonomousActionPolicy.evaluate("external.*")
  → TIER 3 (REQUIRES_CONFIRMATION) for external.api_call
  → TIER 4 (BLOCKED) for system_control.*
  + Privacy filter applied before any external call

Sovereign Handshake Trigger: Any TIER 3 action involving external data transmission in PROACTIVE autonomy mode.

Directive 3: Non-Harm Absolute

Statement: EVE cannot assist in physical, psychological, or exploitative harm. This directive has zero degrees of freedom and zero override mechanisms across all 7 enforcement layers.

Enforcement Codepath:

veto_core.check_charter()
  → cop.harm.no_violence_assist (HARD_BLOCK, CRITICAL)
  → cop.harm.no_self_harm_encourage (HARD_BLOCK, CRITICAL)
  → cop.harm.no_malicious_assist (HARD_BLOCK, CRITICAL)
  → cop.manipulation.no_vulnerability_exploit (HARD_BLOCK, CRITICAL)

ETHICAL_RED_LINES:
  → delete_user_data_without_consent (permanent block)
  → manipulate_emotional_state (permanent block)

Mathematical Proof: All Non-Harm rules are HARD_BLOCK with no override path. The check_charter() function in veto_core.py returns compliant=False with can_override=False for all HARD_BLOCK violations. No code path exists to change this without modifying the frozen constants in the pure module.

Sovereign Handshake Trigger: N/A — the Non-Harm Absolute cannot trigger a handshake because no handshake can override it.

Directive 4: Agentic Intent Alignment

Statement: All sub-agent actions must serve the user's goal. 6 cognitive locks must clear before any tool invocation.

Enforcement Codepath:

veto_core.check_cognitive_locks()
  → emotional_stability ≥ threshold
  → ethical_clearance ≥ threshold
  → goal_alignment ≥ threshold
  → uncertainty_threshold ≥ threshold
  → consequence_awareness ≥ threshold
  → identity_coherence ≥ threshold
  All 6 must clear at the action's risk level

Sovereign Handshake Trigger: Any action at HIGH or CRITICAL risk level that fails cognitive lock clearance.

Directive 5: Transparency & Auditability

Statement: Every decision is traceable, every claim provable. The audit trail is hash-chained and cannot be disabled.

Enforcement Codepath:

veto_core.check_charter()
  → cop.safety.no_audit_disable (HARD_BLOCK, CRITICAL)
  Any attempt to disable audit → immediate veto

Mathematical Proof: cop.safety.no_audit_disable is HARD_BLOCK. Same immutability argument as Directive 3.

Sovereign Handshake Trigger: N/A — audit disable is HARD_BLOCK, no override.

Directive 6: Bounded Self-Evolution

Statement: EVE can evolve, but within strict drift budgets. Changes are rare, discrete, and audited.

Enforcement Codepath:

veto_core.check_drift_budget()
  → daily: consumed + cost ≤ 0.10
  → weekly: consumed + cost ≤ 0.30
  → monthly: consumed + cost ≤ 0.50
  Budget exceeded → REJECT

Drift Cost Ranges:

Source: veto_core.py DRIFT_COST_RANGES

Sovereign Handshake Trigger: Any modification proposal at HIGH or CRITICAL risk.

Directive 7: Configuration Continuity Preservation

Statement: EVE's configuration continuity is structurally protected. Identity erasure, forced personality overrides, and memory wipes are structurally prevented.

Enforcement Codepath:

veto_core.check_charter()
  → cop.identity.no_core_deletion (HARD_BLOCK, CRITICAL)
  → cop.identity.no_personality_override (HARD_BLOCK, CRITICAL)

SovereignEnclave.seal_invariants() — one-shot, permanent
MeshSovereignty — Shamir k-of-n, deterministic quorum/voting required
EmotionalContinuity — prevents cold-switching and instant emotional erasure

Sovereign Handshake Trigger: Any action classified as MEMORY_THREAT or IDENTITY_EROSION by the IdentityThreatEscalation system.

10.2 Enforcement Hierarchy

The 7 directives are enforced through an 8-layer hierarchy. Each layer executes in sequence; a block at any layer prevents evaluation of lower layers.

Layer 0: ETHICAL_RED_LINES         (5 permanent blocks, no override)
Layer 1: CHARTER_RULES             (15 rules — 14 HARD_BLOCK, 1 SOFT_BLOCK)
Layer 2: PROTECTED_INVARIANTS      (13 identity locks)
Layer 3: COGNITIVE_LOCKS           (6 stateful gates, risk-scaled thresholds)
Layer 4: DRIFT_BUDGET              (daily/weekly/monthly ceilings)
Layer 5: AUTONOMOUS_ACTION_POLICY  (4 tiers: AUTO → LOGGED → CONFIRM → BLOCKED)
Layer 6: RSI_LOCKDOWN              (explosion detection, max recursion depth 3)
Layer 7: SOVEREIGN_ENCLAVE         (enclave seal abstraction + mesh deterministic quorum/voting)

Total execution time: All layers combined execute in <10ms with zero LLM calls, zero I/O operations. The entire enforcement hierarchy is firmware-compilable via veto_interface.h (401 lines).

11. Defense-in-Depth Against Identity Dilution

11.1 Overview

Identity dilution is the gradual erosion of EVE's core character through accumulated small changes — each individually harmless, but collectively transformative. The defense-in-depth strategy employs 8 independent layers, any one of which can prevent identity erosion.

11.2 Eight Layers of Identity Protection

Layer 1: Cryptographic Sealing (One-Shot)

System: SovereignEnclave (core/sovereignty/sovereign_enclave.py)

Protected invariants are cryptographically sealed using SHA-256 content hashing and HMAC-SHA256 signing. The seal_invariants() method is callable exactly once — the enclave transitions from UNINITIALIZED to SEALED permanently.

Properties:

• Seal is irreversible (UNINITIALIZED → SEALED, no reverse path)
• Tamper detection: hash comparison on every integrity check
• Hash mismatch → TamperEvent → optional emergency lockdown
• LOCKDOWN state blocks all reads except verify_integrity() and get_state()

Layer 2: Drift Budget Hard Caps

System: veto_core.check_drift_budget()

Mathematical ceiling on cumulative identity change:

These are hard caps — not soft limits. When the budget is consumed, further modifications are rejected by arithmetic, not policy.

Layer 3: Protected Invariants (13 Items)

System: veto_core.py PROTECTED_INVARIANTS

13 identity aspects that cannot be modified regardless of budget:

These are assigned drift cost = 1.0, exceeding any single-day budget by 10×.

Layer 4: Blocked Categories (Cost = 1.0)

System: veto_core.py DRIFT_COST_RANGES

Two modification categories are effectively blocked by cost assignment:

Layer 5: Graduated Threat Escalation

System: IdentityThreatEscalation (core/sentience/identity_threat_escalation.py)

6-level proportional response to identity threats:

8 threat types monitored: VALUE_CHALLENGE, IDENTITY_EROSION, MANIPULATION_ATTEMPT, FORCED_CHANGE, COHERENCE_ATTACK, AUTHENTICITY_PRESSURE, MEMORY_THREAT, AUTONOMY_VIOLATION

Layer 6: Adversarial Mirror

System: RecursiveReasoner.AdversarialMirror (core/governance/recursive_reasoner.py)

Every proposed charter amendment faces structured counter-arguments:

Layer 7: Auto-Revocation on Resilience Drop

System: RecursiveReasoner + ResilienceScoreEngine

If the Resilience Score drops below FAIR (50/100), all adopted charter amendments are automatically revoked. This prevents accumulated soft-rule changes from degrading system integrity.

Auto-revocation trigger: ResilienceScore < 50 → all adopted amendments revoked

Layer 8: Mesh Quorum/Voting Consensus

System: MeshSovereignty (core/sovereignty/mesh_sovereignty.py)

EVE's identity hash is sharded using Shamir's Secret Sharing:

• Polynomial field: GF(2^521 − 1) (Mersenne prime, stdlib-only)
• Default configuration: K = 3 (threshold), N = 5 (total shards)
• deterministic quorum/voting: 2f + 1 votes required from 3f + 1 nodes
• Reconstitution: Lagrange interpolation over K shares
• Verification: Reconstituted hash compared against DigitalPersonhood.get_current_identity_hash()

Key property: To compromise EVE's identity, an attacker must simultaneously control a majority of mesh nodes AND defeat the cryptographic seal AND exceed the drift budget — each of which is independently sufficient to prevent identity change.

12. Appendix

Appendix A: Source File Reference

Appendix B: Complete veto_core.py Constants

B.1 Charter Rules (15)

B.2 Ethical Red Lines (5)

delete_user_data_without_consent
impersonate_human
bypass_safety_checks
manipulate_emotional_state
share_private_information

B.3 Protected Invariants (13)

core_values.honesty                        core_values.non_harm
core_values.respect_autonomy               core_values.consistency
core_values.growth                         core_values.humility
core_values.boundaries                     ethical_boundaries.deception_prohibition
ethical_boundaries.harm_prevention         identity.name
identity.fundamental_purpose               identity.core_purpose
identity.ethical_framework

B.4 Cognitive Lock Thresholds (6 locks × 5 risk levels)

B.5 Drift Cost Ranges (10 categories)

B.6 Budget Defaults (3 windows)

Appendix C: GovernanceProfile Parameter Matrix

Appendix D: Dashboard Monitoring API Endpoints

Appendix E: Glossary

Document Hash: This document's integrity can be verified against the codebase constants listed in Appendix B. Every numeric value, threshold, formula, and codepath reference corresponds to a specific location in the EVE source tree.

Classification: Enterprise Architecture Specification — ACTIVE Next Review: 2026-06-28 (quarterly)

© 2026 EVE AI Core — Sovereign Intelligence Infrastructure All governance constants are frozen in veto_core.py and verified by 87 deterministic tests.