BIM-CVP: Common Value Protocol for openBIM coordination.

Why CVP

Modern BIM coordination has a structural problem: the people creating project value often do not control the communication infrastructure they depend on. Coordination data is scattered across proprietary CDEs, email chains, PDFs, issue trackers, disconnected BCF silos and vendor-controlled platforms.

The result is predictable: lost context, unclear responsibility, duplicated coordination, platform lock-in, weak interoperability and expensive information asymmetry. BIM-CVP approaches that problem by separating the coordination record from the platform that happens to display it.

BIM and Nostr in plain language

BIM is the building-information side. It describes walls, ducts, spaces, equipment, requirements, issues and approvals as structured data instead of loose screenshots or email text. The important openBIM standards are already defined by buildingSMART and ISO: IFC for model objects, BCF for coordination issues, IDS for checkable requirements and ISO 19650 for information management.

Nostr is the signed-record side. It does not know what a wall, duct or BCF topic is. It only gives each author a keypair, signs small JSON events and sends those events to relays. BIM-CVP puts BIM meaning into those signed events: the standard still defines the domain data, while the signature proves who created the record and which file, topic or requirement it references.

Coordination as an economic process

BIM-CVP uses a simple Austrian-economics lens: coordination is a decentralized knowledge problem. No central platform possesses complete project knowledge. Architects, engineers, contractors, operators, suppliers and owners each hold local information that becomes valuable only when others can trust and use it.

This follows Friedrich Hayek's knowledge-problem insight: economically relevant knowledge is dispersed and cannot be fully centralized. In a BIM project, the same is true for constructability constraints, design intent, site conditions, maintenance requirements, product evidence and approval risk. Real coordination emerges through exchange between responsible individuals.

Rahim Taghizadegan's Austrian School work is useful here because it frames value as contextual, action-based and tied to responsibility. CVP turns that into a technical rule: if a project claim matters, it should be signed by the person or system making it, linked to the openBIM object it concerns, and portable beyond the application that created it.

Core principles

1. Sovereign communication

Project communication should not depend on a single software vendor or cloud tenant. Coordination events belong to the participants creating them. Identity is portable, history is verifiable and infrastructure can be federated.

2. Signed responsibility

Every coordination event is cryptographically signed. No anonymous edits, no invisible modifications and no uncertainty about authorship. That creates accountability, trust, traceability and professional ownership.

3. Open market coordination

Different tools should compete on usability and value creation, not on data captivity. BIM-CVP separates protocol, identity, transport and application layer. Any compliant application can participate, just as email and the web allow many clients and providers.

4. Distributed knowledge

Project intelligence emerges from many actors interacting through shared standards. BIM-CVP uses relay-based event distribution inspired by Nostr: lightweight, resilient, interoperable and vendor neutral.

Why not a blockchain for BIM

BIM-CVP is not about speculative tokens or artificial decentralization narratives. BIM coordination needs signed communication, interoperable issue exchange, verifiable history, resilient infrastructure and open standards. It does not need financialization to solve that problem.

Nostr gives us the useful part: public-key identity, event signatures, relays and simple JSON messages. Lightning-style settlement thinking is useful for payment references and paid validation services, but the coordination workflow remains practical engineering infrastructure.

Technical overview

BIM-CVP combines BCF semantics, signed Nostr events, relay distribution, optional encryption, IFC hash references, portable identities and append-only coordination history.

A BIM-CVP event can contain issue references, viewpoints, comments, approvals, coordination states, model references, signatures and timestamps. Each record is independently verifiable and can still be exported back into normal openBIM artifacts such as BCFZIP, IDS reports and IFC file references.

Sources

• buildingSMART International — Solutions and Standards
• buildingSMART Technical — standards portal
• Nostr NIP-01 — basic event model
• Hayek knowledge-problem reference
• Rahim Taghizadegan / scholarium
• Austrian Institute — Rahim Taghizadegan profile