Victory Ledger - April 2026
In April the focus was really starting to take advantage of the infrastructure we had been laying over the previous three months.
The biggest example of this is that we now had an event ETL daemon which we call Clio that would let all the logging that we're generating get saved to a file on disk and uploaded to S3 from there. Clio would then make a POST request to a server called Helicon where it would tell Helicon about the files that Clio had uploaded to S3. Helicon would take that list of files, and then ingest the events from those files into a database where we could then query them.
The entire system above was something I built in service of Vulcan Forge. Back in 2013 I had built an entire start-up around providing this exact infrastructure to other start-ups. That's how far AI-driven development has really come. Something that used to be an entire company is now a feature I put together in a few weeks.
The rest of the work was really about improving things under the scale that we are now achieving:
- Workers needed to use the new auth system to be able to log in properly so we could manage multiple workers and multiple types of jobs
- Our rig ID system needed to be updated so that rigs belong more clearly to their nodes
- The data repo needed to get split into four different repos, so that the data repo itself stops being a bottleneck to working on multiple rigs in parallel
Tempering and Node Curing
Victory ledgers, as great as they are, don't seem to capture improvements to the workflows very well. Workflows don't appear in the code. They're updates to the prompts, to my mental models, and things like that. As such, they just don't show up in the Victory Ledgers.
We made two major improvements to the workflow during April:
- Tempering
- Node Curing
Tempering
Tempering basically lets us set a set of best practices that we want the code base to adhere to. Then we can run a job to examine a repo using those set of best practices and find deviations or improvements. For any work that's found, we then seed rigs to improve the code. That can be anything from deviations in the code from specs, deviations in the code from our design principles, or even just deviations in the code from my expected functionality.
The rigs that tempering generates are assigned to special tempering nodes, which don't have node plans. These are sort of catch-all nodes that we can use to assign ad hoc work as we find it.
Node Curing
Node curing, on the other hand, works a lot like rig curing, where we have a spec, we have a plan, and we're now looking to see how well the code that we just implemented aligns with the spec at the node level. Remember that nodes are units of human intent, whereas rigs are more about the machine level units of work. Sometimes when we implement all the rigs correctly we still end up with deviations where the pieces don't quite add up to the hole we expected.
This is what node curing is intended to catch. When it does, we again just create a new set of rigs that will close the gaps.
I'm really proud of how tempering and node curing basically are two different ways finding deviations in the code base from our intentions, but functionally they are just ways of creating new work that slots right into our existing workflows. Yes, the tempering analysis is different, the node curing analysis is different, but we just create rigs the exact same way that we would for new work.