Looking back, these past two weeks have been denser and more meaningful than all the time I spent building space ocr alone.

I asked six developers to build a demo with the space ocr API. What they brought back came straight out of the problems they deal with in their own work use cases I hadn't imagined. Getting to see that, and getting to talk with them about it, was probably the most valuable stretch of time in the whole life of this project.

It was a week of refactoring: one response shape across every surface, the structure behind it pulled into one place, and the bugs that turned up while I was in there.

The shape. /ocr/fields, /ocr/markdown and /ocr/text now return the same four keys. values is your data, exactly the schema you asked for and nothing else. cells is a flat map keyed by path, one entry per value, carrying box and quad (both always present, normalized 0 1000), verified, review, and the raw evidence behind that verdict. review is the summary: declared, returned, boxed, verified, flagged[], by_reason. image is the source size, for turning the normalized boxes back into pixels. Full shape with a worked example: https://space-ocr.com/docs#post-...

In my first update post I turned down a suggestion. Someone with nineteen years in banking software asked for control totals, checking that the numbers on a document add up, and I said no. Getting there meant giving fields types, then converting formats, then summing, then comparing, and I thought all four of those belonged to a layer above this one. I have now built the first two, and I want to explain what moved.

What moved was not the argument. It was hearing the same thing from people who had never read that thread.

Last week I ran space ocr against Mistral's Document AI, and the number that stayed with me afterwards was not the one in the headline.

The benchmark. Same document photos, same fields, same scorer, three runs each. Across 463 fields, space ocr came out at 91.1% field accuracy and Mistral at 70.0%, and the repeated runs were considerably more stable on my side. Full write-up with the individual cases and where the differences actually showed up: https://space-ocr.com/articles/s... and https://medium.com/@oisidonut/co...

My first launch is over, and I was more nervous going in than I expected to be.

The questions were sharper than I was ready for. Every one of them landed on something I did not have a comfortable answer to, and I answered anyway.

I launched space ocr here on August 4. This thread is where I will put what I am changing and why.

A commenter with nineteen years in banking software suggested control totals, checking that the numbers add up. I liked it immediately and put it at the top of my list, and then I kept turning it over for a few days and it started to bother me in a way I could not name at first.

What I eventually landed on is that it was pulling space ocr toward being a receipt and invoice product. Receipts and invoices are the example I have been leading with, but they are one use case sitting on top of the thing, not the thing. What the thing does is read characters from an image and verify them by comparison. Two independent passes read the same image, one from a language model and one from a vision engine, and a character level matcher compares them. Where they disagree, the field is flagged rather than resolved by quietly picking a winner. That is the whole of it.

Small one, and it is already live.

You can now mark a field as required in a schema. If a read finishes and that field comes back empty, or does not come back at all, the response records it in the review summary with the reason "missing", and in the sheet view the cell is drawn as an explicitly empty cell instead of just blank space.