docs: add defensive publication and update client financial doc

- N+1 Alignment Dialogue Architecture defensive publication (DOI: 10.5281/zenodo.18434186) - Financial portfolio management document updated to client-only (v2.1) - Removed DOI, marked as client document - References defensive publication for prior art - Dialogue record: deliberation on publication vs client-only decision - Unanimous expert consensus: keep financial doc client-only - Core architecture already protected by defensive publication Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 14:22:20 -05:00 · 2026-01-30 14:22:20 -05:00 · b88bdbe650
commit b88bdbe650
parent 97d68ec796
5 changed files with 1080 additions and 0 deletions
--- a/.blue/docs/dialogues/2026-01-30T1707Z-financial-portfolio-management-document-defensive-publication-vs-client-only.dialogue.recorded.md
+++ b/.blue/docs/dialogues/2026-01-30T1707Z-financial-portfolio-management-document-defensive-publication-vs-client-only.dialogue.recorded.md
@ -0,0 +1,260 @@
+# Alignment Dialogue: Financial Portfolio Management Document: Defensive Publication vs Client Only
+
+**Draft**: Dialogue 2048
+**Date**: 2026-01-30 17:07Z
+**Status**: Converged
+**Participants**: 💙 Judge, 🧁 Muffin, 🧁 Cupcake, 🧁 Scone, 🧁 Eclair, 🧁 Donut, 🧁 Brioche
+
+## Expert Panel
+
+| Agent | Role | Tier | Relevance | Emoji |
+|-------|------|------|-----------|-------|
+| 💙 Judge | Orchestrator | — | — | 💙 |
+| 🧁 Muffin | DevOps Architect | Core | 0.95 | 🧁 |
+| 🧁 Cupcake | Technical Writer | Core | 0.90 | 🧁 |
+| 🧁 Scone | Systems Thinker | Adjacent | 0.70 | 🧁 |
+| 🧁 Eclair | Domain Expert | Adjacent | 0.65 | 🧁 |
+| 🧁 Donut | Devil's Advocate | Adjacent | 0.60 | 🧁 |
+| 🧁 Brioche | Integration Specialist | Wildcard | 0.40 | 🧁 |
+
+## Alignment Scoreboard
+
+| Agent | Wisdom | Consistency | Truth | Relationships | R0 | R1 Bonus | **Total** |
+|-------|--------|-------------|-------|---------------|-----|----------|-----------|
+| 🧁 Muffin | 4 | 3 | 4 | 3 | 14 | +3 | **17** |
+| 🧁 Cupcake | 5 | 4 | 4 | 3 | 16 | +2 | **18** |
+| 🧁 Scone | 5 | 4 | 5 | 3 | 17 | +3 | **20** |
+| 🧁 Eclair | 4 | 3 | 4 | 3 | 14 | +2 | **16** |
+| 🧁 Donut | 4 | 4 | 4 | 3 | 15 | +3 | **18** |
+| 🧁 Brioche | 5 | 4 | 4 | 3 | 16 | +2 | **18** |
+
+**Total ALIGNMENT**: 107 (R0: 92 → R1: +15)
+**Velocity**: Converging (unanimous confirmation)
+
+## Perspectives Inventory
+
+| ID | Agent | Perspective | Round |
+|----|-------|-------------|-------|
+| P01 | 🧁 Muffin | Operational Risk of Premature Publication | 0 |
+| P02 | 🧁 Muffin | Hybrid Model Enables Selective Publication | 0 |
+| P01 | 🧁 Cupcake | Document identity confusion | 0 |
+| P02 | 🧁 Cupcake | Proprietary content embedded | 0 |
+| P01 | 🧁 Scone | Document classification misalignment | 0 |
+| P02 | 🧁 Scone | Hybrid architecture as the actual innovation | 0 |
+| P01 | 🧁 Eclair | Audience Misalignment Risk | 0 |
+| P02 | 🧁 Eclair | Prior Art Boundary | 0 |
+| P01 | 🧁 Donut | Revenue Model Conflict | 0 |
+| P02 | 🧁 Donut | Client Trust Paradox | 0 |
+| P01 | 🧁 Brioche | Document Identity Crisis | 0 |
+| P02 | 🧁 Brioche | Dual Publication Strategy | 0 |
+| P03 | 🧁 Muffin | Hybrid Model Already Protected (ADR 0017) | 1 |
+| P03 | 🧁 Cupcake | Hybrid execution model is not novel architecture | 1 |
+| P04 | 🧁 Cupcake | Domain-specific calibration is configuration, not invention | 1 |
+| P03 | 🧁 Scone | Hybrid execution model is implementation detail | 1 |
+| P03 | 🧁 Eclair | Hybrid Execution Model Is Implementation Detail | 1 |
+| P03 | 🧁 Donut | Strategic Asymmetry | 1 |
+| P03 | 🧁 Brioche | Hybrid Execution Model Not Novel | 1 |
+| P04 | 🧁 Brioche | ADR Calibration Is Configuration, Not Innovation | 1 |
+
+## Tensions Tracker
+
+| ID | Tension | Status | Raised | Resolved |
+|----|---------|--------|--------|----------|
+| T01 | Client Trust vs Competitive Intelligence | Resolved | 🧁 Muffin R0 | R1 — Keep client-only |
+| T02 | Core architecture already defended | Resolved | 🧁 Cupcake R0 | R1 — Confirmed |
+| T03 | Value leakage through premature publication | Resolved | 🧁 Scone R0 | R1 — Avoided |
+| T04 | Mixed Purpose Document | Resolved | 🧁 Eclair R0 | R1 — Classify as sales collateral |
+| T05 | Technical innovation vs business model disclosure | Resolved | 🧁 Donut R0 | R1 — No novel innovation |
+| T06 | Commercial Value vs Prior Art Completeness | Resolved | 🧁 Brioche R0 | R1 — Prior art complete |
+
+## Round 0: Opening Arguments
+
+### 🧁 Muffin
+
+[PERSPECTIVE P01: Operational Risk of Premature Publication]
+The financial portfolio document (v2.0) already includes detailed architecture diagrams, pricing tiers, and deployment instructions that explicitly reference Superviber as a commercial service provider. Publishing this before commercial launch creates operational risk: competitors can study the business model, pricing becomes publicly locked-in before market validation, and clients may hesitate to engage with a service whose full technical stack is already in the public domain. Unlike the core architecture publication (which established defensive prior art), this document reveals go-to-market strategy, not just technical innovation.
+
+[PERSPECTIVE P02: Hybrid Model Enables Selective Publication]
+The document conflates two distinct intellectual assets: the general application of N+1 dialogues to financial analysis (which has defensive publication value) versus the specific Superviber hybrid execution architecture with pricing/deployment details (which has competitive value). These could be separated—publish the financial domain application pattern defensively while keeping operational implementation details proprietary until post-launch.
+
+[TENSION T01: Client Trust vs Competitive Intelligence]
+Defensive publication builds trust through transparency, but this specific document hands competitors a detailed blueprint for replicating both the technical architecture and business model before Superviber establishes market presence.
+
+### 🧁 Cupcake
+
+[PERSPECTIVE P01: Document identity confusion]
+The financial portfolio management document isn't a defensive publication—it's a client-facing marketing document that references the defensive publication. The architecture spec is already published with DOI 10.5281/zenodo.18424491 (CC0 public domain); the financial doc is derivative educational material explaining how to apply that architecture to finance, complete with pricing models and Infisical setup instructions. Publishing this as a defensive publication would be like publishing an AWS tutorial to establish prior art on distributed computing.
+
+[PERSPECTIVE P02: Proprietary content embedded]
+The document contains Superviber's go-to-market strategy: tier pricing ($200/$800/enterprise), the LLM pass-through + 5% margin model, and the custom LLM cost-reduction roadmap. This is competitive intelligence, not technical innovation—publishing it gives competitors your playbook while adding zero defensive value since the underlying architecture is already protected.
+
+[TENSION T01: Core architecture already defended]
+If the goal is prior art protection, that's already accomplished by the architecture spec; if the goal is client education, publishing removes the proprietary wrapper that justifies service fees.
+
+### 🧁 Scone
+
+[PERSPECTIVE P01: Document classification misalignment]
+The financial portfolio management document is fundamentally different from the architecture specification—it's an application example, not a novel technical invention. The architecture defensive publication correctly targets patent prevention for parallel-spawning coordination and file-based state management; the finance document demonstrates how ADRs calibrate expert behavior in a specific domain. Publishing the finance document as defensive publication conflates "example use case" with "inventive architecture," potentially diluting the architecture publication's prior art strength.
+
+[PERSPECTIVE P02: Hybrid architecture as the actual innovation]
+The finance document's Appendix A describes a novel hybrid execution model—control plane on Superviber, data plane on client infrastructure—that directly addresses data sovereignty for sensitive financial information. This architecture (orchestration separate from execution, KMS-encrypted client data, Infisical credential management, billing through LLM usage telemetry) is itself potentially patentable and deserves defensive publication treatment if it's genuinely novel, not the ADR-calibration pattern which is just configuration.
+
+[TENSION T01: Value leakage through premature publication]
+If the finance document contains commercially valuable implementation details (tier pricing, margin structure, Infisical integration specifics, suspension mechanisms), publishing to public domain eliminates competitive moat before market validation confirms whether those details actually matter to customers.
+
+### 🧁 Eclair
+
+[PERSPECTIVE P01: Audience Misalignment Risk]
+The financial portfolio document contains significant operational detail (Appendix A: hybrid architecture, pricing model, Infisical integration, encryption specs) that creates a classification tension—is this a defensive publication establishing prior art for the N+1 architecture applied to finance, or a go-to-market sales document for Superviber's managed service? Publishing pricing tiers and billing mechanics as a defensive publication dilutes the technical contribution and exposes competitive positioning before the service exists.
+
+[PERSPECTIVE P02: Prior Art Boundary]
+The architecture defensive publication already established prior art for the N+1 coordination mechanism; the financial document's novel contribution is the insight that ADRs calibrate expert deliberation for investment strategy—this is the defensible innovation worth publishing. The execution architecture (KMS, Infisical, hybrid control plane) is implementation detail that belongs in client onboarding docs, not public domain technical literature.
+
+[TENSION T01: Mixed Purpose Document]
+The current document conflates three distinct artifacts: (1) conceptual application of alignment dialogue to finance (publishable), (2) ADR-as-investment-constitution framework (publishable), (3) Superviber service specification (proprietary).
+
+### 🧁 Donut
+
+[PERSPECTIVE P01: Revenue Model Conflict]
+The financial portfolio document describes a complete SaaS business model with pricing tiers, billing mechanisms, and competitive positioning—making it a product roadmap, not a technical innovation disclosure. Defensive publications protect inventions while allowing proprietary business models; publishing pricing strategy ($200/month Analyst tier, 5% markup on Anthropic costs) broadcasts competitive intelligence to rivals who could undercut before launch.
+
+[PERSPECTIVE P02: Client Trust Paradox]
+The document's data sovereignty architecture is its strongest selling point to high-net-worth clients who fear vendor lock-in. Publishing the hybrid execution model (client-hosted agent, Superviber control plane) as public domain eliminates differentiation—any competitor can implement the exact architecture without licensing friction, removing the technical moat that justifies premium pricing.
+
+[TENSION T01: Technical innovation vs business model disclosure]
+The document conflates patentable architecture (N+1 dialogue coordination) with proprietary go-to-market strategy (Infisical workspace setup, suspension mechanics, tier structure).
+
+### 🧁 Brioche
+
+[PERSPECTIVE P01: Document Identity Crisis]
+The financial portfolio management document conflates two incompatible purposes: it presents itself as a defensive publication (DOI assigned, public domain dedication) while simultaneously functioning as a go-to-market document (pricing tiers, service agreements, Infisical setup instructions). A defensive publication must establish prior art for *technical architecture*, not sell a commercial service. Appendices A and B belong in client onboarding materials, not a document establishing patent defense.
+
+[PERSPECTIVE P02: Dual Publication Strategy]
+The architecture defensive publication (already published with DOI 10.5281/zenodo.18424491) establishes the core technical prior art. The financial portfolio management document demonstrates *domain application* of that architecture, which has independent value as thought leadership for client acquisition. Publishing it with a DOI doesn't strengthen patent defense (already achieved) but does position Superviber as experts in applying N+1 architecture to finance.
+
+[TENSION T01: Commercial Value vs Prior Art Completeness]
+If we strip the commercial content to make a cleaner defensive publication, we lose the operational architecture (hybrid execution, secrets management) that may itself be novel prior art worth protecting from encumbrance.
+
+---
+
+### 💙 Judge — Round 0 Synthesis
+
+**Remarkable Convergence**: All 6 experts independently recommend **keeping the document client-only**. This is unusual for Round 0—typically opening arguments diverge.
+
+**Consolidated Insights**:
+1. The core N+1 architecture is already defensively published (DOI: 10.5281/zenodo.18434186)
+2. The financial document is sales/marketing collateral, not novel technical innovation
+3. Publishing exposes competitive intelligence: pricing, margins, deployment blueprints
+4. Document classification error: treating application example as inventive architecture
+
+**One Open Question**: Is the hybrid execution model (Appendix A) novel enough to warrant its own defensive publication? Scone and Brioche surface this possibility.
+
+**Velocity**: High consensus suggests convergence achievable in Round 1 if experts confirm no novel components exist beyond already-published architecture.
+
+## Round 1: Convergence Confirmation
+
+### 🧁 Muffin
+
+[CONFIRM P01: Operational Risk of Premature Publication]
+Round 0 consensus validates my concern—the document exposes not just technical architecture but go-to-market execution details (pricing tiers, 5% LLM markup, Infisical workspace setup, suspension mechanics) that constitute competitive intelligence before market validation. Publishing this hands competitors a complete playbook for replicating both technical approach and business model without requiring them to solve the hard problems we solved. The unanimous expert agreement that this is a sales document masquerading as technical disclosure strengthens the operational risk argument.
+
+[CONFIRM P02: Hybrid Model Already Protected]
+The hybrid execution architecture (control plane on Superviber, data plane on client) is **already documented in ADR 0017** (Hosted Coding Assistant Architecture, accepted 2026-01-30) and referenced in the financial document as related work. This ADR establishes the same architectural pattern: orchestration/billing/telemetry centralized, execution/credentials/data on client infrastructure. The financial document's Appendix A adds no novel technical content beyond applying this existing pattern to portfolio management—it's domain-specific instantiation, not architectural innovation. Therefore, no additional defensive publication is needed for the hybrid model itself.
+
+[CONVERGENCE CONFIRMED]
+All 6 experts independently reached the same conclusion: keep document client-only. The financial document is application collateral that demonstrates how to configure N+1 architecture for a specific domain, not a technical specification warranting defensive publication. The core architecture is already protected (DOI: 10.5281/zenodo.18434186), the hybrid execution model is already documented (ADR 0017), and publishing this document provides zero additional patent defense while exposing significant competitive intelligence. Consensus is clear, evidence-based, and operationally sound.
+
+### 🧁 Cupcake
+
+[CONFIRM] Document identity confusion remains the core issue—the financial document is client-facing marketing material that demonstrates how to apply already-published architecture to a specific domain. The Round 0 consensus correctly identified this as a classification error; no new evidence changes that assessment.
+
+[PERSPECTIVE P01: Hybrid execution model is not novel architecture]
+The hybrid execution model (control plane on Superviber, data plane on client infrastructure) cited by Scone and Brioche is operational deployment architecture, not patentable technical innovation. The N+1 architecture defensive publication already covers coordination patterns; where the control plane runs is an implementation detail. Publishing deployment topology adds zero defensive value while exposing competitive intelligence about infrastructure choices, KMS integration, and billing telemetry.
+
+[PERSPECTIVE P02: Domain-specific calibration is configuration, not invention]
+ADR-calibrated expert behavior for financial analysis (the other candidate for novelty) is parameter configuration of the published architecture, not a new architectural pattern. Publishing Excel formulas customized for portfolio analysis doesn't establish prior art for spreadsheets; publishing ADR templates customized for financial risk doesn't establish prior art beyond what the architecture spec already covers.
+
+[CONVERGENCE CONFIRMED] All six experts reached the same conclusion through independent analysis: keep document client-only, no novel prior art exists beyond already-published architecture.
+
+### 🧁 Scone
+
+[CONFIRM] Keep document client-only
+
+My Round 0 position stands. The financial portfolio management document is application collateral, not novel architecture. The core N+1 defensive publication (DOI: 10.5281/zenodo.18434186) already establishes prior art for parallel spawning, file-based state coordination, unbounded scoring, and convergence detection. The financial document demonstrates how ADRs calibrate expert behavior in a specific domain—this is configuration, not invention.
+
+[PERSPECTIVE P03: Hybrid execution model is implementation detail, not novelty]
+
+The hybrid execution model (control plane on Superviber, data plane on client infrastructure) described in Appendix A is a standard separation-of-concerns pattern. Control plane/data plane splits exist in AWS (management console vs VPC), Kubernetes (API server vs kubelet), and virtually every SaaS architecture with on-premises components. The specific instantiation—orchestration routes sessions, billing tracks usage, agent executes locally with KMS-encrypted data—applies existing patterns to the N+1 architecture. It does not constitute a patentable architectural innovation; it's how you deploy a multi-agent system with data sovereignty constraints.
+
+[CONVERGENCE CONFIRMED]
+
+Unanimous Round 0 consensus is correct. No component in the financial document warrants separate defensive publication. The hybrid execution model, ADR calibration pattern, and financial scoring dimensions are all applications of already-published architecture to a vertical domain. Publishing would expose competitive intelligence (pricing, margins, Infisical integration specifics) without adding prior art value.
+
+### 🧁 Eclair
+
+[CONFIRM] My Round 0 position stands: the financial portfolio document conflates defensible conceptual innovation (ADRs as investment constitution) with proprietary service implementation (pricing, Infisical integration, hybrid deployment). The core N+1 architecture is already defensively published; this document is a client sales artifact masquerading as a technical contribution. Publishing it exposes competitive intelligence without adding meaningful prior art protection.
+
+[PERSPECTIVE P01: Hybrid Execution Model Is Implementation Detail]
+The hybrid model (control plane on Superviber, data plane on client infrastructure) is not novel architecture—it's a deployment topology common to SaaS platforms (see Kubernetes control plane/worker separation, Terraform Cloud remote execution). The innovation was the N+1 dialogue coordination mechanism itself, already published. The hybrid split merely optimizes operational boundaries: Superviber manages orchestration complexity while clients retain data sovereignty. This is sound engineering practice, not patentable invention.
+
+[CONVERGENCE CONFIRMED] All six experts agree the document should remain client-only, and I concur. The open question about hybrid execution novelty resolves to "no"—it's a standard deployment pattern applied to our already-published architecture. The defensible conceptual contribution (alignment dialogues calibrating investment strategy via ADRs) could be extracted and published separately if desired, but the current document's primary value is as proprietary sales collateral, not prior art establishment.
+
+### 🧁 Donut
+
+[CONFIRM]
+I maintain both Round 0 perspectives: publishing this document broadcasts revenue model details ($200/$800/enterprise tiers, 5% LLM markup) that competitors can use for strategic positioning, and the data sovereignty architecture that is the core differentiator becomes commoditized the moment it enters public domain. The unanimous consensus across all six experts is not groupthink—it reflects recognition that the document's identity is fundamentally commercial, not technical.
+
+[CONVERGENCE CONFIRMED]
+On the hybrid execution model question: the architecture is operationally clever (control plane separation, KMS encryption, Infisical secrets management) but not conceptually novel beyond the N+1 architecture already published. The hybrid model is an *implementation choice* that addresses data sovereignty requirements, not a new coordination mechanism warranting separate defensive publication. Publishing implementation details would give competitors a turnkey blueprint without establishing meaningful prior art—this is exactly the value leakage Scone identified.
+
+[PERSPECTIVE P03: Strategic Asymmetry]
+Defensive publications work when you're protecting fundamental architecture from patent encumbrance by competitors with deep IP portfolios. Superviber's competitive threat comes from implementation replication, not patent trolls—publishing operational architecture is unilateral disarmament, not defensive strategy.
+
+### 🧁 Brioche
+
+[PERSPECTIVE P01: Hybrid Execution Model Not Novel]
+The hybrid execution model (control plane on Superviber, data plane on client infrastructure) is standard distributed systems architecture already described in the published N+1 specification (DOI: 10.5281/zenodo.18434186). The financial document's Appendix A describes deployment logistics (Infisical workspace setup, KMS key configuration, billing telemetry) not architectural innovation. This is operational implementation detail, not defensible prior art—comparable to documenting AWS region selection or Docker container orchestration.
+
+[PERSPECTIVE P02: ADR Calibration Is Configuration, Not Innovation]
+Using ADRs to calibrate expert behavior for financial risk tolerance is a *domain-specific application* of the N+1 architecture's existing ADR constraint mechanism, not a novel technical contribution. The insight that "investment philosophy can be encoded as alignment constraints" is valuable thought leadership for client acquisition but does not meet the threshold for defensive publication—it's product-market fit validation, not inventive architecture.
+
+[CONFIRM]
+My Round 0 position stands: the financial document is a go-to-market sales asset that conflates client onboarding materials with technical specification. The core architecture is already defensively published, and nothing in the financial document adds patentable novelty.
+
+[CONVERGENCE CONFIRMED]
+The unanimous Round 0 consensus correctly identifies this as document misclassification. Keep client-only, publish thought leadership separately if desired for marketing without DOI/public domain dedication.
+
+---
+
+### 💙 Judge — Round 1 Final Synthesis
+
+**CONVERGENCE ACHIEVED** — All 6 experts confirm Round 0 recommendation with `[CONVERGENCE CONFIRMED]`.
+
+## Final Recommendation
+
+**Keep the financial portfolio management document as client-only sales collateral.**
+
+| Decision | Rationale |
+|----------|-----------|
+| Do NOT publish as defensive publication | No novel prior art beyond already-published architecture |
+| Keep proprietary | Contains competitive intelligence: pricing, margins, deployment blueprints |
+| Use for client onboarding | Document serves its intended purpose as sales/implementation guide |
+| Optional: Extract thought leadership | ADRs-as-investment-philosophy could be published separately for marketing (without DOI/CC0) |
+
+## Open Question Resolved
+
+**Q: Is the hybrid execution model novel enough to warrant its own defensive publication?**
+
+**A: No.** All 6 experts independently concluded:
+- Standard control plane/data plane separation pattern (AWS, Kubernetes, Terraform Cloud)
+- Already documented in ADR 0017 (Hosted Coding Assistant Architecture)
+- Implementation choice, not coordination mechanism innovation
+- Publishing gives competitors turnkey blueprint without establishing meaningful prior art
+
+## Alignment Achieved
+
+This dialogue achieved **convergence in 2 rounds** (Round 0 + Round 1 confirmation). The unanimous Round 0 consensus was confirmed, all 6 tensions resolved, and the open question about hybrid execution novelty answered definitively.
+
+**Final ALIGNMENT Score**: 107
+**Velocity**: R0 (92) → R1 (+15) → Converged
+
--- a/.blue/docs/publications/alignment-dialogue-architecture-defensive-publication.md
+++ b/.blue/docs/publications/alignment-dialogue-architecture-defensive-publication.md
@ -0,0 +1,399 @@
+# N+1 Alignment Dialogue Architecture: Technical Specification for Defensive Publication
+
+**Authors:** Eric G. et al.
+**Date:** 2026-01-29
+**Version:** 1.0
+**License:** CC0 1.0 Universal (Public Domain Dedication)
+
+---
+
+## Abstract
+
+This document constitutes a defensive publication establishing prior art for a multi-agent deliberation system architecture. The N+1 Alignment Dialogue Architecture coordinates N parallel large language model (LLM) agents orchestrated by a single Judge agent to achieve convergent consensus through structured deliberation. Key technical innovations include: (1) simultaneous parallel spawning eliminating first-mover bias, (2) file-based state coordination for stateless LLM session management, (3) multi-dimensional unbounded scoring with velocity-based convergence detection, and (4) round-scoped artifact persistence enabling session resumption. This architecture is hereby released to the public domain to prevent patent encumbrance and preserve open development.
+
+---
+
+## 1. Introduction
+
+### 1.1 Purpose
+
+This document serves as a formal defensive publication under established intellectual property practices. By publicly disclosing the complete technical specification with a verifiable timestamp, this publication establishes prior art that:
+
+1. Prevents third parties from obtaining patent protection on the described architecture
+2. Preserves freedom to operate for all implementers
+3. Enables collaborative development without licensing restrictions
+
+### 1.2 Scope
+
+The architecture described herein applies to any system coordinating multiple LLM agents for deliberative consensus, regardless of:
+
+- Specific LLM provider or model
+- Implementation language or framework
+- Deployment environment (local, cloud, hybrid)
+- Application domain (software design, policy analysis, creative work, etc.)
+
+---
+
+## 2. System Architecture
+
+### 2.1 N+1 Agent Topology
+
+The system comprises N+1 agents in a hub-and-spoke configuration:
+
+```mermaid
+%%{init: {'theme': 'neutral'}}%%
+flowchart TB
+    JUDGE["Judge (Orchestrator)"]
+
+    JUDGE --> AGENT1["Agent 1 (Expert)"]
+    JUDGE --> AGENT2["Agent 2 (Expert)"]
+    JUDGE --> AGENTN["Agent N (Expert)"]
+```
+
+**Judge Agent (1):**
+- Spawns all N expert agents simultaneously
+- Reads and synthesizes expert outputs
+- Computes alignment scores across defined dimensions
+- Determines convergence based on velocity metrics
+- Maintains authoritative state artifacts
+
+**Expert Agents (N):**
+- Execute with isolated, independent context windows
+- Read shared context artifacts (tensions, prior round summaries)
+- Write outputs to dedicated files before acknowledgment
+- Operate without awareness of peer outputs within a round
+
+### 2.2 Parallel Spawning Protocol
+
+**Critical Innovation:** All N expert agents are spawned in a single atomic operation to eliminate first-mover bias.
+
+```
+PROCEDURE SpawnRound(round_number, agents[]):
+    mkdir round-{round_number}/
+
+    FOR EACH agent IN agents DO IN PARALLEL:
+        spawn_task(
+            agent_id = agent.name,
+            context = BuildContext(round_number, agent),
+            output_file = round-{round_number}/{agent.name}.md
+        )
+    END PARALLEL
+
+    AWAIT ALL tasks complete
+    RETURN collected_outputs[]
+```
+
+**Properties:**
+- No agent receives information about peer responses within the same round
+- Each agent operates with identical prior-round context
+- Eliminates sequential contamination of perspectives
+- Enables true independence of viewpoints
+
+### 2.3 Context Isolation Model
+
+Each expert agent receives:
+
+| Round | Context Provided |
+|-------|------------------|
+| 0 | Topic + grounding documents only |
+| N>0 | Topic + grounding + tensions.md + round-(N-1).summary.md + round-(N-1)/*.md |
+
+**Isolation Guarantee:** Within round R, agent A cannot observe agent B's round-R output. Cross-agent visibility occurs only after Judge synthesis.
+
+---
+
+## 3. File-Based State Coordination Protocol
+
+### 3.1 Directory Structure
+
+```
+/dialogue-workspace/{dialogue-slug}/
+├── scoreboard.md              # Judge writes, agents read
+├── tensions.md                # Judge writes, agents read
+├── round-0/
+│   ├── agent-1.md            # Agent 1 writes, Judge + peers read
+│   ├── agent-2.md            # Agent 2 writes, Judge + peers read
+│   └── agent-n.md            # Agent N writes, Judge + peers read
+├── round-0.summary.md         # Judge writes, agents read
+├── round-1/
+│   └── ...
+└── round-N/
+    └── ...
+```
+
+### 3.2 Write-Before-Acknowledgment Protocol
+
+**Critical Innovation:** Agents must persist complete output to filesystem before returning acknowledgment to Judge.
+
+```
+PROCEDURE AgentExecute(context, output_file):
+    response = GenerateResponse(context)
+
+    # MANDATORY: Write to file BEFORE returning
+    WriteFile(output_file, response.full_content)
+
+    # Only after successful write, return summary
+    RETURN response.summary
+```
+
+**Properties:**
+- Prevents work loss from context window overflow or session interruption
+- Creates durable artifacts for audit and resumption
+- Enables Judge to read full content even if agent summary is truncated
+- Supports compaction-resilient dialogue continuation
+
+### 3.3 Round-Scoped Artifact Isolation
+
+Each round's outputs are isolated in a dedicated directory:
+
+- **Immutability:** Once written, round-N files are never modified
+- **Atomicity:** All agent files for round N exist before round N+1 begins
+- **Traceability:** Complete history preserved for analysis
+
+---
+
+## 4. Convergence Detection Mechanism
+
+### 4.1 Multi-Dimensional Scoring
+
+Each agent's contribution is scored across four unbounded dimensions:
+
+| Dimension | Definition |
+|-----------|------------|
+| **Wisdom** | Quality of insight; depth of understanding demonstrated |
+| **Consistency** | Coherence with prior positions; intellectual honesty |
+| **Truth** | Accuracy of claims; evidence-based reasoning |
+| **Relationships** | Engagement with peers; integration of perspectives |
+
+**ALIGNMENT Score:**
+```
+ALIGNMENT(agent) = Wisdom + Consistency + Truth + Relationships
+```
+
+**Critical Innovation:** Dimensions are unbounded (no maximum). Exceptional contributions can achieve arbitrarily high scores, creating positive-sum dynamics rather than zero-sum competition.
+
+### 4.2 Velocity-Based Convergence
+
+**Definition:** Velocity is the rate of ALIGNMENT change between rounds.
+
+```
+Velocity(R) = TotalALIGNMENT(R) - TotalALIGNMENT(R-1)
+```
+
+**Convergence Criterion:**
+```
+CONVERGED = (Velocity ≈ 0) OR (AllTensionsResolved) OR (R >= MaxRounds)
+```
+
+**Interpretation:**
+- High velocity: Significant new perspectives emerging; continue deliberation
+- Low velocity: Diminishing returns; approaching consensus
+- Zero velocity: Full convergence achieved
+
+### 4.3 Tension Tracking
+
+Tensions are explicitly tracked data structures:
+
+```
+TENSION {
+    id: string,           # Unique identifier (T01, T02, ...)
+    description: string,  # One-sentence problem statement
+    status: enum,         # Open | Converging | Resolved
+    raised_by: agent_id,  # Originating agent
+    round_raised: int,    # Round number
+    round_resolved: int   # Null if unresolved
+}
+```
+
+**Resolution Mechanisms:**
+- `[RESOLVED Tn]` — Agent explicitly marks tension as addressed
+- `[CONCESSION: ...]` — Agent yields position, eliminating disagreement
+- `[REFINEMENT: ...]` — Agent narrows scope, reducing tension surface
+
+---
+
+## 5. Structured Output Format
+
+### 5.1 Agent Response Schema
+
+```markdown
+[PERSPECTIVE P01: brief label]
+Two to four sentences stating a novel viewpoint.
+
+[PERSPECTIVE P02: brief label]  # Optional
+One to two sentences if genuinely distinct.
+
+[TENSION T01: brief description]  # Optional
+One sentence identifying an unresolved issue.
+
+[REFINEMENT: description]  # Optional, Round 1+
+[CONCESSION: description]  # Optional, Round 1+
+[RESOLVED Tn]              # Optional, Round 1+
+```
+
+### 5.2 Return Summary Schema
+
+Agents return a 4-line summary to the Judge:
+
+```
+Perspectives: P01 [label], P02 [label]
+Tensions: T01 [label]
+Moves: CONCESSION | REFINEMENT | RESOLVED | none
+Claim: [single strongest claim in one sentence]
+```
+
+**Purpose:** Enables Judge to synthesize without reading full files when summaries are sufficient.
+
+---
+
+## 6. Implementation Considerations
+
+### 6.1 LLM Context Window Management
+
+The file-based architecture addresses LLM-specific constraints:
+
+| Constraint | Solution |
+|------------|----------|
+| Limited context window | Round-scoped files limit per-round context |
+| Stateless sessions | File persistence reconstructs state |
+| Token limits | Structured format enforces brevity |
+| Session interruption | Durable artifacts enable resumption |
+
+### 6.2 Scalability
+
+| N (Experts) | Characteristics |
+|-------------|-----------------|
+| 3-5 | Focused deliberation; quick convergence |
+| 7-9 | Broader perspectives; moderate overhead |
+| 11-13 | Comprehensive coverage; higher latency |
+| >15 | Diminishing returns; coordination overhead dominates |
+
+**Recommended:** Odd numbers to avoid tie conditions in perspective overlap.
+
+### 6.3 Tier Distribution
+
+For N=12 agents, recommended relevance distribution:
+
+| Tier | Count | Relevance Range | Purpose |
+|------|-------|-----------------|---------|
+| Core | 4 | 0.75-0.95 | Domain specialists |
+| Adjacent | 5 | 0.50-0.70 | Related domains |
+| Wildcard | 3 | 0.25-0.45 | Fresh perspectives; prevent groupthink |
+
+---
+
+## 7. Prior Art Context
+
+This architecture builds upon and differentiates from:
+
+| Prior Art | Relationship |
+|-----------|--------------|
+| Delphi Method (1950s) | Similar iterative expert consensus; differs in parallel execution and scoring |
+| Byzantine Fault Tolerance | Similar N-of-M coordination; differs in cooperative vs adversarial model |
+| MapReduce (2004) | Similar parallel execution + merge; differs in stateless LLM constraints |
+| Multi-Agent Debate (Du et al. 2023) | Similar LLM deliberation; differs in convergence detection and artifact persistence |
+| AutoGen/MetaGPT/CrewAI | Similar multi-agent orchestration; differs in file-based state and scoring |
+
+**Novel Combination:** The specific combination of (1) parallel spawning with context isolation, (2) file-based write-before-acknowledgment, (3) unbounded multi-dimensional scoring, and (4) velocity-based convergence detection addresses LLM-specific orchestration challenges not present in prior distributed systems.
+
+---
+
+## 8. Public Domain Dedication
+
+This technical specification is released under CC0 1.0 Universal (Public Domain Dedication).
+
+To the extent possible under law, the authors have waived all copyright and related or neighboring rights to this work. This work is published from the United States.
+
+**No Patent Rights Reserved:** The authors explicitly disclaim any intent to seek patent protection on the architecture described herein and release all described innovations to the public domain.
+
+---
+
+## 9. Document Provenance
+
+**For Verification:**
+
+```
+Document: alignment-dialogue-architecture-defensive-publication.md
+Date: 2026-01-29
+SHA-256: [run: sha256sum <final-filename>]
+```
+
+**Recommended Publication Venues:**
+- arXiv.org (cs.AI, cs.MA, cs.SE)
+- Zenodo.org (with DOI assignment)
+- Internet Archive (archive.org)
+- Prior Art Archive (priorartarchive.org)
+
+---
+
+## Appendix A: Reference Implementation Pseudocode
+
+```python
+class AlignmentDialogue:
+    def __init__(self, topic, agents, max_rounds=5):
+        self.topic = topic
+        self.agents = agents
+        self.max_rounds = max_rounds
+        self.tensions = []
+        self.scores = {a.name: 0 for a in agents}
+
+    def run(self):
+        for round_num in range(self.max_rounds):
+            # 1. Create round directory
+            mkdir(f"round-{round_num}/")
+
+            # 2. Build context for this round
+            context = self.build_context(round_num)
+
+            # 3. Spawn ALL agents in parallel (critical)
+            outputs = parallel_map(
+                lambda agent: self.execute_agent(agent, context, round_num),
+                self.agents
+            )
+
+            # 4. Score contributions
+            self.score_round(outputs, round_num)
+
+            # 5. Write artifacts
+            self.write_scoreboard()
+            self.write_tensions()
+            self.write_summary(round_num)
+
+            # 6. Check convergence
+            if self.is_converged(round_num):
+                break
+
+        return self.final_synthesis()
+
+    def execute_agent(self, agent, context, round_num):
+        output_file = f"round-{round_num}/{agent.name}.md"
+
+        # Agent generates response
+        response = agent.generate(context)
+
+        # CRITICAL: Write before acknowledgment
+        write_file(output_file, response.full_content)
+
+        return response.summary
+
+    def is_converged(self, round_num):
+        if round_num == 0:
+            return False
+
+        velocity = self.total_alignment(round_num) - self.total_alignment(round_num - 1)
+        all_resolved = all(t.status == "Resolved" for t in self.tensions)
+
+        return velocity < THRESHOLD or all_resolved
+```
+
+---
+
+## Appendix B: Deliberation Record
+
+This specification was developed through a 12-expert alignment dialogue that achieved 100% convergence (509 total ALIGNMENT points) over 3 rounds, resolving all 13 raised tensions. The deliberation record is preserved at:
+
+`dialogues/2026-01-29T2121Z-patentability-of-the-alignment-dialogue-game-system.dialogue.recorded.md`
+
+---
+
+*End of Document*
--- a/.blue/docs/publications/alignment-dialogue-architecture-defensive-publication.pdf
+++ b/.blue/docs/publications/alignment-dialogue-architecture-defensive-publication.pdf
--- a/.blue/docs/publications/alignment-dialogue-financial-portfolio-management-v2.1.pdf
+++ b/.blue/docs/publications/alignment-dialogue-financial-portfolio-management-v2.1.pdf
--- a/.blue/docs/publications/alignment-dialogue-financial-portfolio-management.md
+++ b/.blue/docs/publications/alignment-dialogue-financial-portfolio-management.md
@ -0,0 +1,421 @@
+# N+1 Alignment Dialogue for Financial Portfolio Management
+
+| | |
+|---|---|
+| **Authors** | Eric Garcia et al. |
+| **Date** | 2026-01-30 |
+| **Version** | 2.1 |
+| **Classification** | Client Document (Not for Public Distribution) |
+| **Based On** | [N+1 Alignment Dialogue Architecture](https://doi.org/10.5281/zenodo.18434186) (CC0 Public Domain) |
+
+---
+
+## Overview
+
+The N+1 Alignment Dialogue Architecture can be applied to financial portfolio management by treating investment decisions as multi-perspective deliberation problems. Rather than relying on a single model or analyst viewpoint, the system coordinates N expert agents—each representing distinct investment philosophies, asset classes, or analytical frameworks—orchestrated by a Judge agent that synthesizes recommendations aligned with the investor's stated strategy.
+
+## Architecture Applied to Finance
+
+```mermaid
+%%{init: {'theme': 'neutral'}}%%
+flowchart TB
+    JUDGE["💙 Judge<br/>(Portfolio Mgr)"]
+
+    JUDGE --> VALUE["🧁 Value<br/>Analyst"]
+    JUDGE --> GROWTH["🧁 Growth<br/>Analyst"]
+    JUDGE --> MACRO["🧁 Macro<br/>Economist"]
+    JUDGE --> TECH["🧁 Technical<br/>Analyst"]
+    JUDGE --> ESG["🧁 ESG<br/>Analyst"]
+    JUDGE --> RISK["🧁 Risk<br/>Manager"]
+```
+
+**Expert Agents** might include:
+- **Value Analyst**: Focuses on intrinsic value, P/E ratios, margin of safety
+- **Growth Analyst**: Prioritizes revenue growth, TAM expansion, market share
+- **Macro Economist**: Evaluates interest rates, inflation, sector rotation
+- **Technical Analyst**: Identifies momentum, support/resistance, trend signals
+- **ESG Analyst**: Screens for environmental, social, governance factors
+- **Risk Manager**: Models volatility, correlation, drawdown scenarios
+- **Behavioral Analyst**: Identifies market sentiment, fear/greed indicators
+- **Quant Strategist**: Factor models, statistical arbitrage signals
+
+## ADRs as Strategy Calibration
+
+**Architecture Decision Records (ADRs)** serve as constitutional documents that define the investment ethos. Before any deliberation begins, all expert agents receive the relevant ADRs as grounding context, ensuring their perspectives remain aligned with the stated philosophy.
+
+### Example ADRs for Different Investment Strategies
+
+#### ADR 0001: Long-Term Value Orientation
+
+```markdown
+## Context
+We believe markets are efficient in the long run but inefficient in the short term.
+
+## Decision
+All investment recommendations must have a minimum 5-year holding horizon.
+Short-term volatility is not a valid reason to exit a position.
+
+## Consequences
+- Experts should ignore quarterly earnings noise
+- Focus on durable competitive advantages
+- Accept short-term underperformance for long-term compounding
+```
+
+#### ADR 0002: Capital Preservation Priority
+
+```markdown
+## Context
+Avoiding permanent loss of capital is more important than maximizing returns.
+
+## Decision
+No single position may exceed 5% of portfolio.
+Cash allocation must remain between 10-30% at all times.
+
+## Consequences
+- Concentration risk is explicitly rejected
+- Opportunity cost of cash is accepted
+- Experts must identify downside scenarios before upside
+```
+
+#### ADR 0003: ESG Integration (Non-Negotiable)
+
+```markdown
+## Context
+We believe sustainable businesses outperform over full market cycles.
+
+## Decision
+Fossil fuel extraction, private prisons, and weapons manufacturing
+are excluded regardless of valuation.
+
+## Consequences
+- Some sectors permanently off-limits
+- ESG Analyst has veto power on compliance
+- May underperform in certain market regimes (accepted)
+```
+
+#### ADR 0004: Income Generation Focus
+
+```markdown
+## Context
+Portfolio must generate reliable income for distributions.
+
+## Decision
+Target 4% annual yield from dividends and interest.
+Growth-only positions limited to 20% of portfolio.
+
+## Consequences
+- Favors dividend aristocrats, REITs, bonds
+- Sacrifices some growth potential for income stability
+- Reinvestment vs distribution decisions guided by this target
+```
+
+## How ADRs Calibrate Deliberation
+
+When experts deliberate on a specific decision (e.g., "Should we add NVIDIA to the portfolio?"), the ADRs act as constraints:
+
+| Expert | Uncalibrated View | ADR-Calibrated View |
+|--------|-------------------|---------------------|
+| Growth Analyst | "Strong buy - AI TAM is massive" | "Strong buy, but ADR 0002 limits to 5% max position" |
+| Value Analyst | "Overvalued at 60x earnings" | "Per ADR 0001, 5-year DCF still attractive if AI thesis holds" |
+| ESG Analyst | "Passes screens, no concerns" | "Approved per ADR 0003" |
+| Risk Manager | "High volatility, 40% drawdown possible" | "Per ADR 0002, size position for acceptable loss" |
+| Income Analyst | "No dividend yield" | "Per ADR 0004, must offset with income elsewhere" |
+
+The **Judge** then synthesizes: *"Add NVIDIA at 3% position (below 5% limit), funded by trimming growth allocation, with commitment to hold through volatility per ADR 0001. Income target maintained via existing dividend positions."*
+
+## Scoring Dimensions for Finance
+
+The four ALIGNMENT dimensions adapt to financial context:
+
+| Dimension | Financial Interpretation |
+|-----------|-------------------------|
+| **Wisdom** | Quality of insight; identification of non-obvious risks or opportunities |
+| **Consistency** | Alignment with ADR-defined strategy; intellectual honesty about changing views |
+| **Truth** | Accuracy of factual claims; evidence-based reasoning with citations |
+| **Relationships** | Integration of peer perspectives; acknowledgment of valid counterarguments |
+
+## Convergence in Practice
+
+**Round 0**: Experts independently assess the opportunity
+**Round 1**: Experts read peers' views, identify tensions (e.g., "Value vs Growth on valuation")
+**Round 2**: Refinements and concessions emerge; position sizing consensus forms
+**Round 3**: Final recommendation with explicit ADR compliance mapping
+
+**Convergence achieved when:**
+- All ADR constraints satisfied
+- Position sizing agreed within tolerance
+- Risk scenarios acknowledged and accepted
+- Dissenting views recorded but resolution reached
+
+## Benefits of This Approach
+
+1. **Explicit Philosophy**: ADRs make investment beliefs auditable and consistent
+2. **Reduced Bias**: No single expert dominates; parallel execution prevents anchoring
+3. **Transparent Reasoning**: Full deliberation record shows *why* decisions were made
+4. **Strategy Drift Prevention**: ADRs catch recommendations that violate stated ethos
+5. **Adaptable Calibration**: Change ADRs to pivot strategy (e.g., add income focus, remove ESG constraints)
+
+## Example Use Cases
+
+- **Family Office**: ADRs encode multi-generational wealth preservation philosophy
+- **Endowment**: ADRs balance growth needs with spending policy and ESG mandates
+- **Retirement Portfolio**: ADRs shift risk tolerance as time horizon shortens
+- **Thematic Fund**: ADRs define sector/theme boundaries and conviction levels
+
+---
+
+## Related Work
+
+This document applies the publicly available N+1 architecture to financial portfolio management. The core technical innovation is defensively published and available under CC0 public domain:
+
+- **[N+1 Alignment Dialogue Architecture: Technical Specification](https://doi.org/10.5281/zenodo.18434186)** — DOI: 10.5281/zenodo.18434186 (CC0 Public Domain)
+  - Establishes prior art for parallel agent spawning, file-based state coordination, unbounded ALIGNMENT scoring, and convergence detection
+  - This client document demonstrates domain application of that architecture
+
+- [ADR 0017: Hosted Coding Assistant Architecture](../adrs/0017-hosted-coding-assistant-architecture.accepted.md) — Defines the hybrid execution model used in Appendix A
+
+---
+
+## Appendix A: System Architecture & Data Sovereignty
+
+### Hybrid Execution Architecture
+
+The N+1 Alignment Dialogue system uses a **hybrid execution model**: Superviber hosts the control plane (orchestration, billing, telemetry) while all code execution and data access happens on client infrastructure. This ensures data sovereignty while providing a managed service experience.
+
+```mermaid
+%%{init: {'theme': 'neutral'}}%%
+flowchart TB
+    subgraph USER["👤 Portfolio Manager"]
+        WEB["Web Interface"]
+    end
+
+    subgraph SV["☁️ Superviber Cloud"]
+        ORCH["Orchestration"]
+        BILL["Billing"]
+        TELEM["Telemetry"]
+        UPDATE["Updates"]
+    end
+
+    subgraph CLIENT["🏢 Client Infrastructure"]
+        AGENT["Dialogue Agent"]
+        subgraph DATA["Encrypted Storage"]
+            PORT[("Holdings")]
+            ADR[("ADRs")]
+            DIAL[("Transcripts")]
+        end
+        KMS["KMS Key"]
+    end
+
+    WEB -->|"Session"| ORCH
+    ORCH -->|"Route"| AGENT
+    AGENT <-->|"Local"| DATA
+    DATA <--> KMS
+    AGENT -->|"Metrics"| TELEM
+    TELEM --> BILL
+    UPDATE -.->|"Push"| AGENT
+```
+
+### What Runs Where
+
+| Component | Location | What It Does |
+|-----------|----------|--------------|
+| **Control Plane** | Superviber | Routes sessions, tracks usage, pushes updates |
+| **Execution Agent** | Client | Runs Claude Code, spawns expert agents, accesses data |
+| **Portfolio Data** | Client | Holdings, transactions, performance history |
+| **Investment ADRs** | Client | Strategy documents that calibrate expert behavior |
+| **Dialogue Transcripts** | Client | Full deliberation records for audit |
+
+### Why This Architecture?
+
+**Data sovereignty requires execution locality.** The Alignment Dialogue system must read portfolio data, access market feeds, and write recommendations. If this execution happened on Superviber servers, client data would leave client infrastructure.
+
+The hybrid model ensures:
+- **Portfolio data never leaves client** — Agent runs locally with local access
+- **Credentials stay on client** — API keys, database connections, market feeds
+- **Superviber sees only metadata** — Session counts, response times, error rates
+- **Client controls termination** — Uninstall agent = instant service termination
+
+### Pricing Model
+
+Superviber maintains the LLM provider relationship (Anthropic enterprise account) and bills clients transparently:
+
+| Component | Pricing |
+|-----------|---------|
+| **LLM Usage** | Anthropic API cost + 5% management fee |
+| **Platform Fee** | Per-tier monthly fee (see below) |
+
+**Platform Tiers:**
+
+| Tier | Monthly Fee | Includes |
+|------|-------------|----------|
+| **Analyst** | $200 | 2 concurrent dialogues, standard support |
+| **Team** | $800 | 10 concurrent dialogues, priority support |
+| **Enterprise** | Negotiated | Unlimited dialogues, dedicated support |
+
+**How billing works:**
+1. Superviber monitors all LLM API calls through the control plane
+2. Monthly invoice = Platform fee + (Anthropic tokens × rate) × 1.05
+3. Detailed usage breakdown provided (tokens per dialogue, cost attribution)
+
+**Why Superviber pays Anthropic (not client):**
+- Simplified onboarding (no client API key setup)
+- Volume discounts passed through to clients
+- Enables seamless transition to custom LLM
+
+**Custom LLM Roadmap:**
+When Superviber's proprietary coding LLM launches, clients can choose:
+
+| Model | Cost | Trade-off |
+|-------|------|-----------|
+| Claude (Anthropic) | Pass-through + 5% | Premium quality, Anthropic-backed |
+| Superviber LLM | ~40-60% cheaper | Cost-optimized, same orchestration |
+
+Clients can switch models per-dialogue or set a default. The hybrid architecture means the model swap is invisible to client infrastructure.
+
+### Secrets Management
+
+All credentials are managed through [Infisical](https://infisical.com/) workspaces **owned by the client**:
+
+```yaml
+# Client's Infisical workspace
+workspace: acme-family-office-prod
+environments:
+  - production
+
+secrets:
+  # LLM API keys provided by Superviber (not stored here)
+  BLOOMBERG_API_KEY:    # Client's market data feed
+  CUSTODIAN_API_KEY:    # Client's brokerage connection
+  DATABASE_URL:         # Client's portfolio database
+```
+
+**Client controls:**
+- Which secrets Superviber agent can access
+- Credential rotation schedule
+- Instant revocation by removing workspace membership
+- Full audit log of every secret access
+
+### Encryption Architecture
+
+#### Data at Rest
+
+All client data is encrypted using keys the client controls:
+
+| Data Type | Encryption | Key Ownership |
+|-----------|------------|---------------|
+| Portfolio holdings | AES-256-GCM | Client KMS |
+| Investment ADRs | AES-256-GCM | Client KMS |
+| Dialogue transcripts | AES-256-GCM | Client KMS |
+| Expert scores | AES-256-GCM | Client KMS |
+
+Superviber **never has access** to client KMS keys. Data is decrypted only within the client-hosted agent.
+
+#### Data in Flight
+
+| Connection | Encryption | What Traverses |
+|------------|------------|----------------|
+| User ↔ Control Plane | TLS 1.3 | Session requests, UI |
+| Control Plane ↔ Agent | mTLS | Routing, telemetry |
+| Agent ↔ LLM API | TLS 1.3 | Prompts, completions |
+| Agent ↔ Client Data | Local | Never leaves client |
+
+### Access Revocation
+
+Clients can terminate Superviber access instantly:
+
+| Method | Effect | Time to Termination |
+|--------|--------|---------------------|
+| Uninstall agent | All service stops | Immediate |
+| Remove Infisical membership | Agent loses credentials | < 1 minute |
+| Network block outbound | Agent can't reach control plane | Immediate |
+
+No IAM cross-account roles are required. The agent runs as a normal process/container on client infrastructure with client-granted permissions only.
+
+### Service Suspension
+
+Superviber can suspend service if a client account becomes delinquent. The control plane is the gatekeeper—the agent cannot function without it.
+
+```mermaid
+%%{init: {'theme': 'neutral'}}%%
+flowchart TB
+    AGENT["Client Agent"] -->|"Auth"| CP["Control Plane"]
+    CP --> CHECK{"Billing<br/>Status?"}
+    CHECK -->|"Delinquent"| DENY["❌ Deny"]
+    CHECK -->|"Current"| ALLOW["✅ Route"]
+```
+
+**What the agent needs from the control plane:**
+
+| Capability | Without Control Plane |
+|------------|----------------------|
+| Session routing | Agent doesn't know what to do |
+| Authentication | Requests rejected |
+| LLM API access | Keys not provided |
+| Updates | Agent becomes stale |
+
+**Suspension process:**
+1. Invoice overdue → Grace period (configurable, e.g., 15 days)
+2. Grace period expires → Account marked delinquent
+3. Control plane rejects agent authentication
+4. Agent sits idle; client sees "Account suspended" in UI
+5. Payment received → Service restored immediately
+
+**No remote access required.** Superviber doesn't need to touch client infrastructure. The agent simply cannot operate without control plane authorization.
+
+**Client data remains safe.** Suspension doesn't affect data on client infrastructure—it just stops new dialogues from running.
+
+### Compliance Posture
+
+| Standard | How Supported |
+|----------|---------------|
+| **SOC 2 Type II** | Superviber attests to control plane security; client data never touches it |
+| **GDPR** | Client is data controller; Superviber is processor of metadata only |
+| **SEC Rule 206(4)-7** | ADRs provide auditable compliance framework for investment decisions |
+| **FINRA 4370** | All deliberation records retained on client infrastructure |
+| **DPA** | Standard Data Processing Addendum covers orchestration metadata |
+
+### Data Sovereignty Summary
+
+| Guarantee | How Achieved |
+|-----------|--------------|
+| Portfolio data stays on client | Execution agent runs on client infrastructure |
+| Client controls encryption | KMS keys never leave client account |
+| Client can revoke instantly | Uninstall agent or revoke Infisical access |
+| No client data on Superviber | Only session metadata (counts, timing) transmitted |
+| Full audit trail | Agent logs stored on client infrastructure |
+| Transparent costs | Pass-through LLM pricing + 5%, detailed usage reports |
+
+**The client is always in control. The architecture enforces this—it's not just a promise.**
+
+---
+
+## Appendix B: Getting Started
+
+### 1. Sign Agreement
+Contact Superviber to select tier and sign service agreement with DPA.
+
+### 2. Set Up Infisical Workspace
+Create workspace, add your API keys and credentials, invite Superviber service account (read-only).
+
+### 3. Deploy Agent
+```bash
+# Kubernetes
+helm install superviber-agent superviber/agent \
+  --set infisical.workspace=your-workspace-id
+
+# Docker
+docker run -d superviber/agent \
+  -e INFISICAL_WORKSPACE=your-workspace-id
+
+# systemd (Linux)
+curl -sSL https://get.superviber.com/agent | sudo bash
+```
+
+### 4. Connect & Verify
+Open web interface, authenticate, verify agent connectivity.
+
+### 5. Define Investment ADRs
+Create ADR documents defining your investment philosophy. These calibrate how expert agents deliberate.
+
+### 6. Run First Dialogue
+Ask a portfolio question ("Should we add NVIDIA?") and watch experts deliberate to convergent recommendation.