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: twelve 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 scope rigorous technical work, verify it, ship it, and stand behind it. 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.

What transfers is the tempo: triage under time pressure, escalation paths, unblocking operators mid-procedure, sustained load without a break in it. The domain is what the rest of this page is for.

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 was picked up to build MUNINN on Android. Ratatoskr added the agent stack: a local decision model (Strands Decider 2B, served on CPU and, optionally, on the laptop's GPU) in front of an open-weight model on Amazon Bedrock, Strands Agents hooks, local OCR, a Telegram bot, and a mobile web prototype on GitHub Pages. My research software ships with CI/CD-enforced pytest suites and versioned releases; Ratatoskr's suite adds 273 mutation checks, each mutation applied alone and caught, and every published report regenerates from a committed export.

Python · OpenC3 COSMOS · Docker · v0.1 · 492 tests · 11 check suites

A mission operations simulator for a fictional 6U CubeSat. The spacecraft is simulated in Python, and I operate it by written procedure against real ground software, OpenC3 COSMOS. The repository holds the complete systems-engineering record behind it: requirements, FMEA, three procedures with 39 steps, and the reports of the four passes I flew — a nominal activation, then three anomaly passes: a solar-array string loss across two contacts, a stuck-on load, and a halt in housekeeping telemetry.

Flying the passes found defects that review hadn't. The design record went through seventeen adversarial review rounds, and I dispositioned all 97 findings. Planning and flying the campaign still found a decision step that could not be completed with a stuck load on a charging battery, procedures that sent me to a staleness alarm on a screen where it never appears, and no route into the telemetry-loss procedure once a contact had begun. Each one is recorded as a finding, ruled on, red-lined and flown, and 18 rulings in DECISIONS.md record who decided what.

Huginn is the other raven: thought, where MUNINN's vocabulary goes to work at a console.

_{Scope: the spacecraft and its mission are fictional, and its model is simplified. A training simulator, and the starting point for HUGINN's flight version under Project AESIR. Built with AI assistance under my direction and review: Claude wrote the code, tests and documents, and GPT reviewed the design record adversarially. Code: Apache-2.0; documentation: CC BY 4.0; files derived from OpenC3's project template keep OpenC3's licences.}

mission operations · ground segment · procedure execution · anomaly response · systems engineering

Python · Strands Decider 2B · Amazon Bedrock · Strands Agents · v1.0.0 · 985 tests · 273 mutation checks · interactive sandbox

A courier that turns spoken commitments into tasks. A wearable recorder's transcript passes a stop-list tripwire and a local privacy gate before an open-weight model on Amazon Bedrock extracts the commitments; then Strands Decider 2B, running on my laptop, answers six typed questions per task (project, real commitment, someone waiting, hard deadline, worth researching, too sensitive to post), and plain code turns the answers into a Todoist task and a three-line notice on a smartwatch. An unsure privacy answer holds the recording. An unsure project leaves the task unsorted with filing buttons on the notice, and my tap is recorded as mine. A photo path puts the same gate in front of pictures, with local OCR and a commitment-or-reference decision, and a companion mobile web prototype is the owner's screen, with one live connection into the courier.

The finding that set the architecture: a proposed task can look harmless once extraction has dropped the private context around it. In a live hook check, a Strands hook judging tool arguments alone let such a note through, so the courier gates the source text before Bedrock reads it and checks each proposed task again before writing. On a fresh set of 24 fictional conversations, labels committed before the first model call, the gate held all 12 sensitive ones before any cloud call; asked about the 26 labeled ordinary tasks, Decider assigned a project to 8, all 8 right, and abstained on 18. The camera run is the honest limit: of twelve phone photographs of handwritten cards, every sensitive card stayed held and every reference card stayed local, and none of the four commitments was recovered: the OCR lost key words on every handwritten card, and I filed one card as reference by mistake. Every report regenerates byte for byte from a committed export with no model and no keys.

Built for the AWS Builders Agent Experience Hackathon (Strands Decider), October 2026: the entry, the overview video, a development roadmap with a public board, and a one-minute sandbox that plays the recorded results with no sign-in. Ratatoskr is the squirrel who carries messages up and down Yggdrasil; the interesting part is what it declines to carry.

_{Scope: a demo on one laptop with fictional fixtures. The checkpoint was evaluated on images without image training, so the photo numbers are an experiment with that checkpoint; the companion is a prototype with a simulated private viewer and one live connection. I directed the build and dispositioned every design question; Claude Code wrote the code under that direction, and GPT reviewed it adversarially. Apache-2.0. Pocket, Todoist, Telegram, and CircuitMess are their owners' marks; not affiliated with any of them or with AWS.}

AI systems integration · decision models · privacy by refusal · Strands Agents · Amazon Bedrock · hackathon entry

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.20695719.

_{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

TypeScript · HTML/CSS · Vite · GitHub Pages · Free browser demo

A narrative game about the people, decisions, and responsibility of Mission Control. The first playable scenario is inspired by Gemini VIII: choose supplemental ground rehearsals, question your controllers, weigh incomplete reports, and make a return decision whose consequences carry into the debrief, relationships, and preparation for the next mission.

My role spans the whole delivery: concept, scope, historical research, narrative and art direction, multi-model AI coordination, playtesting, and release decisions. I direct the work across Claude and Codex, review the results, and own what ships. The game combines illustrated 2D scenes, Apollo-inspired controls, an original soundtrack, and a deterministic simulation with replay verification. Historical sources and fictional departures are documented rather than blended into an implied reconstruction.

One playtest exposed a design failure: the Procedures Binder revealed mission information before the player encountered it. The resulting rule now governs the Binder, Evidence, and History: nothing appears before it is encountered in play, and every addition is visibly announced. A small example of translating player feedback into a clear requirement and a verified change.

Available now: one Gemini VIII demo, ending with a Gemini IX-A preparation plan. Long-term vision: a campaign from Gemini toward Artemis, with decisions carrying across missions. The full campaign is in development; no release date is announced.

Play the demo · Source code

_{Scope: an independent, non-commercial game, not operational training or a flight-qualified simulator. Created using generative AI with human creative direction, review, and final decision-making. Not affiliated with, authorized, sponsored, or endorsed by NASA. Code: MIT; original content: CC BY 4.0, subject to the repository's licence terms and third-party exceptions.}

interactive systems · historical research · requirements & acceptance testing · AI-directed delivery · shipped product

JavaScript · three.js · WebGL · Blender · GitHub Pages · Live site

STS-26 was the first launch I watched, at six years old. Discovery flying again on September 29, 1988, thirty-two months after Challenger. This is that vehicle and that mission in a browser: rotate and zoom the spacecraft, pull the assemblies apart and put them back, and switch between the launch stack, the orbiter alone, and Discovery riding NASA 905, the Boeing 747 Shuttle Carrier Aircraft.

Open the payload bay and deploy an illustrative Canadarm. Go inside a reconstructed crew cabin with the flight deck and middeck labeled. Take a main engine apart in assembled, cutaway, and separate-parts views. Four reading pages carry the mission history, the five veterans who flew it, why STS-26 stayed with me, and the source credits.

No build step, no backend, no account, no API key. Models, textures, and the Draco decoder all ship with the site. It's static files on GitHub Pages.

Every asset's provenance is checkable. Each one has a row in ASSET-LICENSE-MAP.csv naming its source and its rights boundary, and a PACKAGE-MANIFEST.sha256 hashes all 98 files. The STS-26 patch is the one asset whose rights split two ways. It is public domain in the United States, having been created solely by NASA, and insignia use is restricted under 14 CFR 1221 independently of copyright, which the notices say. The asset map carries its Commons source, the hash of the full-resolution original, and the hash of the downscaled copy that ships here.

Explore it · Source code

_{Scope: an educational visual reconstruction, not flight software, validated engineering CAD, a training system, or a physics simulation. Geometry, materials, markings, mechanisms, and separation paths are approximations, and some cabin and engine references depict later configurations. Built with AI assistance under my direction and review. Not affiliated with, authorized, sponsored, or endorsed by NASA. Code: MIT; original art and writing: CC BY 4.0, subject to the repository's licence terms and third-party exceptions.}

WebGL · 3D reconstruction · historical research · asset provenance · 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

Completed training

In progress: NASA Open Science 101 · Elements of AI, Introduction to AI

Professional memberships: AIAA (student) · IEEE (student; Robotics & Automation Society, Aerospace & Electronic Systems Society) · INCOSE (student) · National Space Club Florida Committee (student) · 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.

Hackathons

AWS Builder Center	Agent Experience Hackathon: Strands Decider — October 16-23, 2026. Ratatoskr: A Smart Wearable Dispatcher, Powered by Strands Decider 2B Project link

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) · INCOSE ASEP · FCC Amateur Radio Technician · Amateur Space Program ideation and development