What this is
Every engineering job starts with a brief, someone reads it, works out what the job involves, and quotes a fee. At Civilocity, that reading was done by a single engineer working from twenty years of unwritten instinct.
He was good at it. Nobody was doing anything wrong. But there was no way to tell, from outside his head, whether a quote was sharp engineering judgment or shooting from the hip, and both look identical on a proposal. If a job bled margin, nothing explained why. And the better he was at it, the more expensive he became to lose.
So this system takes that reading out of one person's head and writes it down. A quote stops being a number inside someone's head or a gut feeling and becomes a list of named tasks, each carrying a price and a reason. You can check it, and approve it. A year later, you can test the estimate against what the job actually cost. The estimator can learn to grow and adapt with real world use.
I brought the experience: I worked with finance and the founder, and I have spent twenty-five years producing and managing the exact documents this system now reads.
The problem
Civilocity currently sells production drafting with precision engineering oversight to other engineering firms. Now it is expanding into engineering itself, sealing drawings as the Engineer of Record. That means one firm pricing three different kinds of work at once: drafting for a peer firm, plan production under someone else's engineer, and sealed work carrying its own liability.
Those three have to stay separate. A production task billed onto a sealed job, or a sealed obligation missing from a quote, is not a rounding error. It is a mispriced liability.
Then there is the second issue. Language models read briefs beautifully. They will hand you a fee in four seconds, with complete confidence, yet they will never mention that they made it up. An estimate that varies each and every time the same brief is read is worse than no estimate, because someone will believe it.
The design question was never whether AI could price a project. It was where AI must be forbidden to act and when in doubt, show why.
Where the boundary sits
The AI reads. The workbook prices. A person decides.
Intake takes the brief, the emails, the sketches, and the county notes, and produces one thing: a packet of extracted facts, each tied to the sentence it came from, plus an explicit list of what it could not work out. It writes no cell. It sets no fee. It drafts no proposal language.
A project manager resolves the unknowns and approves. Scope decisions go through a review card that records every include and exclude against the specific workbook cells it changed, so a call made in a Tuesday meeting is still legible in November.
Then the workbook runs. Version pinned, hash checked, and the only thing in the system permitted to produce a priceC1.
Three kinds of job, one engine
Each estimate declares who answers for the work before anything gets priced: Engineer of Record, consultant support, or production support. That choice is not a label on a form. It gates which tasks are allowed to fire at all.
Project management and quality assurance attach automatically to sealed work and cannot appear on a drafting job. Production-only tasks cannot leak into a support estimate. Client rate cards are a separate control, and a blank one fails closed rather than guessing, which is more or less the entire personality of the system.
Keeping three service lines honest is a configuration problem, not a discipline problem.
What checks the checker
Two gates audit the engine rather than the estimate.
The first is a parity gate. Before any release, the system has to reproduce sixteen reference proposals exactlyC2. Not approximately.
The second is a pricing oracle: a registry of authority records held independently of the workbook, each one ratified by running it through the same calculation path production uses. It carries a mutation proof. Change a single workbook cell by one dollar and the audit has to catch it. If it does not, the audit is the thing that failed.
Records that have not been ratified are marked blocked, not passed. Nothing ships on an unratified rule.
Judgment gets a scoreboard
The trouble with pricing from experience is not that it is wrong. It is that it never finds out.
A number pulled from twenty years of instinct leaves no record you can hold up against the job that followed it. Nobody is hiding anything. There is simply nothing there to check.
So the system keeps something. Eight completed jobs are loaded in from their time-tracker exportsC5, down to the hour and the cost rate, and a new quote can be measured against what that earlier work actually took. When there are too few comparable jobs to say anything honest, the system reports insufficient comparables and shows nothing.
A calibration band conjured out of two data points is worse than no band at all, because it looks like evidence.
Today the sample is small and most estimates come back with that lens unavailable. That is the true state of it. What exists is the loop: quote, deliver, measure, compare. It sharpens as jobs close, and it cannot sharpen without them.
The decisions I would defend
The spreadsheet stayed. Rewriting it into code was the obvious move and the wrong one. The firm's pricing knowledge lives in that workbook in a form the people who own it can open and read on a Sunday without asking a developer for help. The rule I wrote into the project's governance: no pricing logic gets rewritten into code until the oracle can independently verify every rule it would carry.
Uncertainty has to be said out loud. Test documents carry deliberately planted ambiguities. If the system quietly resolves one instead of surfacing it as a flagged question with a citation, the test fails. "I am not sure" is a permitted answer here. It is frequently the correct one.
The system governs judgment. It does not replace it. The dollar figures underneath are professional judgment, set per lot and per unit, with no external benchmark to check them against. This system does not make those numbers right and has never claimed to. What it does is make each one explicit, attached to a named rule with a ratification trail, and applied the same way every time. That is what turns instinct into something you can eventually calibrate, rather than something that quietly drifts.
Evidence
Demonstrations use Alder Ridge, a fictional development project built for the purpose. Real client work does not leave the firm.
- Sample intake packet showing a planted ambiguity surfacing as a flagged question with its citation
- The cell-level workbook contract and version manifest, with pinned hashes
- Parity gate output and the oracle mutation proof
- Automated test suite running on every changeC4
Status
Working and in internal use. Intake, the governed workbook contract, role gating across the three service lines, the parity gate, the oracle audit runner, the review card, and the desktop application are all built and running.
Validated. Sixteen of sixteen parity cases. One completed project priced retrospectively within 3.8% of what was actually billedC3. That is one data point, and it is reported as one data point.
In development. The oracle ratification program is partway through its rule set. Pricing for the sealed Engineer of Record line is flagged as house judgment until clean signed comparables exist.
Known gaps. The dollar values underneath are professional judgment with no external benchmark yet. Fee accuracy against reality rests on a single retrospective comparison, and the calibration sample is still too small to speak for itself. The sealed line is new and its pricing is uncalibrated, which the system states rather than hides. One operator uses it today.