4.5 KiB
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:
- clear the blockers
- build the foundation
- deliver the physics core
- deliver the operational workflows
- expand into both aviation and space-facing products
- harden for institutional trust
- 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 for the detailed architecture, controls, and acceptance criteria.
- Use Implementation_Plan.md for the sprint-oriented coding plan.