Documents describe intent. Photographs record facts.
A construction project generates an enormous number of documents, and nearly all of it is a statement about the future. Drawings say what will be built. The programme says when. Method statements say how. Even progress reports, which sound like accounts of the past, are usually someone's summary of how the future is going.
None of that is a criticism. A project has to be planned, and planning produces documents. The problem arrives later, when something goes wrong and everyone reaches for the paperwork to establish what actually happened - and discovers they are holding a stack of intentions.
What Reality-Driven Intelligence is
Reality-Driven Intelligence (RDI) is a public framework published by Evercam at rdi.evercam.io. It is not a product. It is a description of how site reality should be captured, verified, interpreted, acted on and measured - and, more usefully, of the order those things have to happen in.
The framework sets out five layers, from the bottom up: Reality Capture → Ground Truth → Interpretation → Action → Command.
Reality Capture is observation of the physical site: sensors, cameras, wearables, equipment telemetry and site activity. The raw material - what was there, at what time, recorded by something with no opinion about it. Everything above inherits its limits: intermittent capture makes everything intermittent, and nothing without a timestamp can be placed in sequence.
Ground Truth is time-aligned, location-aware evidence of what is actually happening - observation turned into something verified and traceable back to what produced it. This is where most of the difficulty lives. A photograph is not evidence; a photograph with verified provenance is. The difference only shows when someone contests it, which is exactly the moment you cannot go back and add it.
Interpretation is meaning: detecting patterns, exceptions, risks and likely outcomes. Is that the third pour or the fourth? Is standing water on that slab normal for this stage? This is the layer the industry talks about most, and it is worth nothing without the two beneath it. A model reading a contested photograph produces a confident answer to an unanswerable question.
Action is alerts, workflows, escalations, tasks and follow-ups - what happens as a result. The test is whether the loop closes. This is where construction data initiatives most often stall: not because nobody understood the data, but because understanding it was not connected to anybody's decision.
Command is where the stack pays for itself: leaders directing attention, coordinating the response, and measuring whether any of it changed the outcome.
Why the order is the point
The stack is not a menu. You cannot buy a layer.
This is the single most useful thing about the framework. It also explains a familiar pattern in construction technology. Interpretation is what gets sold - analytics, dashboards, increasingly AI - and it is often sold on top of capture that is intermittent and provenance that was never established. The output looks impressive and cannot be relied on, because the thing underneath it was never verified.
The same trap is being set one layer higher. There is great enthusiasm for automated decision-making in construction and in the insurance around it. Decisions are the Action layer. An Action layer resting on unverified Interpretation resting on intermittent capture will make confident, fast, well-presented mistakes.
Build from the bottom. It is slower, and nothing built the other way round holds up when it is contested.
Bought by the project, valuable far above it
Now notice something about the shape of the stack.
Reality capture is almost always bought as a project management tool. Time-lapse for progress meetings, walk-throughs for coordination, sensors for the wet trades. The purchase sits with the project team and the case for it is operational. That is how the kit gets on site, and it is the right way round - a tool has to earn its keep where it is used.
But the framework does not end with the project team. Its top layer is written for leadership: directing attention across the work, coordinating response, measuring outcomes. A framework that terminates in the boardroom is making a claim - that verified site reality is not a site tool that happens to produce pictures, but an asset whose value runs up and out of the organisation that bought it.
Follow it up and the same verified account of the site is worth something to everyone above the project team: to the people signing valuations, to the people carrying disputes that turn on sequence and condition, to a board that sees its portfolio through reports written by the people it is trying to oversee - and, outside the organisation entirely, to the parties carrying the project's risk, who have historically seen least of all.
One purchase, made for operational reasons, producing an asset most of whose potential readers never open it. That is the situation the framework puts a name to.
And in one place, that value can now be counted
The honest difficulty with everything above is measurement. Most of those benefits resist a number - you cannot run the project twice, once watched and once not, and compare. For the severe physical damage losses in construction insurance - the fires, the collapses, the major escapes of water - events are too infrequent and too unalike for a book to accumulate credible experience of what continuous evidence contributed.
But not everywhere. Where the figures are already agreed, worth can be calculated instead of observed. In construction insurance that place is delay in start-up cover, where the sum insured, indemnity period, waiting period and rate are all written into the policy before anything happens. Our Reality Capture Value calculator does that arithmetic: on a project's own figures, it shows how many days off the waiting period would offset the whole capture spend. Not a forecast - arithmetic, checkable by anyone with a handful of numbers and a reason to check.
One corner of the picture, counted. The rest of the stack's value arrives the way the framework says it does: from the bottom, layer by verified layer.
Why photographs, specifically
Structured data answers the questions you knew to ask when you installed it. Imagery answers questions asked in the future.
That is the property that makes reality capture foundational rather than merely useful. A moisture sensor tells you about moisture. A camera tells you about the moisture, the scaffold, the sequence of the pour, the material stacked where it should not be and the weather that day - including the parts that only become interesting eighteen months later, when someone asks a question nobody anticipated.
It is also the layer with the least stake in the answer. A photograph taken by a fixed camera on a Tuesday has no position on the dispute that arrives two years later. Every document on the project has an author with an interest. The camera does not.
Where this leads
The framework applies well beyond insurance - anyone trying to build something reliable on construction data is working somewhere in this stack, whether they name it or not. It is worth reading in full at rdi.evercam.io.
Pikt works in the same stack. It gives risk engineers continuous visibility of the projects they oversee, by connecting to the reality capture and sensing already running on site and turning it into one time-stamped view of each project. That is the bottom of the stack made continuous, and made available to the people carrying the risk.
Everything else in construction risk is built on what the site actually was. What has been missing is not the account. It is its continuity.
Pikt - continuous site visibility for construction risk engineering. Pikt is an independent technology company. It is not an insurer, MGA or broker, and gives no insurance advice.