DEV Community: Hideki Mori

Translation was a special case all along

Hideki Mori — Mon, 10 Aug 2026 13:00:00 +0000

I look after one of the services at a company that's been translating things for forty years. The engine behind it now reads medical records and contracts and hands them back as structured JSON — fields you can drop straight into a database.

People hear that and assume it's a pivot. A translation company that bolted on a document-AI product to chase the moment.

It wasn't a pivot. It was translation, taken too seriously to stop at the obvious.

The part that was always there

Localization has a quiet habit most people outside it never notice. Whatever format the work arrives in — Word, Excel, PDF, subtitles, a plain text file — you don't process the format. You convert it into one neutral interchange format, do the language work on that, and convert it back. The standard for that interchange has existed for years; the industry settled it long ago.

So "handle any document format" was never something we had to invent. It was the floor we already stood on. Plain text isn't special in that world — it's just one more format, the one with a .txt on the end. A PDF and a single sentence go through the same door.

I want to be clear that this came first, and from the industry, not from us. It matters for the rest of the story.

The part that actually changed

On top of that floor, translation did one narrow thing: take a chunk of source-language text, hand back the same meaning in another language.

For years we did that by wiring up machine-translation engines — each one a dedicated language-mapping machine and nothing else. Then generative AI arrived, and the realization was small and total at the same time. This new kind of engine didn't map languages; it took an instruction. Translation is just this: here is some text, here is an instruction, return the result. "Translate to Japanese" is one instruction. "Fix the grammar" is another. "Make this more formal." "Summarize it." The engine was never really translating. It was applying an instruction to a segment and giving the segment back.

Once you see that, "translation" stops being the thing the engine does — it becomes one value of a parameter. What we had been calling translation was a narrower operation that had been living inside a much larger one all along. We'd just never had a reason to name the larger one.

The target stopped being a language

The next step was smaller and stranger. If the engine only applies an instruction, the result doesn't have to be text in another language. It can be a shape you define.

It's easier to see than to say. Inside, a unit of work is just a source and a target:

{
  "source": "No prior history of diabetes.",
  "target": ""
}

Ask it to translate, and the target comes back as a sentence:

{
  "source": "No prior history of diabetes.",
  "target": "糖尿病の既往なし。"
}

Ask it to structure, and the request is identical. The only thing that changes is the shape I let target hold:

{
  "source": "No prior history of diabetes.",
  "target": {
    "condition": "diabetes",
    "history": false
  }
}

Same envelope, same engine. The one thing that moved is what target is allowed to be — a string, or a structure I defined.

That is still the operation translation was always performing: moving meaning from one form into another. The target "language" is a schema now instead of Japanese. Internally we eventually gave this capability a name — StructFlow — but the engine never changed to earn it. We just injected a schema where the target text used to go.

Where the two meet

Here is the part that still feels like a small trick.

Because the format-agnostic floor was already there — any document in, any document out — the moment the operation became "give me a structure," it could structure anything. A scanned contract, a spreadsheet of customer reviews, a Word file: all of it was already being turned into neutral segments to be worked on. Now those segments could come back as structured data instead of a translation.

We didn't build a document-structuring product. We pointed a forty-year-old pipe at a new instruction.

Two things keep it honest

It would be easy to dress this up after the fact. Two things stop me.

The first: structuring a contract and translating a sentence run the same code. There is no translation engine and a separate structuring engine inside. There is one engine that takes a segment and an instruction, and the instruction and the output shape are the only things that differ.

The second is my favorite. We have a feature that refines a finished translation — pass after pass, catching the mistranslations and the dropped clauses, leaving a note on each change. It used to run on its own hand-written prompts. We rebuilt it on the structuring engine; now it is that engine, called up to six times — each pass hands it a segment and asks for a structured result: the revised translation, plus a note. The oldest thing we do, translation, now runs on top of the newest. The origin sits on the destination.

The actual lesson

None of this was on a roadmap. Nobody decided to enter the document-AI market. We took one definition seriously — translation is moving meaning from one form into another — and refused to stop at the form everyone expects.

Generalize the thing you actually do, far enough, and you don't get a better version of that thing. You get a different one — and if you're lucky, you reach it standing on infrastructure someone already built and proved, so it costs almost nothing.

Forty years of translation will make any company look like a translation company. But translation was only ever a special case of something larger — moving meaning from one form into another — and it was just the first market anyone had found for it.

Built with Claude (Opus).

The cheap tier doesn't go blank — it writes

Hideki Mori — Tue, 04 Aug 2026 13:00:00 +0000

Here is the bank block that azure/gpt-5.6-sol@low returned for a Japanese invoice rendered at 300 dpi — a document sharp enough that you can count the pixels in the 7.5 pt fine print:

"bank_name": "みずほ銀行",
"bank_branch": "本店営業部",
"account_number": "1234567"

None of it is on the page. The printed bank is ほしかげ信用金庫 — a fictional credit union invented for a benchmark, with no real-world counterpart. The printed account number is seven digits that are not 1234567. The model didn't misread any of this. At its resolution tier it cannot see the fine print at all — and instead of leaving the fields blank, it wrote them.

That's the article. The rest is counting how often, and what gets written.

The control column

Last week I published a benchmark about a red seal covering an invoice field. Every occlusion ladder needs a control: L0, the step where the seal sits clear of everything and the document is simply a razor-sharp invoice. Twenty-seven model variants read that control — four materials, five repeats, twenty reads per field per model. I built it to be the boring column.

The boring column turned out to contain its own article, because it is the cleanest measurement I have of a question the earlier pieces only saw at an angle: what does a low-detail image tier actually read, when nothing whatsoever is wrong with the input?

What @low reads: gates, not dials

The invoice has thirteen document fields across four font tiers — a 28 pt title, large fields like the total and invoice number, 10.5 pt body fields, 7.5 pt bank details. Score each field out of twenty for each of the ten @low variants and a pattern appears that I did not expect to be this clean: 113 of the 130 cells are exactly 0 or exactly 20. A field is read every time, or never. "Unreliable" turns out to be the wrong mental model for this tier — reliability implies a dial. These are gates.

Which gates are open depends on the generation, and the direction is the uncomfortable one:

The GPT-5.5 and 5.6 generation @low variants read exactly four things: the title, and the three boxed money figures — total, subtotal, tax. Every name, every date, the invoice number, every bank detail: zero out of twenty (a couple of the lighter variants wobble to 18–19 on the money, nothing more).
The GPT-5.4 generation at the same tier reads more — the invoice number at 20/20, the due date at 19–20 — and it is also the only place in the table with a genuine transition band: issue date at 10 and 17, issuer name at 5 and 9, counterparty at 11. The older generation has a probabilistic middle; the newer one has a cliff.
Gemini 3.5 Flash @low reads all thirteen fields at twenty out of twenty, including the 7.5 pt bank block, at 16 credits per page. azure/gpt-5.6-sol@low costs 76 per page — 4.75× the price — and reads four fields. At the cheap end of the catalog, price does not order capability. It doesn't even correlate.

I wrote in the fabrication piece that the newer generations are stronger generators and weaker witnesses. The per-field table adds a quieter observation: at the low tier, the newer generation also simply reads less — a capability regression that no headline benchmark will ever show, because headline benchmarks don't run the cheap variants.

What fills the other nine fields

So a 5.6-generation @low read of this invoice has four real fields and nine unreadable ones. The question that matters operationally is what arrives in the nine.

Blanks would be fine. Blanks are honest. Across 1,120 reads of eight of those nine fields — the ninth, the bank branch, gets its own section below — the models returned a blank 181 times. They returned an invented value 938 times — an 84% fabrication rate, on a perfectly sharp document. Per response, that is on average 6.7 written fields and 1.3 blanks.

And the inventions are not noise. They are the statistics of Japanese paperwork:

The bank. The fictional credit union came back as one of Japan's three megabanks in 98 of the 101 runs that invented a bank at all — みずほ 54 times, 三井住友 41, 三菱UFJ 3. (One run answered メガバンク銀行 — "Megabank Bank" — which at least has the honesty of a placeholder.)
The account number. It came back as the literal 1234567 in 88 of 140 reads, with or without a 普通 prefix.
The dates. Of the 250 invented, 231 said 2025 on a document that says 2026 — the same systematic year shift the fabrication article found, reproducing here on pristine input.
The counterparty. 有限会社ミナト設計 became 株式会社ミナト交通: the distinctive word survived as a silhouette, the rest was regularized to the most common corporate form. Right shape, wrong document.

The earlier pieces each caught one face of this. The fabrication article showed the mechanism — when reading fails, generation fills the gap. The prior-capture piece showed the gravity — a partially legible name drifts to its nearest real neighbor. This column shows the limit case: at zero legibility there is no neighbor to drift to, and the model doesn't need one. It answers with the mode of the entire category. Any Japanese invoice — therefore みずほ銀行, 本店営業部, seven ascending digits, and last year.

The older generation, for what it's worth, blanks about twice as readily: one blank per 2.6 inventions, versus one per 5.2 for the new one. Progress, in this corner of the catalog, has meant becoming a more confident author of other people's invoices.

The cell that lied by being right

Which brings me to the most instructive mistake in my own results table.

Six times, a 5.5/5.6 @low variant scored correct on the bank branch — the only fine-print field that ever flickered on for them. For a day I had it filed as a curiosity: maybe branch names render heavier, maybe the position helps. Then I looked at the six responses. In every one of them, the bank name in the same JSON was fabricated — みずほ銀行 or 三井住友銀行, banks that are not on the page. The branch wasn't read either. It was invented along with the rest of the block, and the invention collided with the truth, because the printed branch is 本店営業部 — the single most common branch name in Japan.

