Space & insurance
Spacecraft Health Scoring and QA Tooling for Space Insurance
Leading an internal QA platform, building spacecraft system-health scoring, and turning insurance stakeholder interviews into risk-scoring requirements.
- DomainSpace systems & insurance underwriting
- TeamLeading development with 3 other engineers
- MigrationFive-stage, flag-gated data transition
Problem and stakes
Charter Space builds spacecraft engineering and risk-analysis software for the insurance side of the space industry. I work there as a senior engineer across several repositories, on three threads: tooling to keep the engineering platform reliable, a spacecraft system-health scoring capability, and requirements for insurance risk scoring.
- Scattered test signal: CI results lived in separate repositories, with no single view of regressions or recurring failures
- Translating domain knowledge: Insurance and actuarial stakeholders described risk in their own terms, and spacecraft data had to be mapped onto it
- Changing the data model safely: Legacy consumers had to keep working while the underlying data model changed
- Trust and access: Test results and artifacts needed authenticated, fail-closed access and validated ingestion
My role
- Role
- Senior Software Engineer
- Stage
- Space-technology company
- Team
- Four engineers on the QA platform (I lead development with three others)
Strategy and decisions
Leading an internal QA platform
Cross-repository CI analytics
- Consolidated CI test results into one regression-analytics view
- Added failure signatures to group recurring failures
- Built a plain-language bug board that syncs to the team's task tracker every 15 minutes
- Secured test ingestion and artifact access with fail-closed authorization and input validation
Implemented spacecraft system-health scoring
From snapshots to interactive breakdowns
- Persisted snapshots as the input to scoring
- Built feature extraction and a covariate registry feeding the score computation
- Computed system-health scores from those features
- Built interactive views that break a score down into its contributing factors
Translated insurance discovery into requirements
Stakeholder interviews and dataset analysis
- Worked from insurance stakeholder interviews and spacecraft dataset analysis
- Defined risk-scoring requirements for underwriting and actuarial-baseline development
- Defined signature-visualization requirements alongside the scoring requirements
Designed planning workflows and a safe data migration
Hierarchical tasks and staged transition
- Architected hierarchical task and requirements workflows with Gantt planning and role-based permissions
- Added issue-tracker import
- Authored architecture decisions for hierarchical workflows and data redundancy
- Shipped a five-stage, flag-gated dual-write transition with telemetry and fallback reads
Outcomes
- One view of CI healthRegression analytics and failure signatures consolidated across repositories
- Bugs readable beyond engineeringA plain-language bug board kept in sync with the team's task tracker every 15 minutes
- Interviews turned into buildable requirementsRisk-scoring and signature-visualization requirements for underwriting and actuarial-baseline work
- Data-model change without breakageA five-stage, flag-gated transition kept legacy consumers working
Evidence
Optional layers for anyone who wants to inspect the reasoning.
Architecture
Decision log
How to make CI health visible across repositories
Options considered
- Leave results inside each repository's CI
- Consolidate results into one regression-analytics view
Chose One regression-analytics view, with failure signatures that group recurring failures
Why Recurring failures only read as a pattern when results from separate repositories sit side by side.
Who the bug board is for
Options considered
- An engineering-only tracker
- A plain-language board synced to the team's task tracker
Chose A plain-language board that syncs to the team's task tracker every 15 minutes
Why People outside engineering needed to read quality status without translating it.
How to show system health
Options considered
- A single opaque score
- A score that breaks down into its contributing factors
Chose Interactive views that break a score down into its contributing factors
Why A risk view is only useful if someone can see why the score moved.
How to change the data model without breaking consumers
Options considered
- A single cutover
- A staged, flag-gated transition with dual writes and fallback reads
Chose A five-stage, flag-gated dual-write transition with telemetry and fallback reads
Why Legacy consumers kept working at every stage, and each stage could be turned off by flag.
Trade-offs
- A staged migration takes longer than a single cutover. It trades calendar time for no breakage.
- Fail-closed access to test results refuses a request when authorization is uncertain. For engineering data that is the right way to fail.
What's public and what isn't
This story describes current work at a private company. It stays at the level of problems, decisions and approach: no client names, internal system names, tools, data or figures beyond what is stated here.