Kind Registry — Gemeinwert / BIM CVP Pilot

Status. Internal allocation, not a NIP yet. Maintained alongside pilot code. NIP proposal only after 3+ project validations.

Principle. Use existing kinds where they fit. Own range only where there is a NIP gap + replaceable need. Document tag conventions cleanly so future self and contributors don't have to guess.

Reference to standards. The version choices (which IFC, which BCF, which MVD …) are centrally fixed in STANDARDS-PROFILE.md. This registry describes only how the Nostr events are structured. When a standard version bumps, STANDARDS-PROFILE.md is updated; the corresponding tag value ranges follow here.

Own range 30900–30999 (parameterized replaceable)

Own range 1170–1179 (regular, immutable)

BCF viewpoint profile rule. 30901 lives in the addressable range so a viewer can look up a viewpoint by BCF GUID, but the pilot profile forbids republishing the same d value. BCF viewpoints are immutable; a changed camera, selection, clipping plane or snapshot gets a new BCF viewpoint GUID.

Own range 1180–1189 (regular, immutable)

Used existing kinds

Tag conventions (binding for the pilot)

Honesty tags — data provenance

CAM data is often modelled, not measured. Each sustainability value carries a source marker:

Usage example in a kind:30850 PDT or kind:30940 LCA event:

["epd-uri", "https://epditaly.it/epd/abc123"]
["epd-source", "verified"]
["epd-valid-until", "2029-04-15"]
["co2-source", "model"]

Audit trail thus shows what was estimated and what was measured. Over years, measured gradually replaces model values without structural change.

Private-layer cross-references (Bitcoin / White Noise / Bitcredit)

Per PRINCIPLES section 4 (Public ledger, private conversation): every signed public event MAY carry references to corresponding off-chain private artifacts. Identity stays npub-rooted; both layers share the same actor.

Usage example on a kind:30970 Approval event:

["a", "30902:<pubkey>:building-2026"]
["e", "<topic-event-id>"]
["bcf-status", "Closed"]
["white-noise-group", "mls-grp-building-hkls-bauteam"]
["bitcredit-note", "bcr:bn1...subleistung-EG-HKLS"]
["ots", "<base64 timestamp proof>"]

The Approval is publicly signed and auditable. The pre-discussion remains in the MLS group. The Real Bill is anchored on Bitcredit and references the same approval as its underwriting source. Three protocols, one event.

CAM Edilizia 2025 tags

Versioning policy

Two version axes

• bcf-version in the event references the buildingSMART BCF version the event is semantically compatible with (3.0 as default, 2.1 as fallback). This axis follows buildingSMART, not us.
• Our pilot schema iteration is tracked at the repo level: git tag, release notes, README.md. This axis describes how our tag conventions mature. Pre-1.0 expects breaking changes; consumers must be tolerant.

When to bump what

• buildingSMART version bump (e.g. BCF 3.0 → 3.1): update STANDARDS-PROFILE.md, extend the bcf-version value list here, events carry the new version once producers switch.
• Our tag rename or required-tag change: repo tag bump to major (e.g. v0.2 → v0.3), consumers need to adjust their parsers.
• New optional tags: repo tag bump to minor, old consumers work unchanged.
• Repo tag 1.0: only after NIP draft consensus and at least 3 completed pilot projects.

Current state

• Repo version: 0.1 (pre-release, breaking changes expected)
• BCF default: 3.0
• IFC default: 4.3.2.0 with Reference View MVD
• IDS default: 1.0

Path to NIP

1. Run through phases 0–6 of the Building pilot (see building-pilot-build-plan.md).
2. Review the event corpus — which tags were actually used, which were dead, which were missing.
3. Run schema validation over the gathered material, mark inconsistencies.
4. Write the NIP draft with real events as test vectors.
5. Consensus sondierung with 1–2 other AEC builders before PR.
6. PR against nostr-protocol/nips with the allocated range reservation.

Earliest Q4 2026, realistically Q1/Q2 2027.

This file lives with the code. Every change in the tag or kind schema = entry here. No tag convention in code that isn't documented here.