eeef9cce3e
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
Made-with: Cursor
234 lines
6.8 KiB
Markdown
234 lines
6.8 KiB
Markdown
# Architectural Intent — Sankofa Phoenix
|
|
|
|
**Last Updated:** 2026-03-25
|
|
**Document Version:** 1.1
|
|
**Status:** Active Documentation
|
|
|
|
---
|
|
|
|
_Last reviewed: 2026-01-20_
|
|
_Status: Intent Document (Not Enforcement Contract)_
|
|
|
|
---
|
|
|
|
## Purpose of This Document
|
|
|
|
This document describes **intended architectural roles and boundaries** for Sankofa Phoenix services. It is an **intent statement**, not a permanent contract. Implementations may evolve without violating these intents.
|
|
|
|
**Key Principle:** Intent ≠ Contract. Evolution is expected and encouraged.
|
|
|
|
---
|
|
|
|
## Core Architectural Intents
|
|
|
|
### 1. Phoenix Cloud Platform
|
|
|
|
**Intended Role:** Sovereign-grade cloud infrastructure control plane
|
|
|
|
**Intended Characteristics:**
|
|
- Operator-facing control plane
|
|
- API-first architecture
|
|
- Multi-tenant resource provisioning
|
|
- Service orchestration and lifecycle management
|
|
|
|
**Current Implementation:**
|
|
- GraphQL API at `phoenix.sankofa.nexus`
|
|
- VMID 7800, 192.168.11.50:4000
|
|
|
|
**Intent Flexibility:**
|
|
> "Phoenix is intended to operate as an operator-facing control plane. This does not preclude future public or delegated interfaces."
|
|
|
|
**What This Means:**
|
|
- Current: API-first, operator-facing
|
|
- Future: May evolve to include public UI, delegated access, or other interfaces
|
|
- No permanent restriction on access patterns
|
|
|
|
**Public sector baseline:** Tenancy, **service catalog vs public marketing** (NON_GOALS §9), SMOA / Complete Credential repo registry: [PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md](PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md), [../../config/public-sector-program-manifest.json](../../config/public-sector-program-manifest.json).
|
|
|
|
---
|
|
|
|
### 2. Sankofa Brand & Access Layer
|
|
|
|
**Intended Role:** Corporate presence and brand narrative
|
|
|
|
**Intended Characteristics:**
|
|
- Public-facing corporate website
|
|
- Brand philosophy and mission
|
|
- Entry point to Phoenix services
|
|
- Sovereign identity messaging
|
|
|
|
**Current Implementation:**
|
|
- Next.js portal at `sankofa.nexus`
|
|
- VMID 7801, 192.168.11.51:3000
|
|
- Currently presents login-gated interface
|
|
|
|
**Intent Flexibility:**
|
|
> "Sankofa Portal serves as the corporate brand surface. Authentication requirements are policy-driven and may evolve."
|
|
|
|
**What This Means:**
|
|
- Current: Login-gated interface
|
|
- Future: May split into public marketing + authenticated portal, or maintain unified model
|
|
- Auth is a policy boundary, not a permanent architectural constraint
|
|
|
|
---
|
|
|
|
### 3. Public Transparency Layer (Explorer)
|
|
|
|
**Intended Role:** Public blockchain transparency and settlement inspection
|
|
|
|
**Intended Characteristics:**
|
|
- Public access (no authentication required)
|
|
- ChainID 138 block explorer
|
|
- Transaction and address inspection
|
|
- Network metrics and statistics
|
|
|
|
**Current Implementation:**
|
|
- SolaceScanScout at `explorer.d-bis.org`
|
|
- VMID 5000, 192.168.11.140
|
|
- Blockscout-based technology
|
|
|
|
**Intent Flexibility:**
|
|
> "The explorer serves as public infrastructure for ChainID 138. It remains independent from portal authentication systems."
|
|
|
|
**What This Means:**
|
|
- Current: Public, no auth, separate from Phoenix/Sankofa
|
|
- Future: May evolve branding, federation, or additional features
|
|
- Independence from portal auth is intentional, not permanent
|
|
|
|
---
|
|
|
|
## Service Boundary Intentions
|
|
|
|
### Brand Surface vs Control Surface
|
|
|
|
**Intent:** Clear separation in **language and documentation**, not necessarily in code or infrastructure.
|
|
|
|
**Brand Surface:**
|
|
- Corporate presence
|
|
- Public messaging
|
|
- Product introduction
|
|
|
|
**Control Surface:**
|
|
- Infrastructure management
|
|
- Resource provisioning
|
|
- Operational controls
|
|
|
|
**Flexibility:**
|
|
- These are **descriptive roles**, not structural mandates
|
|
- Implementation may evolve
|
|
- No requirement for separate repos, DNS structures, or service meshes
|
|
|
|
---
|
|
|
|
### Canonical vs Non-Canonical Services
|
|
|
|
**Intent:** Use canonical/non-canonical labels to clarify without restricting.
|
|
|
|
**Canonical Services:**
|
|
- `sankofa.nexus` — Canonical corporate website
|
|
- `phoenix.sankofa.nexus` — Canonical cloud control plane
|
|
- `explorer.d-bis.org` — Canonical ChainID 138 explorer
|
|
|
|
**Non-Canonical Services:**
|
|
- `blockscout.defi-oracle.io` — Reference/experimental instance
|
|
|
|
**Flexibility:**
|
|
- Canonical status can change
|
|
- Non-canonical can be promoted
|
|
- No implied permanence
|
|
|
|
---
|
|
|
|
## Policy Boundaries (Not Feature Boundaries)
|
|
|
|
### Authentication Requirements
|
|
|
|
**Intent:** Document auth as policy, not permanent feature.
|
|
|
|
**Current Policy:**
|
|
- Phoenix: Operator authentication required
|
|
- Sankofa Portal: Currently requires authentication
|
|
- Explorer: No authentication required
|
|
|
|
**Flexibility:**
|
|
- Auth requirements are policy-driven
|
|
- Can be adjusted based on governance decisions
|
|
- Not a permanent architectural constraint
|
|
|
|
---
|
|
|
|
## Naming and Identity Intentions
|
|
|
|
**Intent:** Use names that describe **role**, not **implementation**.
|
|
|
|
**Examples:**
|
|
- "Phoenix Cloud Services" — Describes role
|
|
- "SolaceScanScout" — Describes purpose
|
|
- "ChainID 138 Explorer" — Describes function
|
|
|
|
**Avoid:**
|
|
- Names that imply finality
|
|
- Names that encode technology choices
|
|
- Names that imply jurisdictional permanence
|
|
|
|
---
|
|
|
|
## Evolution Pathways (Non-Binding)
|
|
|
|
These are **possible futures**, not commitments:
|
|
|
|
### Possible Future Evolutions
|
|
|
|
1. **Sankofa / Phoenix hostname split (canonical intent)**
|
|
- `sankofa.nexus` → public **Sovereign Technologies** web
|
|
- `phoenix.sankofa.nexus` → public **Phoenix Cloud Services** division web
|
|
- `portal.sankofa.nexus` / `admin.sankofa.nexus` → **client SSO** (Keycloak IdP at `keycloak.sankofa.nexus`)
|
|
- `dash.sankofa.nexus` → **IP-gated** systems admin + **MFA**
|
|
- Detail: [EXPECTED_WEB_CONTENT.md](EXPECTED_WEB_CONTENT.md)
|
|
|
|
2. **Phoenix UI Evolution**
|
|
- May develop delegated UI interfaces
|
|
- May expose public-facing features
|
|
- Remains API-first, but UI is not precluded
|
|
|
|
3. **Explorer Branding**
|
|
- May align branding with DBIS Core products
|
|
- May federate with other explorers
|
|
- May evolve independently
|
|
|
|
**Note:** These are illustrative possibilities, not requirements or commitments.
|
|
|
|
---
|
|
|
|
## What This Document Does NOT Do
|
|
|
|
This document does **not**:
|
|
|
|
- ❌ Lock repo structure to domains
|
|
- ❌ Mandate folder structures
|
|
- ❌ Require service mesh topology
|
|
- ❌ Enforce immutable governance rules
|
|
- ❌ Create "security by DNS" decisions
|
|
- ❌ Force marketing vs ops separation
|
|
- ❌ Map to specific compliance frameworks
|
|
|
|
**Why:** These would create permanent constraints. This document preserves optionality.
|
|
|
|
---
|
|
|
|
## Review and Evolution
|
|
|
|
**Review Cadence:** As needed, when architectural decisions are made
|
|
|
|
**Evolution Process:**
|
|
- Intent can be refined based on experience
|
|
- Implementations can evolve independently
|
|
- No requirement to update this document for every implementation change
|
|
|
|
**Authority:** This document reflects architectural intent, not implementation contracts.
|
|
|
|
---
|
|
|
|
**Last Updated:** 2026-01-20
|
|
**Status:** Intent Document (Flexible, Non-Constraining)
|