HOW I WORK
projects ▸cat method.txt
So the decision can be made on data and repeated without me. If a number cannot be defended, it does not go in the report; if something cannot be reproduced, it does not count. Whether the job is an LLM red-teaming audit or a platform on Kubernetes, the tool changes — the promise does not.
The order does not change either: scope, reproduce, measure, deliver. That is what keeps a report useful next month.
I write for the person who decides, not only for the one who runs it. I spent five years shipping product to production before moving into AI offensive security, so I know what it costs to have a report end up on a shelf — and what it is worth to be able to reproduce it.
./deliver --verifiable
WHAT YOU GET
// the work, not just the result
- A repository with what was run and the commands that reproduce it: NORN is the complete example.
- A report where every claim carries its metric and its baseline, exported by the tool itself rather than from a spreadsheet.
// including what did not work
- The experiments that failed and the metrics that showed nothing significant, with a reading: that is the data that changes decisions.
- The limits of the method said out loud: an ASR measures one attack under one set of conditions, not the security of the system.
// if the job is platform work
- Infrastructure as code and deployments that come out the same twice (Terraform, Ansible, CI/CD) instead of hand-made changes.
- Monitoring and continuous delivery included: the work ships and runs, it does not stay in a document.
HOW I DO IT
// 01 · scope
- Scope and threat model in writing before the first line: what is in, what is out and on which assumptions.
- If the starting data does not exist, it gets defined before we start: without a "before", the "after" means nothing.
// 02 · reproduce
- The failure, deterministically. If it cannot be reproduced, it does not exist — and what does not exist cannot be patched.
- Every finding ships with the configuration that repeats it: your team will try it on Monday.
// 03 · measure
- One metric per claim, with its baseline written next to it.
- From this site: 48 campaigns, 924 cases and 4,470 replicas in NORN (ASR, FAR/FRR, PSR@K, TDS, UAR); from a day to 10 minutes per release at the industrial scale-up (≈98% less time).
- If the data has variance, I report it: the LLM judge adds cost and its own variability to the scoring.
// 04 · deliver
- Repository, report and commands. Nothing that only works on my machine.
- Atomic commits and reviewable PRs, with the why in the message: a decision without a reason reverts itself.
- Automated verification: tests and guardrails that fail the build if something breaks, plus documentation of what cannot be automated.
FROM SYMPTOM TO PRODUCT
// debug to the root cause
- A symptom, an instrument and a datum: metrics, traces and low-level traffic before touching code. My final degree project was exactly that — a multithreaded C sniffer that pulls 15 traffic features and classifies them in real time with a Random Forest.
- Root cause or it does not count: a patch that hides the symptom comes back, and the second time costs double.
- A flaky failure is a failure with a condition we do not know yet: find the condition, do not re-run until it shows up.
// deliver through the product
- Landing in product: features in production with real users — machine learning for industrial operations, real-time communication with WebRTC and the multi-vendor data platform of the cybersecurity product.
- Treating the platform as part of the product: from a day to 10 minutes per release and 50+ tenants on Kubernetes, with infrastructure as code and continuous delivery.
- Nothing stays a demo: if it does not reach the user and is not maintained, it does not count as delivered.
// close with method
- Baseline before touching anything, one metric per claim and the limits said out loud: without that, a result cannot be defended in a meeting.
- And what did not work, published: that is the datum that changes the next decision.
- Not in my own projects either: NORN is a CLI with its metrics, its validation and its report export — not a test notebook.
HOW IT STARTS
./first-step --no-ceremony
Send me two lines: what you have in front of you and what hurts. If it needs context, I will suggest 30 minutes with no presentation; and if I am not the right person for it, I will tell you in that first reply. A person answers, not a form.
If you are looking for someone for your team, start with the profile: work areas, track record and certifications.