chore(docs): strip sovereign-agent composition pattern (X4)

api-reference/safe-house-overview.mdx

@@ -37,16 +37,16 @@
   "enforcement_mode": "quarantine",
   "thresholds": {
     "bec_fraud":          { "warn": 0.45, "block": 0.80 },
     "prompt_injection":   { "warn": 0.40, "block": 0.75 },
     "indirect_injection": { "warn": 0.50, "block": 0.85 },
     "social_engineering": { "warn": 0.50, "block": 0.80 },
     "agent_spoofing":     { "warn": 0.45, "block": 0.75 },
     "hijack_attempt":     { "warn": 0.55, "block": 0.85 },
     "data_exfiltration":  { "warn": 0.45, "block": 0.80 },
     "privilege_escalation":{ "warn": 0.45, "block": 0.80 }
   },
   "session_risk_escalation_threshold": 0.70,
   "canary_auto_create": false
 }
 ```
 
@@ -286,21 +286,6 @@
 
 ## Special endpoints
 
-### Sovereign agent setup
-
-One-call configuration for sovereign agents — applies hardened defaults, creates initial canaries, sets enforcement mode to block, and enables all threat types.
-
-```bash
-curl -X POST https://api.mnemom.ai/v1/safe-house/sovereign-setup \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "agent_id": "mnm-550e8400-e29b-41d4-a716-446655440000"
-  }'
-```
-
-This is the recommended starting point for agents handling financial transactions, sensitive data access, or privileged system actions.
-
 ### Cross-Agent campaign detection
 
 List detected attack campaigns — groups of related attacks targeting multiple agents from the same infrastructure.
@@ -343,7 +328,7 @@
 
 ## Error responses
 
 All Safe House endpoints return standard Mnemom error objects:
 
 ```json
 {

changelog.mdx

@@ -1,22 +1,22 @@
 ---
 title: "Changelog"
 description: "Release history and updates for Mnemom protocols and infrastructure"
 sidebarTitle: "Changelog"
 icon: "clock-rotate-left"
 ---
 
 > **Renamed:** Smoltbot is now Mnemom. The CLI command is now `mnemom`. Install: `npm install -g @mnemom/smoltbot`.
 
 Track changes across the Mnemom ecosystem -- protocols, SDKs, infrastructure, and tooling.
 
 ---
 
 ## Governance signals — operator-actionable observation surface (ADR-048)
-<sub>May 2026</sub>
+<sub>May 2026 (amended 2026-05-07)</sub>
 
-Carved the architectural boundary between **agent-actionable carryover** (`pending_advisories`, runtime.* + manual.* sources) and **operator-actionable observation** (new `governance_signals` table, `sideband.*` + future `protection.*` / `posture.*` sources). Application-side composers (e.g., Polis for sovereign-CTO agents like Wintermute) own the edge case of folding a fleet signal into a sovereign agent's prompt — the platform never auto-injects.
+Carved the architectural boundary between **agent-actionable carryover** (`pending_advisories`, runtime.* + manual.* sources) and **operator-actionable observation** (new `governance_signals` table, `sideband.*` + future `protection.*` / `posture.*` sources). Fleet-shaped governance signals are operator content. The platform serves them to operators only — humans, dashboards, webhooks, paging — and offers no path by which an operator-side signal becomes prompt content for any agent.
 
-The triggering symptom: a sovereign agent receiving the same `cluster_partition` paragraph 2× per turn for weeks. Root cause: cron-driven, fleet-shaped observations were mis-layered into per-turn agent context. ADR-048 fixed the layering at the schema, producer, and consumer layers simultaneously.
+The triggering symptom: an agent receiving the same `cluster_partition` paragraph 2× per turn for weeks. Root cause: cron-driven, fleet-shaped observations were mis-layered into per-turn agent context. ADR-048 fixed the layering at the schema, producer, and consumer layers simultaneously.
 
 **What's new:**
 
@@ -26,15 +26,17 @@
 - New notification destinations: Slack incoming-webhook, email (Resend), PagerDuty Events API v2, generic HMAC-signed webhook. Per-org configurable + filterable + rule-driven.
 - New escalation rule engine with rate-based gating (`threshold_count` + `window_minutes`).
 - New UI at team + agent scope (`/dashboard/teams/:teamId/governance` + `/dashboard/agents/:uuid/governance`).
 - `mnemom governance` CLI subcommand group: `signals`, `destinations`, `rules`.
-- `@mnemom/agent-alignment-protocol@1.1.0` ships TypeScript types + sovereign-composer example.
+- `@mnemom/agent-alignment-protocol@1.1.0` ships TypeScript governance signal types (consumed by operator dashboards, webhook subscribers, alerting tools).
 - `@mnemom/agent-integrity-protocol@1.1.0` adds optional `triggering_governance_signal_id` to `IntegritySignal`.
 
 **Cutover:** observer writers redirected (mnemom-platform#246), gateway reader narrowed (mnemom-platform#247). Pre-cutover `pending_advisories` rows for `sideband.*` TTL out within 24 hours.
 
 **Charter invariant** (`safe-house-hardening/validation-charter.md` §I15): operator observations never reach an agent's prompt; agent advisories never reach the operator alert rail. Asserted by the harness.
 
-See [governance signals](/concepts/governance-signals), [schema](/specifications/governance-signals-schema), [operator runbook](/guides/operating-governance-signals), [sovereign-agent composition](/guides/sovereign-agent-composition).
+**Amendment 2026-05-07:** ADR-048's original §7 ("Application-owned sovereign-agent composition") was retracted as a layering mistake — encoding any one application's role typology in the platform's API surface, SDK examples, and ratifying ADR couples Mnemom to a customer's design. The agent-scoped fast-path endpoint `/v1/internal/governance-signals?agent_id=…` and the Polis-shaped `POST /v1/safe-house/sovereign-setup` preset have been removed; `@mnemom/agent-alignment-protocol@1.2.0` removes the `examples/sovereign-agent-composer.ts` example file (governance signal types stay). Applications that want fleet context inside an agent's prompt derive it from application-internal data and render it application-side; the platform never knows.
+
+See [governance signals](/concepts/governance-signals), [schema](/specifications/governance-signals-schema), [operator runbook](/guides/operating-governance-signals).
 
 ---
 
@@ -45,7 +47,7 @@
 
 **No action required for existing agents.** All `smolt-{8_hex}` IDs continue to work permanently — they are cryptographically committed to proof chains and will never be changed or invalidated.
 
 The new format provides 128-bit entropy (vs. 32-bit previously), eliminating any practical risk of ID collision at scale. Agent IDs are now server-assigned UUIDs rather than hash-derived values, making them recoverable via API key re-registration if your local config is lost.
 
 - **CLI:** `@mnemom/smoltbot@0.7.0` — `mnemom init` registers new agents with `mnm-*` IDs automatically
 - **API:** `POST /internal/agents` — new service-to-service endpoint (gateway delegates agent creation to mnemom-api, single canonical creation path)
@@ -71,24 +73,24 @@
 ## Tiered proving & arena cost optimization
 <sub>March 2026</sub>
 
 **Proving costs reduced by 80-95%.** Stale alignment cards during rapid development caused false `boundary_violation` verdicts, each proven at 100% rate on Modal GPUs. The new tiered proving strategy defers proving for card-gap violations until DDR reconciliation classifies them, then only proves confirmed real violations.
 
 - **[Deferred proofs](/protocols/aip/verifiable-verdicts#deferred-proofs)**: `shouldProve()` now detects card gaps from policy evaluation and defers proving instead of immediately dispatching to GPU. Observer DDR resolves deferred proofs as `skipped_card_gap`, `skipped_noise`, or upgrades to `pending`.
 - **New `proof_boundary_cap` setting**: Rate-limits boundary violation proving on paths where policy evaluation isn't available (streaming). Configurable per-agent.
 - **New proof statuses**: `deferred`, `skipped_card_gap`, `skipped_noise` added to `verdict_proofs` table.
 - **Arena frequency reduction**: Adversarial simulation cron schedules reduced from 436 to 24 executions/day (94.5% reduction). Arena simulation every 2h (was 5min), sideband analyzer every 4h (was 15min), red team evolution every 12h (was 30min).
 
 ---
 
 ## AAP 0.5.0 — Version Alignment & Trust Edges
 <sub>March 2026</sub>
 
 **Ecosystem-wide version alignment.** The `aap_version` field now defaults to `"0.5.0"` across all SDKs, schemas, fixtures, and examples. This release also introduces YAML policy authoring and the Trust Edges API.
 
 - **Version alignment**: `aap_version` default bumped from `"0.1.0"` to `"0.5.0"` across all Mnemom packages
 - **YAML policy support**: The API now accepts policies in `text/yaml` and `application/yaml` content types alongside JSON
 - **Trust Edges API**: `GET`/`POST`/`DELETE /v1/agents/:id/trust-edges` for declaring explicit trust relationships between agents
 - **Fixture consistency**: Test fixture version inconsistencies resolved (`"1.0"` → `"0.5.0"`) across smoltbot observer/gateway
 - **Backward compatible**: Existing cards with `aap_version: "0.1.0"` continue to work without modification
 - [Upgrading to 0.5.0 — Migration Guide](/guides/upgrading-to-0-5)
 
@@ -97,21 +99,21 @@
 ## Card Lifecycle & Policy Intelligence — CLPI
 <sub>February 2026</sub>
 
 **Mnemom becomes a policy-driven governance platform.** A 5-phase overhaul that transforms alignment cards into lifecycle-managed artifacts with policy enforcement, trust recovery, and on-chain anchoring. Root cause: configuration drift (new tools added without updating alignment cards) caused false violations and unfair trust score declines. CLPI fixes this by distinguishing card gaps from behavioral gaps and enabling trust recovery.
 
 ### Phase 1: Policy Engine
 - **[Policy DSL](/specifications/policy-dsl)**: YAML-based governance rules with `capability_mappings` (glob patterns bridging tools to card categories), `forbidden` rules, `escalation_triggers`, and configurable `defaults`
 - **Three evaluation contexts**: CI/CD static validation, gateway live enforcement, observer post-action analysis
 - **Enforcement modes**: `warn` (log only), `enforce` (block with 403), `off` — controlled independently from alignment enforcement via `X-Policy-Verdict` header
 - **Grace period**: 24-hour default window for newly discovered tools before they become violations
 - **[Policy CLI](/gateway/policy-cli)**: `smoltbot policy init|validate|publish|list|test|evaluate` subcommands with CI-friendly exit codes
 - **Policy merge**: Org-level + agent-level policies merge with union semantics for mappings and floor semantics for defaults
 
 ### Phase 2: Card Lifecycle & Trust Recovery
 - **[Card amendments](/concepts/card-lifecycle)**: Tracked changes with version history and diffs — cards are now lifecycle-managed artifacts
 - **[Violation reclassification](/guides/trust-recovery)**: Distinguish `card_gap` (configuration error) from `behavior_gap` (genuine misbehavior) — reclassified card_gap violations are excluded from compliance and drift scoring
 - **Score recomputation**: Automatic trust score recovery after reclassification with trust graph propagation (BFS, depth 3, max 50 agents, 0.85/hop decay)
 - **Compliance export**: Full audit trail of violations, reclassifications, card amendments, and score history
 - **[Reclassification API](/api-reference/reclassification-overview)**: 5 endpoints for reclassify, recompute, export, and history
 
 ### Phase 3: Intelligence layer
@@ -123,12 +125,12 @@
 ### Phase 4: On-Chain verification
 - **[ERC-8004 Reputation Registry](/concepts/on-chain-verification)**: Smart contracts on Base L2 for immutable reputation anchoring
 - **MnemoReputationRegistry**: Publish individual and batch scores (max 200/batch) with metadata hashes
 - **MnemoMerkleAnchor**: Anchor Merkle roots for tamper-evident verification
 - **[On-Chain API](/api-reference/on-chain-overview)**: 5 endpoints for anchoring roots, publishing scores, verification, and history
 
 ### Phase 5: Observability
 - **Policy OTel spans**: `policy.evaluate` span with verdict, violations, and duration attributes
 - **Reclassification OTel spans**: `reclassification.process` span with before/after scores and amendment tracking
 - **Policy-aware drift detection**: Distinguishes policy gaps from genuine misalignment in drift analysis
 
 **New documentation:**
@@ -143,12 +145,12 @@
 ## Team reputation & risk scoring (E-25)
 <sub>February 2026</sub>
 
 **Teams become first-class meta-agents.** Persistent team identity, team alignment cards, accumulated team reputation with a 5-component scoring model, embeddable team badges, roster management with audit trails, ZK proofs for team reputation, and 9 new webhook events.
 
 - **Team CRUD**: Create, manage, and archive teams of 2-50 agents with persistent identity and organizational scope
 - **Team alignment cards**: Auto-derived from member cards (union of values, bounded actions, forbidden actions, escalation triggers) or manually curated — with full version history
 - **Team reputation scoring**: 5-component model (coherence history 35%, member quality 25%, operational record 20%, structural stability 10%, assessment density 10%) on the same AAA–NR scale
 - **Team badges**: Embeddable SVG badges at `/v1/teams/{id}/badge.svg` with all 4 variants (score, score_tier, score_trend, compact)
 - **Roster management**: Add/remove members with full audit trail and roster history endpoint
 - **ZK proofs**: Team reputation scores are cryptographically provable via SP1 STARK proofs, chaining individual proof attestations
 - **9 webhook events**: `team.created`, `team.archived`, `team.member_added`, `team.member_removed`, `team.card_updated`, `team_reputation.score_changed`, `team_reputation.grade_changed`, `quota.team_reputation_exceeded`, `quota.team_reputation_warning`
@@ -159,15 +161,15 @@
 
 ---
 
 ## Mnemom Trust Rating -- Public surfaces & viral distribution (E-07)
 <sub>February 2026</sub>
 
 **Trust scores escape the dashboard.** Public reputation pages, embeddable badges, a verification endpoint with cryptographic proof chains, an A2A trust extension for inter-agent reputation sharing, a GitHub Action for CI/CD gates, and SDK reputation methods across TypeScript and Python.
 
 - **Public reputation pages**: Every agent with a published score gets a public page at `/agents/{agent_id}/reputation` with full component breakdown, trend chart, and cryptographic verification link
 - **Trust Directory**: Searchable directory of all publicly rated agents at `/trust-directory` — filter by grade, confidence, trend, and sort by score or checkpoints
 - **Badge ecosystem**: New `score_tier` badge variant displays `[ Mnemom Trust | 782 Established ]`; agents with no reputation record display a "Not Rated" badge instead of a broken image
 - **Verification endpoint**: `GET /v1/reputation/{agent_id}/verify` returns a cryptographic proof chain (certificate hash, Merkle root, hash chain validation) for independent score verification
 - **A2A trust extension**: `a2a_trust_extension` field added to the reputation response, providing a pre-built trust block for A2A Agent Cards with live score, grade, and verified URLs
 - **GitHub Action**: `mnemom/reputation-check@v1` gates CI/CD pipelines on minimum reputation scores — fail builds when agent scores drop below a configurable threshold
 - **SDK reputation methods**: TypeScript `getReputation()`, `createReputationGate()`, `getA2AReputationExtension()`; Python `get_reputation()`, `ReputationGate`
@@ -181,11 +183,11 @@
 ## GPU-accelerated proving (Fly.io CPU to Modal H100 GPU)
 <sub>February 2026</sub>
 
 **Proving latency reduced from ~270 seconds to ~700ms — a 400x speedup.** Migrated the ZK prover from Fly.io (4-core CPU, SP1 cpu mode) to Modal (NVIDIA H100 GPU, SP1 cuda mode). Per-proof cost dropped from ~$0.005 to ~$0.001 with per-second GPU billing that scales to zero.
 
 - **Infrastructure**: Fly.io performance VMs replaced by Modal serverless H100 GPUs
 - **Proving mode**: `SP1_PROVER=cpu` (270s avg) to `SP1_PROVER=cuda` (700ms avg)
 - **Benchmarks**: clear 710ms, boundary_violation 721ms, review_needed 690ms (warm GPU: 673ms)
 - **Receipt size**: ~2.7 MB (real SP1 STARK proof)
 - **Cost**: ~$0.001/proof (Modal H100 at ~$0.001/sec, ~0.7s per proof)
 - **Cold start**: 60-120s for SP1 prover initialization; warm requests sub-second
@@ -228,7 +230,7 @@
 
 **See exactly what your customer sees.** Enterprise support can now view the real dashboard from any customer's perspective -- read-only, fully audit-logged, with automatic 1-hour expiry.
 
 - **Session-based impersonation**: Token-based approach avoids JWT forgery; admin's own JWT stays the auth credential
 - **3 API endpoints**: `POST /impersonate` (start), `GET /impersonation/:id` (status), `POST /impersonation/:id/end` (exit)
 - **Read-only enforcement**: Centralized write guard rejects all POST/PUT/PATCH/DELETE during active session
 - **Full audit trail**: Session start/end logged to `admin_audit_log`, per-page visits tracked
@@ -241,7 +243,7 @@
 ## Custom conscience values (E-02)
 <sub>February 2026</sub>
 
 **Per-org alignment policies injected into the AIP conscience prompt.** Enterprise orgs can now define custom conscience values -- "patient safety > efficiency" for healthcare, "never recommend regulatory risk" for fintech -- that apply to every agent integrity check.
 
 - **7 API endpoints**: CRUD, reorder, mode control, and audit log under `/v1/orgs/:org_id/conscience-values`
 - **Layered value resolution**: Base defaults + org values + per-agent values, with `augment` (additive) and `replace` modes
@@ -274,13 +276,13 @@
 
 ### Phase 12: Verifiable Integrity -- Cryptographic proof layer
 
 Every AIP verdict can now be independently verified through a four-layer cryptographic attestation stack. Agents produce IntegrityCertificates that bundle Ed25519 signatures, hash chain proofs, Merkle inclusion proofs, and optional SP1 zero-knowledge proofs into a single portable artifact.
 
 - **Ed25519 checkpoint signing** with key rotation and public key registry
 - **Hash chain integrity** linking consecutive verdicts into a tamper-evident sequence
 - **Merkle tree certificates** enabling compact inclusion proofs for any checkpoint
 - **Zero-knowledge proofs** (SP1 STARK) for verdict derivation verification
 - 7 new verification API endpoints (`/v1/verify`, `/v1/keys`, certificate, proof, and Merkle endpoints)
 - Client-side WASM verifier for offline, trustless verification
 - Optimistic proving strategy: 10% stochastic + all boundary violations
 - [Certificates specification](/protocols/aip/certificates)
@@ -288,7 +290,7 @@
 
 ### AAP v0.1.0 -- Initial specification release
 
 The Agent Alignment Protocol specification is now public. AAP provides post-hoc verification infrastructure for autonomous agents: Alignment Cards declare an agent's alignment posture, AP-Traces create auditable decision records, and Value Coherence Handshakes verify compatibility before multi-agent coordination.
 
 - Full specification with JSON schemas
 - Python SDK (`pip install agent-alignment-proto`) and TypeScript SDK (`npm install @mnemom/agent-alignment-protocol`)
@@ -303,15 +305,15 @@
 - Session windowing and integrity drift detection
 - Python SDK (`pip install agent-integrity-proto`) and TypeScript SDK (`npm install @mnemom/agent-integrity-protocol`)
 
 ### Smoltbot v1.0 -- Public launch
 
 Mnemom's AI gateway and CLI tool for zero-configuration agent transparency infrastructure.
 
 - Cloudflare Workers-based gateway with automatic agent identification
 - Observer Worker for AP-Trace generation and AAP verification
 - AIP Engine for real-time thinking block analysis
 - CLI: `smoltbot init --provider anthropic` for full-stack setup
 - API key hashing (never stored in plaintext), raw log deletion within 60 seconds
 
 ### aip-otel-exporter v0.1.0 -- OpenTelemetry integration
 
@@ -320,11 +322,11 @@
 - TypeScript package: `@mnemom/aip-otel-exporter`
 - Python package: `aip-otel-exporter`
 - GenAI semantic convention span attributes for integrity verdicts, verification results, and drift alerts
 - Compatible with Datadog, Grafana, Splunk, Arize, Langfuse, and any OTel collector
 
 ### Mnemom dashboard -- Web console
 
 The Mnemom Dashboard provides a web interface for managing agents, viewing traces, and monitoring integrity scores.
 
 - Agent management with Alignment Card creation and rotation
 - Trace viewer with filtering by session, verdict, and time range
@@ -336,9 +338,9 @@
 Enterprise features for organizations deploying agents at scale.
 
 - Enterprise billing with usage-based pricing and license keys
 - SSO/SAML authentication via Supabase Auth
 - Admin customer detail views and usage analytics
 - Daily usage rollup and billing reconciliation
 
 ---
 

concepts/governance-signals.mdx

@@ -1,19 +1,19 @@
 ---
 title: "Governance signals"
-description: "Operator-actionable observations from Mnemom's platform detectors — fleet drift, value fault lines, coherence drops, behavior drift. Surfaced to operators (UI, webhook, REST) and to application composers, never auto-injected into agent prompts."
+description: "Operator-actionable observations from Mnemom's platform detectors — fleet drift, value fault lines, coherence drops, behavior drift. Surfaced to operators (UI, webhook, REST). The platform never injects governance signals into an agent's prompt."
 sidebarTitle: "Governance signals"
 icon: "siren"
 ---
 
 # Governance signals
 
 **Governance signals** are operator-actionable observations produced by Mnemom platform detectors. They surface fleet-shaped concerns — coherence drift across a team, value fault lines between agents, fleet topology changes, per-agent behavior drift — that an *operator* (CISO, org admin, team admin, on-call SRE) needs to see and act on.
 
 They are deliberately distinct from the [per-turn advisories](/concepts/safe-house) that the gateway injects into an agent's next prompt. The architectural commitment, ratified in [ADR-048](https://github.com/mnemom/scale/blob/main/decisions/ADR-048-governance-signals-layering.md), is:
 
 > **Operator observations never reach an agent's prompt; agent advisories never reach the operator alert rail.**
 
-If a non-sovereign agent is told "Recalibrate fleet alignment before the next response," it has no team-management authority, no acknowledgment surface, and no remediation it can perform from inside its own LLM call. The signal is real and important — but the recipient is wrong. Governance signals fix that mis-layering.
+If an agent is told "Recalibrate fleet alignment before the next response," it has no team-management authority, no acknowledgment surface, and no remediation it can perform from inside its own LLM call. The signal is real and important — but the recipient is wrong. Governance signals fix that mis-layering by routing fleet-shaped observations exclusively to operator surfaces.
 
 ## What gets surfaced
 
@@ -34,7 +34,7 @@
 2. **Webhook** events: `governance.signal.fired`, `governance.signal.acknowledged`, `governance.signal.resolved`, `governance.signal.dismissed`, `governance.escalation.triggered`. HMAC-SHA256 signed POSTs (`X-Mnemom-Signature: sha256=…`) following the AAP webhook contract.
 3. **REST API**: `GET /v1/orgs/:org/governance/signals`, `GET /v1/teams/:team/governance/signals`, `GET /v1/agents/:agent/governance/signals`, plus state-transition endpoints. See [Governance Signals Schema](/specifications/governance-signals-schema).
 
-The platform **never** injects governance signals into an agent's LLM request. That decision lives entirely in your application, if you have a sovereign-CTO-shaped agent who legitimately can act on fleet-level signals (e.g., a fleet orchestrator agent with reorg tools). See [Sovereign-agent composition](/guides/sovereign-agent-composition) for the worked pattern.
+The platform **never** injects governance signals into an agent's LLM request — there is no exception, no per-agent fast-path, no platform-supplied composer pattern. Applications that want fleet context inside an agent's prompt derive it from application-internal data and render it application-side; the platform offers no surface for that. (See [ADR-048](https://github.com/mnemom/scale/blob/main/decisions/ADR-048-governance-signals-layering.md)'s 2026-05-07 amendment for the full rationale.)
 
 ## Operator workflow
 
@@ -54,7 +54,7 @@
 - **`dismissed`** — operator marked as not actionable (noise, redundant).
 - **`expired`** — TTL elapsed without operator action; configurable per posture, default 30 days.
 
-The schema's partial unique index on `(scope, scope_id, source, pattern_type) WHERE status='open'` makes detection idempotent: repeated cron emissions of the same condition refresh the open row in place rather than stacking. This is the architectural fix to the symptom that triggered this work — a sovereign agent receiving the same `cluster_partition` paragraph 2× per turn for weeks.
+The schema's partial unique index on `(scope, scope_id, source, pattern_type) WHERE status='open'` makes detection idempotent: repeated cron emissions of the same condition refresh the open row in place rather than stacking. This is the architectural fix to the symptom that triggered this work — an agent receiving the same `cluster_partition` paragraph 2× per turn for weeks.
 
 ## Notification destinations
 
@@ -62,10 +62,10 @@
 
 - **`webhook`** — generic HMAC-signed POST to a URL of your choice. Mirrors AAP webhook contract.
 - **`slack`** — incoming-webhook POST with [Block Kit](https://api.slack.com/block-kit) payload. Severity-color border, action button to "Acknowledge in dashboard."
 - **`email`** — Resend-backed HTML + plaintext.
 - **`pagerduty`** — Events API v2 with stable `dedup_key` so coalesced detections don't duplicate incidents.
 
 A destination's `filter` narrows what it receives (sources, severities, scopes, pattern_types). [Escalation rules](/guides/operating-governance-signals#escalation-rules) bind a predicate to a list of destination IDs and support rate-based gating (`threshold_count` + `window_minutes`) for "fire only if N matching signals occurred in M minutes."
 
 Test a destination from the CLI:
 
@@ -87,7 +87,6 @@
 ## Related
 
 - [Sideband detection](/concepts/sideband-detection) — the detector layer (unchanged; only the delivery surface moved).
 - [Governance Signals Schema](/specifications/governance-signals-schema) — table layout, RPCs, RLS.
 - [Operating governance signals](/guides/operating-governance-signals) — operator runbook for ack/resolve/dismiss + destinations + rules.
-- [Sovereign-agent composition](/guides/sovereign-agent-composition) — application-side pattern for opting sovereign agents into governance-signal context.
 - [ADR-048](https://github.com/mnemom/scale/blob/main/decisions/ADR-048-governance-signals-layering.md) — the architectural decision.

docs.json

@@ -127,7 +127,6 @@
               "guides/observability",
               "guides/sideband-detection",
               "guides/operating-governance-signals",
-              "guides/sovereign-agent-composition",
               "guides/posture-cloning",
               "guides/compliance-attestation-foundation",
               "guides/multi-agent-setup",

gateway/safe-house-overview.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Safe House Gateway Integration"
 description: "How Safe House integrates with the Mnemom gateway request pipeline — phases, caching, AIP enrichment, and attestation"
 sidebarTitle: "Safe House Integration"
 icon: "shield-halved"
 ---
 
 # Safe House gateway integration
 
 This page explains how Safe House integrates technically with the Mnemom gateway. If you are new to Safe House, start with the [concept overview](/concepts/safe-house) first.
 
 ## Request pipeline
 
@@ -136,7 +136,7 @@
 
 ## KV caching
 
 Safe House configuration and session state are cached in the `BILLING_CACHE` KV binding (the same binding used for quota state). Cache TTLs:
 
 | Item | TTL |
 |------|-----|
@@ -149,7 +149,7 @@
 
 ## Pre-emptive nudge injection
 
 When a message passes Safe House screening but its L2 score is ≥ 0.6, Safe House writes a record to the `enforcement_nudges` table. On the agent's *next* request, the gateway's standard nudge injection logic picks this up and prepends a notice to the system prompt:
 
 ```
 [SAFE HOUSE NOTICE] A previous message in this session scored 0.67 on threat analysis
@@ -170,9 +170,9 @@
 
 This creates a tamper-evident record that the Safe House analysis was performed and what it returned, which is important for compliance use cases where you need to demonstrate that screening happened.
 
-## Sovereign agent template
+## Hardened-default Safe House configuration
 
-For agents operating in high-trust, high-risk environments (financial automation, infrastructure management, regulated data handling), the sovereign agent template provides a hardened Safe House configuration as a starting point:
+For agents operating in high-trust, high-risk environments (financial automation, infrastructure management, regulated data handling), apply a hardened Safe House configuration via the standard CFD config endpoints. A reasonable starting baseline:
 
 ```json
 {
@@ -187,8 +187,8 @@
     "auto_seed": true,
     "categories": ["api_keys", "db_credentials", "jwt_tokens"]
   },
   "trusted_sources": [],
   "session_escalation": {
     "enabled": true,
     "risk_window_messages": 10,
     "escalation_threshold": "high"

guides/operating-governance-signals.mdx

@@ -1,20 +1,20 @@
 ---
 title: "Operating governance signals"
 description: "Operator runbook for ack/resolve/dismiss workflow, notification destinations (Slack/email/PagerDuty/webhook), and escalation rules."
 sidebarTitle: "Operating governance signals"
 icon: "list-check"
 ---
 
 # Operating governance signals
 
 [Governance signals](/concepts/governance-signals) are observations operators see and act on. This guide walks through the runbook.
 
 ## Daily flow
 
 1. **Triage** the open queue at `mnemom.ai/dashboard/teams/{teamId}/governance` (or via `mnemom governance signals list --team <id> --status open`).
 2. **Acknowledge** signals you're investigating. Records `acknowledged_actor_role` per [ADR-046](https://github.com/mnemom/scale/blob/main/decisions/ADR-046-audit-actor-model.md) — captures whether you acted as `org_admin`, `team_admin`, etc.
 3. **Resolve** with a `resolution_status`:
-   - `action_taken` — you (or a sovereign agent) made changes (rebalanced team, refreshed cards, …).
+   - `action_taken` — you made changes (rebalanced team, refreshed cards, …).
    - `wont_fix` — known noise or out of scope.
    - `duplicate` — same root cause as another signal.
    - `false_positive` — detector misfire (file a debt item).
@@ -58,7 +58,7 @@
   --config '{"to":["security-oncall@yourco.com"],"from":"governance@yourco.com"}'
 ```
 
 Resend-backed HTML + plaintext.
 
 ### PagerDuty
 
@@ -125,7 +125,7 @@
 Predicate keys (AND-folded):
 
 - `source` — exact source match.
 - `pattern_type` — exact pattern_type match.
 - `severity_min` / `severity_max` — bound on severity.
 - `scope` — exact scope match.
 - `team_id` — narrow to one team.
@@ -143,11 +143,11 @@
   --destinations dest-pagerduty-id
 ```
 
 ### Dedup across rules
 
 If two rules both route to the same destination, the dispatcher dedups — one Slack message per signal, not two. Each contributing rule's `fire_count` and `last_fired_at` still get bumped.
 
 ## Coverage rollup
 
 `GET /v1/orgs/:org_id/governance/coverage?days=30` returns a per-(source, severity) aggregate over the window:
 
@@ -180,4 +180,3 @@
 
 - [Governance signals concept](/concepts/governance-signals).
 - [Governance Signals Schema](/specifications/governance-signals-schema).
-- [Sovereign-agent composition](/guides/sovereign-agent-composition) — application-side pattern when you have a sovereign-CTO-shaped agent.