chore: reorganize repo around planning docs and tender materials

docs/Overview.md

@@ -0,0 +1,88 @@
+# 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.