proxmox/docs/02-architecture/NON_GOALS.md

# Non-Goals — Sankofa Phoenix

**Last Updated:** 2026-03-25  
**Document Version:** 1.1  
**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

---

### 9. Phoenix IS Allowed an Internal Service Catalog (Not a Public Marketing Site)

**Clarification (2026-03-25):** Non-goal **§1** means Phoenix is **not** a **public brochure** or **anonymous consumer storefront**. It does **not** exclude:

- An **authenticated internal service catalog** (sometimes called “marketplace” in product language)
- **Entitlement management** and **provisioning APIs** for **public sector tenants**

**Wording discipline:** Prefer **service catalog** + **entitlements** in external/regulatory packs until **procurement-backed billing** exists. See [PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md](PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md).

**Why This Matters:**

- Reconciles [EXPECTED_WEB_CONTENT.md](EXPECTED_WEB_CONTENT.md) (“internal service catalog / marketplace”) with **§1** without turning Phoenix into a public marketing site.

---

### 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
- `PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md` — Tenancy, catalog vs marketing, repo boundaries

**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-03-25  
**Status:** Explicit Non-Goals (Preserves Optionality)