145 lines
4.5 KiB
Markdown
145 lines
4.5 KiB
Markdown
|
# 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.
|