Truth Latency: How Long Does It Take Bad Data to Get Caught on Your Project?

Here's a metric no dashboard on your project is showing, and it predicts coordination pain better than any number that is: when something wrong enters the project's information — a misplaced element, a stale coordinate, an empty property, a superseded drawing still in circulation — how long does it live before someone catches it?

Call it truth latency: the elapsed time between an error entering the shared information and the moment the project knows it's an error. Every project has it. Almost no project measures it, because we've organised our quality processes around a different question — do we catch errors? — when the question that prices the damage is how fast?

The pricing is brutal and familiar. An error caught the day it's made costs its author an hour. The same error caught at the next coordination cycle costs a meeting and a re-issue. Caught after the downstream disciplines have modelled against it, it costs a small cascade of rework. Caught on site, it costs money with a contractual reference number attached. Same error every time — the only variable is latency. Which means a project's coordination quality isn't really its error rate (errors are certain; people are people); it's the distribution of its truth latency. Two projects with identical error rates and different latencies are two entirely different projects to work on.

Where latency comes from

If latency prices the damage, the engineering question is what creates it. Four structural sources, in ascending order of how much they're under your control:

Cycle time. The most visible source: if coordination reviews happen fortnightly, the average error waits a week just for its first chance to be seen — and that's the floor, before any human factors. Every gate on the path (the fortnightly federation, the monthly design review, the milestone submission) adds a queue, and errors sit in queues.

Access friction. Subtler and larger than cycle time: an error can only be caught by someone who looks, and every obstacle between a project participant and the information — licences they don't have, software they can't install, files they must request, platforms they need accounts for — shrinks the population of lookers. On many projects, the people best positioned to spot a specific error (the site engineer who knows the level, the supplier who knows the product) are precisely the people with the least access to the model. High access friction doesn't just slow catching; it silently reassigns all checking to the small licensed few, and their queue becomes your latency.

Review shallowness. What the lookers look at. Reviews organised around geometry — orbit the federation, run the clash test — catch geometric errors and stream past informational ones: the empty property, the wrong classification, the generic type that should have matured into a product by this milestone. Informational errors routinely carry the longest latencies on a project precisely because nothing in a visual review touches them; they surface when a downstream consumer (the cost plan, the procurement schedule, the asset register) finally queries data that isn't there. That consumer's timeline, not the review calendar, becomes the catch date — often months out. (This is the LOD-versus-LOI blindness wearing its process costume.)

Status ambiguity. The sleeper: information whose usability is unclear — is this the current revision? is this shared-for-coordination or approved-for-construction? — generates a special error class: correct data, wrongly trusted. A superseded drawing isn't wrong; building from it is. Projects with weak status discipline manufacture these errors continuously, and their latency runs until the collision with reality, because no review is even looking for them.

Engineering the latency down

Reframe coordination as latency-reduction and the levers organise themselves — and notably, the expensive lever isn't first:

Shrink the loop for cheap checks. Not everything needs the fortnightly federation. A model export can be triaged the day it lands — coordinates against the agreed base point, tree walked for strays, properties sampled — in ten minutes, by whoever receives it. Splitting the checking into fast screens on receipt plus deep reviews on cycle takes days off the median latency without adding a meeting. (The ten-minute screen is exactly the IFC triage sequence we've written up.)

Attack access friction directly. This is the highest-leverage lever and the cheapest it has ever been: browser-based, licence-free viewers mean anyone on the project — the client's PM, the site team, the small subcontractor — can open the current IFC and look, today, with zero procurement. Every person added to the looking population is a latency reduction you didn't have to schedule. A free viewer link in the transmittal email does more for truth latency than another column on the clash report.

Give informational errors a reviewer. Since visual review won't catch them, name the check: per milestone, sample the property sets that milestone's consumers require — present, populated, plausible. Machine-readable requirement specs (IDS) point at full automation of this; a disciplined manual sample gets most of the value now.

Make status un-ignorable. Latency from wrongly-trusted information dies with boring CDE discipline: one place per project, statuses on everything, revisions kept. The behaviours cost naming conventions and habit, not platforms — as we argue in what ISO 19650 actually asks of a small practice.

Pro tip: You can measure your project's truth latency this month, retroactively, with the records you already have. Take the last ten issues raised in coordination — clashes, RFIs, model comments — and for each, establish two dates: when the underlying error entered the information (the model issue date, the revision that introduced it) and when it was raised. The gap is the latency; the ten gaps are your distribution. Teams that run this exercise are reliably shocked twice — once at the median, and once at discovering which kind of error owns the long tail. That second discovery tells you exactly which lever above is yours.

The cultural half

One honest caveat: latency is only half process. The other half is whether catching errors is safe. On projects where a raised issue triggers blame, people learn to look less — the finder pays the social cost of the maker's error, so rational people stop finding, and latency climbs while the review calendar looks immaculate. The teams with genuinely short latency share a tell: errors get raised casually, early, and without ceremony, because finding one is treated as the system working. You can't tool your way past a culture that punishes the messenger — but you can notice that every lever above also makes raising easier, and easier is how casual starts.

The access-friction lever is the one you can pull before lunch. Send the current IFC's recipients a link that requires nothing of them:

The BIM Model Viewer → — free, browser-based, no licences — because the fastest way to shorten the time to truth is to let more people look.