Ridgeline · Independent build · 2026 —

The review nobody was doing

An owner-side project controls platform that interrogates what a contractor submits rather than merely storing it.

Client
None. Built on my own time.
Discipline
Owner-side project controls
Years
2026 —

Context

For six years I sold construction work for a living, and the five pursuits we lost taught me more than the four we won. Not because of how we lost them — we were simply not the lowest bidder — but because of where they went. They went to owners with nobody of their own reading what the contractor sent, before award or after it.

I spent the decade after that being the person those owners did not have: reading the estimate before award, re-running the monthly update rather than reading the dates the contractor’s file was saved with, pricing the change before opening their number. Across $1.5B+ of capital work, nearly all of it by hand.

Most construction firms have no dedicated project controls team. On most capital programs nobody with the right expertise reviews the contractor’s monthly schedule update, payment application, or change proposals. The submission gets stored. It does not get read.

The mandate I gave myself

Not to store what the contractor submits. To interrogate it.

Every large program already has somewhere to put the update, the payment application and the change proposal. What almost none of them have is the second step — somebody who re-runs the schedule before reading its dates, and prices the change before opening the contractor’s number. That step is judgement, and judgement does not staff. So the question I set myself was whether it could be written down: not the numbers, the reasoning that produces them.Ridgeline sells the review, not the record.

Every figure below was checked against something I did not author. Where a figure could not be checked, it is not on this page.

The decisions

Auditing the bid, then trying to destroy the audit

The first real test was a contractor’s live bid on an industrial project, more than $300M — nine discipline sheets, 42,228 priced rows. Arithmetic first: 168,728 checks against the estimate’s own quantities, production factors and rates, and not one error. Twenty-four of twenty-four foundations on the concrete sheet reconcile against dimensions the estimator wrote into his own line descriptions. That is a carefully built estimate, and it earns the benefit of the doubt on everything after it.

It produced 65 findings, which I put to a second reviewer instructed to refute every one. Thirty-nine did not survive. Where the challenge corrected the money, the corrected figure is the one the report publishes. The twenty-six that stood are not summed — they carry ranges and conditionals, and a total built out of them would have no defensible meaning.

The audit runs as a module over the sealed workbook, and what it produces is a written report. There is nothing to show you here but the numbers.

Attributing the slip change by change

A delay position is normally argued schedule against schedule, and ends with two experts disagreeing about logic. This argues it forward instead: each change between one update and the next is applied onto the network as it actually stood, with the critical path re-run after every one — additive modelling, under AACE 29R-03 — so every intermediate network is one that could have existed.

The line I would read first is the one carrying 111 days of time that merely passed. Remaining work cannot start before the new data date, so part of any window’s movement is the job failing to keep up rather than anything anybody changed. Charged to whichever change was applied first, that 111 days makes one revision look catastrophic and hands the other side its defence. Carried on its own line, against changes netting 28 days back, what is left is 83 days worth $1,718,100 between recoverable damages and the owner’s own extended cost.

The engine is written rather than bought, so it is scored against Primavera rather than against my own expectations: computed float agrees with the float P6 itself stored to a mean absolute error of 0.013 days, across the 232 incomplete activities carrying one. That is the difference between a demonstration and an audit.

Window analysis: 112 days elapsed, 29 absorbed by float, 83 reaching the completion date
One window, 112 days. Twenty-nine days absorbed by float, 83 reaching the completion date, and 111 accounted for by time passing rather than by anything anybody changed. Six of the ten changes in the window are shown.

Testing the claim against the record, not against another schedule

Daily reports are sealed on receipt; a correction is a later record, never an edit. Each claimed event is tested against the days it covers — days claimed set beside days recorded by somebody who was there, written down before anyone knew which day would matter. A weather day is a day that lost working time, not a day it rained, and it counts against the contract’s own allowance: ten weather days against an allowance of eight is two days of exposure, not ten.

The third event is the one worth dwelling on. Nine days are claimed, the record does not cover twelve of the days in that window, and the claim cannot be tested at all — and the output says so, rather than quietly dropping it or scoring it against the contractor. A gap is a question, not a finding. What comes out is figures and a question to put to the contractor, never a conclusion about the claimant.

Three claimed delay events tested against the daily site record
Three claimed events set against the daily record: five days claimed where it shows none, twelve where it shows five, and nine that cannot be tested because the record does not cover twelve of the dates. The dataset is the module’s own test fixture, not an engagement.

What it will not answer

There is no model in it. Nothing learns, and no figure on any screen is a guess at what a comparable project did. Every number is arithmetic over documents the project itself produced, which is the only kind that survives being asked where it came from.

The DCMA fourteen run before any variance is read, and on the same update the attribution above is drawn from, four of them fail. Each check states the basis it was computed on, and a check that needs a designated baseline returns not computable, with the reason, rather than a number that looks authoritative.

Every automated quantity carries a confidence score and is flagged unverified until a named person signs it off. The flag blocks nothing; it means a quantity cannot reach a control budget without somebody’s name against it. Of 7,422 piping rows read from 657 isometrics, 566 sit on 33 sheets where the designer disclaimed his own bill of material, and the tool declines to total them. Where a reading can be scored it is: 440 numbered piles read off a structural package against 432 priced in the executed contract.

About a third of the estimating package is built and tested but not wired to a caller, classification is entered by hand, and commitments and subcontracts are not built at all. The first question anyone in this discipline asks about automation is what happens when it is confidently wrong and the number is already in a board pack. Naming what it will not answer is the only honest reply.

What I carry forward

Six of the twelve screens cite the Recommended Practice they implement on the panel itself — update review under 53R-06, forensics under 29R-03, estimate at completion under 80R-13, contingency under 65R-11. In this discipline a number that cannot cite its method is a number that loses an argument.

I built it solo, with AI coding agents under direction — the same posture I would want from any team using them.

the agent writes, the engineer decides, and the tests are the argument.

Ridgeline may never be a product, and that was never the test. What it settles is smaller. The review I ran by hand for a decade turned out to be real work with a method inside it, and a method you can write down is a method you can hand to somebody else. That is what I have been trying to do in every role I have held.

Python · FastAPI · SQLAlchemy · PostgreSQL · React · TypeScript · PyMuPDF · Tesseract · Monte Carlo · DCMA 14-point · AACE 65R-11