The super retired on a Friday. By the following Wednesday, nobody on the job could say why the lobby storefront was detailed the way it was. There was a reason — there’s always a reason — and it had lived in his head for fourteen months. He knew the architect had verbally blessed the glazing substitution back in March, knew which submittal it tied to, knew the owner’s rep had nodded along after a site walk. None of it was written down anywhere a person could find it on a Wednesday. So the new super did the only thing he could: he stopped the install, wrote an RFI, and waited five days for an answer the project already had — it just couldn’t remember it.

That is the quiet tax on every construction project. Not the dramatic failures — the bad pour, the wrong steel delivered to the wrong gate. The slow leak of knowing. The reason behind a decision, the assumption behind a number, the “we settled that back in the spring” that nobody can prove. A job generates an enormous amount of knowledge, and almost none of it ends up where the project can get it back.

Knowledge lives in people, and people roll off

Walk any active job and ask where the project actually knows things. Not where the files sit — where the knowing is. The super knows which subs need a babysitter and which ones you can leave alone. The PM knows change order #14 was really about the owner’s late tile selection, not the “unforeseen field condition” the paperwork blames. The estimator knows the sitework number leaned on a soils report that turned out optimistic. The construction administrator knows spec section 09 91 23 got amended by an ASI that never made it into the right folder. That knowledge is load-bearing, and it lives in human memory and private inboxes. When someone rolls off — promoted, poached, retired, or laid off at closeout — the knowing rolls off with them. The files stay. The understanding walks to the parking lot.

The files stay. The understanding walks to the parking lot.
On what turnover actually costs

The channels are scattered, so the answer is always somewhere else

Even when nobody leaves, the knowledge is shattered across a dozen channels that don’t talk to each other. The approval is in an email. The drawing it approved is in the plan room at Rev C. The cost impact is in a spreadsheet on somebody’s desktop. The “go ahead, we’ll paper it later” is a text. The photo proving the field condition is on a phone. The signed CO is a PDF in a shared drive nobody has fully organized since the footings went in.

Each piece is findable on its own. The trouble is that an answer almost never lives in one piece — it lives in the connection between them. “Why is the lobby budget up $3,200?” isn’t answered by the spreadsheet. It’s answered by the spreadsheet plus the change order plus the email approving the tile substitution plus the RFI that kicked it off. When those live in five tools owned by four people, the connection exists only in someone’s head — and you’re right back to depending on the one person who remembers.

Illustrative, not measured — but every builder knows the shape: the answer to a simple question is rarely sitting in one place.

The cost of forgetting

Forgetting rarely sends an invoice, which is exactly why it’s underrated. It shows up as the RFI you didn’t need to write, asking a question the project already answered. It shows up as rework when the field installs to a superseded revision because the current one never reached the trailer. It shows up at closeout, when the as-builts and the warranty chain turn into a scavenger hunt across inboxes and the people who knew the story are already on the next job. And it shows up in claims: when a dispute lands and someone asks “when did you first know about the differing site condition, and who did you tell?”, the project either has a timeline with sources or a room full of people saying “I think it was around April.” One of those positions holds. The other one settles. And a lost reason isn’t paid for once — it gets re-litigated every time a new person joins and the old question resurfaces, the same five days of RFI limbo billed again and again.

A record beats a recollection — if it’s connected and cited

The fix isn’t another folder. Storage isn’t the problem; most teams are drowning in storage. The trouble is that storage holds files, not knowledge — it can hand you the change order but can’t tell you why it exists or what it touched. What keeps knowledge on the job is a record that does three things a filing system can’t: it connects the pieces, it remembers who decided what, and it shows its work with a source attached to every claim.

Same documents, two very different outcomes — one stores files, the other keeps the project’s memory.

This is the gap BRAD is built to close. You forward it the documents and messages a project already runs on — plans, specs, submittals, RFIs, change orders, invoices, field photos, the email and text flying between the office and the field — and it turns them into one connected record. Then it answers the team’s questions over the same email and text they already use. Ask “why is the lobby glazing detailed this way?” and you get the substitution, the submittal it tied to, the approval, and the date — with the source document attached to each, so you’re not trusting a black box. The reason that used to live in the super’s head now lives with the project.

Every job will lose people. That part you can’t change. What you can change is whether the project loses its memory every time it loses a person — or whether the knowing stays put, connected and cited, ready for whoever walks up next and asks the oldest question on any jobsite: wait, why did we do it this way?