First real blind-adjudicated baseline for Ktor: 65.1% wrong-match across 418 judged findings on two real production apps. No competitor tool exists for Ktor-specific detection, and no fixes have been applied yet — this is the honest, unimproved starting point, published before any remediation, not after.
Every other benchmark on this site reports a fix pass, a re-certification, or both. This one doesn't — it's a first measurement, published as-is, because publishing only the numbers that already look good isn't the standard we hold ourselves to.
No competitor exists
There is no Ktor-specific static analysis tool to measure against. This is TrueMend-only, judged the same way every other campaign is judged — blind, two-axis, against real production source — just without a second tool in the pool.
The corpus, and a corrected mistake
418 findings, blind two-axis judged, drawn from two real production Ktor
applications: plainhub/plain-app and aruppi/aruppi-api — 309 files total,
not synthetic fixtures. Prior evidence for this framework tested
Exposed, a Kotlin SQL library with no
Ktor routing or server code in it at all — the wrong corpus, by mistake. That
result is retired; this is the first evidence that actually exercises
Ktor-specific detectors.
Result
65.1% wrong-match, 14.8% real-rate, 418 judged. No fixes have been applied. Per our own campaign discipline, round one is measurement, not remediation — the same way Django's 37.1% round-one baseline was published before any of that session's fix work began.
One real engine bug did surface and get fixed along the way, though it
doesn't touch this number: src/core/project_detector.py's Ktor detector
only checked build.gradle/build.gradle.kts for a literal "io.ktor"
string, missing the modern Gradle version-catalog dependency pattern
(gradle/libs.versions.toml) that both corpus apps actually use. Before the
fix, the framework gate didn't even open — 0 ktor_* findings. After, 189.
That bug being fixed is what made this baseline possible to measure at all;
it isn't a precision improvement counted in the number above.
Still open
65.1% is above even the methodology's own "expect 20-50% on a first run" range — a real, high starting point, not a conservative one. Nothing has been fixed yet. The next step is the same root-cause-and-verify discipline used on Django, Bash, Java, SCSS, and Go: read the top wrong categories against real Ktor source, fix the detection logic (not just the judged sites), and re-certify on a fresh sample before claiming any improvement.