We wrote the specification for a format that does not have one

BTLx is a published standard. You can read it, validate against it, and argue with somebody about what a clause means. We do all three, and every file Kerf writes is checked against the official schema before it leaves.

BVX is not that. It is what a Hundegger machine actually reads, it is in production in workshops all over Europe, and there is no document. You cannot buy one and there is nobody to ask.

What you do instead

You get files. Real ones, from real jobs, written by the software that already works. Then you read them the way you would read a language with no grammar book: find the parts that repeat, change one thing in the workshop, cut again, see what moved in the bytes.

We ended up with twelve production files, 879 parts and somewhere around 9,100 operations. That corpus is not a nice-to-have. It is the specification.

A format you inferred is only as good as the day you last checked it.

Why it stays in the build

Every release runs against all twelve files and every operation in them. If a byte moves that we did not mean to move, the build fails before anybody sees it.

That is slower than shipping and it is the entire reason a carpenter can drag an angle on screen and trust the saw. The alternative is a beam cut to a geometry nobody drew, discovered by the person holding it.

What we are still missing

Plenty. The corpus is twelve files from a narrow slice of the work, so there are operations we have never seen and will get wrong the first time we meet them. That is what the trials are for, and it is why Kerf says in trials on every page instead of something more comfortable.

If you run a Hundegger and you have files you would let us read, that is the most useful thing anyone can send us right now.