Technology, research, and public service.

Software that has to survive real operations.

My strongest technical work is not isolated to one language or one kind of application. It is the work of translating messy operational needs into maintainable systems: automated data ingestion, validation workflows, database-backed portals, custom public websites, civic records tools, research automation, and interfaces that help nontechnical users act on complicated information.

That usually means understanding the existing process first: who owns the data, what happens when a feed arrives late, where manual review still matters, what a public user needs to find, what has to be auditable, and how to keep the system understandable for the people who rely on it after the first version ships.

The common thread is operational discipline: make the data path clear, protect the handoffs, expose the right status to the right people, build around actual operating constraints, and document enough of the system that it can keep being improved.

High-volume data systems with validation and delivery pressure.

At Acxiom, I work in enterprise data management environments where automated ingestion, database processing, file transfer reliability, validation, and delivery timelines all matter. My work includes production pipelines processing tens of millions of records daily, with some workflows reaching roughly 100 million records.

The client work has included Consumer Reports, Norwegian Cruise Lines, and current work for Wells Fargo. Across those environments, the technical concerns are similar even when the business context changes: data arrives from multiple sources, schemas evolve, transfers can fail, validation rules have to be repeatable, and downstream users need confidence that the records are complete, timely, and usable.

That kind of work is less about writing a clever script and more about operational discipline: Oracle database work, SQL performance, Python automation, Snowflake workflows, daily feed monitoring, controlled file movement, audit checks, exception handling, runtime tuning, and enough documentation for production support.

Automation that improves reliability, not just speed.

I have worked on automating validation and monitoring workflows so production systems are easier to operate and easier to trust. The practical goal is to let people spend less time checking routine conditions and more time handling exceptions, judgment calls, and higher-value work.

In data systems, automation is not just a convenience layer. It is part of reliability engineering. A good workflow can identify missing inputs, detect unexpected row counts, surface schema changes, distinguish a late file from a bad file, and create an audit trail for what happened. A weak workflow hides failure until someone downstream notices.

That mindset also carries into public-facing and nonprofit work: build repeatable processes, reduce manual re-entry, design forms that collect clean information, make administrative review easier, and keep the technical path understandable enough for a team to own after launch.

Technical work inside structured client environments.

Enterprise systems work has shaped how I think about software: production constraints matter, client context matters, data contracts matter, and maintainability matters. My Acxiom work has involved Oracle database work, SQL-heavy processing, Snowflake workflows, Python automation, feed oversight, file ingestion, and production support across client environments.

These systems are rarely blank-slate engineering projects. They already have dependencies, deadlines, service expectations, business rules, and real users. The challenge is to improve reliability and clarity inside an existing system without breaking the operational assumptions around it.

That requires a different kind of technical communication. You have to be able to explain what changed, why a feed failed, what validation caught, what the impact is, whether a rerun is safe, and what should be adjusted so the same issue is less likely to happen again.

Web work tied to mission, coordination, and public safety.

At The "I Love U Guys" Foundation, I build and maintain internal systems and web platforms supporting nationwide school-safety programs used by educators, emergency personnel, public administrators, and community partners. The technical work is connected to a public-safety mission, which changes how I think about clarity, dependability, accessibility, and collaboration.

The work spans custom HTML and CSS pages, GitHub-based development workflows, database-backed configurations in MariaDB and SQLite, and Vite/React tools for agreement and MOU-related portals. It also includes Mapbox-based map configuration, contact and training-inquiry ingestion forms, and practical workflow improvements that help the organization manage information across programs, partners, and public-facing resources.

This is not web work as decoration. It is operational infrastructure: helping a mission-driven organization publish clearly, collect structured information, support agreement workflows, reduce manual handling, and keep important school-safety resources easier to maintain.

OpenHotSprings as a source-first civic records system.

OpenHotSprings reflects a different kind of technical problem: civic information is often public, but still hard to discover, track, and understand. Civic technology is not just publishing data. It is designing a path from scattered public records and meeting information to something a resident can actually use.

