chore: reorganize repo around planning docs and tender materials

docs/Tenders/ESA_182213_PROPOSAL_DRAFT.md

@@ -0,0 +1,662 @@
+# ESA Tender 182213 Proposal Draft
+
+## 1. Proposal Overview
+
+**Project Title:** SpaceCom AIRSAFE
+
+**Acronym:** AIRSAFE
+
+**Call / Topic:** ESA Tender 182213 - Characterisation and assessment of risks due to subsonic space debris re-entry fragments crossing airspace
+
+**Duration:** 24 months
+
+**Coordinator:** SkyNav Europe
+
+**Consortium Partners:** Proposed prime-led consortium with SkyNav Europe as coordinator and software owner and DLR as the preferred technical and validation partner. Additional specialist support to be added only where needed for aircraft vulnerability or debris / re-entry modelling depth.
+
+---
+
+## 2. Strategic Framing
+
+### Problem Statement
+
+Europe is entering an era in which uncontrolled satellite and launch-vehicle re-entries are no longer rare exceptions but an increasingly frequent operational hazard. Existing assessment methods are still oriented toward ground casualty or broad debris-footprint questions and remain weak in one of the most operationally consequential areas: the risk posed to aircraft and managed airspace by subsonic debris fragments after the main break-up phase.
+
+The result is a dangerous decision gap. Air navigation stakeholders are forced to choose between under-reaction and overly conservative closure under conditions of limited evidence, uncertain fragment behaviour, incomplete aircraft-vulnerability logic, and poorly integrated air-traffic exposure data. The 2022 Spanish airspace closure during the Long March 5B re-entry is the clearest example of this gap: a major network-level decision taken under time pressure with limited criteria, uncertain fragment risk, and substantial economic consequence.
+
+Tender 182213 addresses exactly this gap. The activity is not simply about improving re-entry physics in isolation. It is about making fragment risk credible enough, operationally interpretable enough, and airspace-aware enough to support better aviation decisions.
+
+### Strategic Context
+
+This proposal sits at the interface between space safety and aviation operations. That is the central strategic thesis of SpaceCom.
+
+SpaceCom has been defined as a dual-domain re-entry debris hazard analysis platform that bridges the space and aviation domains. In the space domain, it provides decay prediction, uncertainty quantification, and corridor planning. In the aviation domain, it translates those predictions into operational outputs such as hazard corridors, FIR intersection analysis, decision prompts, and draft NOTAM support.
+
+The project therefore aligns with the broader European need to connect space situational awareness with practical ATM and ANSP action. It also complements earlier SESAR and higher-airspace work without merely repeating it. Prior programmes have progressed launch, re-entry, HAO, and STM integration. The remaining unsolved operational issue is the decision-quality layer for aviation stakeholders confronting uncertain re-entry debris in active airspace.
+
+### Value Proposition
+
+This proposal fills the missing operational layer between re-entry hazard modelling and airspace action.
+
+SkyNav is uniquely positioned because it is not approaching this challenge as a generic software integrator, nor as a space-only analysis house. The SpaceCom roadmap was explicitly designed around the translation problem:
+
+- from orbital and atmospheric uncertainty to plain-language operational risk
+- from fragment and corridor physics to FIR and route impact
+- from raw Monte Carlo outputs to defensible action criteria
+- from space-domain alerts to aviation decision support
+
+The value proposition is therefore:
+
+**a validated, airspace-aware subsonic debris risk-assessment capability that helps aviation stakeholders act safely with less unnecessary conservatism**
+
+The preferred consortium design reinforces this positioning:
+
+- SkyNav owns the software, integration logic, and exploitation pathway
+- SkyNav brings demonstrated ATM, regulatory, validation-planning, and stakeholder-engagement capability from prior higher-airspace and space-transport work
+- DLR contributes technical depth and validation credibility
+
+This is the right balance for an SME-led bid: enough specialist depth to strengthen the science, while keeping the resulting capability clearly owned by SkyNav.
+
+---
+
+## 3. Objectives
+
+### Primary Objective
+
+To develop and validate an operationally usable risk-assessment framework for subsonic space debris re-entry fragments crossing airspace, combining fragment behaviour, aircraft exposure, and airspace impact logic into decision-support outputs for aviation stakeholders.
+
+### Supporting Objectives
+
+- Objective 1: Characterise the post-breakup behaviour of subsonic re-entry debris fragments relevant to aircraft encounter risk, including uncertainty bounds and scenario variability.
+- Objective 2: Develop an aircraft exposure and vulnerability assessment layer that translates debris trajectories into aviation-relevant risk metrics.
+- Objective 3: Integrate traffic-density, route structure, and managed airspace context into re-entry debris risk assessment to produce actionable airspace impact outputs.
+- Objective 4: Validate the resulting framework against historical cases, replay scenarios, and stakeholder review to demonstrate more targeted and less overly conservative decision support.
+- Objective 5: Produce a pathway for institutional use, future standardisation, and productisation within the broader SpaceCom platform.
+
+### Proposed Success Metrics
+
+- Demonstrate quantified improvement in identifying affected airspace versus a conservative baseline closure model.
+- Demonstrate traceable uncertainty ranges for fragment-aircraft encounter assessment.
+- Demonstrate operationally interpretable outputs for ANSP-style users, including affected FIRs, time windows, and graded risk bands.
+- Demonstrate a validation package suitable for future institutional review and regulatory discussion.
+
+### Placeholder KPI Table
+
+This table is intentionally provisional and should be aligned to the formal tender documentation, statement of work, and evaluation criteria once the full ESA pack is available.
+
+| KPI Area | Indicative KPI | Baseline | Target | Validation Method | Notes |
+|------|------|------|------|------|------|
+| Airspace impact accuracy | Accuracy of predicted affected airspace footprint versus replay case | TBD | TBD | Historical replay / scenario replay | Define once tender datasets are known |
+| Conservatism reduction | Reduction in precautionary closure area or duration versus conservative baseline method | TBD | TBD | Comparative scenario analysis | Must remain safety-consistent |
+| Uncertainty quality | Calibration of uncertainty bands for fragment-airspace exposure | TBD | TBD | Monte Carlo back-test / sensitivity analysis | Formal metric to be selected |
+| Aircraft exposure logic | Accuracy or usefulness of aircraft exposure ranking by airspace/time slice | TBD | TBD | Expert review + scenario replay | Depends on available traffic inputs |
+| Operational usability | Share of stakeholder review cases judged decision-useful | TBD | TBD | Structured operator review | To be defined with end-user criteria |
+| Timeliness | Time from event update to updated operational output | TBD | TBD | Demonstrator timing test | Relevant if near-real-time updates are in scope |
+| Uptake pathway | Number and quality of actionable recommendations for institutional / regulatory use | TBD | TBD | Stakeholder review and final uptake brief | May be qualitative with structured scoring |
+
+---
+
+## 4. Concept of Operations (CONOPS)
+
+### Operational Concept
+
+The proposed system operates as a decision-support layer above the fragment-risk engine.
+
+When an uncontrolled re-entry event is identified, the system ingests available object, trajectory, atmospheric, and event-state data. It then generates a probabilistic assessment of post-breakup fragment behaviour, with explicit treatment of the subsonic fragment regime identified in the tender. That output is combined with aircraft exposure and managed airspace context to produce time- and location-specific aviation risk products.
+
+These products are not intended to automate airspace closure. They are intended to support authorised aviation decision-makers with a clearer answer to the operational question:
+
+**Which airspace is credibly affected, when, with what level of confidence, and how does that compare with a conservative precautionary action boundary?**
+
+### Key Features
+
+- Real-time or near-real-time ingestion of re-entry event information
+- Subsonic fragment behaviour modelling with uncertainty propagation
+- Airspace intersection logic using FIR and route-aware geospatial layers
+- Aircraft exposure modelling using traffic-density and operational context
+- Decision-support outputs for aviation stakeholders, not raw physics alone
+- Plain-language uncertainty communication for operators and incident leads
+- Traceable update chain linking every operational recommendation to model version, assumptions, and timestamped inputs
+
+### Operational Outputs
+
+- affected FIRs and time windows
+- dynamic hazard corridors and confidence bands
+- aircraft exposure estimates by airspace/time slice
+- graded advisory thresholds
+- comparison between conservative precautionary area and refined risk-informed area
+- validation replay outputs for post-event review
+
+### Operational Impact
+
+The expected operational outcome is not the elimination of uncertainty. It is better action under uncertainty.
+
+Specifically, the project aims to enable:
+
+- safer and more defensible airspace risk decisions
+- fewer unnecessarily broad restrictions where evidence supports narrower action
+- clearer coordination between space-domain analysts and aviation stakeholders
+- a stronger basis for regulatory and procedural development in Europe
+
+---
+
+## 5. Technical Approach
+
+### Architecture
+
+The proposal uses a modular architecture aligned with the SpaceCom roadmap. The technical stack is built around a physics core, an airspace-impact layer, and an operational decision-support layer.
+
+The architecture has three main layers:
+
+- Event and data ingestion
+- Fragment and exposure analytics
+- Operational visualisation and decision-support outputs
+
+This architecture is API-driven and designed so that each analytical component can be validated independently before integration into an end-to-end demonstrator.
+
+### Core Modules
+
+#### Module 1 - Event and Context Ingestion
+
+- re-entry event ingestion
+- orbit / decay state updates
+- atmospheric and space-weather context
+- airspace and FIR boundary data
+- air traffic density and route context
+
+#### Module 2 - Fragment Risk Engine
+
+- breakup and descent scenario generation
+- subsonic fragment regime treatment
+- uncertainty propagation and Monte Carlo analysis
+- hazard corridor and confidence-band generation
+
+#### Module 3 - Aircraft Exposure and Vulnerability Layer
+
+- aircraft encounter likelihood estimation
+- aircraft vulnerability logic for debris interaction scenarios
+- mapping from fragment trajectories to aviation-relevant risk indicators
+
+#### Module 4 - Airspace Impact and Decision Layer
+
+- FIR and route intersection analysis
+- time-windowed operational impact assessment
+- graded risk outputs
+- comparative conservative-baseline analysis
+- draft operational products for aviation stakeholders
+
+#### Module 5 - Validation and Replay Toolkit
+
+- historical event back-testing
+- scenario replay
+- operator-facing demonstration views
+- post-event assessment and evidence packaging
+
+### Methodological Principles
+
+The technical method will be explicit and testable from the start of the activity.
+
+The proposal will define:
+
+- baseline and advanced fragment-modelling approaches
+- assumptions and limits for atmospheric and subsonic fragment modelling
+- uncertainty treatment and convergence logic
+- aircraft exposure modelling inputs and abstractions
+- validation baselines and comparison cases
+
+This is critical because the past tender feedback shows that evaluators penalise proposals that defer the method, the validation detail, or the KPI logic to later phases.
+
+### Innovation Elements
+
+The innovation is not merely better debris analysis in isolation. It is the integration of four elements that are currently weakly connected:
+
+- subsonic fragment behaviour after breakup
+- aircraft risk logic
+- managed-airspace context
+- operational decision products for aviation actors
+
+What is new versus current practice is the shift from broad, precautionary, often opaque airspace reactions to a more evidence-based and traceable approach that still remains conservative where the uncertainty demands it.
+
+This is also where SpaceCom is differentiated. The broader platform roadmap already includes:
+
+- Monte Carlo-based uncertainty handling
+- hazard corridors
+- FIR intersection analysis
+- NOTAM-adjacent drafting support
+- operator-oriented uncertainty communication
+
+This tender allows those concepts to be developed in a focused way around one of the most urgent European operational questions.
+
+---
+
+## 6. Work Packages (WPs)
+
+### Why SkyNav + DLR
+
+This section is intentionally concise and can be expanded once the full tender documents clarify the expected consortium profile, evidence requirements, and any mandatory competency areas.
+
+SkyNav + DLR is a strong fit for tender `182213` because it combines:
+
+- SkyNav's operational ATM, regulatory, validation-planning, and software-integration capability
+- DLR's technical and scientific credibility in modelling and ATM validation
+- a compact consortium structure that keeps ownership, accountability, and exploitation clear
+
+This pairing is also strategically coherent. SkyNav leads the translation of technical outputs into decision-support software and operational artefacts. DLR strengthens the modelling and validation case. Together, the team can present a bid that is both technically credible and clearly product-led.
+
+Most importantly, this structure avoids one of the recurring weaknesses seen in broader tenders: diffuse roles and overbuilt consortia. For this activity, clarity is likely to score better than scale.
+
+### WP1 - Project Management and Quality Assurance
+
+Purpose:
+Ensure disciplined delivery, technical integration control, risk management, reporting, and quality assurance.
+
+Key tasks:
+
+- governance and reporting
+- technical quality reviews
+- risk and issue management
+- milestone and deliverable consistency control
+
+Outputs:
+
+- project management plan
+- quality assurance plan
+- periodic progress reporting
+
+### WP2 - Requirements, Operational Scenarios, and Evaluation Framework
+
+Purpose:
+Define the operational decision problem in aviation terms and establish measurable success criteria from day one.
+
+Key tasks:
+
+- stakeholder needs analysis
+- operational scenario definition
+- Long March 5B-style reference scenario definition
+- KPI framework and baseline definition
+- validation and acceptance criteria
+
+Outputs:
+
+- operational requirements specification
+- scenario catalogue
+- KPI and validation framework
+
+### WP3 - Subsonic Fragment Modelling and Uncertainty Analysis
+
+Purpose:
+Develop the technical core for assessing subsonic debris fragment behaviour after breakup.
+
+Key tasks:
+
+- fragmentation and descent modelling approach selection
+- uncertainty propagation design
+- Monte Carlo and confidence-band generation
+- sensitivity analysis
+
+Outputs:
+
+- fragment modelling specification
+- uncertainty and sensitivity report
+- technical prototype of fragment risk engine
+
+### WP4 - Aircraft Exposure, Airspace Impact, and Decision Logic
+
+Purpose:
+Translate fragment behaviour into aviation-relevant risk outputs and decision-support products.
+
+Key tasks:
+
+- aircraft exposure logic
+- aircraft vulnerability model integration
+- airspace and FIR impact mapping
+- route and traffic-density integration
+- advisory threshold definition
+
+Outputs:
+
+- aircraft exposure module
+- airspace impact module
+- decision-support logic and output specification
+
+### WP5 - Integrated Demonstrator and Validation
+
+Purpose:
+Demonstrate the end-to-end capability and prove its operational usefulness.
+
+Key tasks:
+
+- system integration
+- historical case replay
+- scenario-based testing
+- comparison with conservative baseline decisions
+- stakeholder review sessions
+
+Outputs:
+
+- integrated demonstrator
+- validation report
+- operational lessons learned report
+
+### WP6 - Dissemination, Exploitation, and Uptake Pathway
+
+Purpose:
+Ensure the project has a credible route beyond the study itself.
+
+Key tasks:
+
+- dissemination to technical and institutional audiences
+- engagement with aviation and space safety stakeholders
+- uptake pathway definition
+- productisation pathway into SpaceCom
+
+Outputs:
+
+- dissemination and exploitation plan
+- institutional uptake brief
+- SpaceCom integration roadmap for follow-on deployment
+
+### Placeholder Deliverables Table
+
+This table is provisional and should be updated once the ESA tender pack confirms the formal work structure, milestone logic, and expected deliverable types.
+
+| ID | Deliverable Title | Indicative WP | Type | Timing | Lead | Status |
+|------|------|------|------|------|------|------|
+| D1.1 | Project Management and Quality Plan | WP1 | Report | TBD | SkyNav | Placeholder |
+| D2.1 | Requirements, Scenarios, and Evaluation Framework | WP2 | Report | TBD | SkyNav | Placeholder |
+| D2.2 | KPI Baseline and Validation Methodology | WP2 | Report | TBD | SkyNav | Placeholder |
+| D3.1 | Subsonic Fragment Modelling Specification | WP3 | Technical Report | TBD | DLR | Placeholder |
+| D3.2 | Uncertainty and Sensitivity Analysis Report | WP3 | Technical Report | TBD | DLR | Placeholder |
+| D4.1 | Aircraft Exposure and Vulnerability Method | WP4 | Technical Report | TBD | SkyNav / DLR | Placeholder |
+| D4.2 | Airspace Impact and Decision Logic Specification | WP4 | Technical Report | TBD | SkyNav | Placeholder |
+| D5.1 | Integrated Demonstrator | WP5 | Demonstrator | TBD | SkyNav | Placeholder |
+| D5.2 | Validation and Replay Report | WP5 | Report | TBD | DLR / SkyNav | Placeholder |
+| D6.1 | Dissemination and Exploitation Plan | WP6 | Report | TBD | SkyNav | Placeholder |
+| D6.2 | Institutional Uptake and Follow-On Roadmap | WP6 | Report | TBD | SkyNav | Placeholder |
+
+---
+
+## 7. Consortium Structure
+
+### Partner Roles
+
+- **Coordinator - SkyNav Europe:** Overall project leadership, system architecture, software ownership, operational translation layer, demonstrator integration, exploitation pathway, aviation-facing decision-support design, and post-project productisation into SpaceCom. SkyNav also leads the operational scenario framing, requirements traceability, validation planning, stakeholder coordination, and regulatory translation needed to turn technical analysis into usable aviation outputs.
+- **DLR - Preferred technical partner:** Fragment-modelling support, ATM simulation and validation methodology, scientific credibility, and evidence-based assessment of operational usefulness.
+- **Optional specialist partner(s):** Only where needed for aircraft vulnerability modelling or highly specific debris / re-entry modelling tasks not already covered by SkyNav and DLR.
+
+### Why SkyNav Should Lead
+
+SkyNav should not position itself as a peripheral software subcontractor in this bid. It should lead the bid because the strongest differentiator is not a single algorithm; it is the operational integration of fragmented technical domains into an airspace decision-support product.
+
+That integration problem is exactly what SpaceCom was designed to solve.
+
+The prior proposal material and SkyNav's public positioning show a consistent company profile:
+
+- decades of operational ATM experience
+- regulatory drafting and international aviation-policy capability
+- project leadership and cross-border stakeholder coordination
+- work on ECHO / ECHO2 and higher-airspace integration
+- strength in operational scenarios, validation planning, OSED-style concept work, and standards / regulatory translation
+
+That means SkyNav is not just commercially motivated to lead. It is substantively well placed to lead.
+
+### Consortium Design Principle
+
+The consortium should be compact, high-credibility, and easy to explain. The past ESR lessons show that diffuse task ownership and unclear partner roles are penalised. Every partner must have a visible task-level reason to exist.
+
+The recommended narrative is:
+
+- SkyNav leads and owns the resulting capability
+- DLR strengthens the scientific and validation case
+- the consortium stays small enough to remain product-led, measurable, and easy to evaluate
+
+That is a stronger structure than building a broad consortium too early or allowing the bid to drift away from SkyNav's ownership and exploitation path.
+
+---
+
+## 8. Impact
+
+### Scientific and Technical Impact
+
+The project will advance understanding in one of the least mature parts of uncontrolled re-entry risk assessment: the subsonic fragment regime as it relates to aircraft and managed airspace.
+
+It will also contribute an integrated framework joining:
+
+- fragment behaviour
+- uncertainty analysis
+- aircraft exposure and vulnerability
+- airspace operational interpretation
+
+### Operational Impact
+
+The direct operational benefit is improved decision quality for aviation stakeholders during re-entry events.
+
+Expected benefits include:
+
+- clearer identification of airspace genuinely at risk
+- stronger justification for precautionary measures
+- fewer unnecessarily broad closures where a narrower action is defensible
+- better coordination between technical and operational actors
+
+### Economic Impact
+
+The project targets a real economic pain point: high-cost operational disruption caused by blunt or poorly evidenced precautionary airspace decisions.
+
+Even modest improvements in targeted restriction logic can produce:
+
+- reduced network disruption
+- reduced airline and ANSP cost exposure
+- lower indirect cost from unnecessary precautionary action
+
+### Regulatory and Institutional Impact
+
+The project will provide a stronger evidence base for future European guidance and institutional decision criteria regarding re-entry debris in airspace.
+
+It is particularly well placed to support:
+
+- future aviation safety doctrine around re-entry events
+- better harmonisation of decision criteria across states
+- stronger institutional confidence in risk-informed rather than purely ad hoc closure responses
+
+---
+
+## 9. Exploitation Strategy
+
+### Commercialisation Path
+
+The outputs of this project are designed to flow directly into SpaceCom.
+
+This is important strategically: the project is not a one-off study disconnected from a product path. It strengthens a defined platform roadmap already oriented toward ANSP-facing re-entry decision support.
+
+The main exploitation route is:
+
+- integrate the validated outputs into the SpaceCom aviation-domain product layer
+- package them for ANSP shadow-mode and institutional demonstration use
+- expand toward operational deployments and support services
+
+### Revenue and Follow-On Path
+
+Potential follow-on routes include:
+
+- ANSP-facing software subscriptions or institutional deployments
+- funded pilot or shadow trials
+- follow-on institutional studies and validation activities
+- consulting and integration support around re-entry event readiness and operational procedures
+
+### Market Entry
+
+The first target users are:
+
+- ANSPs
+- aviation authorities
+- network-level operational safety stakeholders
+- space safety and civil protection actors needing aviation-facing interpretation of re-entry risk
+
+This sequence is stronger than trying to market a generic debris-analysis engine. The commercial edge lies in the decision-support layer.
+
+The market-entry logic is strongest when framed around SkyNav's existing positioning: operationally grounded aviation expertise, regulatory fluency, and the ability to convert a technically complex problem into a deployable, decision-support product rather than a stand-alone research model.
+
+---
+
+## 10. Risk Management
+
+| Risk | Probability | Impact | Mitigation |
+|------|------------|--------|-----------|
+| Subsonic fragment behaviour is more uncertain than expected | Medium | High | Use a baseline-plus-advanced modelling strategy, expose uncertainty explicitly, and validate against replay scenarios rather than overclaiming precision |
+| Aircraft vulnerability modelling requires assumptions that are hard to validate directly | Medium | High | Bound assumptions clearly, involve specialist partner input, and publish decision limits and sensitivity analysis |
+| Operational users reject outputs as too technical or not decision-ready | Medium | High | Define operator-facing products in WP2, include ANSP review in validation, and test outputs against real operational questions |
+| Impact claims are criticised as qualitative | Medium | High | Put KPI logic and conservative-baseline comparison into the proposal early and carry them through all WPs |
+| Consortium roles become diffuse | Low | High | Assign task-level ownership in each WP and keep the consortium compact |
+| Data availability for historical validation is limited | Medium | Medium | Use mixed validation strategy: historical replay where possible, synthetic scenario set where needed, and explicit evidence grading |
+| Regulatory pathway is slower than expected | Medium | Medium | Treat project outputs as evidence-building and decision-support input, not immediate regulatory replacement |
+
+### Software Delivery Risks
+
+This subsection is intentionally candid and should be refined once the final delivery model, staffing plan, and partner commitments are confirmed.
+
+| Risk | Probability | Impact | Mitigation |
+|------|------------|--------|-----------|
+| Prime has limited practical in-house software delivery track record relative to its strength in operations, regulation, and project leadership | Medium | High | Keep scope tightly controlled, structure delivery around clearly bounded modules, bring in technical partner support where needed, and use formal acceptance criteria for each software increment |
+| Project leadership is strong in programme management but not yet backed by extensive hands-on software product delivery experience | Medium | High | Use a delivery model with explicit technical ownership, sprint-level review gates, external code review, and milestone-based demo acceptance rather than relying on informal oversight |
+| Requirements may drift from implementable software scope because the domain problem is richer than the initial delivery capacity | Medium | High | Prioritise a minimal demonstrator around the tender's core problem, freeze scope early, and defer non-essential platform features to post-project SpaceCom phases |
+| Over-reliance on contractors or external contributors for core software build could weaken continuity after project close | Medium | Medium | Retain software architecture, requirements traceability, and integration ownership inside SkyNav; ensure all external work is documented, reviewed, and absorbed into the product roadmap |
+| The team may overestimate internal capacity to turn domain expertise into production-grade software artefacts | Medium | High | Make software engineering maturity an explicit management topic, schedule integration and test effort early, and require working prototypes and acceptance tests at each major stage |
+| Validation artefacts may be stronger than the demonstrator itself if software build effort slips | Medium | Medium | Tie validation planning to actual implemented increments, require demonstrable end-to-end workflows before major review points, and avoid producing paper outputs disconnected from working capability |
+
+The proposal should not attempt to hide this risk. A stronger position is to show that SkyNav understands where its core strengths lie, where support is needed, and how software delivery will be governed so that the project remains credible and controlled.
+
+---
+
+## 11. Implementation Timeline
+
+### Phase 1 - Setup and Requirements (Months 1-4)
+
+- consortium mobilisation
+- project governance setup
+- requirements and stakeholder framing
+- scenario and KPI framework finalisation
+
+### Phase 2 - Core Model Development (Months 5-11)
+
+- fragment-regime modelling
+- uncertainty analysis framework
+- aircraft exposure and vulnerability logic
+- baseline model comparison
+
+### Phase 3 - Integration and Validation (Months 12-19)
+
+- integration of core modules
+- historical case replay
+- scenario-driven validation
+- stakeholder review cycles
+
+### Phase 4 - Exploitation and Final Packaging (Months 20-24)
+
+- final demonstrator refinement
+- evidence package and final reporting
+- uptake and exploitation package
+- SpaceCom integration roadmap
+
+---
+
+## 12. Key Success Factors
+
+- A narrowly focused, technically explicit scope rather than a sprawling concept bid
+- Early KPI definition and clear validation logic
+- Strong translation from physics to operational aviation use
+- A compact consortium with visible task-level roles
+- Credible institutional and commercial follow-on pathway
+- Proposal language that shows measurable impact, not just strategic relevance
+
+---
+
+## 13. Common Pitfalls to Avoid
+
+- presenting the project as a generic SSA or re-entry study without the aviation decision-support layer
+- broad objectives without measurable outputs
+- impact language without KPIs or baselines
+- unclear distinction between scientific modelling and operator-facing outputs
+- vague validation plan deferred to a later work package
+- diffuse consortium roles
+- overclaiming regulatory transformation instead of evidence-building
+
+---
+
+## 14. Draft Bid Narrative
+
+### Executive Positioning
+
+AIRSAFE will address one of the most operationally urgent and technically underdeveloped problems in European space safety and aviation: how to assess, interpret, and act on the risk posed by subsonic space debris re-entry fragments crossing managed airspace.
+
+The project responds directly to the growing frequency of uncontrolled re-entries, the demonstrated operational disruption they can cause, and the recognised inadequacy of current assessment methods when aviation decision-makers need to determine whether, where, and for how long airspace restrictions are justified.
+
+AIRSAFE is built on a simple but powerful proposition: Europe does not only need better re-entry modelling; it needs better translation of re-entry risk into aviation action.
+
+### What the Project Will Deliver
+
+The project will deliver a validated framework that combines:
+
+- subsonic fragment behaviour modelling
+- uncertainty-aware hazard generation
+- aircraft exposure and vulnerability assessment
+- managed-airspace and traffic-context integration
+- operational decision-support outputs
+
+This will allow the project to move beyond broad hazard characterisation and toward practical airspace-relevant outputs such as:
+
+- likely affected FIRs
+- time-windowed risk zones
+- confidence-bounded airspace footprints
+- comparison between conservative closure assumptions and refined risk-informed assessments
+
+### Why SkyNav Is Credible
+
+SkyNav's credibility comes from the fact that this is not a speculative pivot. The SpaceCom roadmap already defines the operational architecture needed to turn uncertain re-entry physics into aviation-facing action support. That includes hazard corridors, FIR intersection logic, uncertainty communication, and operator-oriented output design.
+
+In other words, AIRSAFE is not trying to invent a product direction from scratch. It is using a focused ESA activity to mature the most strategically valuable and operationally urgent component of an existing platform vision.
+
+SkyNav's existing company profile also supports this bid directly. Across previous proposals and its public-facing positioning, the company consistently presents strength in:
+
+- operational ATM practice
+- regulatory drafting and implementation support
+- validation planning and requirements traceability
+- higher-airspace and space-transport integration work
+- stakeholder engagement across ANSP, regulatory, and international coordination contexts
+
+With DLR alongside SkyNav, the bid can show a credible combination of:
+
+- product ownership and SME agility
+- scientific and modelling depth
+- operational and regulatory relevance
+
+That combination is exactly what a winning prime-led SME bid should look like.
+
+### Why This Matters to Europe
+
+Europe’s current exposure is not only technical. It is operational, regulatory, and economic.
+
+As re-entry events increase, European airspace managers will face more decisions in which the cost of over-reaction is high, but the cost of under-reaction is unacceptable. Current tools do not provide enough confidence in the subsonic fragment and aircraft-risk layer of the problem. AIRSAFE will address that exact deficiency.
+
+The outcome will not be a promise of perfect certainty. It will be a framework for safer, better-justified, and less unnecessarily disruptive decision-making under uncertainty.
+
+---
+
+## 15. Final Checklist
+
+- [ ] Objectives are measurable and tied to validation
+- [ ] KPI table is included early in the proposal
+- [ ] Methodology names the actual modelling approaches and data assumptions
+- [ ] Validation is defined in the bid, not deferred
+- [ ] Operational users and decisions are explicit
+- [ ] Consortium roles are concrete and defensible
+- [ ] Impact includes reduction in unnecessary conservatism as well as safety benefit
+- [ ] Exploitation is tied directly to SpaceCom productisation
+- [ ] Proposal language remains sharp, evidence-led, and operationally grounded
+
+---
+
+## Reflective Prompt
+
+Does this proposal read as a disciplined programme to improve aviation decision quality during uncontrolled re-entry events, or does it drift back into a broad and under-measured space safety concept?
+
+If the answer is the latter at any point, the draft should be tightened before submission.