chore: reorganize repo around planning docs and tender materials
This commit is contained in:
Allissa Auld
144
docs/Roadmap.md
Normal file
144
docs/Roadmap.md
Normal file
@@ -0,0 +1,144 @@
|
||||
# SpaceCom Roadmap
|
||||
|
||||
## Roadmap Intent
|
||||
|
||||
This roadmap is the big-picture delivery view of SpaceCom. It compresses the master plan into the main stages of platform maturity, from architectural gating through operational deployment readiness.
|
||||
|
||||
## Phase 0: Commitment Gates
|
||||
|
||||
Before major implementation proceeds, the project clears the blockers that would otherwise force rework later.
|
||||
|
||||
- confirm the Space-Track AUP architecture path
|
||||
- execute the Cesium commercial licence
|
||||
- lock in self-hosted GitLab as the CI/CD authority
|
||||
- confirm the contract-led entitlement model
|
||||
- approve the Redis trust split between application state and worker traffic
|
||||
|
||||
Outcome:
|
||||
- the team can build without uncertainty on ingest architecture, frontend licensing, commercial authority, or deployment governance
|
||||
|
||||
## Phase 1: Platform Foundation
|
||||
|
||||
Goal:
|
||||
- establish a safe, testable, developer-ready baseline for the product
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- containerised stack running locally and in controlled environments
|
||||
- backend and frontend scaffolding in place
|
||||
- authentication, RBAC, logging, and network segmentation active
|
||||
- core docs, ADRs, CI/CD, and pre-commit hooks established
|
||||
- legal/compliance acceptance gates wired into onboarding and delivery
|
||||
|
||||
This phase is about building the foundation correctly, not shipping every feature.
|
||||
|
||||
## Phase 2: Physics and Operational Core
|
||||
|
||||
Goal:
|
||||
- turn the prototype into a real hazard-analysis platform
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- object catalog and ingest pipelines
|
||||
- SGP4 propagation and frame conversion
|
||||
- numerical decay prediction
|
||||
- Monte Carlo uncertainty handling
|
||||
- corridor generation and event orchestration
|
||||
- first usable operational globe, alerting, and degraded-mode handling
|
||||
|
||||
This is where SpaceCom starts to become technically distinctive.
|
||||
|
||||
## Phase 3: User Workflow Maturity
|
||||
|
||||
Goal:
|
||||
- make the platform genuinely usable for operations, not just technically correct
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- event detail workflows
|
||||
- operator alert acknowledgement and decision support
|
||||
- reporting flow
|
||||
- stronger human-factors treatment
|
||||
- accessibility and validation improvements
|
||||
- deeper auditability and readiness controls
|
||||
|
||||
This phase converts a capable engine into a credible product.
|
||||
|
||||
## Phase 4: Aviation Decision Support Expansion
|
||||
|
||||
Goal:
|
||||
- strengthen the aviation-side operational layer
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- FIR-aware outputs
|
||||
- uncertainty communication suitable for non-specialist operators
|
||||
- NOTAM-adjacent support
|
||||
- shadow mode workflows
|
||||
- multi-ANSP coordination features
|
||||
- stronger safety-case and regulatory documentation
|
||||
|
||||
This is the phase where SpaceCom most clearly occupies the bridge between space and aviation.
|
||||
|
||||
## Phase 5: Space Operator Expansion
|
||||
|
||||
Goal:
|
||||
- extend the shared physics core into upstream space-operator workflows
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- space operator portal
|
||||
- owned-object workflows
|
||||
- controlled re-entry planning
|
||||
- API key lifecycle and external integration support
|
||||
- CCSDS export and partner-facing interfaces
|
||||
|
||||
This broadens the platform without abandoning the aviation differentiator.
|
||||
|
||||
## Phase 6: Operational Hardening and Evidence
|
||||
|
||||
Goal:
|
||||
- prepare the platform for shadow deployment, procurement credibility, and long-term operation
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- full observability and reliability maturity
|
||||
- stronger incident response and recovery posture
|
||||
- post-deployment safety monitoring
|
||||
- validation and backcasting evidence
|
||||
- licensing, privacy, and procurement artefacts
|
||||
- commercial packaging and contract enforcement
|
||||
|
||||
This is where the platform becomes institutionally defensible, not just technically interesting.
|
||||
|
||||
## Phase 7: Scale and Deployment Readiness
|
||||
|
||||
Goal:
|
||||
- support real customer use with disciplined scale-up, not speculative over-engineering
|
||||
|
||||
Major outcomes:
|
||||
|
||||
- capacity thresholds and scaling review process
|
||||
- tiered deployment model
|
||||
- shadow ANSP deployment readiness
|
||||
- long-term operational governance
|
||||
- roadmap path to higher-availability deployments when justified by usage
|
||||
|
||||
## Summary View
|
||||
|
||||
The roadmap is intentionally cumulative:
|
||||
|
||||
1. clear the blockers
|
||||
2. build the foundation
|
||||
3. deliver the physics core
|
||||
4. deliver the operational workflows
|
||||
5. expand into both aviation and space-facing products
|
||||
6. harden for institutional trust
|
||||
7. scale only when operational evidence justifies it
|
||||
|
||||
## Relationship to the Master Plan
|
||||
|
||||
This document is a compression of the master plan, not a replacement for it.
|
||||
|
||||
- Use [MASTER_PLAN.md](/d:/Projects/SpaceCom/docs/MASTER_PLAN.md) for the detailed architecture, controls, and acceptance criteria.
|
||||
- Use [Implementation_Plan.md](/d:/Projects/SpaceCom/docs/Implementation_Plan.md) for the sprint-oriented coding plan.
|
||||
Reference in New Issue
Block a user