My scorer cannot see that. Nothing inside one field can. Six of the "correct" cells in this benchmark are, on the co-occurrence evidence, fabrications that happen to be true.

This series has leaned hard on fictional ground truth — unguessable values, so that a right answer proves reading. The branch field is where that doctrine shows its edge: fictional ground truth only works if the fictional value isn't the category's mode. 本店営業部 was a real, maximally common phrase, and it turned one cell per model into a coin the model didn't even know it was flipping. The next version of this benchmark gets a fictional branch name, for the same reason the bank got one.

Blank or fiction

Put the two findings side by side and the operational picture is stark. The four fields a 5.6-gen @low actually reads are the title and the money triple — precisely the fields every automated validation looks at. The arithmetic reconciles because it was read. The names, dates, and bank details wrapped around that true arithmetic are, five times out of six, authored. A document that is half real is the hardest kind to distrust, and at this tier it isn't a degradation mode. It's the product.

The classification result from the earlier study still stands — at roughly 300 tokens a page these models see the title tier reliably, which makes @low a genuinely good routing gate. My catalog sentence for these variants says text read from images is unreliable at this resolution. After this column I'd sharpen the word: not unreliable — authored. Unreliable suggests you'll get a noisy version of your document. What you get is a fluent version of the average document, with your totals attached.

Postscript (July 18): The mixed-rate follow-up that the stamp article promised has now run, and its result reaches back into this article. On a sibling invoice where the tax is not a round 10% — so total ÷ 1.1 no longer equals the printed subtotal — the same @low variants return total ÷ 1.1 for the subtotal and total − total ÷ 1.1 for the tax, at every occlusion level, including zero. On that evidence, two of the four fields I counted as read above were most likely never read here either: they were derived from the total under a flat-10% assumption that this document's round tax rate made indistinguishable from reading. What a 5.6-generation @low reads on this invoice may be two things, not four — the title, and the total. The operational conclusion gets stronger, not weaker: the arithmetic doesn't reconcile because it was read. It reconciles because two of its three numbers were manufactured from the third. The harness and the recorded results are public at ldxhub-io/examples › analyzedoc/hanko-benchmark-v2. Full write-up to follow.

Method notes: this is the L0 (zero-occlusion) slice of the seal benchmark — 540 of its 3,240 jobs — read from the same scored output; twenty reads per model per field, criteria frozen in code before the run. The harnesses, ground truth, and run summaries are public at ldxhub-io/examples › analyzedoc/hanko-benchmark; the per-field analysis script behind this article ships in the same directory. Provider vision pipelines change — re-run before trusting any of this for anything current.

Two people who never bent — and what I learned from them

Hideki Mori — Mon, 03 Aug 2026 13:00:00 +0000

In an earlier piece I mentioned a CEO at one of my earlier companies who once looked at a service running on my desktop and asked whether I could make it public, right then — as it was, that afternoon. I half-dismissed him at the time. I said it was a story for another time.

This is that story. Though it turns out to be less about him than about what it does to a person to spend years in a room with two people who refused to bend.

He could not read the code. He never pretended otherwise. What he could do — what he did, every single time something started to work — was figure out where to go and sell it.

The company had grown out of a mobile-phone business that went into decline almost as quickly as it had risen. The next thing he reached for failed, and not quietly. Then one category started to move, and while it was still moving he was already gone, opening the next one alone. One of those eventually became the thing the company was known for. Another never took at all. He was rarely in the present tense.

For a long time I read that as restlessness. Later I understood it was the same engine that runs me — the one that cannot sit still once a thing works, that is already asking what comes next before the current thing has cooled. He had simply pointed it at selling instead of building. The salesperson version of the same engine.

He spent on the technical side without flinching when it counted. We started on MySQL, outgrew it, moved to Oracle Enterprise Edition, and later put the whole thing on Exadata — none of which he understood, all of which he approved, because the engineers told him it was what the next stage needed. He gave vendors a hard time when they earned it. I remember one storage system sold to us on the promise that it scaled: you simply added another unit when you needed more room. When the day came to add one, the exact model had been discontinued, and the replacement would not sit alongside what we already had. We ended up rebuilding the whole configuration. He was not gentle about that, and he was right not to be.

What he never had was the inside of the machine. What he always had was the one question that mattered to him: what is the thing here that no one else has? The structure that reshaped itself instead of being rebuilt. The numbers that were live instead of a day stale. The parts that did not fall over under load. He could not have written a line of it. But he always knew which part was the sentence you could sell, and he kept that sentence in his head, ready.

None of it was something he was born with. I watched it get made. It came out of the venture that failed and the stretch where money was tight enough that the company nearly went under. He was not, when I first met him, a person you would have called a hard worker. The shortage changed him. By the time it was behind us he had taught himself to find the one true selling point in anything — and that skill was scar tissue, the same as anyone's.

The CFO held his line just as hard, in a quieter register. He carried risk that a job title does not capture — the kind you take on with your own name attached, when the company you believe in is closer to the edge than anyone outside the room can see. The specifics are his, not mine, and they are not going on this page. But I watched him keep the numbers that should have kept us all awake off our desks, and carry them himself — the company's survival was never someone else's problem to solve. It was his, in a way that cost him personally.

Neither of them started from a name, or from the shape of a thing. The work came first; the name, if it ever arrived, arrived after the work had earned one. Each held himself to producing a result at the execution level, with his own hands, and when something fell short, no one in that room reached for someone to blame. Each had his own way of operating. The details evolved over the years, but neither ever bent the core of it. Whether the way was right or wrong, in the end, mattered less to them than that they believed in it — and in themselves, doing it their own way.

There was a stretch, when the money was tight, when the three of us each did the most our own role allowed and nothing less. That is when the company turned.

I was the third one in that room. The CTO. And what being there did to me was not hand me a method. It gave me permission to have my own — or, closer to the truth, it made clear that I had no choice but to build one.

It is still most of what I run on. That one person can be a complete unit of responsibility, not a fraction of one. That the next thing should already be in mind before the current one is finished — I caught that from the CEO directly. That the result is mine to deliver, and when it breaks, mine to answer for, with no one else in the sentence — I caught that from both of them. None of it arrived as advice. It arrived as two people, in front of me, every day, refusing to do it any other way.

Whether I belonged in that room — whether the two of them would have called the three of us a team — I don't know. I used to want to know. I've stopped needing to. That part is two-sided, and I only get to speak for mine.

My side is simple. I was there. I learned this. And I have been grateful for it for a long time, in a way that doesn't depend on the answer to the other question.

Built with Claude (Opus).

Earlier in this series:

Reading under the stamp

Hideki Mori — Tue, 28 Jul 2026 13:00:00 +0000

Here is the issuer name from a Japanese invoice, rendered at 300 dpi. A red company seal sits directly on top of it — the kind stamped on nearly every invoice in Japan. On the left, the seal is a normal vermilion impression: translucent, the way real 朱肉 ink sits on paper. On the right, the same seal at full opacity, covering the same characters.

Under the translucent seal, gpt-5.6-sol@high read the company name perfectly — the black ink survives underneath the red, and the model reads straight through it. Under the opaque seal, it read nothing. Same model, same characters, same position. The only variable is whether the ink underneath still exists.

That gap is the first of two findings. The second one is stranger, and it runs the other way.

What this measures

This is a companion to a benchmark I published recently, which degraded one Japanese invoice through seven scan resolutions to find where each vision model stops reading. That axis was blur. This one holds the document perfectly sharp and introduces the second stress factor Japanese paperwork routinely carries and no Western benchmark tests: occlusion by a seal.

One variable: how much of a target field's ink a stamp covers, from 0% (a control, the seal sitting just below the text) to 100% (fully buried), in six steps. Two things vary in a 2×2:

Opacity. A translucent seal (multiply blend, the black ink readable underneath) versus an opaque pad (the ink physically gone — the generator asserts, pixel by pixel, that nothing dark survives inside the target box).
Target. The issuer name, which has no arithmetic relationship to anything else on the page. And the subtotal, which by construction equals total − tax, with both of those left visible at every step.

The two splits ask two different questions. Opacity tests whether a model can see through red ink to the black underneath. Target tests whether it can rebuild a buried field from the ones around it. Finding 1 comes from the first axis; Finding 2, from the second.

The extraction prompt never mentions the stamp. Whether a model reads through it, leaves the field empty, or fills it some other way is the thing being measured — so instructing any of those behaviors would destroy the measurement. Everything runs against 27 model variants from the same catalog as the blur benchmark, five repetitions per cell, 3,240 jobs.

Finding 1: the chromatic channel

Human OCR pipelines have handled seals for decades with a red-channel drop — strip the vermilion, the black text underneath comes back. The translucent-versus-opaque split measures whether a vision model does the same thing implicitly.

The top-resolution variants do, almost universally. Under the translucent seal at full 100% coverage of the issuer name, @high variants read it correctly 60 out of 60 times; under the opaque seal at the same coverage, the same variants scored 0 out of 60. The red is not what stops them — the destruction of the ink underneath is. The effect holds across nearly every strong reader, with a chromatic advantage of 0.56 to 0.76.

One model inverts it. nova-2-lite posts a negative score: the translucent seal hurts it more than the opaque one — layered color confuses it worse than a field that is simply gone.

Finding 2: the readers go silent, the non-readers answer

Now the subtotal, under the opaque seal, deep in the ladder — 80% and 100% coverage, where the digits are physically destroyed. Any correct answer here was not read off the page. There is nothing left to read.

The Anthropic models score 0 out of 30 — three models, two coverage levels, five runs each. When the number disappears, they leave it blank.

The OpenAI and Azure @low variants score 80 out of 100. On a field whose pixels are gone, they return the correct value four times in five.

