The most common way a building loses its own history is at a handoff. A developer finishes, hands over a set of files on a drive, and the operator taking the building on starts again from a blank spreadsheet. Two years later nobody can say who installed the rooftop unit, what it was specified to, or whether the warranty on it has already expired.
The transfer between Scope3D and Clickpad exists to close exactly that gap. A twin authored upstream moves downstream intact: geometry, storeys, rooms, the assets mapped into those rooms, and the records already attached to those assets. What arrives is a building that opens populated rather than empty.
It is a real export and import running on a frozen shared contract, not a diagram in a deck. The payload is an organisation, a property, its locations, its assets, the model file itself, and the two mappings that tie the geometry to the operational data — space to location, and element to asset.
That shape matters because both sides already speak it. Scope3D authors it while it is building the twin, and Clickpad stores it in order to run the building, so agreeing on the handoff was mostly agreeing on field names and identifiers rather than inventing a new way to model a property from scratch.
What the receiving side gets is immediately usable. The twin viewer lights up, rooms resolve to real locations rather than labels, and an asset clicked in 3D has a service history behind it from the first day — instead of after a year of somebody patiently typing equipment lists into a new system.
The direction of travel is deliberate. Scope3D is upstream, where a building becomes a twin; Clickpad is downstream, where it is operated for the rest of its life. Water does not run back up the hill, and neither does the model. Origination and operations are different jobs with different users and different rhythms.
Ownership moves with the twin, which is what makes the transfer useful at a sale rather than only at first fit-out. Transfer hands the property and everything on it into the receiving account, under their control, so the building's accumulated record becomes an asset that changes hands with the deed.
It also works in the other order, which surprises people. A building can run in Clickpad for years with no model at all — QR intake, work orders, vendors, spend — and a Scope3D twin can land on top later, attaching itself to assets that have already been quietly accumulating history the whole time.
None of this requires the two products to merge, and merging them would cost more than it bought. They stay separate, priced separately, sold separately, with separate databases. What they share is one versioned contract that neither side is allowed to change unilaterally, because that is the only thing a transfer actually needs to be real.
The reason to insist on the word real is that this claim is easy to fake. "It all connects" is a slide anyone can draw. The version that survives scrutiny is the one where a specific building, with its specific assets, moved end to end and can be opened on the other side while somebody watches.
For an owner the practical question is simpler than any of this. If you build a twin during construction, does it still exist and still mean something in year fifteen, in a different system, run by a company you have not hired yet? That is what the transfer is for.