# 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)