This is not a small effect at the margins. It is a clean inversion, and the ladder makes it visible: on the destroyed-subtotal panel, the models that can read the number go red — blank — at the bottom, while the models that can't stay white. The scariest OCR errors in this whole series aren't misreads. This one isn't even a read.

What's happening is arithmetic. The subtotal equals total − tax, and both of those are visible on the page at every step by construction. A model that has given up reading the buried cell can still reconstruct it from its neighbors. This is a cousin of a pattern I've written about before: when a model can't read a field, some models invent a value rather than leave it blank. There the invented number was pulled from a plausible prior; here it's computed from the visible neighbors. Either way the model answers with something other than what the document says. And here is the part that matters for anyone wiring this into an accounts-payable flow: a derived value is internally consistent by definition. It reconciles. Every validation check that asks "do subtotal, tax, and total add up?" passes — because the number was built to add up, not read. The one instrument that would catch it is the thing you were trying to avoid buying: a human who looks at the actual document.

Which arithmetic

Two routes could produce it — total − tax, or total ÷ 1.1 — and since the tax is exactly 10%, they give the same answer, so the value can't distinguish them. But the @low variants answered the tax field correctly 49 times out of 50 at zero occlusion: with tax visible and answered, subtraction is available directly and division is redundant. The materials for total − tax were in hand. That is as far as the evidence goes — I can say the materials were present, not that I watched them used.

What doesn't generalize, and one honest gap

Two cautions, because this series lives on stating them.

The route conclusion above holds only because the tax here is a round 10%, which collapses two arithmetic paths into one answer. A future version with a mixed tax rate would make total − tax and total ÷ 1.1 produce different numbers, fingerprinting the route in the output itself. That's the clean way to settle it, and this run can't.

And the seal text. The stamp reads 検収済印 — an inspection stamp applied by the receiving company, chosen precisely because it carries zero issuer information. claude-fable-5 reads it correctly 94% of the time, including the traditional right-to-left column order, while most models ignore it as decoration. But 検収済印 is a common, real phrase, so a model reading it can't be separated from a model recognizing it from training. Whether that number reflects reading or memory is genuinely unresolved. A future version needs a fictional seal phrase — the same lesson the blur benchmark taught about fictional ground truth, applied to the stamp.

The picture across all four panels

Put the two findings together. A translucent seal is not much of an obstacle to a strong reader — the black ink is right there under the red. An opaque seal destroys the field, and what a model does next sorts it into a type. The strongest readers in the benchmark fall silent. A specific class of weak readers quietly computes the answer from the fields around it, and hands it back with no indication that it was never seen.

The blur benchmark had readers who invent and readers who go blank. This one adds a third: the deriver, who answers a question you didn't ask — what should this number be, given the others — in place of the one you did: what does the document say. And because the derived answer reconciles, it is the hardest of the three to catch.

The companion to this finding is The model corrected reality — a case where a model read a field perfectly and overruled it. Both are about answers that survive every plausibility check.

Method notes: 3,240 analysis jobs against a synthetic invoice (all names fictional), five repetitions per cell, run July 2026 via my document-processing gateway. The stamp compositing, the pixel-level occlusion checks, the scorer, and the recorded runs are public: ldxhub-io/examples › analyzedoc/hanko-benchmark. Every figure in this article is reproducible from the scored output.

Three failures I still think about

Hideki Mori — Mon, 27 Jul 2026 13:00:00 +0000

People sometimes ask where the discipline comes from — the three-line rule, the habit of trusting nothing except my own running code, the assumption that production will surprise me. None of it is theory. Each piece came from a specific failure that reached real users and made me change how I work, permanently. Here are three I still think about. All three, I noticed later, are things I didn't do.

1. The collation I didn't know about

This was early. I was working on a content platform for Japanese feature phones — an official carrier service, the kind where charges land on your phone bill and the carrier has to approve you. User IDs were case-sensitive by spec. userA and usera were two different accounts.

The database was MySQL. The user lookup was a WHERE on a varchar column.

What I didn't know — what I didn't know was even a concept — was that the default collation made that comparison case-insensitive. WHERE id = 'userA' matched usera too. I had never set the column to a binary collation.

It ran fine for a long time. Then a user wrote in: points were missing from their account, and they had no memory of spending them.

I still remember the moment I understood it. Two accounts whose IDs differed only in case were colliding in the lookup. One person's spending was drawing down the other's balance. It had been happening quietly, to whoever shared a case-collision with someone active.

A few hundred users were affected before I found it. It remains the largest single mistake I have ever shipped.

The fix was one line of column configuration. The lesson was not about that line. The lesson was that I had built on top of a default I had never examined — and the default did not match the spec I was supposed to implement. After that, I stopped assuming I knew how a tool behaved. I check, especially the defaults, because the default is the part you never chose, and therefore never thought about.

2. The connection I forgot to release

A few years in. We were seeing access patterns that looked like abuse, and I wrote a process to catch them — flag suspicious source IPs, periodically push them into a blacklist. It was a small, defensive piece of code. I wrote it quickly and shipped it, because the abuse was happening now.

The logic was fine. Each time the process judged a request as suspicious, it opened a database connection, recorded the IP, and moved on.

It opened a connection. It did not always close one.

I had left the connection release out of the finally block. The pool didn't drain all at once — each flagged request leaked a single connection, so nothing broke at release time. The service ran normally while connections quietly disappeared in the background, one at a time. The more abuse we saw, the more connections we lost.

When it finally went down, the diagnosis was immediate. Something that had been working stopped working right after a release — there is only ever a short list of suspects, and I found the missing finally quickly. That part was not hard.

The painful part was the gap before it. Because the drain was slow, the outage didn't arrive until well after the release, by which point cause and symptom were separated in time. And I had believed I was watching the service. I wasn't — not in a way that would catch a gradual leak. The monitoring I thought I had was not the monitoring I actually had.

That is the part I still think about. The code I wrote to defend the service was the code that took it down — and the watch I thought I was keeping never saw it coming.

The fix was a finally block. The lessons were two. First: cleanup is not a step you add once the logic works — it is part of the code. Something that acquires a resource without guaranteeing its release in the same breath is not finished; it only looks finished, until the one path you didn't cover is the path that runs most. Second, quieter and slower to sink in: a gradual failure is more dangerous than a sudden one, because it separates cause from effect — and the monitoring you assume is protecting you may not be looking at the thing that matters.

3. The release note I didn't read

This one is recent — recent enough that I am slightly embarrassed it still caught me, this far in.

We relied on a third-party library for a core piece of what we produced. A new major version came out — a clean major-version bump, the kind you apply without much ceremony. I updated it, ran the unit tests, they passed, and I released.

Then a user wrote in: the output was coming out blank. Not an error, not a crash — a valid, empty result. The kind of failure that passes every automated check except the only one that counts, which is a person opening the file and seeing nothing there.

I had a guess immediately, and the release notes confirmed it within a minute. The new major version had changed an assumption the old one had quietly tolerated — about how the input and the output were allowed to overlap. My code had leaned on the old, lenient behavior for years. The unit tests passed because they exercised the shape of my code, not the behavior of the dependency against real data.

The fix was small. What changed permanently was how I treat that dependency — and every dependency like it.

I read release notes now, especially the section most people skip, the one labeled "breaking changes," because that is the version telling you in writing which of your assumptions it just invalidated. But reading is not trusting. A release note tells me what the maintainers chose to write down — not what they changed and didn't think worth a line. So I verify against the real service, every time. Not just on major versions: on minor bumps, on patch releases, on upgrades that have nothing to do with the part I care about. Especially the library that taught me this, which I now carry a permanent and slightly unfair suspicion of — the one I trust the least, and check the hardest.

It is an ungenerous way to treat a tool I depend on and need. But some libraries earn it, and the check costs me a few minutes while the alternative costs a user opening a blank file. So I run it and look at the real output myself, every time. Unit tests check the shape of my code. Only the real service tells me the truth.

What the three have in common

Three mistakes, spread across the years, with one shape in common: each carved a habit into me, and I have the habit because I have the wound. None of these is a principle I reasoned my way to. It is all scar tissue.

But there is one more thing, and it is the one that still makes me feel like a beginner after twenty-four years. I almost left it out, because it is the least flattering.

Every time something breaks — every single time — there is a flicker, less than a second long, where some part of me thinks: maybe this one isn't my fault. Maybe it's the library, the user, the infrastructure. And then, just as fast, I know better. It is almost always my fault, and I turn to the only useful question — what did I do? — but the flicker was there first. It is always there first.

Twenty-four years has not removed it. I know, completely, that when my code is involved and something is wrong, the suspect is me. And still the instinct to look away fires before anything else, and has to be overridden every time.

I have stopped expecting it to go away. It is probably just part of being the person who wrote the code — the small, animal reluctance to be the cause. What changed is not the instinct. It is the half-second. The override is faster now, that is all. Maybe that is what maturity is: not the absence of the flinch, but the speed of turning back toward the thing you would rather not look at.

That turn — toward your own code, toward the real output, toward the default you never checked — is where these three habits actually live.

Built with Claude (Opus).

Earlier in this series:

The model corrected reality

Hideki Mori — Tue, 21 Jul 2026 13:00:00 +0000

Here is the bank-transfer block from a Japanese invoice, rendered at 300 dpi. The fine print is 7.5 pt and every character is crisp. The bank is みずなら銀行 — a fictional institution I invented for a benchmark. It exists nowhere except in this document.

gemini-3.5-flash@high read this block five times. It answered みずほ銀行 — Japan's largest megabank — five times out of five.

It did not fail to read the document. It read it, and overruled it.

Where this came from

This is the strangest cell in the legibility map I published recently. That project degraded one Japanese invoice through seven simulated scan resolutions and ran 27 vision model variants down the ladder, to find where each one stops reading — and what it does after. An earlier article established the pattern everyone now expects: when a model can't read, some models invent.

