A site record is a permanent, time-indexed history of a physical location, anchored to that location’s address and coordinates, growing each time anyone captures or contributes data about it. It is the record of the place, not the record of any particular project or visit.
That’s the short answer. The longer answer is that the difference between a site record and ordinary file storage is one of the more important distinctions you can draw in spatial data management — and it’s the difference that decides whether the data you capture today is still useful in five years.
This post is the longer answer.
File storage vs site record
File storage keeps files. That’s its job, and the major platforms — Dropbox, Google Drive, OneDrive, SharePoint, Box — are very good at it. Files have names. Files live in folders. Folders nest inside folders. You upload, you download, you share, you sync.
A site record keeps something different: the history of a place. Files are part of it, but they are not the organising principle. The organising principle is the location. Every file is filed under the site it belongs to, time-stamped to when it was captured. The system knows that two LAS files captured six months apart at the same site are two views of the same physical asset. The folder model doesn’t.
The cleanest way to see the difference is to imagine asking each system the same question: what does the front retaining wall at 47 Park Street look like, and how has it changed over the last three years?
A file storage system has nothing meaningful to say. It can give you a list of files that contain “Park Street” or “retaining wall” in their filenames, if anyone has been disciplined about naming. It can show you what was uploaded when. It cannot show you the wall.
A site record opens to that address, displays every capture grouped by date, and lets you click between the November 2023, May 2024, and February 2026 sessions to see the wall in each one. The site record knows the wall is at that address; the storage doesn’t.
What makes a site record
Three properties define a site record and distinguish it from a folder of files.
Address-anchored
The record is keyed to the physical location, not the project, the customer, the contract, or the file itself. Customers come and go. Contractors change. Projects close out. Job numbers get retired. The address is the constant. As long as the building stands or the asset exists, the record persists against that location.
This is also what makes site records useful across organisational changes. When a property is sold, the record can travel with the property. When a maintenance contract is reassigned to a new vendor, the new vendor inherits the site record and starts contributing to it. The continuity is in the location, not in any particular relationship.
Time-indexed
Every file knows when it was captured. Every site can be viewed at any point in its history. Comparing two captures of the same location at different times is a built-in operation, not a manual exercise in finding the right files.
For physical environments, time is the second axis after location. A scan from 2024 and a scan from 2026 are not two versions of one file; they are two snapshots of one place at two different times. Treating them as time-indexed sessions — rather than as v1 and v2 of a file — preserves the chronology cleanly and makes time-series analysis straightforward.
For more on this from the spatial-formats angle, see what is a point cloud and what is a GeoTIFF.
Persistent and additive
Every visit adds a layer. Nothing is overwritten to make room. The record grows monotonically — the newest capture sits alongside everything that came before, not in place of it.
This is the property that produces the compounding value over time. After three months of contributions, the record is useful. After three years, it is irreplaceable. After ten years, it is the most accurate record of the asset’s history that exists anywhere.
A folder of files doesn’t behave this way. Folders accumulate clutter; old files get archived, deleted, or just become invisible under the weight of newer ones. Site records get richer.
Why it compounds in value
The compounding effect is the part that’s easy to underestimate. To make it concrete: consider a heritage agency that starts using a site record system for one of its listed buildings.
In the first month, the record contains a baseline condition survey — perhaps a point cloud, some orthomosaics, a few hundred photos, and a PDF report. Useful, but you could argue you got most of that value from the original survey on its own.
After six months, a conservation team has added a second capture documenting the early stages of stonework repair. The first comparison value emerges: the conservation team can now show, in the browser, the before-and-after of one wall. That’s a small but meaningful upgrade.
After two years, the record contains seven sessions covering different repair phases, an architect’s 3D model, a tourism-grade 360° tour, three sets of inspection photos by different contractors, and the original capture. Now the site record is a resource — for grant reporting, for tour development, for engineering decisions, for the public record.
After ten years, the record covers two full restoration cycles, three changes of conservation contractor, an emergency response after storm damage, the resolution of a heritage dispute, and dozens of routine inspections. The record is now indispensable. Replacing it would require time-travel.
The same compounding curve applies to mining operations tracking a pit, to infrastructure operators tracking a corridor, to field service businesses tracking a service portfolio. The longer the record runs, the more valuable it becomes — and the harder it becomes to imagine operating without it.
Who needs one
Anyone whose work involves repeat engagement with physical locations.
Surveyors and drone operators building deliverable archives that double as long-term references for their clients. See Swyvl for surveyors.
Field service and trades documenting every callout so the next technician dispatched walks in with full context. See Swyvl for field service.
Heritage agencies maintaining permanent records of listed buildings across portfolios of dozens to hundreds of properties. See Swyvl for heritage.
Asset owners receiving spatial data from multiple contractors and consolidating it into a single source of truth per asset. See Swyvl for asset owners.
Infrastructure operators treating each section of a corridor or each major structure as a site, with inspection and maintenance data accumulating against it.
Environmental monitoring teams doing time-series comparison across coastal erosion, vegetation change, water quality, and similar long-running observation programmes.
Construction project teams maintaining a permanent record of ground conditions, progress, and as-built reality at every site they work on.
Property developers and inspectors documenting condition before, during, and after development.
The common thread is that the location is the durable thing. Projects, contracts, and personnel all turn over faster than the physical asset does. A record organised around the physical asset outlasts any of them.
Where AI fits
Most of the discussion above is about humans using site records to understand physical environments. There is a second audience, and it is about to grow rapidly: AI systems trying to reason about the physical world.
Large language models can reason over text and code because text and code are well-structured, addressable, and queryable. They struggle to reason over the physical world because the data about the physical world is, almost everywhere, unstructured — files in folders, photos in phones, scans on hard drives, knowledge in heads.
A site record changes this. A site record is structured spatial data: each file knows where it is, when it was captured, what type it is, what site it belongs to, and what came before it. That structure is the kind of thing an AI agent will be able to query directly as the protocols for it mature.
Within the next few years — sooner than most people expect — AI agents will routinely answer questions like what was the condition of the south wall when the building was last inspected, which contractor delivered the most recent point cloud for this site, or show me everything captured at this address in the past 12 months. The agents will only be able to answer those questions for organisations whose spatial data is in a form that supports the query. Folders of zip files in SharePoint don’t.
For a deeper take on this, see why AI agents need a system of record for physical environments.
File storage, with extra steps?
A reasonable question at this point is whether a site record is just file storage with better metadata. The honest answer is that it could be, if you were diligent enough about how you used file storage. In practice, almost nobody is. The discipline required to maintain consistent address-keyed, time-indexed organisation across a large organisation, over many years, with multiple contributors, is more discipline than most teams sustain.
A platform built for site records bakes the discipline in. Files are uploaded against a site, time-stamped on capture, classified by format, and organised into capture sessions automatically. The user doesn’t have to remember to apply a naming convention or maintain a folder hierarchy. The structure is intrinsic to the platform.
That’s the whole proposition: take the work that someone could do manually if they were endlessly disciplined, and make it the default behaviour of the system.
Where Swyvl fits
Swyvl is a spatial data platform built around the site record idea. Files are uploaded against a site. Sites have addresses, coordinates, and a chronological history of every capture session that has ever been added to them. Every file gets the right browser-based viewer automatically. Every access is audit-logged. Every region is configurable.
The pitch is not “we store your files.” The pitch is “we maintain the spatial record of your physical environments, forever, in a form your team and the next generation of AI tools can actually use.”
If that sounds useful, the free tier is the place to try it. Set up one site, run a single capture session against it, and see how the record starts to behave. The compounding takes care of itself from there.