Start with a question
Building a product often exposes questions that were not obvious in the original idea. Why did a benign message get deleted? Why did a high-risk classification produce no action? Why did a warning look successful against two crises but no better than many random controls?
I’m interested in using those discrepancies as starting points for investigation. The strongest examples in this portfolio include a specific observation that changes the explanation or limits the claim.
Explain the contribution
My projects include AI-assisted research and development. Each case study explains the technical question, relevant methods, observed results, and limitations.
My direct contributions include project direction, requirements, test requests, supplied observations, integration decisions, and questioning whether the system actually behaves as intended. Where a claim depends on a historical artifact rather than a fresh test, the case study says so.
Keep negative results
An experiment that does not support deployment can still be valuable. In Assera’s AI-exit evaluation, confidence intervals spanning benefit and harm led to no promotion. In the market-warning work, a more elaborate model could lose to a simpler baseline, and a revised dataset could weaken a return claim.
The point is to preserve the result that was obtained, including missingness, timing assumptions, and uncertainty, rather than treating every iteration as progress toward a predetermined conclusion.
Use evidence precisely
- A source file supports an implementation claim, not necessarily a current deployment claim.
- A historical test receipt supports the tested snapshot and scope, not every later version.
- A saved model probe demonstrates that output, not a population error rate.
- Installation counts are adoption milestones, not effectiveness measurements.
- A proposed next experiment is a plan, not completed research.
These pages draw on retained technical artifacts and historical records reviewed in October 2026. Public-safe summaries are used in place of private logs, employer material, client implementation details, or personal correspondence. There are no claims of peer-reviewed publication or comprehensive independent security certification.
What I want to explore next
I want to get better at designing evaluations that separate model failures from systems failures, testing behavior under realistic constraints, and turning observations into a defensible next experiment. Security-oriented AI evaluation is a natural direction because it connects questions I have already encountered across these projects.