Build log

Everything before this had been run against documents I made up. That is a comfortable way to test software and it proves almost nothing. So I pulled a real one: a public project manual for a school-district HVAC replacement, 333 pages, issued for bid.

It read the full mechanical division — all eight Division 23 technical sections, 49 pages of specification — in 75 seconds, entirely on the box. Then I took every passage it had quoted and went back to the source to see whether those words were actually there.

Twelve of twelve, verbatim. Every paragraph number it cited was real. That is the load-bearing claim of this whole product and it held on first contact with a document I did not write.

It surfaced six candidate conflicts and then argued itself out of all six. Every one is exactly the false positive a keyword matcher would have dropped on a coordinator's desk: dielectric unions rated 250 psig against flexible connectors rated 125 — different components, not a contradiction. Duct insulation at 1-1/2" concealed against 1" exposed — separated by scope. Duct liner against external wrap — different assemblies entirely.

The sixth is the one I keep thinking about. Two sections both call for 5,000 psi grout, and one of them writes it psig. It declined to call that a conflict and flagged it as the spec writer's typo instead, on the grounds that compressive strength is not a gauge pressure.

Nothing was found because nothing was there. But six times it declined to waste my afternoon, and once it caught something the spec writer missed. Precision is the thing every checking tool I have been sold got wrong — an unread clash report is just a different way of missing the conflict.

What I can say is that it reads a real bid package and cites it honestly. Whether it reliably catches a conflict is a different claim, and it needs a set where one actually exists before I will make it.

The schema that couldn't say "fine." The first attempt failed, and the reason was mine, not the model's. I had asked for a list of findings with no way to record a negative. So when it correctly concluded that a pair of clauses did not conflict, it had nowhere to put that conclusion except the findings list — and filed it as a finding anyway. Then it looped, re-titling the same entry "(Final Check)", "(Final Final Check)", until it hit the token ceiling. Its judgment was right the entire time; my output contract was wrong. Any schema like this needs a legitimate place to say I checked this and it's fine.

A false alarm worth recording. My verification script initially reported one quote as a hallucination. It wasn't. The PDF text layer had split 10-feet across a line break, and my whitespace handling turned that into a mismatch. Strip everything before you accuse a model of making something up.

The assistant running on the box had developed a stall. Long pauses, no output, then eventually a normal answer. I diagnosed it three times and was wrong three times — I blamed the time it takes to read a long prompt, then the memory store, then the hardware.

The actual cause: one particular model simply never stopped generating when handed a certain class of prompt. Individual calls were running twenty-nine to thirty-nine minutes before anything gave up. It was not slow. It was not finishing.

I am writing this one down because the first three explanations were all plausible, all consistent with the symptom, and all wrong. The thing that broke the tie was timing the individual calls instead of theorizing about the pipeline.

There is a version of this product that ships with the second explanation baked in as a permanent workaround, and nobody ever finds out the real cause. Measuring is cheaper than being clever.

I ran the thing end to end for the first time: hand it a PDF of building inputs, have it pull out the envelope details, calculate a heating load. Ninety-two seconds, start to finish. Every figure it produced was arithmetically correct.

And the method was wrong. It used gross wall area instead of net — it never subtracted the window openings, so it counted that glass twice, once as wall and once as window. On the room I tested it was a small error. On an elevation that is mostly glazing, it would not be.

This is the reason the calculation engine is built the way it is: the model reads the document, and vetted code does the math. A language model is superb at finding "R-21" buried in a general note and useless as an authority on which areas belong in which term. Those are different jobs and they stay separate.

The same shape of mistake shows up again in Entry 005 — a model reasoning correctly and then being let down by the structure it was asked to answer in. Both times the fix was in my design, not in the model.

I had been treating the box as full. It wasn't. Every limit I ran into turned out to be an assumption in software rather than anything physical about the machine.

There were three walls and none of them were made of silicon. The first was a setting — the split between processor and graphics memory was configured in a way that fought the software instead of feeding it. The second was a bug in the runtime, not the machine: a different engine on identical hardware immediately saw 95 GB where the first saw 59, and two kernel parameters took that to 120. The third wasn't a memory limit at all — garbled output I had been blaming on the model was a formatting bug in how requests were being packaged. The model had been fine the whole time.

Not all of the speed belongs to those three walls, and it would be dishonest to imply it does. The memory headroom let me switch to a mixture-of-experts model rather than a dense one, and that architecture is simply faster on this hardware. The walls are what made the switch possible; the switch is what you see in the second row.

The practical result is that one model now handles text, tools and images together. Point it at a scanned drawing and it reads the drawing. That used to take two models competing for the same memory.

The ceiling moved because I could get underneath it. That is an argument for measuring rather than believing the first number you are given — not an argument about who owns the metal.

The appliance is a single Ryzen AI MAX+ 395 with 128 GB of unified memory — one pool, shared between the processor and the graphics engine, with the division between them set in firmware. Get that division wrong and you have bought memory you cannot use.

Left on its default setting, the firmware carved out 64 GB for graphics and left 62 GB as system memory, of which the runtime could address roughly 58.8 GB. Models loaded, the accelerator stack came up, and answers came back locally. It worked.

It also looked, at that point, like the hard limit of the hardware. Entry 002 is what happened when I stopped believing that.