What I have built

Lead Software Engineer · WebInspect

WebInspect is an enterprise dynamic application security testing platform: a large, mature C# and .NET product with a long history and an installed base that cannot be disrupted. I joined Micro Focus as a Senior Software Engineer in 2021, stayed when OpenText acquired them, and was promoted to Lead in 2025. The work spans architecture, modernization, implementation, debugging, cross-platform compatibility, data integrity, build and release reliability, and production maintenance.

Across that time I have delivered more than 250 production-integrated changes and led roughly five major feature initiatives, owning design through to delivery.

• The WebInspect settings API. Led the settings model that exposes WebInspect's scan configuration as a programmatic API, shipped as a library and consumed by ScanCentral DAST to control scans. It covers the full settings surface and is the largest thing I have owned on this product. I wrote roughly 80 percent of it: the model itself, the override system layered on top so a caller can change one setting without restating the rest, and validation across every model in it. The validation work ran as its own campaign across roughly fourteen model classes.
• Suppressed findings and false-positive export. My feature from the start, and the longest-running thread of work here: February 2023 to April 2026. The original export feature, then import, merge behavior, correlation across providers, file encoding, failed-import cleanup, and making the whole path thread-safe. Customer-facing reliability rather than new surface area, which is why it kept coming back.
• HAR support. Built end to end, letting a recorded browser session be used as a scan source, with a parser hardened against the non-standard files real-world tools emit. The largest single feature by volume of code.
• SQL Express through the Entity Framework migration. The product's move to Entity Framework Core was led by another engineer focused on SQL Server. I was brought in when SQL Express broke on Linux and took ownership of making the system work on SQL Express across both platforms. Scan management was restored under .NET 8 and EF Core by replacing legacy ADO.NET enumeration with a cache-backed design, keeping backward compatibility with existing scan files. The interesting problems were the ones the migration exposed rather than the migration itself: connection settings deprecated since 2012, crashes from shared threads and detached databases mid-scan, and false change detection caused by timezone rounding. The team is now moving that .NET 8 codebase to .NET 10 for the next release, on a long-running modernization branch that is about to become the product's main line.
• Linux and container enablement. One of two engineers on the team who develop against the Linux container branch, where the product runs in Docker with SQL Express under Entity Framework. Aligning runtime and data behavior across platforms means resolving differences that only appear off Windows, down to filesystem permission models.
• API configuration and validation. I did not write the REST API, but I owned validating it: request and configuration validation, transport and authentication header handling, endpoint correctness, and later Postman collection support. Also encryption for stored credentials, OAuth providers, client certificate pins and bearer values, which was smaller but mine.
• Copilot governance framework. Led this with others on the team. A modular set of repository instructions defining boundaries for AI-assisted change around high-risk projects, platform symmetry, localization, logging and public APIs, intended to prevent unrequested architecture-altering edits while keeping each prompt's context small.

Independent AI research and systems engineering

A sequence-learning engine built from first principles, and the trading terminal that supervises it. It has been a spare-time project for many years and close to a second full-time job for the last eighteen months. The engine is built. The terminal is the surface a human uses to watch, evaluate, and act on what it is doing.

The engine

• Built without pretrained weights, and not layered on an existing transformer. It combines probabilistic state modeling, in the spirit of hidden Markov models, with attention-based sequence processing.
• Learning is continuous and driven by surprise. There is no separate training phase followed by a frozen model. Error and surprise signals decide when to update, and the system carries persistent long-term memory across sessions.
• It reads the same signal at several time scales at once and treats agreement and disagreement between those scales as information in its own right.
• Prediction is a set of forward paths, not a point estimate. Where the paths converge is conviction; where they fan out is uncertainty. The terminal draws them directly on the chart, so the shape of the model's doubt is visible rather than reduced to a number.
• Designed to run on hardware I own. A linear sparse attention scheme chosen to execute efficiently on a single consumer GPU, with multimodal input and disk-backed structures that keep a working set far larger than memory inside millisecond response targets.

The terminal

A Rust trading terminal, built on egui and wgpu, that renders the engine's output and gives it a controlled way to act. The framework underneath it is complete: every milestone built, with unit and integration tests passing and manual verification behind each one. On top of that framework the application already puts a real, fast chart on screen from a TimescaleDB store, and I am currently building the trading-enablement layer. This is the part I can describe in detail, and the engineering in it stands on its own.

