What if hardware could enhance itself?
Every board you make could teach the next one.
Software gets better while you sleep. A crash report comes in, someone fixes it, and the next release carries the fix to everyone who runs it. Every change is a diff with a message that says why. Tests run on it before it ships. Over the years, what a team learns ends up inside the code itself, where the next person will find it.
Hardware does not work that way. A circuit board is frozen the day it is ordered. Whatever it teaches you on the bench ends up somewhere else: in a notebook, a chat thread, a photo on someone's phone, or nowhere but memory. The regulator that ran hot. The connector everyone plugs in the wrong way. The track you cut and bridged with a wire at two in the morning so the demo would work. The next revision starts from the last revision's files, and from whoever remembers.
That is the part of hardware we most want to change. Not the board itself: copper stays where the factory put it. The design. What if every board you made taught the next one?
Why the next revision starts over
A layout file is very good at saying what is on the board and very bad at saying why. It knows that a 10 µF capacitor sits 2 mm from a pin. It does not know which line of which datasheet asked for it, whether anyone checked, or whether it was a guess that happened to work. The reasons live in the head of whoever drew it, and in the tabs they had open that week.
When a board comes back and something is off, the fix happens with a soldering iron. A resistor gets swapped, a wire gets added, a part gets lifted. The board works, and that is where the lesson usually stops. There is no place in the design to write "this value was wrong, here is the measurement that showed it", next to the decision it overturns. So the next revision gets the fix if someone remembers to carry it over, and loses the reason either way.
Reviewing your own design does not save you here either. You see what you meant to draw, not what you drew. That is true of people, and as we wrote about the checks, it is just as true of an AI agent asked to check its own work (the agent never grades itself).
What a board would need
For a design to get better from one revision to the next, three things have to be true. They are the things Provenboard is built on.
It has to remember why
A revision can only improve on a decision if the decision and its reason survive. Provenboard keeps a record of decisions as they are made, each with where its reason came from: a datasheet, the brief, the person's own words, or the agent's own judgement, marked as such.
That last distinction matters more than it looks. On an Uno-style board, for example, the agent chose the copper weight because no rail carries more than about half an amp; the record marks that as its own judgement, drawn from the currents in the brief. When a measurement later disagrees with a decision, you want to know which you are overturning: a figure from a datasheet, or an engineer's estimate. One is a surprise worth understanding. The other is exactly what the measurement was for.
It has to be judged by something other than its author
A design that grades itself always improves. So in Provenboard the agent does not decide whether a board passes: separate checks do, and the questions only a person can answer, such as whether the pin map matches the datasheet or whether the board worked on the bench, wait for that person.
For a loop that is meant to learn, this is not a detail. If the thing proposing a change also decides that the change worked, the loop learns whatever it wants to.
It has to know what it was for
A change is only better against a goal. Every board starts from a brief: what it must do, in what conditions, and how many will be made.
And when a design is finished, the agent writes a bring-up plan for the first time it meets a power supply: what to power first, what to measure, and what each measurement should read according to the datasheets used in the design. The plan for a small flight controller opens with an assumption the design had to make. The crystal's datasheet gives no pinout, so the design assumed one, and the plan says so: if the chip never starts, check the crystal first.1
A board that says where it is least sure of itself is a board you can learn from. That plan is the first half of a loop. Today, the second half is still a person with a multimeter and a notebook.
The loop we already run
There is one part of the product where we already close the loop: the router.
It started with a board we showed on a KiCad Discord. Every automatic check had passed, and the reviewers called the routing messy. They were right. A check can say a board is valid; it cannot say that an experienced person would have laid it out that way. So we needed something that could.
We route boards that people already routed by hand and compare our copper with theirs, board by board (how we measure the router). The person's layout is the reference. The comparison looks at what an experienced eye looks at. When it finds a pattern, we change the router and run the comparison again.
One example, from the first days of that comparison. Of the 82 boards the router finished completely, 53 had more right-angle corners in our copper than in the person's. The first change brought that to 13. A second one, the same day, to 5. By the next afternoon, it was 0. At every step, the bench found no board that routed worse than before.2
Nobody had to remember to look. The reference was there, the measure was there, and running it again was cheap. That is all a loop needs, and it is what a board on your bench does not have yet.
Now imagine it on your boards
The same loop, one level up. This is not something Provenboard does today; it is where the pieces above point.
Revision A comes back from the factory. You follow its bring-up plan: you power the rails in order, you measure, you check that the crystal starts. Each reading goes next to the value the plan expected and the decision behind that value. Most of them agree, and that is worth recording too: a decision that has met a real board is stronger than one that has only met a datasheet.
Some do not agree, and they tend to come in three kinds.
- A value is off. The regulator runs hotter than you expected, or a rail sags under load.
- An assumption was wrong. The crystal's pinout was the other way round, and the board never started until you reworked it.
- You changed something by hand. A pull-up swapped for a stronger one, a wire across two pins, a part left off.
Revision B starts from those. Each one becomes a proposal with your measurement as its source: more copper around the regulator, because revision A measured it hot; the crystal turned, because revision A only started after rework. The agent proposes. The checks judge the new layout. You decide, and your bench fix is treated as your decision, not as noise to be designed away. When someone opens revision B a year later, its record says why it differs from revision A, in your own measurements.
Over several boards, the knowledge adds up. A part that misbehaved once is something the next design already knows about. A layout pattern that held up on three boards earns more trust than one that has never been built.
It is worth saying what this is not. It is not a board rewiring itself, and it is not an agent deciding on its own that it has got better. The checks still judge. You still decide. The order is still yours.
What it would take
None of this is magic, and the hard parts are not the ones people expect.
- Recording has to be quicker than the notebook. A reading at the bench takes seconds. If writing it into the design takes longer than scribbling it on paper, it will go on paper.
- A reading has to find its decision. A measurement is only useful next to the expectation it tests and the reason behind that expectation. The bring-up plan already knows both, which is why we think it is the right place to start.
- One board is one sample. A regulator that ran hot on one board might be a design problem or one bad part. The loop has to tell a pattern from an accident, and say how sure it is.
- The person stays in charge. A measurement is evidence, not a verdict. The decision about what changes in the next revision stays with the person who has to live with it.
Where we are
Most of the loop exists. Decisions are recorded with their reasons. Separate checks judge the layout. The person signs off on what only a person can check, including whether the board worked. Finished designs come with a plan for their first power-up, and the router is measured against people, board by board. The step still ahead is the one this post is about: what you learn at the bench flowing into the next revision.
Provenboard is in early access at provenboard.com. If you have ever started a revision from a notebook, we would like to hear what was in it.
Footnotes
- The bring-up plan of a flight controller board designed with Provenboard, 2026-10-07. ↩
- Our routing bench, runs of 2026-10-07 to 2026-10-09: right-angle corners per metre of track, ours against the person's, on the 82 D3-A boards routed completely in each run. No board routed worse in any run in between. ↩