Eleven years delivering enterprise software — requirements, implementation, escalation triage, and unblocking the people who run live systems — now aimed at mission operations, ground segment, and technical program management in the space sector.

I direct multi-model AI workflows to do rigorous technical work, then publish it with its limits intact: eleven DOI-archived Zenodo deposits across four research programs, all ORCID-linked, all reproducible. Self-published, reproducible technical work with explicit scope limits; qualified external engineering review is the next validation step.

I'm not claiming to be a flight-qualified engineer. I'm claiming I can scope rigorous technical work, verify it, ship it, and be accountable for it — and that every claim below is checkable.

Eleven years in enterprise HCM implementation — software delivery, project leadership, requirements analysis, escalation handling, technical support. The number that matters is the tempo, not the total:

A continuous, high-tempo delivery load — not a sequence of one-off projects. The queue stays full and I don't fall over. I've since moved onto an internal SME support team: triaging incoming issues, unblocking consultants running live implementations, owning the support queue.

Triage under time pressure, escalation paths, unblocking operators mid-procedure, sustained tempo under continuous load — those are the transferable parts, not the domain. I have not done mission operations, and I won't claim a support queue is the same thing.

anomaly triage · escalation management · requirements analysis · technical program management

Python is the primary language — simulation, numerical analysis, automation, test suites. Closed-form derivations in Wolfram Language, cross-checked against the numerical implementation. Kotlin is the newest addition, picked up to build MUNINN on Android. My research software ships with CI/CD-enforced pytest suites and versioned releases.

Python · Wolfram Language · GitHub Actions · v1.1.0 · 259 passing tests

Thermodynamic bounds and mass-trade criteria for heat rejection in orbital data centers: analytic radiator-area bounds, an executable radiator simulation package, and a Phase B chip-to-radiator architecture trade study.

Found and corrected an error in someone else's published model. Reproducing Andrew McCalip's open Space Datacenters orbital-radiator model, I found its cosine-tilt view-factor heuristic underestimated the edge-on per-face Earth view factor by roughly 12×. With exact tilted-plate-to-sphere geometry, equilibrium temperature moves +6.35 K (335.75 K → 342.10 K). Correction, derivation, and verification script published: DOI 10.5281/zenodo.20695720.

_{Scope: reduced-order, one-node model. Not validated against flown hardware. Not for flight design, certification, or safety-critical decisions.}

spacecraft thermal control · radiator sizing · heat rejection · trade study

JavaScript · Chrome Extension APIs · N2YO API · published v0.6.1

A glanceable countdown to the next visible ISS pass. Pass predictions come from the N2YO API — N2YO propagates the orbit, not me. What I built is the client: a 6-hour cache, graceful degradation with no key / location / network, a background worker scheduling notifications ahead of bright passes, and one-click calendar export (Google Calendar or .ics).

Scoped, tested, and launched by me — including the parts no agent can do: developer account, store submission, public listing, and standing behind it when it breaks. Launched to r/ISS and r/amateursatellites; an SDR operator flagged that several roadmap satellites (NOAA weather sats) are decommissioned and recommended the still-operational Meteor-M series instead. Roadmap updated.

API integration · caching · graceful degradation · shipped product

Kotlin · Jetpack Compose · Android 8.0+ · v1.0.0 · 15 JUnit tests

An Android trainer for the working vocabulary of spacecraft operations: 154 terms across mission operations, ground systems, spacecraft systems, and operations management, played as a six-phase campaign that follows a mission's real life from pre-launch reviews through disposal and passivation. Each phase certifies on a 12-question exam (10 correct to pass) and unlocks the next. XP climbs a rank ladder lifted straight from a control room: Trainee → Console Operator → Flight Controller → Ops Lead → Flight Director.

Wrong answers are drawn from the same domain as the right one, so the quiz drills the difference between neighboring concepts rather than the shape of the correct button. Game logic is plain Kotlin with no Android dependencies, covered by 15 JUnit tests. The content is one JSON file, so adding a term updates the quizzes and the phase counts at runtime. No permissions, no network, no accounts.