• One command surface for both the human and the AI. Every mutation in the application flows through a single typed command queue, and the AI uses exactly the same API a click does. That decision was made in the first milestone, which means the AI's control surface has been the integration test backbone for every feature since, rather than something bolted on at the end.
• A permission layer in front of that surface. Each command category can be allowed, gated behind a human confirmation, or refused outright, according to a configured trust level. Trust is set at startup and deliberately cannot be raised during a session, so there is no in-session prompt for the model to talk its way through.
• Every order passes the same risk gate, including the ones I place by hand. A manual ticket becomes an intent, gets evaluated, approved, and submitted through the identical path an AI-generated trade takes. The human ticket is not a back door around the safety system. A mismatch between the account a profile claims to be and the account the broker reports is a hard refusal rather than a warning.
• Deterministic replay throughout. Nothing reads the system clock directly; time comes from a clock abstraction that can be live or replaying history. The same run at any speed produces identical interpretation order, which is what makes evaluating the engine against the past meaningful.
• A 144Hz frame budget, enforced. An eight-phase frame loop with a per-phase time budget inside 6.9ms, instrumented per phase, and a graduated degradation policy that sheds visual quality before it sheds frame rate. Panels tear out into independent OS windows, regroup, and snap magnetically.
• Pixel regressions caught without a GPU. Draw commands are recorded and replayed through a headless software rasterizer against committed golden images, so rendering regressions fail in CI on a machine with no graphics hardware.
• Continuous-density level of detail. Rather than stepping through fixed resolution rungs, the chart splits and folds buckets by factors of two to hold candle width inside a target pixel band as you zoom, with per-tier caches, fetches moved off the frame thread, and stale-while-refetch rendering so the view never blanks while data is in flight. Getting this right is most of what separates a chart that feels fast from one that does not.
• A production boundary the AI cannot reach. The lab environment is paper-only and open to agent tooling; the live-capable environment runs under a separate identity with its own secrets and is not agent accessible, with signed artifacts and rollback between them. Passing every gate still does not enable live trading. That remains a manual act only I can perform, which is the correct place to put a decision about real money.

How it is built

• Specified before it is written. Roughly 700,000 words of design documents, API contracts, and per-sprint specifications, where each sprint states its acceptance tests, its explicit non-goals, and what must be passing before it starts.
• Adversarially reviewed by several models independently. Each milestone's design goes out to more than one frontier model for criticism from different angles, the findings are consolidated, and the resolutions are recorded against the design gaps they close. This is the same multi-model workflow I brought to work, applied to a codebase where I am the only human reviewer.

Proprietary independent research. The engine's internals, its representation and memory model, and anything resembling a market methodology are deliberately absent from this page. What is described above is architecture and process, not algorithm.

Lead Software Engineer and Systems Architect

Twenty-five years designing, building, deploying and maintaining a complete factory automation and ERP platform, as the sole engineer. Requirements through architecture, code, test, deployment, and the corporate IT it ran on. Three hardware generations, with the system in continuous production throughout.

• Replaced mechanical machine timers with programmable controllers, improving timing accuracy to roughly a tenth of a second and enabling functionality such as vacuum molding. Cycle time fell by at least 20 per cent, with a corresponding gain in productivity.
• Wrote a real-time kernel in C and assembly because no suitable operating system existed for the original Z180 hardware, and a token-ring-style network stack over RS-485 because the industrial environment was too electrically noisy for anything simpler.
• Migrated the controller to x86 and Windows Embedded in C++ when the project outgrew the original hardware, rebuilding the GUI, the development environment and the OS integration while carrying forward what still applied.
• Added centralized production data collection on PostgreSQL running on Debian, growing to roughly 36 tables and 20 stored procedures serving gigabytes of machine data.
• Built the C# clients the business actually ran on: real-time productivity and profitability reporting per machine and per employee, shift overviews, efficiency over arbitrary time ranges, and inventory and customer management. The second-generation system produced an 8 percent productivity gain in its first week online and continued improving after that.

Burton Vision, Software Developer, 1993 to 1994. Assisted in developing an interactive sign language and English dictionary for deaf students, in HyperTalk.

Telecommunication Consulting and Repair, Electronics Technician, 1991 to 1992. PBX installation and component-level circuit board repair, including surface-mount rework and reverse engineering circuit diagrams from bare boards.

B.S. Computer Science, Southern Polytechnic State University, subsequently Kennesaw State University, 2016.

Graduate coursework in Computer Science, machine learning specialization, Georgia Institute of Technology.