I verify systems.

Every engagement answers two separate questions, because they are separate: is it internally correct (does it do what you think it does) and does the evidence actually support what you believe about it. Systems pass the first and fail the second all the time. Knowing which failure you have is the product.

1. I'll try to kill your backtest

You have a strategy: backtested, maybe beautiful, maybe about to get real money. Before it does, I attack it the way I attack my own:

• Survivorship. Are the dead companies in the data, or were they deleted before the test?
• Cost arithmetic. Does the edge survive the tolls, or does it invert?
• Overfitting. Is the good result a plateau or a lucky spike?
• Lookahead. Does any decision quietly use information from its own future?
• Holdout discipline. What does data you never touched say?

You get a written report: what survived, what didn't, and exactly how I checked, with every claim reproducible. Sometimes the answer is "your edge is real, and here's where it's fragile." Sometimes it's a graveyard. Either answer is worth more than a beautiful chart. Read a complete sample report →

2. Put your code on trial

Your AI wrote it. I try to break it. Agents write code that looks right, runs, and passes the tests they also wrote. Whether it does what you think it does is a different question, and it's the one that costs money when it's wrong quietly. Don't ask whether your tests pass. Ask whether your system survives an independent attack.

What that looks like: analitiq-engine had 3,632 green tests. I planted 20 defects one at a time; the suite caught 14, six escaped, and the maintainers reproduced all six. payload-reserve's default install let any customer take over any other customer's account; fixed in v4.1.1. Both audits publish with the attack plan hashed before I read a line. Read the audits →

Why I started in markets: quantitative systems are the most hostile place to verify anything. Backtests lie, data leaks, assumptions change silently, and a tiny implementation error creates an enormous fake edge. I built the verification machinery there first, on my own systems, in public. This is the same machinery applied to software.

Trenyx Independent Verification · one subsystem · 3–5 business days · flat quote · confidential

Give me one production subsystem (or one clearly bounded codebase). What you receive:

• Attack plan. Before I read a line, hashed and emailed to you first: what the system is supposed to do, its critical invariants, its external dependencies, and which paths I'll attack (correctness, state, persistence, ordering and concurrency, data integrity, failure and retry, authorization boundaries, external-API assumptions, AI-code assumptions).
• Independent tests. Written blind to your existing suite, targeting assumptions rather than implementation. No circularity: your AI wrote the code and the tests; I assume both are wrong.
• Adversarial testing. Fault injection with planted defects (leaked future data, off-by-one time, wrong state transition, missing transaction, wrong authorization branch, stale cache, duplicate event, failed dependency, partial write, bad retry, swallowed exception), plus boundary and malformed inputs and state corruption.
• Existing-test challenge. Which planted defects your current suite catches, and which escape.
• Findings report. Every finding tagged confirmed defect / potential defect / design concern / recommendation; confirmed defects graded critical, high, medium, or low; each with reproduction steps, affected component, and why your existing safeguards didn't catch it. Five real findings beat two hundred plausible ones.
• Retest. You fix; I re-run the relevant attacks and confirm.
• Verification receipt. A hash of the attack plan and results, timestamped outside my control, under the same append-only, checksummed discipline as the records on this site. Nothing of your code leaves; the receipt proves what was tested and when.

I report verification coverage instead of a bug count: “112 adversarial scenarios · your system handled 103 · 9 escaped · your tests caught 71; I found 32 more.” One honesty note: the denominator is mine, so the number describes this attack, not a universal metric. The scenario list ships with it so you can judge the denominator.

How this differs from mutation testing (Stryker, mutmut, and friends): those tools mutate syntax (flip an operator, delete a line) and are worth running in an afternoon. The planted defects here are semantic: a future-data leak, the wrong authorization branch, a missing transaction, a duplicate event, a swallowed exception. These are the failures that pass every syntactic mutant and every test written by the same agent that wrote the code. Run both; they answer different questions.

Stacks: Python, TypeScript/JavaScript, Ruby, and Go are in scope today. The method is language-agnostic, so ask about anything else before assuming no.

If I find nothing, you still get everything above: the attack plan, the independent tests, the coverage number, and the receipt. I never promise a bug count. An auditor who guarantees twenty vulnerabilities has already told you what the report will say.

Verification Pilot · one module · 2 business days · flat quote

Try the method before you trust it. Fault injection only, on one module you choose: the planted-defect set, the coverage number, the list of what escaped your tests, and a receipt. If it finds something, the pilot fee credits toward the full engagement. The quote comes in my first reply, before anything is pinned.

The ten questions you should ask any verifier, answered

1. Scope. One subsystem per engagement, agreed in writing before I read a line.
2. Methodology. The attack plan above, delivered before the attack starts, and its SHA-256 emailed to you before any code is shared: your inbox timestamps the pre-registration, not my repository. No static-analysis-and-a-summary.
3. Deliverables. The seven items listed; the report is the smallest part.
4. Reproducibility. Every confirmed defect ships with steps and, where possible, an executable reproduction you run yourself.
5. Independence. My tests are written blind to yours. I don't grade your suite by running it; I grade it by what it fails to catch.
6. Fault injection. Yes: real planted defects in your implementation, counted.
7. Evidence. Findings carry proof or they carry a "potential" tag, never a "confirmed" one.
8. Confidentiality. See below: never published, never referenced, even anonymized, without written permission.
9. Data retention and processing. See "Where your code goes" below: one encrypted machine, deleted within 30 days of the retest, processed only through Anthropic's commercial API, never used for anything else.
10. Guarantee. None on findings, by design. You get the full artifacts and the coverage number whatever the attack finds. You keep full control of remediation and interpretation: I provide findings and evidence, you decide what they mean.

I also build systems this way from scratch: specification before code, tests before implementation, independent adversarial review before anything is trusted. If you want the flavor of how I work, read the slow version was the honest one.

Where your code goes

Your material stays yours

Why my verdict is worth anything

I don't get paid more for approving your system, and I don't get paid more for killing it. Fixed scope, flat quote, agreed before I read a line. The verdict is not for sale. And the method isn't marketing: my own strategies get the same treatment on this site, including the ones the process killed.

How it works

Email a short description of what you have and what worries you: sk@trenyx.io. If it's a fit, I reply with a fixed scope and a flat quote before any commitment (the verification packages above are fixed-price; backtest audits are quoted per scope). One or two engagements at a time. If I'm full, I'll say so and give you a date.

Audit my backtest Put my code on trial