The architecture combines a React, TypeScript, and Vite frontend with a FastAPI backend. The backend is designed around official-source ingestion from City of Hot Springs records, Agenda Center pages, RSS feeds, city calendar and department pages, bid and purchasing pages, FOIA records, official City YouTube streams, and public contact records. The production model separates the public React site from server-side scanning so residents see processed records, source links, update timestamps, and clear status labels instead of internal mechanics.

The backend exposes civic-record endpoints for health and status checks, source probes, packet records, discovered records, official contacts, meetings, projects, contracts, budgets, and search. Optional PostgreSQL storage tracks discovered-record metadata such as source, URL, first-seen and last-seen times, download status, storage keys, content hashes, video IDs, transcript status, and candidate recording-match state.

The ingestion design is careful about evidence. City packets can be downloaded, hashed, and served back through the API. YouTube captions and transcript files can be normalized from VTT or SRT-style cues, while timestamped description lines can provide section navigation when captions are unavailable. Recording matches stay candidate-only until official records, transcripts, minutes, or packet text support the public claim.

On the frontend, the goal is not to overwhelm residents with raw municipal data. OpenHotSprings uses compact browsing patterns for meetings, tracked topics, source records, and expandable details. The user should be able to see what an item is, why it matters, where it came from, and what source document supports it before choosing to go deeper.

Automation for repeatable analysis and computational modeling.

At Michigan State University, I was selected for the Advanced Computational Research Experience for Students program, a 10-week Research Experience for Undergraduates in computational and data science coordinated by MSU's Department of Computational Mathematics, Science and Engineering and the Institute for Cyber-Enabled Research. The program places a small cohort of students into original interdisciplinary research projects and includes exposure to high-performance computing, scientific software development practices, seminars, research-group meetings, poster work, and final presentations.

My ACRES work was with Dr. Andrew Bender on modeling brain network connectivity in Alzheimer's disease. The project focused on computational and statistical approaches to structural brain connectivity in aging and Alzheimer's research, using graph-theory and machine-learning methods to reason about MRI-derived brain networks.

My research work included MRI data-analysis automation tools that created and automated design matrices, Bash scripts, contrast matrices, and cluster-submitted analysis workflows. In practice, that meant turning complex analysis setup into a more repeatable technical process for research use: less manual setup, more consistent runs, clearer artifacts, and better support for review by the research team.

USC capstone: computational policy analysis

For my Master of Public Administration capstone, I led the Decision Making under Deep Uncertainty (DMDU) analysis of policy responses to AI development constraints. The work applied computational modeling to compare policy robustness, feasibility, and adaptive strategies across 10,000 simulated futures.

Read the capstone’s abstract, methods, and full report

That experience reinforced a technical lesson that applies well beyond academia: analysis quality depends on structure. Automation is valuable when it makes the setup clearer, reduces avoidable manual steps, and helps researchers or operators run a process consistently enough that results can be trusted and reviewed.

Tools I use to solve the actual problem.

My technical background includes Python, SQL, Java, JavaScript, jQuery, CSS, HTML, Perl, C, Haskell, LaTeX, Snowflake, Oracle, Streamlit, and ETL work. Current and recent project work also includes React, TypeScript, Vite, FastAPI, MariaDB, SQLite, PostgreSQL, Mapbox, GitHub-based workflows, and S3-compatible object-storage patterns.

AI belongs inside real workflows.

My interest in AI is practical rather than theatrical. The question is not whether a tool sounds impressive; it is whether it can help people understand information, reduce repetitive work, preserve accountability, and improve a real process without hiding uncertainty or creating new risks.

The kinds of AI work that interest me most are source-grounded and reviewable: document analysis, civic-record summarization, search over trusted materials, workflow triage, drafting support, and systems that help people reason through complicated information without losing the link back to evidence.

The USC capstone provides one example of this approach: LLM-assisted qualitative content analysis with human review, followed by computational policy evaluation. The report describes the methods, assumptions, and limits in detail.

Explore speaking on technology, institutions, and uncertainty