My first Kotlin and first Android build, written because I wanted it to exist. In Norse myth Odin flies two ravens; Muninn is the one that carries memory. Vocabulary is the part of mission ops you can't reason your way through — either you know what an ORR is when someone says it, or you're behind for the rest of the meeting.

Knowing the words is not the job. A console seat is earned in simulation runs and certification on live spacecraft, and this app provides neither. It teaches the floor.

_{Scope: definitions are original prose synthesized from the standard mission-ops literature — NASA SE Handbook, CCSDS, ECSS, and the ODMSP, all listed in the repo. A study aid, not a controlled glossary, and not affiliated with any operator or agency.}

mission operations · ground segment · Android development · self-directed study

Python · framework v1.0 · preprint DOI · thirteen-gate frozen case record

An evidence-gated review methodology for work that must survive hostile scrutiny before release. One human directs, one LLM builds, a second separately-run LLM attacks. Work moves through gate reviews against predefined acceptance criteria: the Builder freezes a hash-manifested packet (configuration control — findings are cryptographically bound to the exact bytes reviewed), the Reviewer deposits findings as data, and the human Director dispositions every finding on a signed record. A gate passes with zero unaccepted blockers; convergence is declared by a stopping rule fixed before the findings are seen — never on exhaustion.

The result that earns the paper is a failure. Turned on its own tooling, the loop failed five consecutive gates (12, 11, 12, 12, 15 findings) because each fix closed the reviewer's named probe rather than the defect class behind it. The correction — every fix must demonstrate it addressed the class, every check must be witnessed failing before it is trusted — ended the streak. Published on purpose.

technical program management · gate reviews · configuration control · verification & validation

Python · Monte Carlo · v1.1.0 · evidence pinned to commit ba3ddb5 · 73-test suite

The headline result is a failure I found in my own safety instrument. The kill criterion meant to detect a runaway credit spiral took four versions (v0–v3). v2 is the interesting one: it passed honest-noise tests cleanly and missed genuine spirals — a false negative on the instrument that exists to catch the failure.

Method: 300 Latin-hypercube samples × 50 seeds × 3 demand variants = 45,000-run sweeps, plus a separate 45,000-run out-of-sample re-certification, positive and negative control batteries, and seven scripted attack scenarios.

Recorded lesson: a kill criterion is itself a safety mechanism and must be adversarially tested in both directions — showing that honest behavior doesn't trip it is not enough.

_{Limits: results hold at sampled points only. Nothing is live or production-validated.}

agent-based modeling · Monte Carlo · Latin hypercube sampling · fault detection

HTML · concept brief and requirements notes, published

An independent concept for an ORU-style robotic on-orbit servicing validation payload, developed for NASA TechLeap's Robotically Manipulated Payload Challenge. I didn't assemble a team before the deadline, so I didn't compete.

Every other project here is solo work accelerated by AI. A robotic servicing payload is not — it needs mechanical engineers, flight-hardware experience, environmental test, fabrication. Nobody pulls off a moonshot alone; Apollo was four hundred thousand people. The finding wasn't about the payload: I had built a portfolio and a method, but not yet the professional network that lets you convene a team against a deadline. Building the team is the work, not the overhead around it.

_{Not an official NASA, TechLeap, or Luminary Labs project.}

Professional memberships: AIAA · IEEE (Robotics & Automation Society; Aerospace & Electronic Systems Society) · The Planetary Society

Also building: Artemis Smartwatch — ESP32 kit, first embedded hardware project · Reading list — spaceflight history, propulsion, autonomous systems, with a written reflection on each finished book.

Mission operations · ground segment and ground control operations · technical program management · systems engineering · AI systems integration — in the space sector.

Next up: external engineering review of the Orbital Thermal Bounds Phase B transport and pressure claims (the model needs a qualified human reviewer, and until it has one the repository says so) · OpenC3 COSMOS training · ROS 2 fundamentals → rover build → SLAM/perception and computer vision.