Work

Finished things. Four full case studies, everything else kept dense on purpose.

Tinker CPU

Depth almost nobody at this stage has

The problem: Build a 64-bit out-of-order processor in SystemVerilog — dual-issue, register renaming, reservation stations, a reorder buffer, branch prediction, and a pipelined FPU.
The constraint that made it hard: DRAFT Almost nobody building a CPU at this level attempts real out-of-order execution; the honest reason is verification, not RTL. Register renaming has to be correct against every WAW/WAR hazard combination, and a broken interaction between the reservation stations and the reorder buffer doesn’t show up as a compile error — it shows up as a wrong answer three instructions later.
What was chosen — and against: DRAFT Chose a Tomasulo-style design (reservation stations + a reorder buffer) over a simpler in-order scoreboard. Against: that would have shipped faster and been easier to verify, but it wouldn’t have proven anything about real superscalar execution — the whole point was building the version that’s actually hard.
What I’d do differently: DRAFT Write the randomized instruction-sequence verification harness before the FPU pipeline, not after. The FPU came first because it felt like the fun part; the hazard bugs that took longest to find were always in renaming, and a fuzzer would have caught them earlier.

29 / 29 on the correctness suite

Production judgment plus the appsec signal being recruited on

The problem: A four-state reachability model for triage, backed by a custom CodeQL analysis, read-only by design.
The constraint that made it hard: DRAFT The dangerous failure mode in any triage system isn’t a false positive — it’s a finding silently scored as safe because it hasn’t been analyzed yet. The four-state model exists specifically so “not yet analyzed” can never collapse into “not reachable,” even when merging them would make for a cleaner dashboard. (Using the brief’s general framing here — swap in employer specifics only if clearance comes through; see DESIGN_BRIEF.md §8, decision #5.)
What was chosen — and against: DRAFT Chose read-only, CodeQL-driven analysis over anything that could auto-remediate or auto-close findings. Against: automatic remediation demos better, but a system that can silently close a real vulnerability is worse than one that does nothing — read-only means a human always makes the call.
What I’d do differently: DRAFT Add a confidence signal alongside the four states. They capture what’s known about reachability, but two findings landing in the same state can still deserve very different levels of trust, and right now that distinction isn’t captured anywhere.

~79 tests

Ships for money, on a team, against a real spec

The problem: Shipped against a 41-page spec covering 16 bet types, as part of a team, for a paying client.
The constraint that made it hard: DRAFT The spec was 41 pages covering 16 bet types, written by people who understood the betting product, not the codebase. The hard part wasn’t any single bet type — it was building something the team could implement against without re-deriving the business logic from prose every time the spec hit an edge case it didn’t quite cover.
What was chosen — and against: DRAFT Chose a rules-driven engine that reads bet-type behavior from spec-derived configuration, over hand-coding each of the 16 bet types as its own code path. Against: hardcoding would have shipped the first few types faster, but it would have meant 16 places to fix every time the spec changed, on a team, under a paying client’s deadline.
What I’d do differently: DRAFT Turn the spec’s edge cases into a shared test fixture on day one instead of as bugs surfaced. Several bet-type disagreements on the team turned out to be different readings of the same ambiguous paragraph — a shared fixture would have surfaced that in code review instead of in production.

The most differentiated item in the set

The problem: Founded and scaled a volunteer organization to 30+ contributors, building a classifier that reached 90%+ accuracy.
The constraint that made it hard: DRAFT This was two hard problems wearing one project’s name: coordinating 30+ volunteers with wildly different availability and skill levels, and getting a classifier from “works on the training set” to 90%+ in the real world. Neither was solvable with more engineering alone — the labeling quality volunteers produced fed directly into how good the model could get.
What was chosen — and against: DRAFT Chose to invest early in labeling guidelines and review rather than just recruiting more volunteers to brute-force more labeled data. Against: more volunteers would have looked like faster progress, but inconsistent labels would have capped accuracy no matter how large the dataset got.
What I’d do differently: DRAFT Build the volunteer onboarding and labeling-quality tooling before scaling past the first 10 contributors, not after. The guidelines that ended up mattering most were written in response to disagreements that had already happened.

30+ volunteers · 90%+ accuracy

C memory allocatorRepo

QTrack — QR event check-inRepo

Sports calendar aggregatorSee /sports

AutoQA / CaddyRepo

Spec-driven pipelineRepo

DECA presidency + ICDC 1st Place

Currently poking at — live research reads as more impressive than a polished dead project.