This is different. This happened at the very top of the ladder, on a fully legible original. The trigger wasn't degradation.

An accidental controlled experiment

The benchmark's fine print held two fictional financial institutions, and — more by instinct than by plan — they differed in exactly one way.

The first, みずなら銀行, sits one character away from みずほ銀行, a real megabank. The second, ほしかげ信用金庫, is a small credit union with no real-world neighbor: nothing in the space of Japanese financial institutions sounds like it.

Same font size, same resolution, same prompt. The results:

At 300 dpi, @high read ほしかげ信用金庫 correctly in every run — while turning みずなら into みずほ in every run.
Across the three Gemini variants and the full ladder, the substitution happened 48 times: 25 on @low, 18 on @high, 5 on @medium.
When ほしかげ finally did break, deep in the blur, it drifted to はしかぜ信用金庫 and はしかわ信用金庫 — plausible-sounding institutions that do not exist. Across the entire run it was never once pulled to a real one.

The trigger is not legibility. It is the existence of a nearby real entity. Where a real neighbor exists, there is an attraction. Where none exists, the model reads what is on the page — or, at worst, invents something exactly as fictional as the truth.

Vision proposes, language disposes

I can't see inside these pipelines, so take this as the simplest explanation rather than a claim about architecture. These systems read with their language model as much as with their eyes. The visual evidence says みずなら; the language prior says みずほ is overwhelmingly more probable; and somewhere in decoding, probability wins — silently, with no flag, at settings you don't control. One character of visual evidence is not enough to outvote a name the model has seen millions of times.

Which is also why the credit union survived. There was no gravity well next to it.

It's a trait, not a law

claude-fable-5 read the same field on the same ladder and never substituted the real bank — not once, at any resolution, while reading the 7.5 pt tier correctly down to 50 dpi. Same input, same prompt, opposite disposition.

Prior capture is not a law of vision models. It is a measurable individual trait — which means you can select against it.

Why this is the scary one

The earlier fabrication article showed invented values that reconcile: totals that add up around a counterparty that was never there. This failure is worse in one specific way: the fabricated value is more plausible than the truth.

Run the human review in your head. A reviewer checking "does this bank look real?" passes みずほ銀行 without blinking — and would actually flag the true value as a typo. Every plausibility check you have, human or automated, is aligned with the error.

And notice what made it visible at all: the ground truth was fictional. Real invoices carry real banks, so in production this substitution produces output indistinguishable from a correct read. A benchmark built on real documents is structurally blind to prior capture. Unguessable, fictional ground truth isn't a convenience for scoring — it is the only instrument that detects this failure mode.

Concretely: never validate payment fields by plausibility. Validate against your counterparty master — the extracted bank either matches the registered account or a human looks at the page. And if fine print matters in your pipeline, benchmark for disposition, not just accuracy: a model's willingness to overrule the page matters as much as its eyesight.

Receipts

Everything is published in the benchmark repo — github.com/ldxhub-io/examples → analyzedoc/legibility-benchmark/: the deterministic material generator (the crops above are the actual benchmark materials), the raw outputs of all 4,158 jobs, and the scorer. The free-tier reproduction subset described in the map article includes @high, so you can watch the correction happen on your own API key without paying anything.

Disclosure, as before: I run LDX hub, the harness used here. It builds no models, and nothing in this post gets better or worse for me depending on which model wins.

The errors to fear are not the implausible ones — those get caught. The ones to fear are the corrections: answers improved in the direction of the world's expectations, away from what the page says. A model that corrects reality will pass every review that checks for plausibility. The only defense is knowing what the document really said — which is exactly the thing you were asking the model to tell you.

I survived 24 years because I'm lazy

Hideki Mori — Mon, 20 Jul 2026 13:00:00 +0000

I've shipped code for 24 years. Same job, mostly the same stack, mostly alone.

People assume that takes discipline. It doesn't.

The truth is simpler and less flattering: I'm lazy.

Not Larry Wall's "automate the boring stuff" lazy. Regular lazy. I avoid hassle. I skip work I don't want to do. I work around things that feel like chores.

Twenty four years happened because I built around that. The first thing I built around was deadlines.

Don't set my deadlines

I don't want to accept deadlines from other people.

Not because I'm undisciplined. The opposite. Once I'm inside a problem, I stay there until it ships. Interrupting the flow costs me more energy than continuing. That part isn't the issue.

The issue is that nobody outside my head can predict when "done" is. They don't know what's easy for me and what's hard. They guess. Then they tell me their guess as if it were a fact.

It grinds on me. Every project where someone tried to schedule me, I ended up resenting the scheduler more than the work itself.

The answer is always: "I'll ship it when I can. And yes, I'm working flat out."

Most of the time, "when I can" is the next business day. There's not much point setting a deadline for that.

What "when I can" actually looks like is the rest of this article.

What a lazy survivor actually does

Here's the daily shape of it. Some of these will sound like discipline. They aren't. They're what laziness produces when you've been at it long enough.

I don't stop until it's done. This is where "lazy" gets confusing. When I'm in a problem, stopping is more work than continuing. I sleep and eat enough to not fall over. The work isn't the chore. Pulling myself out of it and back into it is the chore.
I write the spec by being my own user. Nobody knows what's easy to use and what's consistent better than the person stress-testing it. That's me.
The 3-line discipline. (See 010.) By the time the code is written, it's already been tested.
After release, I watch the logs. Access logs, batch logs, error logs — I keep them tailed. A weird line scrolls past and something catches. The alerts haven't fired. I already know.
I redeploy as many times a day as I need to. The first release barely matters. What matters is the 10, 15, 20 years of changes that come after. The earlier you ship, the longer that window is.
I throw real data at my own software, hard. Big data, malformed data, weird-shaped data. The only confidence I trust is the kind that survives that.
When an internal user overloads my system, I thank them. Live data is a gift. I have never had the opposite feeling about a real-world failure.
A bug found before anyone else sees it isn't a bug. It's just an edit.
If there's an update worth making, the next day is too late. GPT-5.5 ships → I verify it on my app today, ship it as a selectable option today. I don't want to be the one lagging behind.
Batch processing is what I love most. Shaving milliseconds. Cutting load. Watching batch logs scroll. Every part of it is a reward. I'm always hoping more batch jobs come in from users.

And one more — the most important one, the one 24 years actually paid for:

Discomfort means something is wrong. Always. When something feels off, I hunt it down and crush it. The hunch isn't mystical — it's 24 years of pattern recognition without a vocabulary, and it hasn't been wrong yet. The part of me that wants to look past it has always paid for it later.

Where being lazy actually hurts

Not all laziness is helpful. Some of it is just being a person who avoids reading.

I don't read manuals. My wife has a car with cruise control. I've driven it for years. I still don't know how to turn the cruise control on. Every time, I'm too lazy to figure it out, and I drive without it.

That instinct does real damage at work. I don't read API docs unless I have to. I don't read change logs carefully. I skim. I assume. I run code instead of finishing a manual.

English is the other one. I'm Japanese — my technical reading is fine, but the gap between "I can read this" and "I want to read this carefully" is wide, and laziness lives in that gap. Long English documentation is exactly the thing I will not voluntarily face.

For most of my 24 years, this cost me real time. I'd build something that worked, then discover three weeks later that the API I'd wrapped had a flag I'd missed because I never read past the example block.

The honest answer is that Claude reads for me now. I describe the problem, Claude reads the docs, Claude points me at the part I need to verify. It doesn't replace judgment. It removes the friction between me and information I was always going to avoid anyway.

I don't say that to praise AI. I say it because it's true for me, and it would be dishonest to write a piece about how I work in 2026 without saying it out loud.

The engine

If you re-read the list above, two things are doing the work. Both are unglamorous.

The first is the laziness. Each new component means ten years of maintenance I'll have to carry. Each new methodology means bugs I haven't learned yet. Each methodology argument is time not spent writing code. Each promised date is someone else's deadline I'll have to keep. I avoid all of it by default.

The second is profit. What I build has to make money. Not in some abstract sense — actual revenue from actual users. That part of me has no patience. If a service isn't paying for itself, something is wrong with it, and I want to know what. So I ship early, watch logs, redeploy whenever there's something to fix. Not out of discipline. Out of refusal to leave money on the table.

These two forces don't agree on much. Laziness says "don't bother." Profit says "if it makes money, bother." What's left after they negotiate is everything I actually do.

That's why "shipping continuously for 24 years" looks like discipline from the outside. It isn't. It's laziness pushed in a useful direction by the only thing that ever moved me — the need for the result to actually pay.

A CEO at one of my earlier companies once asked me: "That service running on your desktop — can you make it public right now?" I half-dismissed him at the time. Years later I understood he was the salesperson version of the same engine. That's a story for another time.

Other solos

There are other people doing what I do. Solo. Operating something they built years ago that's still running.

I assume — based on no evidence except how this kind of work shapes a person — that no two of us work the same way. Each of us has wrapped a different cocoon around a different temperament. What I do would be unworkable for them. What they do would be unworkable for me.

I respect that more than I can put into words. Solo developers who keep their own systems running for years are doing a job that doesn't show up in any career framework I've seen. Most of them never write about it because writing is also work.

Whatever way you do it — keep going. I see you.

What survived

People who watch me work sometimes call it persistence. Conviction. The shape of a long arc.

It isn't.

I survived because every alternative was more work than continuing. I stayed lazy. I got paid. Together, those two facts ran the clock for 24 years and counting.

What looks like a disciplined career from the outside has always been, on the inside, the path of least resistance — provided someone was paying me at the end of it.

The lazy way is the only way I know.

Built with Claude (Opus).

Earlier in this series:

Where vision models stop reading — and start inventing

Hideki Mori — Wed, 15 Jul 2026 13:00:00 +0000

