Ratna

Project Stash Vault

Engineering archive shaped for long-horizon work, not short-term portfolio churn.

Vault 01 / Aerospace

Case file / 2025

Launch Window Planner

A readiness and scheduling console for launch campaigns with typed constraint tracking, timeline visibility, and operator handoff context.

Public materials are still being curated. The internal case file below is the current source of truth until supporting assets are ready to publish.

Next.jsTypeScriptNode.jsTailwindOpenTelemetry

#launch operations#constraint tracking#timeline UI#coordination

20-second project scan

What to understand first

A fast scan for recruiters and engineers: ownership, technical depth, proof status, and current outcome in one place.

Problem, solution, and system shape

The project framed as a system: the problem, the solution boundary, and the architecture choices that make the implementation credible.

Problem

Launch work is often constrained by fragmented operational state. A good planning tool reduces ambiguity at the exact moment teams need to reason across dependencies, not inside isolated discipline dashboards.

Solution

Launch Window Planner treats launch preparation as a coordination system rather than a static checklist. It assembles readiness signals across domains, tracks evolving window constraints, and gives operators a timeline view of what changed, what is blocked, and what becomes critical next.

Architecture

Modeled readiness as typed status slices so propulsion, range, vehicle, and mission inputs can publish independently without collapsing into one global form.

Kept timeline state separate from domain status state so operators can read what changed without losing the source of the change.

Technical highlights

Where the engineering depth shows up

The implementation details a technical reviewer should notice before reading the full case file.

Highlight 01

Modeled readiness as typed status slices so propulsion, range, vehicle, and mission inputs can publish independently without collapsing into one global form.

Highlight 02

Kept timeline state separate from domain status state so operators can read what changed without losing the source of the change.

Highlight 03

Designed the interface around operational review, not around static data entry.

Highlight 04

Used timeline-first navigation to surface sequence, dependencies, and escalation points under time pressure.

Proof surface

Artifacts, references, and public access points

Ready links and planned proof artifacts are shown together so reviewers can distinguish published evidence from reserved case-study slots.

Capture

Planned

Readiness timeline capture

Reserved for the primary launch-campaign timeline surface with changing constraints and escalation points.

Reserved for future publication once the supporting material is ready.

Walkthrough

Planned

Dependency review walkthrough

Reserved for a guided sequence through the operator review flow for shifting launch windows.

Reserved for future publication once the supporting material is ready.

System view

Architecture and implementation

The architectural boundaries and implementation choices that make the system coherent, maintainable, and operationally meaningful.

Architecture

Modeled readiness as typed status slices so propulsion, range, vehicle, and mission inputs can publish independently without collapsing into one global form.

Kept timeline state separate from domain status state so operators can read what changed without losing the source of the change.

Implementation Notes

Designed the interface around operational review, not around static data entry.

Used timeline-first navigation to surface sequence, dependencies, and escalation points under time pressure.

Left room for later alerting and audit history without overloading the first prototype.

Metrics and outcomes

What is proven so far

Honest status, proof readiness, and results. Qualitative markers are used where exact production metrics are not available yet.

Status

Live Prototype

Current maturity of the project record.

Proof

Capture planned

Reserved for the primary launch-campaign timeline surface with changing constraints and escalation points.

Architecture

2 notes

Documented architecture decisions and boundaries.

Outcomes

Produced a clearer operational shell for readiness review than a checklist-oriented tool would provide.

Strengthened the aerospace vault with a category-native interface project, not just back-end infrastructure work.

Future Work

Add scenario comparison views for shifting launch windows and late-breaking readiness changes.

Related entries

More from the aerospace vault

Vault 01 / 2026

Satellite SLA Marketplace

Featured file

Live Prototype

An on-chain marketplace for satellite imaging tasks where requesters fund capture jobs, operators bond execution commitments, and escrow settles against verifiable SLA outcomes.

Built

Full-stack system design and implementation across smart contracts, verifier-service architecture, wallet-connected frontend flows, local developer tooling, and deployment-oriented project structure.

Satellite capture agreements are not just procurement records; they are timing-sensitive operational commitments with real failure modes. If requirements, evidence, and payment logic are loosely managed, it becomes hard to prove whether an operator actually met the task or whether a requester is justified in disputing delivery. This project is interesting because it turns an aerospace coordination problem into a system with explicit trust boundaries across contracts, storage, verification, and operator-facing workflows.

Strongest proof

Repo available

Available

Next.jsTypeScriptFoundrySolidityGoIPFSDocker

#satellite tasking#escrow#sla verification#mission operations

View Project View Repo

Vault 01 / 2026

Telemetry Attestation Rail

Research Track

A provenance rail for mission telemetry that signs critical state changes and preserves an auditable path from raw data to reviewable findings.

Built

Provenance model design, ingestion pipeline architecture, and workflow definition for anomaly review and downstream verification.

In mission environments, raw data alone is not enough. Teams need to know what record was observed, who processed it, what changed later, and whether a conclusion can be defended under review.

Strongest proof

Diagram planned

Planned

PythonFastAPIKafkaClickHouseSolidity

#telemetry#provenance#verification#mission assurance

View ProjectView Repo

Internal case file is live; public repo is not linked yet.