A Company Brain Should Reduce the Cost of Uncertainty

“The contractor carries that risk.” It is a reassuring sentence when you are about to commit millions of dollars to a project.

You sign the contract knowing that, if a particular problem emerges, someone else is responsible for dealing with it. The project can move forward. You sleep a little better.

But the contractor priced the job before you signed it. If they charged for accepting that uncertainty, you have already paid for the protection, whether the problem ever appears or not.

That is a reasonable way to get a building delivered. Developers know their drawings, specifications, estimates and schedules will contain conflicts. They also know the team cannot keep reopening every document and checking every connection each time something changes. Attention goes to the largest exposures. Other risks are allocated through contracts, covered by allowances or left for the people who will figure them out on site.

The economics are familiar: uncertainty can show up in the bid, and unresolved coordination can consume time and money during delivery. The UK Cabinet Office's risk-pricing guidance describes how a buyer can pay an uncertainty premium even when the anticipated loss never occurs. It also recognizes that competition can squeeze that premium out, leaving a bidder with exposure it cannot comfortably absorb. The contract still matters; the risk has a cost. Risk Allocation and Pricing Approaches ↗.

AI can help teams check more of that information, more often. It can compare project records, flag inconsistencies and repeat the checks when a document changes. That gives reviewers a better chance of finding conflicts before a price is agreed or work begins, while they still have options for resolving them.

The value comes from resolving those uncertainties early enough to change the project's cost, scope or delivery plan.

Ask an experienced construction professional whether an estimate includes a particular cost, and the answer is often: “It depends.”

It depends on which drawing revision governs. Whether the supplier included that scope. Whether the owner accepted the substitution. Whether the apparent discrepancy reflects a mistake or a decision already made somewhere else.

A company brain should bring that context together. It connects the evidence behind the price to the project's decisions, requirements and current state. That context makes an AI finding meaningful: the system can help distinguish a real scope gap from a legitimate difference, then bring the supporting evidence to the person who can act on it.

The expert still has to decide what the evidence means. But they should not have to rebuild the project history every time a question comes up. Bringing that history together leaves more time to resolve the issue itself.

This is how a company brain can reduce risk and cost. AI expands the capacity to check. Connected project knowledge gives the findings meaning. Acting on the right findings before procurement or construction can reduce the avoidable uncertainty the developer would otherwise pay to carry, transfer or resolve later.

Keep an up-to-date picture of the project

The system needs to do two things: find conflicts in the information already available, and keep checking as the project changes. A system that only tracks new revisions can miss inconsistencies that were present from the start.

A construction project distributes its knowledge across drawings, specifications, estimates, quotations, schedules, meeting records and people. Each contains a partial account. A price depends on a quantity; the quantity depends on a design revision; the supplier's inclusion depends on a qualification; the installation sequence depends on an approval arriving in time.

A company brain should maintain these relationships as the project develops. Its memory would include the owner's requirements and preferences, the project's current information, its approved commitments, working assumptions and unresolved decisions. It should preserve the distinction between them.

The system has two parts. AI models read language and images and suggest connections between them. Databases and document systems store the project records, including where they came from, which version they belong to and who can access them. When the AI needs to answer a question, it retrieves the relevant records rather than relying on what it remembers from an earlier conversation. Anthropic's context-engineering guidance ↗.

Adding a quotation updates the company's records; it does not retrain the AI model. The connections between those records form a knowledge graph, which records what relates to what and why.

Its basic unit should be a claim with evidence. “This package includes firestopping” needs a project, a package, a source passage, a revision and a status. The record should establish whether the statement came from a supplier, an estimator's assumption or an accepted clarification. A numerical claim also needs its quantity, unit, scope and price basis.

Similar wording can conceal different commercial terms. The system can recognize that two firms describe equivalent work differently while preserving commercially important differences. An exclusion, an allowance and scope carried elsewhere must remain distinct even when they appear beside similar descriptions.

When searching a large archive, the system should filter by access permissions, project, work package and intended use. It can then look for both exact references and related descriptions. Several copies of the same document should not count as independent evidence. Competing revisions should retain their separate status, and a short exclusion should remain attached to the price it qualifies. Finding relevant text is not enough. The system needs to know whether it is approved and what it means for the price or scope. Reading a statement confidently does not authorize the AI to approve it.