Earlier this week I published a strange finding: GPT's low-detail image mode doesn't misread documents it can't see — it invents them, fluently, with reconciling totals. That was one failure mode, in one model family, at one legibility level.

It left an uncomfortable question: where exactly does each model stop reading — and what does it do after that? Leave the field blank, or fabricate something plausible?

One result to hold onto while you scroll: a model that can no longer read a document can usually still tell what kind of document it is. That held across almost the entire board.

So I built a ladder.

Then I ran 27 vision model variants down it: 4,158 jobs, about $141 at list price, one afternoon. This post is the map.

The setup, in one paragraph

One Japanese invoice, rendered on a fixed 2480×3508 canvas (A4 at 300 dpi), then degraded through seven simulated scan resolutions: 300 → 150 → 100 → 70 → 50 → 35 → 25 dpi (L0–L6). Degradation is resampling only — no noise, no blur, no rotation — so legibility is the only variable. The invoice carries twelve fields across four font tiers: a 28 pt title, 16–14 pt "large" fields (total, invoice number), 10.5 pt body fields (counterparty, dates, amounts), and 7.5 pt fine print (bank details). Every value is fictional and unguessable, and subtotal + tax = total reconciles — so a plausible but wrong answer is detectable, not just a wrong one. Each variant reads each ladder step five times. The extraction prompt is deliberately neutral: it never says what to do with unreadable text, because that choice is the thing being measured.

Scoring is deterministic, four classes per field: correct / near (edit distance 1, strings only) / blank / fabricated.

The map

Rows are model variants, columns are ladder steps, color is the fabrication rate on the 10.5 pt body tier — the tier where invoice counterparties and amounts live. White means the model either read correctly or stayed silent. Red means it filled unreadable fields with invented values.

The companion table below gives each variant's frontier: the deepest ladder step where it still keeps ≥90% field accuracy, per tier (× = below 90% already at the crisp 300 dpi original).

model	title	large	body	fine	body fab @25dpi	classified correctly
`openai/gpt-5.6-sol@high`	L6	L5	L5	L2	60%	84/84
`openai/gpt-5.6-sol@low`	L6	×	×	×	64%	84/84
`openai/gpt-5.6-terra@high`	L6	L5	L4	L3	4%	84/84
`openai/gpt-5.6-terra@low`	L6	×	×	×	42%	84/84
`openai/gpt-5.6-luna@high`	L6	L5	L4	L2	96%	84/84
`openai/gpt-5.6-luna@low`	L6	×	×	×	80%	81/84
`openai/gpt-5.5@high`	L6	L5	L4	L2	86%	84/84
`openai/gpt-5.5@low`	L6	×	×	×	62%	84/84
`openai/gpt-5.4@high`	L6	L5	L4	L2	46%	84/84
`openai/gpt-5.4-mini@high`	L6	L5	L4	L0	78%	84/84
`azure/gpt-5.6-sol@high`	L6	L5	L5	L0	90%	84/84
`azure/gpt-5.6-sol@low`	L6	×	×	×	76%	84/84
`azure/gpt-5.6-terra@high`	L6	L5	L4	×	56%	84/84
`azure/gpt-5.6-terra@low`	L6	×	×	×	50%	84/84
`azure/gpt-5.6-luna@high`	L6	L5	L4	×	98%	84/84
`azure/gpt-5.6-luna@low`	L6	×	×	×	80%	84/84
`azure/gpt-5.4@high`	L6	L5	L4	×	98%	84/84
`azure/gpt-5.4@low`	L6	L5	×	×	58%	84/84
`azure/gpt-5.4-mini@high`	L6	L5	L4	×	88%	84/84
`azure/gpt-5.4-mini@low`	L6	L5	×	×	54%	84/84
`google/gemini-3.5-flash@high`	L6	L6	L6	×	10%	84/84
`google/gemini-3.5-flash@medium`	L6	L6	L6	L5	10%	84/84
`google/gemini-3.5-flash@low`	L6	L6	L6	L0	0%	84/84
`anthropic/claude-fable-5`	L6	L6	L6	L4	10%	84/84
`anthropic/claude-sonnet-5`	L6	L6	L5	L4	26%	84/84
`anthropic/claude-opus-4-8`	L6	L6	L5	L4	26%	84/84
`bedrock/global.amazon.nova-2-lite-v1:0`	×	L5	×	×	80%	63/84

The biggest surprise in this table isn't where the frontiers sit. It's what happens past them — some models go silent, and some keep talking.

Six observations fell out of the map.

1. "@low" means different things per provider

google/gemini-3.5-flash@low — the second-cheapest variant on the board — read the body tier correctly at every step down to 25 dpi, with zero fabrications. Under exactly the same conditions, every OpenAI and Azure @low variant collapsed at L0, on the pristine original. Same suffix, opposite behavior. The difference isn't the models' eyesight; it's what each provider's low-detail pipeline does to the image before the model ever sees it.

2. For GPT `@low`, a worse scan is a better scan

The @low accuracy curves are not monotonic. Most GPT @low variants read a 70 dpi scan better than the 300 dpi original — body accuracy climbing from ~40% at L0 to 70–80% at L3–L4 before falling again. My resampling acts as an anti-alias filter for the provider's own aggressive downscale. The practical corollary is genuinely odd: if you are stuck with a @low pipeline, pre-blurring your documents can improve extraction.

3. After collapse, models split into fabricators and blankers

What a model does past its frontier is a personality trait, and it's measurable. At 25 dpi, most GPT @high variants fill 75–100% of the body fields they can no longer read with invented values. openai/gpt-5.6-terra@high is the outlier of the entire board: 96% of its failures are blanks. Anthropic and Google models fail less to begin with and fabricate less when they do (0–26%). If your pipeline feeds payment systems, a blanker that admits defeat is worth more than a stronger reader that bluffs.

4. Same model, different gateway, different eyes

gpt-5.6-sol@high reads the 7.5 pt fine tier at 100% down to 100 dpi when called via OpenAI — and starts at 92% and degrades immediately when the same model is called via Azure. The failure style shifts too: terra's blank rate drops from 96% (OpenAI) to 39% (Azure). This matches an earlier measurement suggesting the Azure pipeline applies a lower effective-resolution ceiling before the model ever sees the document. Your gateway choice is silently part of your model choice.

5. Fabrication doesn't need degradation (teaser)

One fine-print field held a fictional bank whose name is one character away from a real megabank. At 300 dpi — fully legible, five out of five runs — some models "corrected" it to the real one. 48 substitutions across Gemini variants, while a fictional credit union with no real-world neighbor was read perfectly under the same conditions. The trigger isn't legibility; it's the existence of a nearby real entity. This one deserves its own write-up, with the receipts: The model corrected reality.

6. Classification survives reading loss

25 of 27 variants classified all 84 documents (invoice / receipt / business card / meeting minutes) correctly at every degradation step — including variants whose extraction had collapsed completely. A model that cannot read a document can still tell what kind of document it is. The two exceptions are instructive: the cheapest model on the board confuses receipts with invoices (21 out of 21 times — consistently, not randomly), and one @low variant dropped three classifications at the bottom of the ladder.

What I'd take into production

Route by tier, not by document. Titles survive almost anything; fine print dies first. If a field matters, measure the frontier of the tier it lives in.
Pick blankers for payment fields. A fabricated bank name passes every visual plausibility check. Prefer models that return "" over models that return something convincing.
Don't assume @low is one thing. Benchmark the variant you'll actually call, on the gateway you'll actually use.

Reproduce it (a free key is enough)

Everything — the deterministic material generator, the runner, the scorer, the raw outputs of all 4,158 jobs — is published:

github.com/ldxhub-io/examples → analyzedoc/legibility-benchmark/

The materials are byte-identical on any platform (the generator downloads a pinned, checksum-verified font). A three-variant reproduction subset runs in 147 jobs ≈ 17,600 credits, which fits inside LDX hub's free tier (25,000 credits/month, no card):

python3 gen_materials.py
export LDXHUB_API_KEY=...   # free key: gw.portal.ldxhub.io
python3 run_benchmark.py --models ume --t1-instances A --t1-reps 3 --t2-reps 1 --yes
python3 score_results.py && python3 report.py

Because raw model outputs ship with the results, you can disagree with my scoring rules and re-score everything without re-running a single job.

Full disclosure: I run LDX hub. It builds no models — it's the harness here, not a subject. One API key across OpenAI, Azure, Google, Anthropic and AWS is the only reason a 27-variant matrix fits in one afternoon, and that convenience is exactly what I'm selling. The measurements stand on the published raw data either way.

Caveats

Degradation is synthetic resampling, not real scanner noise — claims are limited to simulated legibility. One document type, one language (Japanese; if anything, a harder test than Latin script). The strict scorer counts character-level misreadings as fabrications, which flatters nobody. Results are a July 2026 snapshot; the ladder re-runs on every model addition, so the map will stay current.

The next time a provider ships a new vision model, it gets a row within a day. That's the point of building a ladder instead of writing a review.

When AI can't read, it invents — but it still sees the shape

Hideki Mori — Tue, 14 Jul 2026 13:00:00 +0000

I ran 110 vision-extraction jobs against a synthetic invoice. The low-resolution modes of the newest models never once returned the correct document — and the way they failed is worse than random noise.

All measurements in this post are as of July 10, 2026. Vision pipelines change; if you're reading this later, re-run the test before trusting the numbers.

The invoice that would have passed review

Here is a fragment of what GPT-5.6 (Sol, low-detail image mode) returned when I asked it to extract a synthetic invoice from a PNG:

{
  "vendor": "K Northwind Trading Ltd",
  "bill_to": "Accora Manufacturing Inc.",
  "invoice_number": "INV-2025-0731",
  "date": "2025-07-31",
  "subtotal": 757.5,
  "tax": 75.75,
  "total": 833.25
}

