Part 01 made the case for measuring one module completely and letting the repetition carry the number instead of fighting it. That number now has to survive contact with the build. On a program of repeated pads, a priced estimate is not the finish line. It is the first entry in a record that has to hold through procurement, through the field, and through closeout, without anyone typing the same quantity twice.
The bid side ships
Start with what runs today. Ruh measures quantities off your real drawing set, prices them across a nine-stage estimate built on your own closed jobs, and levels sub bids with the gaps called out as labeled allowances. Invoices are matched to commitments before payment, your estimator signs every line, and the result exports into the Excel, Procore, and Bluebeam workflows your team already runs. All of that is shipped.
The load-bearing part is not the takeoff or the estimate on their own. It is that the estimate becomes the record. The priced number is not a deliverable that gets emailed and forgotten. It is the entry every later phase is meant to read from.
The shipped bid-side products already run on this record today: measured takeoffs and priced estimates for the shell, site, and fit-out scopes, on one project graph.
Where the re-keying comes back
A campus is one module, tiled. When the unit of work repeats, so does the unit of error, and re-keying is that error in its most ordinary form. Multi-site programs multiply every handoff: the same data re-entered across feasibility decks, design sets, bids, and build records, with the mistakes compounding. On a single building you can absorb a retyped quantity. On the fortieth pad it is not an accident anymore, it is a pattern.
Today the seam sits right at the edge of the build. The estimate is the record, and invoices matched to commitments already close part of the loop before payment. But change orders, field reports, and the carry to closeout do not yet read from and write to that same record. That is the honest boundary. The bid side ships. The build side does not, yet.
The number that priced the pad should be the same number that closes it out.
What carrying the build means
Where this is headed is a single loop instead of a chain of exports. One project graph carries feasibility, design, bid, and build for every site, beside the Procore and Autodesk environments your delivery partners run, so program leadership sees real status without a reporting layer built on top. On the build side that means a change order priced against the same history that priced the base scope, a field report that updates the record rather than a parallel log, and quantities that reach closeout tagged to the pad they came from. We are building toward that. We are not shipping it yet.
Carrying the priced estimate into the build phase, change orders, field reports, and closeout across repeated pads without re-keying a single number, is on the roadmap. It is not built today.
The record is already there
The reason this is a roadmap and not a rebuild is that the record already exists. The bid-side products run on the project graph now. Extending it into the build is a matter of teaching the later phases to read and write the same entry, not standing up a second system next to the estimate. When the status is the record, program leadership does not chase it across tools, and the second campus starts from everything the first one wrote down.
The full lifecycle Ruh is building toward runs from raw site to running halls: feasibility, design, documentation, bid, build, and the money rail, with a portal for every seat at the table. The next part follows the money, how the same record that prices the pad today is meant to be the one that settles it.