docs: align roadmap with tender-fit requirements
Plan aircraft-risk modelling, CCSDS RDM support, tender-grade replay validation, and ESA software assurance artefacts in the implementation and master plans.
This commit is contained in:
Allissa Auld
303
docs/Implementation_Plan.md
Normal file
303
docs/Implementation_Plan.md
Normal file
@@ -0,0 +1,303 @@
|
||||
# SpaceCom Implementation Plan
|
||||
|
||||
## Purpose
|
||||
|
||||
This document turns the master plan into an implementation-oriented coding plan. It is focused on phases of engineering work and sprint-style delivery, not on full architectural detail.
|
||||
|
||||
## Delivery Model
|
||||
|
||||
The implementation plan assumes:
|
||||
|
||||
- self-hosted GitLab as the delivery platform
|
||||
- Docker Compose as the baseline deployment model
|
||||
- contracts as the authoritative entitlement source
|
||||
- Phase 0 blockers cleared before major coding commitments
|
||||
- safety-critical, auth, and regulatory-sensitive changes always require human review
|
||||
|
||||
## Phase 0: Pre-Build Decisions
|
||||
|
||||
Objective:
|
||||
- clear the decisions that would otherwise force rework
|
||||
|
||||
Sprint 0 outcomes:
|
||||
|
||||
- Space-Track AUP architecture decision recorded
|
||||
- Cesium commercial licence executed
|
||||
- GitLab CI/CD authority confirmed
|
||||
- contract-driven entitlement model confirmed
|
||||
- Redis trust split approved
|
||||
- initial ADR set aligned with these decisions
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- no unresolved blocker remains that would change ingest, licensing, or deployment direction
|
||||
|
||||
## Phase 1: Foundation Sprints
|
||||
|
||||
Objective:
|
||||
- establish the platform baseline and developer workflow
|
||||
|
||||
### Sprint 1.1
|
||||
|
||||
- backend project structure and FastAPI scaffolding
|
||||
- frontend project structure and Next.js scaffolding
|
||||
- Docker Compose topology
|
||||
- TimescaleDB/PostGIS baseline schema
|
||||
- GitLab CI skeleton
|
||||
- docs tree, ADR format, `AGENTS.md`, changelog baseline
|
||||
|
||||
### Sprint 1.2
|
||||
|
||||
- auth baseline: JWT, cookies, MFA foundation
|
||||
- RBAC and role checks
|
||||
- liveness and readiness endpoints
|
||||
- structured logging
|
||||
- security scan hooks and pre-commit
|
||||
- first-login acceptance gates for ToS/AUP/Privacy Notice
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- full stack starts cleanly
|
||||
- CI runs on every merge request
|
||||
- auth and role boundaries exist
|
||||
- baseline docs and controls are in place
|
||||
|
||||
## Phase 2: Data and Ingest Sprints
|
||||
|
||||
Objective:
|
||||
- make the platform ingest and manage real operational data safely
|
||||
|
||||
### Sprint 2.1
|
||||
|
||||
- object catalog CRUD
|
||||
- TLE ingest
|
||||
- ingest worker wiring
|
||||
- source validation and checksum checks
|
||||
- basic data freshness indicators
|
||||
|
||||
### Sprint 2.2
|
||||
|
||||
- DISCOS import
|
||||
- space weather ingest
|
||||
- retention policy scaffolding
|
||||
- ingest metrics and failure alerts
|
||||
- first degraded-mode backend signals
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- core upstream data can be ingested, validated, stored, and monitored
|
||||
|
||||
## Phase 3: Propagation and Physics Core
|
||||
|
||||
Objective:
|
||||
- deliver the first real analysis engine
|
||||
|
||||
### Sprint 3.1
|
||||
|
||||
- frame/time utilities
|
||||
- SGP4 propagation
|
||||
- frame transformation validation
|
||||
- initial CZML generation
|
||||
|
||||
### Sprint 3.2
|
||||
|
||||
- numerical decay predictor
|
||||
- atmospheric inputs
|
||||
- upper/lower atmosphere model interfaces for terminal descent
|
||||
- model versioning hooks
|
||||
- prediction input validation
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- the platform can produce technically valid propagated and decay outputs with traceable inputs
|
||||
|
||||
## Phase 4: Simulation and Hazard Engine
|
||||
|
||||
Objective:
|
||||
- build the uncertainty and event-analysis layer
|
||||
|
||||
### Sprint 4.1
|
||||
|
||||
- Monte Carlo job orchestration
|
||||
- Celery chord flow
|
||||
- worker resource controls
|
||||
- result aggregation guards
|
||||
|
||||
### Sprint 4.2
|
||||
|
||||
- breakup logic and sub/trans-sonic fragment model baseline
|
||||
- fragment shape, tumble, and descent-assumption reference data
|
||||
- corridor generation
|
||||
- object/event linking
|
||||
- first event orchestration path
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- multi-run hazard outputs are generated safely, bounded, and auditable
|
||||
|
||||
## Phase 5: Operational Frontend
|
||||
|
||||
Objective:
|
||||
- make the product usable for analysts and operators
|
||||
|
||||
### Sprint 5.1
|
||||
|
||||
- globe and layer controls
|
||||
- timeline strip
|
||||
- object/event navigation
|
||||
- degraded-state presentation
|
||||
|
||||
### Sprint 5.2
|
||||
|
||||
- alert centre
|
||||
- acknowledgement flow
|
||||
- decision prompts
|
||||
- keyboard-first interaction paths
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- operators can see, interpret, and act on platform outputs in the UI
|
||||
|
||||
## Phase 6: Event Workflow and Reporting
|
||||
|
||||
Objective:
|
||||
- support full event handling, not just display
|
||||
|
||||
### Sprint 6.1
|
||||
|
||||
- event detail page
|
||||
- event state transitions
|
||||
- report job submission and tracking
|
||||
- WebSocket event flow
|
||||
|
||||
### Sprint 6.2
|
||||
|
||||
- report rendering pipeline
|
||||
- export storage flow
|
||||
- report audit trail
|
||||
- offline/reconnect handling
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- an end-to-end event can be analysed, reviewed, and reported through the platform
|
||||
|
||||
## Phase 7: Reliability, Safety, and Compliance Hardening
|
||||
|
||||
Objective:
|
||||
- turn a capable system into an operationally defensible one
|
||||
|
||||
### Sprint 7.1
|
||||
|
||||
- observability dashboards
|
||||
- SLO instrumentation
|
||||
- alerting rules
|
||||
- incident-response runbook alignment
|
||||
|
||||
### Sprint 7.2
|
||||
|
||||
- privacy workflows
|
||||
- retention and pseudonymisation tasks
|
||||
- safety-case artefacts linkage
|
||||
- audit-log separation and integrity controls
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- the system is observable, auditable, and aligned with documented operational obligations
|
||||
|
||||
## Phase 8: Aviation Product Expansion
|
||||
|
||||
Objective:
|
||||
- strengthen the ANSP-facing differentiation
|
||||
|
||||
### Sprint 8.1
|
||||
|
||||
- FIR intersection and aviation-context outputs
|
||||
- aircraft exposure and vulnerability scoring
|
||||
- uncertainty display refinements
|
||||
- operator-facing airspace impact summaries
|
||||
- conservative-baseline comparison outputs
|
||||
|
||||
### Sprint 8.2
|
||||
|
||||
- shadow mode behaviour
|
||||
- multi-ANSP coordination foundations
|
||||
- NOTAM-adjacent workflow support
|
||||
- live air-traffic density and route inputs for air-risk products
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- the aviation-side product layer is credible for shadow deployment and stakeholder review
|
||||
|
||||
## Phase 9: Space Operator Expansion
|
||||
|
||||
Objective:
|
||||
- extend the shared core into upstream customer workflows
|
||||
|
||||
### Sprint 9.1
|
||||
|
||||
- owned-object data model and access rules
|
||||
- API key lifecycle
|
||||
- portal foundations
|
||||
|
||||
### Sprint 9.2
|
||||
|
||||
- controlled re-entry planner
|
||||
- CCSDS OEM/CDM/RDM export
|
||||
- partner-facing integration workflows
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- the shared physics core now supports both downstream aviation and upstream space-operator use
|
||||
|
||||
## Phase 10: Deployment Readiness and Evidence
|
||||
|
||||
Objective:
|
||||
- prepare for shadow deployment and external scrutiny
|
||||
|
||||
### Sprint 10.1
|
||||
|
||||
- validation and backcasting workflow
|
||||
- named historical replay corpus and conservative-baseline comparisons
|
||||
- tender-grade KPI and air-risk validation pack
|
||||
- shadow reporting outputs
|
||||
- deployment gating refinements
|
||||
|
||||
### Sprint 10.2
|
||||
|
||||
- final compliance artefacts
|
||||
- ESA software assurance artefacts: SRS, SDD, user manual, test report
|
||||
- release checklist completion
|
||||
- operational readiness review
|
||||
- first shadow deployment package
|
||||
|
||||
Exit criteria:
|
||||
|
||||
- the platform is ready for controlled external deployment and evidence-based review
|
||||
|
||||
## Cross-Cutting Workstreams
|
||||
|
||||
The following run continuously across phases rather than in only one sprint:
|
||||
|
||||
- security architecture and dependency hygiene
|
||||
- documentation and ADR maintenance
|
||||
- test coverage and validation artefacts
|
||||
- safety-case traceability
|
||||
- legal/commercial gating
|
||||
- performance and capacity reviews
|
||||
- procurement traceability and bid artefact maintenance
|
||||
|
||||
## Recommended Execution Pattern
|
||||
|
||||
For actual delivery, each sprint should end with:
|
||||
|
||||
- a demoable increment
|
||||
- updated docs
|
||||
- updated ADRs where needed
|
||||
- passing CI
|
||||
- explicit review of safety/compliance impacts
|
||||
|
||||
## Relationship to Other Docs
|
||||
|
||||
- [Overview.md](/d:/Projects/SpaceCom/docs/Overview.md) gives the shortest summary
|
||||
- [Roadmap.md](/d:/Projects/SpaceCom/docs/Roadmap.md) gives the big-picture staged view
|
||||
- [MASTER_PLAN.md](/d:/Projects/SpaceCom/docs/MASTER_PLAN.md) remains the authoritative detailed plan
|
||||
Reference in New Issue
Block a user