The Problem With “Source of Truth”
Every software platform claims to be a “single source of truth.” The phrase has become so overused it’s lost all meaning.
Here’s the uncomfortable reality: you can have a source of truth and still have chaos.
A shared drive can be a source of truth. So can a spreadsheet. So can a well-organized email folder. They hold accurate information. They’re accessible. They’re even up to date.
And yet—crews still guess. Designers still get overruled by outdated specs. Clients still dispute what they approved. GCs still absorb liability for decisions made in threads they weren’t copied on.
Accuracy isn’t the problem. Authority is.
Source of Truth vs. System of Record
These terms sound interchangeable. They’re not.
| Source of Truth | System of Record |
| “This information is correct” | “This decision is governing“ |
| Data lives here | Decisions are ratified here |
| Implies accuracy | Implies authority |
| Can be disputed | Cannot be bypassed |
| Multiple systems can claim this | Only one system can be this |
A source of truth tells you what was selected. A system of record tells you what was selected, where it goes, who approved it, and whether that approval is contractually binding.
That’s the difference between “Client liked Fixture X” and “Client approved Fixture X for Location 218 in the Primary Suite shower on March 3rd, triggering contract release.”
Why This Distinction Matters
Design intent isn’t just information—it’s a chain of decisions with financial and legal consequences.
Consider what happens when intent is unclear:
- The designer remembers a conversation about upgrading the tile.
- The client remembers approving “something like that.”
- The GC has a spec sheet that says something else.
- The subcontractor is standing in the unit, waiting for an answer.
Who’s right? More importantly: who’s liable?
If your project relies on a “source of truth,” the answer is: whoever has the best documentation. Which means the GC, by default. They’re the last ones holding the bag when intent is ambiguous.
If your project has a system of record, the answer is: check the system. The decision either exists there—ratified, timestamped, governing—or it doesn’t exist at all.
If it’s not in the system, it’s not resolved.
The Gap in Your Current Stack
Contract administration has a system of record. Procore and other construction management platforms handle contracts, submittals, and documentation. That layer is solved.
Design intent—the selections, finishes, fixtures, and specifications that define what goes where—has no system of record.
And it’s messier—more decisions, more people, more changes, more chaos. This is where intent gets lost, approvals slip, and changes go undocumented. It’s upstream of everything, but governed by nothing.
That’s the gap.
Your construction management platform assumes design intent is already resolved when it arrives. It’s not. It’s scattered across email threads, spreadsheets, and PDF markups. And when something goes wrong, the GC is accountable for decisions they couldn’t see.
What a System of Record Actually Requires
Not every platform can be a system of record. Most aren’t designed to be.
A true system of record must:
- Capture What AND Where. Item selection is meaningless without location assignment. “Client approved the faucet” is incomplete. “Client approved the faucet for the Primary Bath, Powder Room, and Guest Suite” is governing.
- Separate Design Approval from Contract Approval. Liking something isn’t the same as committing to pay for it. These are two different decisions and must be tracked independently.
- Enforce Sequence. Some decisions can’t happen until others are locked. The system must prevent premature commitments—not just flag them.
- Create Immutability After Commitment. Once a bid is issued, the record must version. Changes become deltas, not overwrites. History must be auditable.
- Assign Decisions to Locations, Not Just Items. Approving an item in the abstract means nothing. Approving it for a specific location in a specific space—that’s a governing decision.
The Chaos Layer
Between design intent and project execution, there’s a gap. We call it the Chaos Layer.
This is where:
- Verbal approvals never get documented
- Substitutions happen without updated specs
- Email threads become de facto decision logs
- “I thought you knew” becomes the root cause of every dispute
A source of truth doesn’t eliminate the Chaos Layer. It just gives you a tidy place to store the chaos.
A system of record compresses the Chaos Layer. It forces decisions into a structure. It requires ratification before action. It makes ambiguity visible—and unacceptable.
What to Ask Before Calling Anything Your “System of Record”
Use this checklist:
-
- Does it require explicit approval—not just uploads or comments?
- Does it tie every item to a specific location?
- Does it distinguish between “design approved” and “contract approved”?
- Does it version automatically after financial commitments (bids, contracts)?
- Is it the reference your contracts point to?
Can someone bypass it and still claim a decision was made?
If the answer to that last question is “yes,” you have a source of truth.If the answer is “no,” you have a system of record.
The Bottom Line
The best projects aren’t built from better information. They’re built from better authority.
A source of truth gives you confidence that data is accurate. A system of record gives you certainty that decisions are final, traceable, and enforceable.
Your project doesn’t need a smarter filing cabinet. It needs a ledger.
That’s what a system of record delivers.