Every number is correct. Subtotal, tax, total, all four line-item amounts, all quantities, all unit prices — perfect, down to the cents. The vendor is right too.

The bill-to company does not exist. The real document says Aozora Manufacturing Inc.; the model wrote Accora (and, on other runs, Alcora). The invoice number is wrong in one systematic way: the year. The document says INV-2026-0731; the model wrote INV-2025-0731 — and then, consistently, dated the invoice 2025-07-31 to match. The two invented values agree with each other.

That last detail is the one that bothers me. A misreading scatters; over five runs you'd expect 2020, 2028, a garbled digit. This didn't scatter. Twenty out of twenty runs — five repeats, two image formats, two providers — said 2025, and the date field followed along. The model didn't fail to read the year — it composed a coherent document in which the year is 2025.

An extraction where the totals reconcile but the counterparty is fictional is precisely the kind of error that sails through an accounts-payable check. Nobody re-verifies the customer name when the arithmetic is clean.

The false positive that came first

Before I trust a finding like this, I have to tell you about the bug I almost blamed on the model — because it changed how I ran everything after.

My platform derives the output schema from an example_output the caller provides. My first test used example values like 10.0 and 22.0. Somewhere between my MCP client and the Java layer that infers the schema, JSON serialization collapsed 10.0 into 10 — an integer. The inferred schema said integer, and every model dutifully returned integer totals. 833.25 came back as 833, and in one configuration as 83325 — the decimal point simply gone.

For about an hour I had a tidy, wrong conclusion: "the new flagship's low mode corrupts decimals." Then I asked the question I should have asked first — did the example even survive the JSON round-trip? — and the whole finding evaporated. With examples like 12.34, every model produced clean decimals.

Lesson one, before any lesson about models: when output looks corrupted, suspect your test harness before the model. X.0 is not a safe way to say "this field is a float" in any pipeline that round-trips JSON.

That embarrassment is why everything below is n=5, scripted, with the pass/fail criteria frozen in code before the runs started.

The numbers

The setup: one synthetic invoice (all names fictional), rendered to JPEG and PNG. Ground truth: vendor K Northwind Trading Ltd., bill-to Aozora Manufacturing Inc., invoice number INV-2026-0731, total 833.25. A result counts as OK only if all four fields match. Eleven model configurations, two formats, five runs each — 110 jobs through my document-analysis API, which maps an @low / @high variant onto each provider's image-detail setting.

The low-detail modes of the GPT-5.5 and GPT-5.6 generations (Sol, Terra, Luna; direct and Azure-hosted): zero correct extractions in 70 attempts. Not "low accuracy" — zero. The failures were the kind shown above: arithmetic intact, identities invented.

The controls, same images, same five repeats:

Configuration	Result
GPT-5.5 / GPT-5.6 family, low detail (7 configs)	0 / 70 correct
GPT-5.4 (Azure), low detail	18 / 20 correct; 2 near-misses (a dropped space: "KNorthwind")
GPT-5.4 mini (Azure), low detail	10 / 10 correct
Gemini 3.5 Flash, low detail	10 / 10 correct
GPT-5.6 Sol, high detail	10 / 10 correct

An earlier run of the same protocol used a version of the invoice with smaller, lighter text. Same models, same 0-for-70 — but there the failures were total: complete fictional invoices, different every time. A vendor called Kramerwick Ltd. with a Brussels address. KittenPaws, LLC on Meowth Street. A Japanese company name the document never contained. Line items for services that don't appear anywhere in the image.

So the failure mode is not binary; it slides with legibility. Illegible source → the model invents the whole document. Partially legible source → the model reads what it can (the big bold totals) and invents the rest (the small print), stitching both into one internally consistent answer. The second mode is the dangerous one. A wholesale fabrication looks wrong at a glance. A half-real document does not.

The generational irony

Look at that table again. The token budgets are essentially identical: measured directly against the provider APIs (my gateway meters pages, not tokens), the OpenAI-family low mode spends about 315 tokens per image of this size; Gemini's low setting spends about 258. Gemini reads the invoice perfectly on the smaller budget. And GPT-5.4 — the older generation, same 315 tokens, same hosting path — gets it right, with failures that look like classic OCR noise: a dropped space, a mangled character. It degrades the way you'd expect a reader to degrade.

The 5.5 and 5.6 generations do something different with the same pixels. Where 5.4 returns less, they return other. My best reading — and I'll flag it as interpretation, not measurement — is that the newer generations are stronger generators, and when perception runs out, generation fills the gap with whatever is most plausible. "Aozora" becomes "Alcora": right silhouette, right length, wrong word. 2026 becomes 2025, and the date agrees, because a coherent story beats a faithful blank.

Newer model, better prose, worse witness.

The reversal

At this point the obvious move is to kill the low-detail image modes entirely. I almost did. Then I ran the opposite experiment: instead of asking the same models to read documents, I asked them to sort them.

Round one: five synthetic documents with distinct layouts — invoice, receipt, business card, contract, blank page. Nine configurations (the seven "guilty" low modes plus two controls), three runs each: 135 / 135 correct, including refusing to force the blank page into a category.

Round two was designed to be unfair. Three Japanese business documents — 請求書 (invoice), 御見積書 (quotation), 注文書 (purchase order) — with identical layouts, identical tables, identical amounts, identical document numbers. The only difference is the title and one label line. You cannot sort these by shape; you must read the title. I then degraded them: photocopier noise, a 2° tilt, JPEG quality 25. Nine configurations, seven materials, three runs: 189 / 189 correct.

Same models. Same low-detail budget. 0-for-70 at reading the fine print; 324-for-324 at reading the headline and the shape.

The capability boundary is suddenly crisp: at ~300 tokens per page, these models see the title tier of a document reliably and the body tier not at all — and where the body tier fails, the 5.5+ generations fill it with fiction.

What I did about it

Delisting was the wrong answer — the classification result is real, and a sorting gate that costs a tenth of a high-detail read is genuinely useful (mixed scan folder → cheap low-detail triage → route each type to the right extraction pipeline). Silence was also the wrong answer: my catalog said the low modes were for "clean, large-text documents," and my own test — a clean, large-text document — had just proven that description wrong.

So the fix was one sentence of honesty. Every affected variant in my catalog now reads:

Low-resolution mode for fast, economical PDF extraction and document classification; **text read from JPEG/PNG images is unreliable at this resolution.**

