Who is your project record for?

When did you last read your own project record?

Not search it. Read it.

General contractors I speak to can tell me, with confidence, that their project record is complete. The contract is filed. The drawings are under revision control. The RFIs and submittals sit in a log. Every email is somewhere. When a claim lands a year after completion, the commercial team spends weeks pulling the story together from that record, and the story usually holds.

That is the standard argument for risk management in construction. Most disputes start with unclear responsibilities and missing documentation, so keep a complete record and you have your defense. None of that is wrong. It just stops too early, because it treats the dispute as the point where the record starts to matter.

So here is my question. Is your project record there to prove what happened, or to tell you what is happening? The difference decides whether your risk management works before the dispute or only after it.

Why do construction disputes happen when the record is complete?

Risk management in construction is the discipline of identifying, pricing and controlling exposure before it turns into a claim, a delay or a defect. Most general contractors practice it as record-keeping. My argument is that a complete record defends you after a dispute but does nothing to prevent one, and that prevention depends on reading the record while the project is still live.

To see why, think about how a scope dispute forms on a live job. A design change comes through as a markup on a drawing issue or buried in the body of an email thread between the architect and your package manager. Nobody raises a change request because, at the time, it looked minor. The subcontractor prices it into their next pay application. Your commercial team queries the line. Three months later the change order is on the table, the owner’s representative says it was always in scope, and your commercial manager goes looking for the moment the change entered the project.

The record was complete the whole time. The email was filed. The drawing revision was logged. The pay application was in the system. Completeness was never the problem. The problem was that nobody connected those three items while there was still time to raise the change, agree the cost and keep the relationship intact.

A complete record does exactly what it promises. It lets you reconstruct events after the fact, and it tilts the dispute in your favor once the dispute exists. What it does not do is reduce the number of disputes, because by the time anyone opens the record with intent, positions are set and the money has been spent.

The flight recorder and the instruments

Every commercial aircraft carries a flight data recorder. It captures hundreds of parameters, continuously, for the whole flight. It is complete and tamper evident, and nobody questions whether it is worth carrying. It is also opened only after something has gone badly wrong, by investigators, to establish what happened and who was responsible.

The crew does not fly by the recorder. They fly by the instruments on the panel, which read from the same sensors but present the data as it arrives, in a form that supports a decision in the next few seconds. It is the same data serving a different purpose. One tells the inquiry what happened, the other keeps the aircraft out of the inquiry.

Most construction project records are built as flight recorders. Document control, email filing, change logs, version registers, issue trackers and reporting dashboards are designed with the investigator in mind. Can we show, later, that we told them, that they approved it, that the revision was issued? That is a legitimate design goal, and I would never argue against it. But a contractor who only has a flight recorder is flying blind and will find out how well everything was recorded at the inquiry.

Where do construction disputes start?

The reason the recorder model persists is that each part of the record is managed well, on its own terms. The document controller keeps the drawing register clean. The commercial team keeps the change log current. The package managers keep RFIs moving. The project administrator files correspondence. Each function can audit itself and pass.

The risk sits between them. When an RFI response changes a detail, nobody logs it as a change, because an RFI is not a change event. A submittal approved as noted carries a scope implication that the person tracking submittals is not paid to notice. A schedule revision that pushes a trade into winter working is logged by the scheduler but never reconciled against the subcontract’s weather provisions. A client email saying go ahead, we will sort out the paperwork, sits in one inbox. A superseded drawing revision is still the one pinned up in the site office, and version control shows the current one was issued, which is true. An open issue gets closed in the tracker because the engineer who raised it moved to another job. The monthly report shows green across the board because every log, taken on its own, is green. None of these is a failure of the system it lives in. Every one of them is a dispute waiting for a claim date.

In my experience, the disputes that cost general contractors the most share three characteristics:

• The triggering event was recorded somewhere, correctly, at the time.
• Its commercial or contractual consequence lived in a different system, owned by a different role.
• Nobody was responsible for reading across the two until a payment, a delay or a defect forced the question.

Documentation did not fail in any of those cases. Attention did, and attention is the one thing no project has in surplus.

How do contractors prevent claims before they form?

The shift I am arguing for is not another repository, another filing discipline or another dashboard. Contractors have enough of those, and adding one more place to record things makes the recorder bigger, not more useful. The shift is to treat the project record as something that is read continuously, across every system it spans, with the specific job of surfacing where the project’s current state has drifted from its contractual position.

In practice that means the record answers questions while they can still be settled with a conversation rather than a claim. Which RFI responses this month altered a detail that has a priced scope attached? Which approved submittals deviate from the specification without a corresponding change request? Which items of correspondence contain an instruction that has not been formalized? Which subcontract packages are now exposed by the latest schedule revision? A good commercial manager asks those questions when there is time, and on a live job there rarely is. A record that warns asks them every day and brings the exceptions to the people who can act.

Two things matter in how that is done. First, the record must be read where it already lives. Asking the site team to re-enter information into yet another platform is how records become incomplete in the first place. Second, the person stays in command. The record raises the exception. The commercial manager decides whether it is a change, a claim, a conversation or nothing. Risk management stays a human discipline. It simply stops depending on someone having the spare hour to go looking.

You get a better dispute file out of this, but that is a by-product. What you get is fewer disputes, because the moment a change is noticed is the moment it is still a change rather than a claim. That is the only point in a project where managing the risk costs less than defending it.

Back to the question

I will put it to you the way I put it to myself. Pick the last dispute your business settled. Go back to the project record and find the first moment the dispute was visible in it, not as a dispute but as a loose end: an RFI, a markup, a line in a pay application, an email. In almost every case it is there, months before anyone used the word claim.

Then ask yourself one thing. Was your record there to prove what happened, or to tell you what was happening? If the answer is the first, you have a very good flight recorder. The industry has invested heavily in those, and the disputes keep coming. The next investment is the instruments.

If you want to see what reading the project record continuously looks like on a live job, with your own RFIs, submittals, correspondence and schedule, and your commercial team in command of every decision, talk to us at ageiro.global. Bring the last dispute you settled. We will show you where it was visible first.