Selected Work
Built for the problem in front of me.
Some work is public. Some lives behind enterprise boundaries. Both are documented here without fake metrics, private data, or hand-waving.
Private case study
Service Center Helper
AI-assisted troubleshooting workflows designed to help support consultants work faster and more consistently.
The problem
Support work often requires jumping between request context, person information, knowledge sources, and response tools while the customer is waiting.
The build
A focused helper interface that brings relevant lookup and AI-assisted support workflows into one experience while respecting the boundaries of enterprise systems.
My role
Workflow and interface design, service integration, production hardening, documentation, and careful DEV-to-PROD porting.
Public boundary
The production implementation is private. No internal endpoints, customer data, prompts, credentials, or university system details are reproduced here.
Private case study
AI Closing Response Helper
RAG-backed response tooling shaped around real ticket-closing workflows.
The problem
Closing notes need to be useful, consistent, and grounded in the work that actually happened—not generic text generated outside the ticket context.
The build
An AI-assisted workflow that uses relevant ticket and knowledge context to draft responses for human review rather than silently replacing support judgment.
Design principle
Put the support workflow first: preserve review, keep the useful context visible, and make generated output easy to correct before it reaches a customer.
Public boundary
Descriptions stay at the workflow level so private ticket data, internal knowledge, and service configuration remain protected.
Project brief
GW2 Command Center
A second-monitor Guild Wars 2 dashboard built around live API data and custom interface systems.
The problem
Useful game information is spread across separate views and tools, creating friction when the player needs a quick operational picture.
The build
A dashboard concept designed for a second screen, where scanability, live data, and clear prioritization matter more than decorative interface chrome.
What it explores
API integration, resilient loading states, information hierarchy, responsive dashboard layout, and interfaces that remain useful during active play.
Status
Active project work. Public screenshots and a demo will be linked when they represent the project accurately.
Project brief
YAP Technician Toolkit
Modular Linux diagnostics and auditing tools for repeatable troubleshooting workflows.
The problem
Ad-hoc diagnostic commands are difficult to repeat, compare, hand off, and document consistently across support sessions.
The build
A modular Python and Bash toolkit for collecting system information, running focused checks, and producing useful logs for later review.
Design principle
Keep diagnostics composable and understandable. A technician should be able to see what a check does, why it ran, and what the result means.
Status
Ongoing toolkit development, with the emphasis on reusable modules and support-friendly output rather than one large opaque script.
The through-line