The Documented Data Map: the deliverable nobody else ships

Ask the owner of a ten-year-old commercial building one question and watch the room go quiet: "Where is the document that tells you exactly what every controller in this building measures, how it is wired, and who can read it without calling the vendor?"

It almost never exists. The building runs. The lights come on, the chillers cycle, the access doors unlock. But the knowledge of how it all fits together lives in three places: a few proprietary configuration files, the memory of one integrator's technician, and nowhere. When that technician changes jobs, the building loses part of its own mind.

At puniq we hand over one thing at the close of every engagement that fixes this for good. We call it the Documented Data Map. It is the deliverable nobody else ships, and once an owner has held one, they stop accepting projects that don't include it.

Once an owner has held a Documented Data Map, they stop accepting projects that don't include one.

What the Documented Data Map actually is

The Documented Data Map is the complete, vendor-neutral record of your building's nervous system. Not a marketing diagram. Not a one-page schematic for the pitch deck. A working reference an engineer who has never set foot in the building can open and understand on day one.

In practice it contains:

• A full point inventory. Every sensor, actuator, meter and controller, each with its real-world meaning, unit, range, and the system it belongs to. The temperature point in the east riser is named, located and explained, not left as an opaque register address.
• The protocol and wiring layer. How each device speaks (BACnet, Modbus, KNX, M-Bus, proprietary), on which network segment, through which gateway. The map shows the path data takes from the field device to the layer where a human or an algorithm can read it.
• The normalized data model. The single readable structure we build over the fragmented systems, so "supply air temperature" means the same thing whether it came from a 2009 chiller controller or a 2024 KNX panel.
• Gaps, assumptions and known faults. Where a point is mislabeled, a sensor is drifting, or a vendor would not expose a value, we write it down. Honesty about what is broken is part of the deliverable.
• Access and ownership. Who holds the keys, where the data sits, and exactly how the owner reads it without us in the loop.

It is produced on-premises, it stays with the building, and it is yours. There is no portal you lose access to when the contract ends.

Why legacy integrators don't produce one

This is the uncomfortable part. The absence of a Documented Data Map is not an oversight. For a traditional systems integrator or a PropTech SaaS vendor, the missing map is the business model.

1. The map is the lock-in

If you cannot read your building without the integrator, you cannot leave the integrator. Every change request, every new tenant fit-out, every fault diagnosis routes back through them at their day rate. A complete, vendor-neutral map dissolves that dependency. Producing it would be writing the exit clause out of their own contract.

2. The economics point the other way

Most integrators earn on hardware and on call-outs. Documentation is unbillable hours that reduce future call-outs. A SaaS vendor earns on the subscription and keeps your normalized data inside their cloud, where it is an asset on their balance sheet, not yours. Handing you a portable record of your own building works directly against how they make money.

3. Nobody built the system to be readable in the first place

Even where intent is good, the map often cannot be produced after the fact without real engineering. Fragmented multi-vendor buildings were assembled in layers over a decade, each contractor solving their slice and leaving. Reconstructing the whole picture takes the discipline to inventory every point and the patience to normalize systems that were never designed to agree. That work is exactly what most teams skip.

Why this is puniq's wedge

We start from the opposite premise. The building belongs to the owner, so the knowledge of the building must belong to the owner too. The Data Auditor exists to produce the Documented Data Map for buildings that already run multiple vendor systems, and the Infrastructure Blueprint produces it from the first day for new builds and deep retrofits.

This is a deliberate strategic position, not a feature. We are an asset-light software company. We carry no hardware on the balance sheet, so we have no incentive to sell you a controller you do not need and no reason to hide how the existing ones work. Our AI Optimization layer is advisory and human-in-the-loop by design, which keeps it useful without making you dependent on a black box. When the map is open, the optimization sits on top of something you can audit.

You do not optimize what you cannot measure, and you do not measure what you have not first documented honestly.

German engineering rigor is the method here. The map comes first because everything credible comes after it.

A building's controllers will be replaced. Its software will be swapped. The honest, vendor-neutral description of how the building thinks is the one thing worth keeping for its entire life. That is why we ship it, and why nobody else does.

If you own or operate a building and cannot put your hands on a document like this, that gap is the most expensive thing in the building you cannot see. Talk to us about an audit, and the first thing you will own at the end of it is the map.