Notes from the
mlab engineering team
How the platform is built, measured and broken. Internal studies, benchmarks against other tools, and the details we usually keep in our own docs. Written for people who read the methodology before the conclusion.
Method before result
Corpus, versions, hardware and configuration come first. If a number cannot be traced back to how it was produced, it does not ship.
We show where we lose
Every comparison names the cases where mlab does worse. A benchmark that wins everywhere is a benchmark nobody should trust.
Raw numbers, open data
Precision, recall, timings and memory as measured, no composite score. Datasets and scripts are published whenever their licence allows it.
All notes
Newest firstinkdex: an index that states facts, a scanner that judges them
How inkdex, our local code index, and inkdex-vuln, the scanner that reads it, went from 9.5 to 99.2 on OWASP Java in fourteen releases: facts kept apart from verdicts, call resolution without a compiler, five benchmarks re-run on every release, a 9.1x speed-up with byte-identical findings, and the limits we still have.
A 421M decision model in front of our MCP output? Not yet
We tested Laya as a prompt-injection guardrail for the text mlab's MCP tools return: three question wordings, a training grid over three sizes and three seeds, real documentation and long pages. Where it works, why it flags 40% of real READMEs, and the numbers that would make us ship it.
Replaying supply-chain attacks against postmortem
Eleven public npm, PyPI and crates.io incidents replayed against postmortem, then five large real projects read by hand: which signals fire before an advisory exists, why a 48-hour cooldown is the cheapest control, and the six bugs the test found in our own tool.
No note matches .