eeef9cce3e
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
Made-with: Cursor
261 lines
6.6 KiB
Markdown
261 lines
6.6 KiB
Markdown
# 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)
|