The owner's preferences belong in the same structure. A standard finish, a maintenance requirement or a policy on acceptable substitutions should have an owner, an effective date and a defined application. A project-specific exception should remain visible. Otherwise, the system can confidently enforce yesterday's preference against today's approved decision.

Make clear what each document can be used for

Construction already has a discipline for this problem. The UK BIM Framework's guidance on ISO 19650 separates work in progress, shared information and published information. It explains that status determines permitted use: material under review should not be used to agree contract costs, procure materials or construct the works. These are UK implementation conventions, but the distinction is fundamental to a project brain. UK BIM Framework, Guidance Part C ↗.

A newer working estimate may contain the best warning of emerging exposure. The approved estimate remains the baseline against which commitments are controlled. Both are useful; combining them into a single “latest answer” destroys the distinction the owner needs.

I would maintain separate views of approved commitments, authorized working information and unresolved proposals. A forecast can consider a pending change without treating it as an instruction to proceed. The system must record when information becomes effective as well as when it was received, so it can reconstruct what was known at an earlier decision.

The same distinction applies to work-in-progress files. The owner is not automatically entitled to every consultant or contractor's internal working file. The brain should use the information made available under the project's access arrangements and identify where a missing input limits its assessment.

Permissions therefore affect the analysis itself. A confidential bid cannot become accessible through a generated benchmark or summary. Source restrictions need to carry into derived information, and changes to access need to affect cached answers. Microsoft's SharePoint indexing documentation describes both document-level access enforcement and synchronization limitations. Those controls need testing throughout the system, rather than an instruction telling the model to be discreet. SharePoint access controls ↗.

Keep every conclusion linked to its evidence

A change to one document can affect several estimates or decisions. The system needs to know which ones depend on it.

If an estimate uses a particular quotation and drawing revision, those relationships should be stored with the estimate. When a new revision arrives, the system can identify the affected conclusions and mark them for review. The older conclusion remains part of the decision history, with its original basis intact.

This is provenance: a record of how information was produced. The W3C's PROV data model provides established concepts for derivation, revision, responsible parties and invalidation. Applying those concepts to an estimate makes it possible to trace which inputs supported a result. It does not make those inputs correct. W3C PROV-DM ↗.

The update cycle should follow the work. A new document or approval event is captured; its claims are extracted; affected dependencies are identified; calculations and checks are refreshed; material changes go to the responsible person. An unresolved contradiction remains unresolved until evidence or an authorized decision settles it.

Google's work on agentic retrieval illustrates part of this capability: systems can search across sources, assess whether the evidence is sufficient and retrieve more when needed. Construction-specific reliability still requires validation. Google Research: Agentic RAG ↗.

AI helps interpret what changed and identify what it could affect. Conventional software should calculate the quantities, rates and scenario totals, enforce permissions and apply explicit rules. People retain responsibility for commercial interpretation and approval.

Some owner requirements can already be made machine-checkable. buildingSMART's Information Delivery Specification, for example, defines information requirements that can be automatically checked in IFC building models. It does not audit arbitrary PDF estimates. It demonstrates the value of specifying an obligation precisely enough for software to test it. The same design principle can be applied to an owner's estimate-submission requirements. buildingSMART IDS ↗.

The reviewer should see what changed, which part of the work it affects, what needs investigating, who should decide and when that decision is needed. A long list of minor alerts would leave the team with another pile of work to sort through.

What the owner sees before committing

Consider ground conditions. In an estimate reviewed for this article, the narrative allows local dewatering in the absence of a hydrogeological report, while the detailed dewatering line is marked not applicable. The same narrative excludes treatment of contaminated soil or groundwater because an environmental report is absent.

That does not necessarily mean the estimate is wrong. It means the team needs to establish what is included in the price before relying on the total.

A company brain should connect those statements to the available investigation reports, excavation scope, qualifications and relevant programme activities. It should identify whether the allowance is carried elsewhere, which information is missing and which upcoming decision relies on it. The owner can then decide whether further investigation, a clarification or an explicit allocation is warranted.

If a new report arrives, the system should revisit the assumptions it informs. It should not invent a dewatering cost from a general model's memory. Pricing requires a suitable quantity, method and current commercial input. The value is in showing the team which assumptions have changed while there is still time to adjust the plan.

The same logic applies to supplier packages. The reviewed estimate references a supplier proposal across several trades and places some scope inside that package. A revised proposal could change the basis of multiple estimate lines at once. A maintained dependency map can bring those lines together, identify the affected qualifications and prepare the review before procurement proceeds. Where the proposal has not been supplied, the inclusion remains unverified.

