# SpaceCom Overview

## Purpose

SpaceCom is a dual-domain re-entry debris hazard analysis platform that connects space-domain prediction with aviation-domain action.

It is designed to solve a specific operational gap: space analysts can generate technically credible predictions, but ANSPs and aviation decision-makers still need those predictions translated into practical, time-bound, airspace-aware decisions.

## Product Vision

SpaceCom operates as two connected products sharing a common physics and data core.

- **Space domain product:** decay prediction, uncertainty quantification, conjunction screening, controlled re-entry planning, and API-based integration with space operations workflows.
- **Aviation domain product:** hazard corridors, FIR intersection analysis, operator-friendly uncertainty communication, NOTAM-adjacent support, and multi-ANSP coordination.

The strategic positioning is that SpaceCom is the interface layer between two domains that currently do not communicate in the same operational language.

## Core Value Proposition

SpaceCom is intended to provide:

- technically credible orbital and re-entry analysis
- operationally usable aviation decision support
- traceability from model input to output to operator-facing recommendation
- a platform that can support both productisation and procurement-led institutional use

## High-Level Architecture

The platform is built as a layered web system with:

- a Next.js and CesiumJS frontend
- a FastAPI backend and WebSocket API
- isolated Celery workers for simulation and ingest
- a network-isolated renderer for reports
- TimescaleDB/PostGIS for persistence
- split Redis trust domains for app state and worker traffic
- MinIO for private object storage
- observability, audit logging, and safety/compliance controls throughout

The current deployment model is Docker Compose on a deliberately managed VPS-style stack, with architecture choices kept compatible with later scale-up.

## Major Capability Areas

- object catalog and propagation
- decay prediction with Monte Carlo uncertainty
- breakup and corridor generation
- conjunction and alert handling
- event timeline and operator workflow support
- reporting and export
- organisation, contract, and entitlement management
- validation, monitoring, and safety-case traceability

## Users

The plan is built around multiple personas, but the most important groups are:

- space operators and analysts
- ANSP operational users
- airspace and incident decision-makers
- internal SpaceCom operations, engineering, and compliance staff

## Delivery Principles

The master plan emphasizes:

- safety-critical changes require human review
- contracts are the authoritative source of commercial entitlements
- self-hosted GitLab is the authoritative CI/CD platform
- commercial enforcement must not interrupt active operational incidents
- Phase 0 legal and architectural blockers must be cleared before commitment-heavy implementation

## Governance Summary

Cross-hat governance is now explicit in the master plan.

- Product and commercial decisions are owned through the contract model.
- Safety-critical UX and alerting decisions are governed by the safety case owner with HF and regulatory review.
- Platform and architecture decisions are owned through the architecture/platform function.
- Legal, privacy, and licensing obligations override implementation convenience.

## What This Document Is

This file is the shortest summary of the programme.

- Read this first for the big picture.
- Read [Roadmap.md](/d:/Projects/SpaceCom/docs/Roadmap.md) for the staged product journey.
- Read [Implementation_Plan.md](/d:/Projects/SpaceCom/docs/Implementation_Plan.md) for the coding and sprint plan.
- Use [MASTER_PLAN.md](/d:/Projects/SpaceCom/docs/MASTER_PLAN.md) as the authoritative detailed specification.