Engineering case studies.

Problem

Experiencing Hurricane Helene in Boone is what motivated HYDRA. Short-lead streamflow forecasts from NOAA’s NextGen framework carry errors that a learned post-processor may be able to reduce, and HYDRA asks whether a model trained on reforecasts generated with the same framework can improve forecasts at 1–18 hour lead times without leaking future information.

Why it matters

The work has two parts: NextGen reforecast generation software with Google Cloud workflows that prepare the data, and a post-processing model evaluated by site and lead time. Results are pending; a results manuscript for Water Resources Research is in preparation, and a software paper for Environmental Modelling & Software is planned.

Approach

1. Built NextGen reforecast generation software and Google Cloud workflows to acquire, validate, and align weather, streamflow, and forecast data with traceable provenance.
2. Designing forecast post-processing for 1–18 hour lead times, comparing LSTM, Transformer, and Mamba-style models on identical inputs and splits.
3. Evaluating with leakage-aware temporal splits and hydrologic metrics (RMSE, NSE, KGE), reporting performance by site and lead time.
4. Preserving initialization, lead, valid-time, version, and source metadata so every training example traces back to the forecast that produced it.
5. Preparing a results manuscript for Water Resources Research; a software paper for Environmental Modelling & Software is planned.

Results

1. Reforecast generation software and Google Cloud data workflows are in place; the NextGen_Hydra repository is public.
2. Model comparison and lead-time evaluation are in progress; results will be posted when the analysis is complete.
3. A results manuscript is in preparation, and a software paper is planned.

What I learned

1. Post-processing depends as much on how reforecasts are generated and aligned as on model architecture.
2. Reproducible data and configuration lineage make changing scientific results auditable.
3. Research claims should evolve with the evidence rather than outrun the analysis.

Problem

Internal teams needed customer data presented through dependable services and clear troubleshooting views.

Why it matters

During my internship at USAA’s global headquarters in San Antonio, I built Java and Spring Boot GraphQL APIs for customer-data workflows and reduced troubleshooting time by 30% through API enhancements and JavaScript comparison views.

Approach

1. Built Java and Spring Boot GraphQL APIs for customer-data workflows used across enterprise channels.
2. Integrated name and employment data from multiple sources into an internal troubleshooting tool.
3. Built JavaScript comparison views and delivered work through an Agile team workflow.

Results

1. Reduced troubleshooting time by 30% through API enhancements and JavaScript comparison views.
2. Contributed customer-data API capabilities for enterprise workflows.

What I learned

1. Clear API contracts help teams make changes safely.
2. Reliable production software depends on close collaboration between engineers, product owners, and end users.

Problem

LLMs are useful for research and analysis, but an automated decision system should not let them act on their own. Harmony is a financial decision pipeline designed so that every step is declared and logged, and every consequential action waits for a human.

Why it matters

Harmony is an active Python project built as an explicit state graph with declared action paths and tamper-evident logging of each step. LLM research and analysis are confined to advisory nodes that can flag or veto but cannot execute.

Approach

1. Built the decision pipeline in Python, scikit-learn, SQLite, and React as an explicit state graph with declared action paths.
2. Logged each step in a tamper-evident record so every decision can be reviewed.
3. Confined LLM research and analysis to advisory nodes that can flag or veto but cannot execute.
4. Required human approval for each consequential action.
5. Designed an isolated AWS environment for reproducible CPU/GPU research experiments, with local tools to control runs and review results.

Current Scope

1. An explicit state graph with declared action paths.
2. Tamper-evident logging of each step.
3. Advisory LLM nodes that can flag or veto but cannot execute.
4. Human approval required for each consequential action.

Design Principles

1. Boundaries belong in the architecture, not in a model’s confidence.
2. Declared action paths make it possible to say exactly what the system can and cannot do.
3. Tamper-evident logs make every decision reviewable after the fact.
4. Performance claims require forward testing, not only historical simulation.