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.

Why This Matters:

• Reconciles 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)