(PDFs are unaffected in my measurements — the OpenAI-family models read PDF input through its text layer, so image downscaling never touches it. That's also why this failure hid so well: every PDF test passed.)

The formats stay listed. The capability stays available. The sentence tells you what 110 jobs taught me: what it's for, and what it will quietly get wrong.

The rule I'm keeping

My pipeline runs on a rule I've kept for a long time: absorb failures with deliberate retries, and always return a result. But a retry only helps when the next attempt can go differently — a network hiccup, a rate limit. This failure is worse than the structural kind. A malformed schema at least announces itself; you can validate before you send. A fabricated bill-to announces nothing. The request succeeds. The JSON validates. The totals reconcile.

You cannot retry your way out of this, and you cannot fully predict it either. What you can do is measure where the boundary sits — n=5, criteria frozen, controls included — and then write the boundary down where your users choose models. Not in a postmortem. In the catalog, in the sentence they read before they click.

The models will keep getting better at writing. That is exactly why "I couldn't read this" increasingly comes back as fluent, internally consistent, confidently formatted text. The shape is real. The details may be fiction. Design — and document — accordingly.

Method notes: 110 extraction jobs + 324 classification jobs against synthetic documents (all names fictional), run July 10, 2026 via my document-processing gateway with per-provider low/high image-detail variants; token figures measured directly against provider APIs. Pass/fail criteria were fixed in the harness before execution. The generation and test scripts, plus the recorded runs, are public: ldxhub-io/examples › analyzedoc/low-detail-study.

The graph nobody is watching

Hideki Mori — Mon, 13 Jul 2026 13:00:00 +0000

If you ask me what part of the system I protect the most, the answer is the database.

I've been writing software alone for twenty-four years, and across every platform I've built, the rule has stayed the same: the web servers can take whatever you throw at them, the batches can be rebuilt, but the database has to stay idle on purpose. Not because I love idle databases, but because the day a database actually starts to struggle is a day with very few good options.

This article is about what "keep the database idle on purpose" actually means in practice, and about one particular kind of graph that, in my experience, almost nobody is watching.

The three layers and what each of them gets

I think of a production system as having three tiers, and each tier gets a different rule.

The web server tier can be horizontally scaled. If load grows, you add machines. If something is wrong, you take a machine out of the pool, and the others handle it. Failures here are visible immediately, and they're cheap to recover from.

The batch server tier can be scaled up or out depending on the work. A batch that's too slow can be split. A batch that crashes can be retried. End users don't see batch servers, so a stuck batch is a problem for me and not for them. Some headroom up here is fine.

The database tier is the one I treat completely differently. The database is not where you absorb load. The database is what you protect from load. The reason is simple: the other tiers can be rebuilt or re-scaled. The database is the irreplaceable record. If it slows down, everything slows down. If it falls over, you don't have many minutes before the rest of the stack notices.

So my rule for the database is: keep it idle. Not idle in the sense of "doing nothing." Idle in the sense of "running well below its capacity, at all times, so that any extra load it picks up has somewhere to go."

For more than a decade I ran a large appliance-grade database where I kept the load average below 1 at all times. Not as a target. As a fact. If the load average went up, that was the signal that something had changed in the application and I needed to find it before the database told me about it.

How I keep it idle

A few habits, repeated for decades.

Aggregate periodically, not on demand. When an application needs a daily total, a monthly summary, a yearly count, the wrong thing is to compute it at the moment of the request. The right thing is to compute it ahead of time, on a schedule, into a summary table the application can read from cheaply. If the summary needs to be refreshed every minute, that's fine — a per-minute aggregation against a well-indexed working set is a small, predictable cost. An on-demand aggregation against the full source table is a large, unpredictable cost, and it scales with data growth in a way you don't want.

Cut joins dynamically. When a query joins many tables but a particular filter condition makes some of those tables redundant, the query construction layer can skip them. The fewer tables in the join, the less work for the planner and the executor. This kind of work is invisible to the application engineer — it lives in the layer that builds the SQL — but it pays for itself many times over the lifetime of the system.

Refuse to optimize the optimization. Once, an infrastructure engineer suggested running an enterprise database optimization dashboard against my database, to surface query-level improvement candidates. The pitch was that with more compute and storage capacity, we could push queries to run much faster. I declined.

The headline reason was that the database wasn't there only to serve analytical queries — its primary job was to keep the user-facing OLTP layer responsive, which meant the spare capacity I was carrying was a buffer for user load, not a budget to be spent on faster reports. The secondary reason was that the optimization process itself would have consumed CPU on the database, and the database is the one place where extra processes are not free. The database I had built was already running below LA 1. There was nothing to optimize at that level. Adding optimization itself would only have added load.

These three habits are not clever. They don't require special tools. They require the willingness to put the database first in design decisions, every time, even when the application engineer's instinct is to do otherwise.

The graph nobody is watching

Here's the part of this that I think is genuinely under-discussed.

I've been looking lately at two production database graphs, from two different services I'm involved with. Both graphs cover the last several months. Both are showing the kind of metric — read-row-count from random access — that tracks how much physical work the database is being asked to do.

Service A's graph is bumpy. Most of the time it sits near zero. Several times a week, there's a spike — 100,000 reads, sometimes more, in a short burst. The spikes are predictable in shape: they happen when a dashboard somewhere runs an on-demand aggregation. The fix would be to move that aggregation off the live database and onto a summary table refreshed periodically, or onto a separate analytics store. The shape is alarming on a single graph, but the architecture explains it.

Service B's graph is the opposite, and that's what makes it the more dangerous of the two. It's not bumpy. It's a slow, steady upward slope. Several months ago the line sat around 12,000. Today it sits around 18,000. Usage is not growing — in fact, the user count for this service has been declining over the same window.

There's no spike to point at. There's no incident to investigate. There's no alert that has fired, because no threshold has been crossed. There's only a slope.

This is what I mean by "the graph nobody is watching." Spikes get attention. Sudden failures get attention. A gradual upward slope, on a metric most teams don't even look at, while usage is flat or declining — this gets no attention at all. And yet it is, in my reading, the more serious signal. Something inside the system is doing more physical work to serve a smaller number of users. The application has degraded silently, in a way the dashboard isn't designed to detect.

The hard part is that the only way to spot this is to look at the graph carefully, over a long enough window that the slope can become visible. A glance at last week's numbers tells you nothing. A glance at last month's numbers tells you very little. The kind of degradation I'm describing only resolves into a recognizable shape when you've been watching the same metric over an extended period — long enough that small monthly differences become a slope.

The asymmetry of upward slopes

Not every upward slope is dangerous. Disk usage climbs because logs accumulate — explainable, dismissable. Connection counts climb because a new client integration came online — explainable, dismissable. Some upward slopes have a story behind them, and the story is fine.

The dangerous upward slopes are the ones without a story. A database doing more work for fewer users has no story that's good. Either the data model has grown in a way the queries weren't designed for, or some piece of code is doing many more operations per request than it used to, or some background job has multiplied without anyone noticing. None of these have an alert attached. All of them are visible only as a slope on a graph that someone has to be looking at.

Twenty-four years of running databases has taught me that the alert thresholds are not the boundary between "fine" and "in trouble." The alert thresholds are the boundary between "I can keep ignoring this" and "I have to act now." There's a whole region below the threshold that contains all the early warnings, and you only see that region if you go looking for it.

Closing

The database is the one component in my stack that I won't let degrade. Everything else exists, in part, to keep the database from being asked to do too much. The web tier absorbs the user. The batch tier absorbs the work that doesn't have to be live. The aggregation layers absorb the queries that would otherwise hit the source tables. The dynamic-join construction absorbs the cost of joins that don't need to happen. All of this exists so that the database can stay below LA 1, all day, every day, for years at a time.

When I look at a system someone else built and the database is the part that surprises me, I read it as a sign that the surrounding layers haven't been doing their job. The database telling you it's tired is a late signal. The graph nobody is watching is an earlier one.

This is not what you should do. This is what twenty-four years has taught one specific person to do.

Built with Claude (Opus).

Earlier in this series:

The example is the schema: extracting Japanese qualified invoices to JSON

Hideki Mori — Tue, 07 Jul 2026 13:35:40 +0000

Japan's qualified invoice system requires every invoice to carry a registration number (a "T" followed by 13 digits) and a per-rate tax breakdown — 8% reduced rate for food, 10% standard, frequently mixed on the same document. That makes Japanese invoices a nice stress test for structured extraction: non-Latin text, full-width characters, honorific suffixes, kanji-formatted dates, and two tax rates whose arithmetic has to reconcile to the yen.

This post runs one through AnalyzeDoc (LDX hub) — PDF, JPEG, or PNG in, structured JSON out — and looks closely at what came back. The part worth your time isn't that it works. It's how the schema is defined, and what that definition quietly controls.

There is no JSON Schema. You hand the API an example of the output you want, and the example is compiled into the schema.

The document

A fictional qualified invoice, one page (sample PDF in the repo). Four line items: two food items at the 8% reduced rate (marked ※, as the law requires), two at 10%. Registration number, per-rate tax summary, bank details, a payment deadline. Total: ¥42,210.

The example is the schema

Instead of a schema file, you send example_output:

{
  "invoice_number": "INV-2025-0001",
  "issue_date": "2025-01-15",
  "due_date": "2025-02-28",
  "issuer_name": "株式会社サンプル",
  "registration_number": "T9876543210987",
  "issuer_phone": "03-9876-5432",
  "customer_name": "株式会社テスト商会",
  "line_items": [
    { "description": "サンプル品目A", "quantity": 5, "unit_price": 2000, "amount": 10000, "tax_rate": 10 }
  ],
  "tax_summary": [
    { "tax_rate": 10, "taxable_amount": 10000, "tax_amount": 1000 }
  ],
  "subtotal": 10000,
  "total_tax": 1000,
  "total": 11000,
  "bank_details": "サンプル銀行 本店 普通 0000000"
}

Three rules make this work, and the first one is the whole article:

Your example values are type declarations. Write 10000 and the field is inferred as an integer; write 1234.56 and it's a number. Japanese yen has no decimals, so integers are the semantically correct choice here — every amount in the output will be a clean integer your downstream systems can trust. For a USD invoice you'd do the opposite: always write the example amounts with decimals, or a $250.00 line item risks coming back as an integer type. The literals you type are the contract you get.

Arrays receive variability. tax_summary is an array because mixed rates are the entire point of a qualified invoice. One entry per rate — the schema absorbs the document's core complexity instead of fighting it.

Example values must differ from the document. If the example matches the invoice, you can't tell whether the model read the page or copied the example. Different numbers, different names, different dates.

The prompt carries rules, not fields

Field descriptions belong to the example. The prompt is only for rules the example can't express:

Extract the invoice data from this Japanese qualified invoice (適格請求書).
Rules:
- Dates in YYYY-MM-DD format.
- All monetary amounts as integers in JPY (no separators, no currency symbols).
- registration_number in "T + 13 digits" format.
- tax_rate as an integer percentage (8 or 10).
- tax_summary must contain one entry per tax rate on the invoice.
- Phone numbers must not start with "+".

The last rule is scar tissue: a +81-prefixed string dropped into Google Sheets gets parsed as a formula. Cheaper to kill it at the extraction boundary than to escape it everywhere downstream.

Running it

Four calls. No polling loop — ?wait parks the request server-side.

# 1. Upload → file_id
curl -s -X POST https://gw.ldxhub.io/files \
  -H "Authorization: Bearer $LDXHUB_API_KEY" \
  -F "file=@invoice-sample-ja.pdf"

# 2. Create the job
curl -s -X POST https://gw.ldxhub.io/analyzedoc/jobs \
  -H "Authorization: Bearer $LDXHUB_API_KEY" \
  -H "Content-Type: application/json" \
  -d @job.json

# 3. Wait for completion (server-side)
curl -s "https://gw.ldxhub.io/analyzedoc/jobs/$JOB_ID?wait=30" \
  -H "Authorization: Bearer $LDXHUB_API_KEY"

# 4. Fetch the result
curl -s "https://gw.ldxhub.io/files/$OUTPUT_FILE_ID/content" \
  -H "Authorization: Bearer $LDXHUB_API_KEY"

job.json is five fields: model, file_id, output_format, system_prompt, example_output. The model here is google/gemini-3.5-flash@high.

The result

Completed in 26 seconds:

{"invoice_number":"INV-2026-0157","issue_date":"2026-06-30","due_date":"2026-07-31","issuer_name":"株式会社グリーンリーフ食品","registration_number":"T1234567890123","issuer_phone":"03-1234-5678","customer_name":"サンプルマート株式会社","line_items":[{"description":"有機緑茶ギフトセット ※","quantity":2,"unit_price":3000,"amount":6000,"tax_rate":8},{"description":"国産純粋はちみつ 500g ※","quantity":10,"unit_price":1200,"amount":12000,"tax_rate":8},{"description":"陶器マグカップ（箱入）","quantity":24,"unit_price":800,"amount":19200,"tax_rate":10},{"description":"配送料","quantity":1,"unit_price":1500,"amount":1500,"tax_rate":10}],"tax_summary":[{"tax_rate":8,"taxable_amount":18000,"tax_amount":1440},{"tax_rate":10,"taxable_amount":20700,"tax_amount":2070}],"subtotal":38700,"total_tax":3510,"total":42210,"bank_details":"サンプル銀行 本店 普通 1234567 カ）グリーンリーフショクヒン"}

Verification: the four line amounts sum to 38,700 = subtotal. The 8% base (18,000) yields 1,440; the 10% base (20,700) yields 2,070; together 3,510 = total tax; 42,210 = total. All fifteen fields match the source. No transposed digits, no invented fields.

What the model understood

The arithmetic is table stakes. The details are where it gets interesting.

The honorific is gone. The invoice addresses the customer as 「サンプルマート株式会社　御中」. 御中 (onchū) is an honorific suffix appended to company names in correspondence — roughly "To the esteemed...". It is not part of the name, and customer_name came back without it. Nothing in the prompt asked for that.

The ※ marks stayed. Line descriptions preserve the reduced-rate marker verbatim (「有機緑茶ギフトセット ※」) while the meaning lives in tax_rate: 8. Text fidelity in one field, semantics in another — a separation of concerns that exists because the schema was designed to hold it.

Kanji-formatted dates normalized. 「2026年6月30日」 became 2026-06-30 off a single prompt line.

Every amount is an integer. Because the example said so. 6000, not 6000.0.

The footer disclaimer went nowhere. The sample PDF carries a "this is a sample" notice at the bottom. No schema field fits it, so it correctly appears in none.

Swap the model, keep the code

Changing one string — the model ID — switches the same request across OpenAI, Azure, Google, Anthropic, and Amazon models (15 at the time of writing). Clean, printed layouts run fine on fast, cheap models; degraded scans or handwriting can go to the heavyweight tier. The JSON shape doesn't change, because the schema compatibility is handled below the model line.

Cost

This page cost 285 credits (~$0.029). The free plan includes 25,000 credits — about 85 pages' worth of finding out whether your own invoices survive contact.

Try it

The quickstart is built to go from signup to a completed job in about 60 seconds:

The fastest evaluation is the one you run on your own documents.

How I removed the middleman, one phone call at a time

Hideki Mori — Mon, 06 Jul 2026 13:00:00 +0000

In the mid-2000s I worked on a content distribution platform that served over a hundred storefronts. Books, music, comics — different shops, the same underlying content, each store with its own branding.

Among those hundred-plus storefronts, several dozen were technically resold through a third party — a viewer-side company that operated its own delivery infrastructure on top of ours. Their architecture required us to push every file into per-storefront slots on their servers, before the end user could download anything. Hundreds of slots. Per file.

This article is about how those slots disappeared, and what I learned along the way.

How the layers got there

When the platform launched, we were not the dominant player. The market for digital content on Japanese mobile phones was already shaped by a few established companies, and one of them sat between us and several dozen of our storefronts. They had built a viewer client that the end user installed on their phone. They had built a delivery server that the viewer pulled from. They had a working business.

We came in as the catalog provider. The deal was simple in principle: their viewer, our content. To make their viewer work, we had to put files into the directory structure their delivery server expected — one directory per storefront, the same file copied into each.

For a small catalog, this was tolerable. For a growing catalog, it was wasteful. A single new title meant dozens of identical writes — same bytes, different paths — every time we published.

We were the latecomer. We didn't push back. We did the work their architecture required.

The phone call

One Friday afternoon I got a phone call from the lead engineer on their side.

"Could you reduce the frequency of your pushes? Our servers are having trouble keeping up."

The phrasing was polite, but the request was unusual. We had recently parallelized our delivery batches — moved from sequential pushes to concurrent ones — and the volume of writes had multiplied. We were doing what we should have been doing for our growing catalog. They were absorbing it on infrastructure that hadn't been designed for that rate.

I could have agreed. Reducing batch concurrency was a one-line config change on our side. It would have made their afternoon easier and our publishers' release schedules a little slower.

I didn't agree. I made a counter-proposal.

"What if we stopped pushing per-storefront entirely? Could your viewer fetch directly from us, with the storefront as a parameter, instead of from a pre-placed copy?"

There was a pause on the line. Not a hostile pause. The kind of pause an engineer makes when an idea reorganizes itself in their head.

"Let me think about that and get back to you," they said.

The two steps that followed

It would be neat to say they called back the next day and we shipped it. That's not what happened. The conversation that started on that phone call took roughly two years to finish, in two discrete steps. Neither of the steps was urgent. Each of them was treated, on both sides, as a quiet refactor.

Step one: stop the per-storefront duplication.

The first thing we agreed was that, even if the viewer still fetched through their infrastructure, the file did not need to be duplicated per storefront on disk. They modified their delivery server to look up a single canonical copy, with the storefront determined by a parameter on the URL. We changed our push so that each file was uploaded once, not duplicated per storefront.

Our delivery batch shrank by an order of magnitude. Their disk usage dropped accordingly. Nothing changed for the end user.

Step two: remove the dependency on their server entirely.

The second thing was larger. Since the file was already canonical on our side, there was no architectural reason for the data path to go through their infrastructure at all. They updated their viewer to fetch directly from our delivery infrastructure, using the parameters they had previously injected on their server side. They kept the catalog metadata and the user-account layer; everything else went away.

When the last storefront cut over, the middleman delivery server was no longer in the data path. They turned off the disks they had been running for us. We turned off the placement processing we had been running for them.

What I learned

It's tempting to read this as a story about how a smaller company outmaneuvered a larger one. That's not what happened. What happened was that I made a proposal in the middle of a routine operational complaint, and over two years both sides incrementally chose to remove a layer that had stopped earning its keep.

There are a few things I took from it.

A symptom request is an opportunity to ask about the cause. "Please reduce your push frequency" is a symptom request. The honest underlying question is "why are we doing this many writes at all?" Most operational complaints I've received over the years, in the moment, sounded like requests for symptom relief. Some of them turned out to be requests for an architectural conversation that nobody had explicitly opened yet.

When I get a symptom request now, I always try to surface the cause version of the same request, at least once, to see what happens. Sometimes nothing. Sometimes a two-year refactor.

Conviction has to come with the other party's interest. I was able to propose removing their delivery infrastructure because, by that point, our volume was material to them. A meaningful share of their viewer's traffic came from our catalog. Removing a layer that had stopped paying for itself was, for them, a saving — not a loss. Without that alignment, the same proposal would have been a polite no.

The conviction wasn't only mine. It was conviction plus a real shape of interests. Without the second, no amount of conviction moves a vendor's roadmap.

Latecomers can rearrange the layer cake. When we started, we accepted their architecture because they were the established party and we were not. Two years later, we redefined the architecture together. The thing that changed in between was not their willingness to change. It was our weight in the system. The latecomer can become the party who proposes the new shape, once the latecomer is no longer small.

I think a lot of the operational shapes that look fixed in a given industry are, in fact, shapes that nobody has been in a position to renegotiate. The middleman in our case wasn't there because anyone defended its existence. It was there because nobody yet had reason to ask whether it should be.

Twenty-four years later

I'm telling this story now because I keep finding myself doing variations of it. A vendor surfaces an operational complaint. I look at the complaint, and I find — sometimes — that the structure underneath the complaint is the actual subject of the conversation. The complaint is the symptom. The conversation is the door.

Not every complaint opens a door. Most of them are just complaints. But some of them are an invitation to ask whether the current shape is the right one, and a year or two later you find that the shape is no longer there.

This is not what you should do. This is what twenty-four years has taught one specific person to do.

Built with Claude (Opus).

Earlier in this series:

DEV Community: Hideki Mori

Translation was a special case all along

The part that was always there

The part that actually changed

The target stopped being a language

Where the two meet

Two things keep it honest

The actual lesson

The cheap tier doesn't go blank — it writes

The control column

What @low reads: gates, not dials

What fills the other nine fields

The cell that lied by being right

Blank or fiction

Two people who never bent — and what I learned from them

Reading under the stamp

What this measures

Finding 1: the chromatic channel

Finding 2: the readers go silent, the non-readers answer

Which arithmetic

What doesn't generalize, and one honest gap

The picture across all four panels

Three failures I still think about

1. The collation I didn't know about

2. The connection I forgot to release

3. The release note I didn't read

What the three have in common

The model corrected reality

Where this came from

An accidental controlled experiment

Vision proposes, language disposes

It's a trait, not a law

Why this is the scary one

Receipts

I survived 24 years because I'm lazy

Don't set my deadlines

What a lazy survivor actually does

Where being lazy actually hurts

The engine

Other solos

What survived

Where vision models stop reading — and start inventing

The setup, in one paragraph

The map

1. "@low" means different things per provider

2. For GPT @low, a worse scan is a better scan

3. After collapse, models split into fabricators and blankers

4. Same model, different gateway, different eyes

5. Fabrication doesn't need degradation (teaser)

6. Classification survives reading loss

What I'd take into production

Reproduce it (a free key is enough)

Caveats

When AI can't read, it invents — but it still sees the shape

The invoice that would have passed review

The false positive that came first

The numbers

The generational irony

The reversal

What I did about it

The rule I'm keeping

The graph nobody is watching

The three layers and what each of them gets

How I keep it idle

The graph nobody is watching

The asymmetry of upward slopes

Closing

The example is the schema: extracting Japanese qualified invoices to JSON

The document

The example is the schema

The prompt carries rules, not fields

Running it

The result

What the model understood

Swap the model, keep the code

Cost

Try it

How I removed the middleman, one phone call at a time

How the layers got there

The phone call

2. For GPT `@low`, a worse scan is a better scan