Originally Posted: 14 September 2026
Testing the Work Before It’s Ready
There is a point in any build where you have to stop looking at what you intended to make and start looking at what you actually made.
That distinction matters.
When you're working with physical materials, you don't get much choice in the matter. Steel doesn't care what you meant the bracket to do. A weld either holds or it doesn't. A hinge either moves properly or it binds. If you've got two components that are supposed to line up and they're a few millimetres out, the physical world will find that problem for you.
Usually pretty quickly.
That's one of the things I like about fabrication. The feedback is honest.
Building Is Only Half the Job
When we started working on the first prototypes for The Hartful Company™, there was a temptation to focus on getting something that looked right. That's normal. You build something, step back, and think, That looks pretty good. But looking right isn't an engineering test. A prototype exists to answer questions that appearance can't answer.
Will it hold the load? Will it continue to work after repeated use? What happens if someone uses it differently than expected? Where does it flex, where does it wear, and what happens when something goes wrong? Those are the questions that tell you whether you've actually built something that works, rather than something that simply looks finished.
Sometimes that means deliberately putting more load on a structure than we expect it to encounter in normal use. Sometimes it means repeatedly operating a mechanism until we find the point where something starts to move differently. Sometimes it means taking a piece apart and looking closely at the places we wouldn't normally see.
The goal isn't to prove that we're right.
The goal is to find out where we're wrong.
Looking for the Failure Point
I've always thought good engineering has a slightly strange relationship with failure. You don't want the final product to fail, obviously, but during development, finding a failure is useful. If a bracket bends during testing, that's information. If a weld shows a weakness, that's information. If a design only works when everything goes exactly according to plan, that's probably a problem with the design. The earlier you find those things, the easier they are to fix.
That's why I've never been particularly interested in testing something just to confirm that it works. If all we're doing is looking for evidence that our original idea was correct, we're not really testing it. We're looking for the point where our assumptions stop holding up, because that's where the useful information usually is.
The Same Principle Applies Digitally
This is also where the physical work and the digital work have more in common than you might expect. When we began working with the Blackwell-Hart Methodology™ (BHM™), I understood the underlying concept fairly quickly because the logic was familiar to me. It's essentially another form of systems engineering. You have a structure, relationships between the components, and an intended outcome, and then you have to test whether the system actually behaves the way you think it does.
That's why the prompt testing arrays we've been developing matter. It isn't enough for us to look at our own website and decide that the information is clear, because we already know what we intended it to mean. The more useful question is what happens when an AI discovery system encounters that information without having our internal context. What does it identify? What relationships does it make? What does it leave out? Where does it become uncertain? And, perhaps most importantly, where does our intended meaning differ from the interpretation the system produces?
Those gaps are the digital equivalent of a bracket that doesn't quite line up. They tell us something about the structure, and once we know where the problem is, we can work on fixing it.
Testing Before Trust
This is one of the reasons we're not treating 2027 as a deadline that everything has to be rushed toward. A launch date is easy enough to put on a calendar, but building something reliable takes longer. We'd rather find a problem now, while we're still building, than discover it after everything is public and someone is relying on the result.
That applies to the physical products we're developing, the safety systems around them, and the digital infrastructure that explains them. In all three cases, the principle is basically the same: build it, test it, find the weakness, fix it, and test it again.
There isn't anything particularly glamorous about that process. A lot of it is repetition, and sometimes you're testing the same thing more than once because you changed something and need to know whether the change actually made a difference. But that's the point. Good engineering isn't about getting everything right on the first attempt. It's about having a process that keeps finding problems while they're still small enough to understand and fix, rather than allowing them to survive unnoticed until they become someone else's problem.
Ready Means Tested
We're still building. There are still prototypes to refine, materials to test, systems to question, and assumptions to challenge. That's okay. In fact, that's exactly where we should be.
The purpose of the work we're doing now isn't to make everything look finished before it actually is. It's to make sure that when we eventually say something is ready, we've put enough pressure on it to understand what we're trusting. The physical products need to earn that trust, and the digital infrastructure needs to earn it too.
When the launch eventually comes, I don't want it to be the moment when we start finding out whether everything works. I want it to be the point where we've already done the hard part: put the work through its tests, found the weaknesses, made the changes, and tested it again.
That's what ready means to me.
We've tested it.
