fbda1b4beb
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
- ADD_CHAIN138_TO_LEDGER_LIVE: Ledger form done; public code review repo bis-innovations/LedgerLive; init/push commands - CONTRACT_DEPLOYMENT_RUNBOOK: Chain 138 gas price 1 gwei, 36-addr check, TransactionMirror workaround - CONTRACT_*: AddressMapper, MirrorManager deployed 2026-02-12; 36-address on-chain check - NEXT_STEPS_FOR_YOU: Ledger done; steps completable now (no LAN); run-completable-tasks-from-anywhere - MASTER_INDEX, OPERATOR_OPTIONAL, SMART_CONTRACTS_INVENTORY_SIMPLE: updates - LEDGER_BLOCKCHAIN_INTEGRATION_COMPLETE: bis-innovations/LedgerLive reference Co-authored-by: Cursor <cursoragent@cursor.com>
5.6 KiB
5.6 KiB
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
wwwvsportalsplit - 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 buildEXPECTED_WEB_CONTENT.md— What each service should provideBRAND_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)