chore: reorganize repo around planning docs and tender materials

2026-04-17 20:32:35 +02:00
parent 266ee30d4b
commit 3929688f58
73 changed files with 34791 additions and 385 deletions
--- a/docs/Tenders/BID_RULES_182213.md
+++ b/docs/Tenders/BID_RULES_182213.md
@@ -0,0 +1,386 @@
+# Bid Rules for ESA Tender 182213
+
+## Purpose
+
+This note converts the lessons from prior SESAR tender feedback into a practical checklist for bidding ESA tender `182213`, whose objective is to characterise and assess risks from subsonic space debris re-entry fragments crossing airspace.
+
+The core rule is simple:
+
+**Do not submit a broad "interesting concept" proposal. Submit a measurable, validation-led, operationally grounded proposal with explicit impact logic, clear task ownership, and a direct line from physics to airspace decision support.**
+
+---
+
+## Why 182213 Fits SpaceCom
+
+Tender `182213` is unusually well aligned with the strongest part of the SpaceCom plan:
+
+- uncontrolled re-entry risk
+- airspace hazard from debris
+- aircraft vulnerability
+- operational disruption and conservative closures
+- the need to improve decision-making under uncertainty
+
+This matches the core SpaceCom positioning in `docs/MASTER_PLAN.md`:
+
+- space-domain prediction plus aviation-domain decision support
+- FIR intersection analysis
+- hazard corridors
+- NOTAM drafting support
+- multi-ANSP coordination
+
+The proposal should therefore be framed as:
+
+**an operational risk-assessment and decision-support capability for uncontrolled re-entry debris in airspace, not merely an orbital analysis tool**
+
+---
+
+## Lessons from Past ESRs
+
+## 1. Objectives must be measurable
+
+Past proposals were repeatedly marked down for objectives that were broad, brief, or hard to verify.
+
+Do:
+
+- define 3 to 5 concrete objectives
+- attach each objective to an observable output
+- state how success will be measured at project end
+
+Do not:
+
+- use vague wording like "improve awareness", "support resilience", or "enable better decisions" without measurement logic
+
+For 182213, every objective should have:
+
+- a technical metric
+- an operational metric
+- a validation method
+
+Example pattern:
+
+- improve prediction of subsonic fragment airspace exposure
+- quantify uncertainty bounds for aircraft encounter risk
+- reduce unnecessary airspace restriction area and/or duration versus conservative baseline methods
+
+---
+
+## 2. KPIs and performance logic must appear early
+
+The strongest prior bid, SCAN, was praised for quantitative KPI-based validation. The weaker bids were criticised for qualitative impact claims without traceable performance logic.
+
+For 182213, include a KPI table in the first substantive section, not as an afterthought.
+
+Minimum KPI families:
+
+- hazard prediction accuracy
+- uncertainty calibration
+- aircraft exposure estimation accuracy
+- operational usefulness for ANSP decision-making
+- reduction in unnecessary conservatism
+- timeliness of updates during active events
+
+Suggested KPI examples:
+
+- error in predicted affected airspace footprint versus reconstructed event outcome
+- calibration of risk bands against back-tested scenarios
+- false positive and false negative rates for affected airspace warnings
+- percentage reduction in precautionary closure area relative to current conservative practice
+- time from updated re-entry assessment to updated operational recommendation
+
+---
+
+## 3. Methodology must be technically specific
+
+Previous weaker bids were penalised when methods, candidate models, datasets, and technical assumptions were under-specified.
+
+For 182213, specify:
+
+- breakup and fragment descent modelling approach
+- treatment of subsonic fragment regimes
+- atmospheric assumptions and data sources
+- aircraft vulnerability / encounter model
+- air traffic density or exposure model
+- uncertainty propagation method
+- validation dataset strategy
+- comparison baseline
+
+The evaluators should never have to guess:
+
+- which models you will test
+- which data you will use
+- how uncertainty is handled
+- what the benchmark is
+
+If multiple methods are possible, state the decision logic up front:
+
+- baseline method
+- advanced method
+- selection criteria
+
+---
+
+## 4. Validation must be concrete, not deferred
+
+One repeated weakness in earlier bids was saying that validation detail would be defined later.
+
+For 182213, validation must already be visible in the bid.
+
+State:
+
+- the scenarios to be tested
+- the data sources for those scenarios
+- the validation environment
+- the comparison cases
+- the acceptance criteria
+
+Recommended validation structure:
+
+1. Historical case back-testing
+2. Monte Carlo scenario testing
+3. Operational replay with airspace and flight-density overlays
+4. Expert review with aviation stakeholders
+
+If possible, include a headline validation case:
+
+- Long March 5B / Spanish airspace closure style scenario
+
+That immediately shows operational relevance and mirrors the tender text.
+
+---
+
+## 5. Trace every claim to operational impact
+
+Past bids lost marks when impact was credible but too qualitative.
+
+For 182213, every technical output should map to an operational outcome:
+
+- fragment model improvement -> better hazard corridor definition
+- aircraft encounter modelling -> clearer risk thresholds for operators
+- uncertainty modelling -> more defensible airspace restrictions
+- event updates -> better timing of restrictions and release decisions
+
+The impact section should explicitly answer:
+
+- what will change for ANSPs
+- what will change for airlines
+- what will change for regulators
+- what will change for re-entry risk assessment practice
+
+Do not leave impact at the level of "better safety awareness".
+
+Use impact language such as:
+
+- fewer unnecessary closures
+- more targeted restrictions
+- faster updates under uncertainty
+- more defensible criteria for action
+- stronger basis for future regulatory guidance
+
+---
+
+## 6. Show the path to standards, regulation, and adoption
+
+Winning bids are not just technically strong; they show where the outputs go next.
+
+For 182213, spell out the route from project outputs to:
+
+- ESA / space safety use
+- aviation authority acceptance
+- ANSP procedures
+- future standardisation and guidance material
+
+Potential channels to mention, if justified in the consortium and work plan:
+
+- ICAO-related airspace risk handling
+- EASA / national authority guidance
+- EUROCONTROL / ANSP operational procedures
+- future ATM / STM coordination frameworks
+
+The key is not to overclaim, but to show a credible uptake path.
+
+---
+
+## 7. Be explicit about automation, human decision support, and cybersecurity
+
+Past proposals were criticised when automation levels or cybersecurity handling were unclear.
+
+For 182213:
+
+- state clearly whether the output is advisory decision support, not automated airspace command
+- define the human decision-maker in the loop
+- state how integrity, traceability, and update provenance are maintained
+- describe cybersecurity proportionately if software or data exchange are in scope
+
+Useful framing:
+
+- the system supports, but does not replace, authorised aviation decision-makers
+- all operational recommendations are traceable to model version, inputs, and timestamped assumptions
+
+---
+
+## 8. Work packages must be concrete at task level
+
+Several past bids were penalised for vague WPs, missing sub-tasks, unclear milestones, and unclear partner roles.
+
+For 182213, each WP should show:
+
+- purpose
+- tasks
+- lead
+- contributors
+- outputs
+- milestone(s)
+- acceptance criteria
+
+No partner should appear as a name in the consortium without a visible task-level role.
+
+Minimum good structure:
+
+- WP1 Project management and quality assurance
+- WP2 Requirements, scenarios, and operational criteria
+- WP3 Physics and fragment risk modelling
+- WP4 Aircraft vulnerability and airspace exposure modelling
+- WP5 Integrated platform / demonstrator and validation
+- WP6 Exploitation, standards, and regulatory uptake
+
+If the tender scope is smaller, compress the WPs but keep the same traceability.
+
+---
+
+## 9. Milestones must align with the handbook and the internal logic
+
+Earlier feedback repeatedly picked up avoidable issues:
+
+- inconsistent durations
+- missing maturity gate
+- deliverables landing after the logical close of technical work
+- unclear PM tables
+
+Before submission, run a consistency check on:
+
+- project duration
+- WP dates
+- milestone dates
+- deliverable dates
+- PM totals
+- partner PM subtotals
+- budget tables versus narrative tables
+
+This is not cosmetic. Evaluators treat these errors as evidence that delivery control may be weak.
+
+---
+
+## 10. Exploitation must be concrete, not generic
+
+Weak bids often described dissemination reasonably well but exploitation too vaguely.
+
+For 182213, separate these clearly:
+
+- communication: who hears about the project
+- dissemination: who receives results
+- exploitation: who uses what, how, and why
+
+Exploitation should identify:
+
+- primary users
+- adoption pathway
+- productisation or service pathway
+- next-phase funding or procurement path
+- what SkyNav will own or commercialise after the project
+
+For SpaceCom, exploitation should be tied to:
+
+- aviation safety decision support for re-entry events
+- ANSP-facing operational tooling
+- integration into broader SpaceCom platform modules
+- future institutional and commercial deployments
+
+---
+
+## 11. The bid should feel smaller, sharper, and more provable than the broad SESAR bids
+
+The prior feedback suggests a recurring risk: trying to sound system-level and strategic without enough measurable technical substance.
+
+For 182213, the better move is:
+
+- narrower scope
+- sharper technical method
+- stronger validation
+- clearer operational end user
+- simpler consortium story
+
+This tender appears to reward a focused, technically credible, high-clarity proposal more than a sprawling programme narrative.
+
+That should favour an SME-led or SME-prominent bid if the scope is disciplined.
+
+---
+
+## Recommended Proposal Spine for 182213
+
+## One-sentence positioning
+
+SpaceCom will deliver a validated risk-assessment and decision-support capability for subsonic re-entry debris in airspace, combining fragment modelling, aircraft exposure assessment, and operational airspace impact logic to support safer and less conservative response decisions.
+
+## Core objectives
+
+- characterise subsonic fragment behaviour after destructive re-entry
+- quantify aircraft exposure and vulnerability to subsonic debris in airspace
+- integrate airspace and traffic-density context into re-entry debris risk assessment
+- validate operationally useful decision criteria for airspace restrictions and release
+- produce a pathway toward institutional adoption and future standardisation
+
+## Core outputs
+
+- fragment risk model
+- aircraft encounter / vulnerability model
+- integrated risk engine
+- operational decision criteria
+- validation report using historical and synthetic scenarios
+- regulator / operator uptake package
+
+---
+
+## Red Flags to Avoid
+
+- objectives that cannot be measured
+- qualitative impact claims without KPIs
+- saying validation will be defined later
+- vague references to AI or analytics without specific methods
+- unclear partner roles
+- weak or generic exploitation language
+- no explicit operational decision-maker or user
+- no cyber / integrity treatment if software exchange is involved
+- no benchmark against current conservative practice
+
+---
+
+## Submission Gate Checklist
+
+- [ ] Objectives are specific, measurable, and testable
+- [ ] Each objective has at least one KPI and one validation method
+- [ ] Methodology names the models, datasets, assumptions, and baselines
+- [ ] Validation cases are already defined in the proposal
+- [ ] Impact is quantified wherever possible
+- [ ] SESAR-style performance logic is mirrored even if this is not a SESAR call
+- [ ] Operational user and decision context are explicit
+- [ ] Standards / regulatory uptake path is credible and specific
+- [ ] Automation and human-in-the-loop position are explicit
+- [ ] Cybersecurity / integrity handling is addressed if relevant
+- [ ] WPs include task-level detail and named partner roles
+- [ ] Milestones, deliverables, PMs, and budget are internally consistent
+- [ ] Exploitation is concrete and linked to SpaceCom's roadmap
+
+---
+
+## Bottom Line
+
+The lesson from the past tenders is not that the concepts were weak.
+
+The lesson is that evaluators rewarded proposals that were:
+
+- more measurable
+- more technically explicit
+- more validation-led
+- more traceable from task to output to KPI to impact
+
+For tender `182213`, SpaceCom has a strong thematic fit. The decisive factor will be whether the bid reads like a precise operational science-and-software programme with defensible metrics, rather than a broad strategic vision.