A schedule change can affect costs across several parts of the project. A longer activity may affect staffing, temporary facilities, equipment hire and a downstream milestone. The system should test those dependencies against the actual programme and resource plan. Multiplying every general-conditions line by extra months would be an inadequate model: some costs are fixed, some are quantity-based and some continue only during particular phases.

Owner reporting should reflect this structure. Alongside the estimate total, show which material assumptions remain open, which packages rely on provisional information and which decisions are approaching commitment. An owner reporting template reviewed for this article asks teams to explain cost changes by division, show allowances separately and check staffing costs against the project resource plan. A brain can maintain the evidence behind that reporting between formal submissions.

Better knowledge can increase the estimate

There is an important test of whether this system is managing risk honestly: it must be able to tell the owner that the project is more expensive than previously understood.

Clarifying an exclusion may increase the forecast. A ground investigation may reveal an exposure that an optimistic allowance concealed. Recognizing that exposure before award gives the team a chance to change the design, obtain better pricing or make a deliberate investment decision.

Conversely, reducing contingency without resolving the uncertainty creates an attractive number with the same underlying exposure. More sophisticated AI should make that harder to disguise.

The Infrastructure and Projects Authority's estimating guidance ties estimate confidence to the maturity of the evidence supporting it. It calls for traceable assumptions and warns that sophisticated probabilistic methods can create false confidence when the inputs are immature. That is an appropriate standard for AI-assisted estimating too. IPA Cost Estimating Guidance ↗.

The archive should improve this judgment over time. At closeout, accepted changes and actual costs can be linked back to the original assumptions. Historical comparisons should retain differences in scope, construction system, design maturity, location and price date. A difficult project provides useful evidence; quietly excluding it from the benchmark teaches the next team the wrong lesson.

The hard part is keeping the connections reliable

Much of the foundation exists today: versioned records, access controls, structured data, provenance and rules-based checking. AI models can help connect those records to the varied documents a project team uses. A bounded system can support extraction, comparison and review, subject to validation on the company's files.

The harder problem is discovering and maintaining the right relationships across a changing project without introducing false connections or missing important ones.

Recent memory research is working on part of this. MemForest's July 2026 revision describes ways to organize information over time and refresh affected summaries efficiently. The authors explicitly acknowledge that extraction errors can propagate and automatic fact verification remains future work. Its conversational-memory experiments do not establish construction reliability. MemForest ↗.

Specialized drawing interpretation is also advancing. An August 2026 Handoff report combines vision models, project knowledge and verification for material takeoff. On its own benchmark of 10 residential drawing sets, it reports 86.1% material coverage and 78.8% quantity precision, with a 25% tolerance for matched quantities. Labour and secondary materials are excluded from scoring. This is a vendor-reported result, not evidence of dependable, complete commercial estimating. Handoff-H1 ↗.

These advances support building carefully bounded capabilities. They do not establish a system that independently resolves every scope dispute, discovers every dependency or certifies the owner's total exposure. A company brain also cannot observe an unrecorded site condition or an agreement no one has shared.

Build around decisions that can still change

Timing is part of the value. The Construction Playbook warns that late tendering can leave suppliers pricing assumptions that earlier engagement might have helped mitigate. The Construction Playbook ↗.

For a developer, I would begin with one live procurement or estimate-review cycle. Connect the applicable requirements, current and prior estimates, available quotations, design revisions and programme. Maintain the assumptions supporting the decision and test how the system responds as that evidence changes.

Measure whether material issues are correctly identified, how many false alarms the team receives, and how quickly verified changes reach the person responsible. Track whether unresolved assumptions are closed before commitment and whether reviewers use the correct versions. Test the system against cases that experienced reviewers have already assessed, including cases with missing documents and conflicting drafts.

Cost claims require a further step. A flagged issue is not a saving. Record the action taken and its commercial result, distinguishing clarified scope, a changed design, a revised price and an exposure the owner deliberately retained. Avoid claiming the full value of a hypothetical future loss as money saved.

AI makes a broader, repeated examination of project information feasible. The business case is to use that capacity to uncover conflicts earlier, direct people to the ones worth resolving and reduce the uncertainty carried into price and delivery.

Contracts will still allocate risk, and teams will still solve problems on site. The aim is to resolve more of the avoidable uncertainty before it becomes a higher bid, a change order or a delay.