proxmox/docs/02-architecture/NON_GOALS.md

# Non-Goals — Sankofa Phoenix

**Last Updated:** 2026-01-31  
**Document Version:** 1.0  
**Status:** Active Documentation

---

_Last reviewed: 2026-01-20_  
_Status: Explicit Non-Goals (What We Are NOT Building)_

---

## Purpose

This document explicitly states **what Sankofa Phoenix is NOT intended to be**, to prevent scope creep, accidental commitments, and architectural drift.

**Key Principle:** Explicit non-goals prevent accidental lock-in and preserve optionality.

---

## Explicit Non-Goals

### 1. Phoenix is NOT a Public Marketing Site

**What Phoenix Is:**
- Cloud infrastructure control plane
- Operator-facing API and management interface
- Sovereign-grade CSP platform

**What Phoenix Is NOT:**
- Public brochure website
- Marketing landing page
- Customer-facing product showcase

**Why This Matters:**
- Prevents accidental public exposure of control plane
- Maintains clear separation of concerns
- Preserves operator-focused architecture

**Flexibility:**
- Does not preclude future public-facing features
- Does not prevent delegated UI development
- Does not restrict API evolution

---

### 2. Sankofa Portal is NOT Solely an Internal Tool

**What Sankofa Portal Is:**
- Corporate brand presence
- Entry point to Phoenix services
- Sovereign identity messaging

**What Sankofa Portal Is NOT:**
- Exclusively internal tool
- Permanently gated system
- Marketing-only site

**Why This Matters:**
- Preserves optionality for public/private split
- Allows evolution of access patterns
- Maintains brand presence flexibility

**Current State:**
- Currently login-gated
- May evolve to include public content
- Decision point remains open

---

### 3. Explorer is NOT Coupled to Portal Authentication

**What Explorer Is:**
- Public blockchain transparency layer
- Independent infrastructure
- Settlement inspection tool

**What Explorer Is NOT:**
- Gated behind portal auth
- Dependent on Phoenix services
- Part of control plane

**Why This Matters:**
- Maintains public transparency
- Preserves independence
- Prevents accidental coupling

**Flexibility:**
- May evolve branding
- May add optional features
- Remains independent from portal auth

---

### 4. We Are NOT Building "One Diagram to Rule Them All"

**What We Have:**
- Multiple intent documents
- Service-specific descriptions
- Illustrative diagrams (when needed)

**What We Are NOT Building:**
- Single, final architecture diagram
- Comprehensive flow diagrams
- Permanent topology maps

**Why This Matters:**
- Diagrams create accidental lock-in
- Multiple small diagrams preserve flexibility
- Evolution remains cheap

**Approach:**
- One diagram per intent (when needed)
- Time-scoped ("As of Q3 2026")
- Labeled "Illustrative"

---

### 5. We Are NOT Locking Implementation to Domain Structure

**What We Have:**
- Descriptive domain names
- Clear service roles
- Flexible deployment

**What We Are NOT Doing:**
- Hard-coding domain structure in code
- Mandating DNS-based architecture
- Creating "security by DNS" decisions

**Why This Matters:**
- Preserves deployment flexibility
- Allows infrastructure evolution
- Prevents accidental constraints

---

### 6. We Are NOT Creating Immutable Governance Rules

**What We Have:**
- Intent documents
- Policy boundaries
- Open decision points

**What We Are NOT Creating:**
- Permanent governance contracts
- Unchangeable rules
- Locked compliance mappings

**Why This Matters:**
- Governance can evolve
- Policies can adjust
- Compliance can be mapped as needed

---

### 7. We Are NOT Forcing Premature Splits

**What We Have:**
- Possible future evolutions documented
- Open decision points
- Flexible architecture

**What We Are NOT Doing:**
- Forcing `www` vs `portal` split
- Mandating Phoenix UI vs API-only
- Requiring explorer branding alignment

**Why This Matters:**
- Avoids premature optimization
- Preserves optionality
- Allows natural evolution

---

### 8. We Are NOT Encoding Technology Choices in Names

**What We Use:**
- Role-based names ("Phoenix Cloud Services")
- Purpose-based names ("SolaceScanScout")
- Function-based names ("ChainID 138 Explorer")

**What We Avoid:**
- Technology-encoded names
- Implementation-locked names
- Jurisdiction-permanent names

**Why This Matters:**
- Technology can evolve
- Implementation can change
- Jurisdictional scope can adjust

---

## What This Document Does NOT Mean

This document does **not** mean:

- ❌ We will never build public Phoenix features
- ❌ Sankofa Portal must remain gated forever
- ❌ Explorer can never integrate with other services
- ❌ We cannot create architecture diagrams
- ❌ Domain structure cannot evolve
- ❌ Governance cannot be formalized
- ❌ Splits cannot happen when needed
- ❌ Names cannot be refined

**What It Means:**
- We are **not committing** to these things now
- We are **preserving optionality** for future decisions
- We are **avoiding premature lock-in**

---

## Relationship to Other Documents

**Complements:**
- `ARCHITECTURAL_INTENT.md` — What we intend to build
- `EXPECTED_WEB_CONTENT.md` — What each service should provide
- `BRAND_RELATIONSHIP.md` — Brand/product structure

**Together They:**
- Define intent without constraining implementation
- Preserve optionality while providing clarity
- Enable evolution without violating doctrine

---

## Review and Evolution

**Review Cadence:** As needed, when scope questions arise

**Evolution Process:**
- Non-goals can be refined
- New non-goals can be added
- Goals can be promoted from non-goals (with explicit decision)

**Authority:** This document reflects explicit non-commitments, not permanent restrictions.

---

**Last Updated:** 2026-01-20  
**Status:** Explicit Non-Goals (Preserves Optionality)