Method · ownership · no scores
How we draw, and who holds the pen.
ė.ink is published by LABS, the studio that builds labs.llc. We drew these diagrams of our own tools — what that means for verdicts in ink.
It means three things. We had every advantage in understanding these tools, because we could read their source; we had every reason to flatter them; and so the reader is owed more evidence than an independent critic would need to show. The rest of this page is how we try to pay that debt.
1What we read
Each labs.llc tool was read in the build 537 source tree, which is byte-for-byte the build that is live, and every statement about how a tool works carries the file and line it comes from. Where a review says a page never makes a network request, or that a relay refuses anything but three numbers, it is because we read the code that does it.
The tools were chosen at random from the labs.llc catalogue, with the seed recorded, before any of them was tested. We did not pick the ten we expected to look best.
In the margin, about this site itself: ė.ink counts its readers through Google Analytics 4, a property of its own, which keeps _ga cookies in the browser.
2What we measured
Every test ran on 27 September 2026 between 20:10 and 20:34 UTC, against a local copy of build 537 served on our own machine, so that testing could not disturb the live site. Where a tool reads an outside service directly from the browser, we repeated its request with the same query shape the page uses and recorded the status, the size, the time taken and what came back.
Each review's test section is a log: the minute, what we did, what we got. When a source failed, as dictionaryapi.dev, PubChem's search endpoint, the EPO's weekly list and the Treasury's feed each did on the day, the failure is in the log and in the verdict. We did not re-run a test until it passed.
3How we choose and treat rivals
Two or three named, current tools from elsewhere on the web stand beside each labs tool. Each was read on its own pages on the test day, and where a site refused our reader we say where the facts came from instead: an app-store listing, the project's own documentation, or its own help pages found by search. If we could not verify a feature, we make no claim about it either way.
For every rival we write down first what it does better. Only then do we list where the labs tool goes further, and each such point cites the source line that shows it. We use no rival's logo, screenshot or look, and link to them plainly.
4How the drawings are made
Every review has one drawing: the tool's data flow from top to bottom, from where its facts come from to what reaches your screen. It is a simplification of the cited code, not a system diagram, and it leaves out anything the page does not actually call.
- red box: part of the labs.llc tool
- grey box: an outside source
- red line: the path the tool takes
- dashed: only when you ask, or a fallback
Red is reserved for the tool's own path. Outside sources are grey, and dashed lines mark steps that happen only when you ask, or only when something else has failed.
5Why there are no scores
A score from the builder about the builder's own work is noise, and structured rating markup would ask search engines to treat it as more than that. So there are no stars, no numbers out of ten and no rating markup anywhere on this site. Each verdict is written instead as two lines: what goes in red ink, and what goes in pencil.
Every review names at least one real shortcoming of the labs tool, and most name four or five. A comparison the home tool won on every row would not be believed, and should not be.
6Corrections
If a measurement is wrong, a rival has changed, or a line reference has moved, write to labs@labs.llc. We will correct the page and note the change on it.