Real Estate Lifecycle Model · Open Standard

One language for the
entire lifecycle
of development.

RELM is a nonprofit consortium developing the open data standard that spans the full lifecycle of real estate development — from feasibility and financing through construction, handover, and 30 years of operations.

The Problem

The industry rebuilds its data infrastructure from scratch. Every project. Every time.

Every development project begins with the same invisible rework. A lender's draw schedule doesn't speak to a contractor's schedule of values. A proforma built in Excel shares no schema with the cost model built by the GC, which shares no schema with the asset management platform the owner will use for the next 30 years. The architect's BIM model — rich with spatial data — hands off to an owner who cannot consume it.

Data loss at handoff is not a technology problem. It is a standards problem. The industry lacks a shared language that spans the full development lifecycle — one that connects financial modeling, construction finance, contract management, physical asset data, and operations into a coherent, machine-readable whole.

The result is friction measured in billions: rework, disputes, missed compliance windows, and operating assets that have lost institutional memory of how they were built and what they cost. RELM exists to fix this.

A shared language that connects financial modeling, construction, and operations into a coherent, machine-readable whole.

Without a standard

Each stakeholder maintains a proprietary schema. Data is manually re-entered, reformatted, or reconstructed at every phase transition. Institutional memory is lost at every handover.

With RELM

A single ontology carries data from feasibility through 30-year operations. Automation becomes possible. Institutional memory is preserved. The industry advances together.

6
Phase transitions where
data loss typically occurs
10+
Stakeholder domains
with no shared schema
0
Open standards spanning finance,
construction, and operations
$1T+
Annual US development activity
without shared data infrastructure
The Case for Ontology

Why a shared ontology changes everything.

An ontology is not a data dictionary. It is a formal, machine-readable agreement about what things are, how they relate, and what properties they carry — across every stakeholder, every platform, and every phase of the lifecycle.

01 — Automation

Automation without rework

When every system speaks the same language, data flows automatically. A draw request validated against a construction loan model. A rent roll generated from a unit mix. A compliance certificate derived from as-built data.

02 — Continuity

Consistency across the lifecycle

A project entity defined at feasibility carries its identity through entitlements, construction, and operations. Budget line items remain traceable from proforma to pay app to capitalized asset.

03 — Interop

Interoperability by default

An open ontology with stable URIs and JSON-LD compatibility means any platform can adopt it, expose it, and consume it. Interoperability becomes the default, not the exception.

04 — Handover

Minimizing data loss at handoff

The most expensive moments in a development project are phase transitions. A shared schema with defined handover protocols means the information required at each transition is specified in advance.

05 — Industry

Advancing together

Proprietary data models benefit platform vendors. Open standards benefit the industry. When a small developer and a $20B REIT share a schema, knowledge transfers and benchmarks emerge.

06 — Compliance

Regulatory compliance as data

Tax incentive programs, affordability covenants, accessibility, environmental compliance — treated as first-class structured data, programs like 485-x, LIHTC, and IRA 45L become verifiable, automatable, and auditable.

The RELM Schema

One schema. Every phase.

RELM extends IFC (ISO 16739) as its physical asset base layer, adding owner-centric financial, contractual, and operational data where IFC ends. Expressed in JSON-LD with stable URIs, designed for registration in the buildingSMART Data Dictionary (registration pending — not yet submitted), and aligned with W3C Spatial Data on the Web standards.

Phase 01
Pre-Development
Proforma IRR/NPV Feasibility
Phase 02
Finance & Capitalization
Loan Equity Tax Incentives
Phase 03
Design & Procurement
IFC/BIM Contracts RFPs
Phase 04
Construction
Draws Change Orders Schedule
Phase 05
Handover & Closeout
COBie O&M As-Built
Phase 06
Operations
Rent Roll NOI Compliance
Schema Modules

Six modules. One ontology.

ProformaModel

Sources and uses of funds, equity waterfall, return metrics (IRR, equity multiple, cash-on-cash), hold period, sensitivities, and tax incentive modeling.

Maps to: OmniClass · OSCRE

ConstructionLoan

Draw schedule, interest reserve, SOFR forward curve, rate caps, covenant tracking, lender reporting, and completion guaranty milestones.

Maps to: MISMO

Contract + ChangeEvent

GMP and stipulated-sum contracts with AIA/ConsensusDocs mapping. PCO → COR → CO chain with cost, schedule, and float impact. Retainage and substantial completion.

Maps to: AIA G-series · OmniClass 22

PhysicalAsset

Extends IFC IfcBuilding, IfcSpace, and IfcElement with owner-facing properties. COBie handover. Equipment, warranties, spare parts, and O&M documentation linkage.

Maps to: IFC ISO 16739 · COBie · BRICK

OperatingStatement

EGI, vacancy loss, operating expenses, NOI by period. Lease abstractions, rent escalations, concessions, options, and tenant improvement allowances.

Maps to: MITS · OSCRE

TaxIncentive + Compliance

Program-specific structures for 485-x, 467-m/AHCC, LIHTC, IRA 45L/179D, and HTC. AMI band tracking, prevailing wage, refund mechanics, covenant recording.

Maps to: HUD · IRS · NYC HPD
Technical Reference

Built for interoperability. Open by design.

RELM is expressed in JSON-LD with resolvable URIs, aligned to W3C Spatial Data on the Web, compatible with OGC API Features, and extensible as IFC EXPRESS schema. Every property is designed for bSDD registration (registration pending).

Standards Alignment

Artifact (L2): IFC (ISO 16739) · MISMO · CSI MasterFormat / OmniClass · AIA G702/G703.
Crosswalk (L1): bSDD · GeoJSON.
Identified (L0): COBie · MITS · OSCRE · BOT · BRICK.
Planned, not yet mapped: CityGML · DTDL · BCF. See the maturity table below for what each level means.

JSON-LD IFC EXPRESS OGC API DTDL (planned) bSDD (L1)

Spatial Web Compliance

All spatial entities are addressable as stable web resources. W3C Spatial Data on the Web Best Practices. OGC API-Features endpoints. W3C Linked Data throughout.

W3C LBD Stable URIs Linked Data

Governance Model

Modeled on buildingSMART International. Technical Steering Committee with representation from each stakeholder domain. Semantic versioning. Public RFC process. CC BY 4.0 license.

Open RFC CC BY 4.0 Semver

Validation & Tooling

Shipping: a TypeScript SDK (@relm/schema — generated types + Ajv validators) and the @relm/adapter-mismo RELM↔MISMO adapter. Planned: Python SDK, IFC schema validator, bSDD registry submission. No third-party pilot validation yet — no integration has reached L3 (Tested).

TypeScript SDK Python SDK bSDD
Governance

A standard is only as good as the community that maintains it.

RELM is not a mature, settled standard. It is an emerging one. The schema is in v0.x working drafts, the working groups are forming, the first reference implementations are being built in production — but the consortium itself is in formation, the certifications do not yet exist, and the conformance suite has not yet been written.

This section describes the governance model we have designed and are committing to. The framework is concrete; what is missing is the community of organizations to put it into practice. Owners, developers, lenders, GCs, architects, BIM managers, asset managers, and platform vendors who recognize the data-loss-at-handoff problem and are willing to invest in solving it through an open standard rather than yet another proprietary integration.

Everything below is a commitment, but a commitment that needs partners to become a practice. If any of it resonates, the Get Involved section describes how to participate.

A standard without a community is just a document. We are building both, in public, and inviting partners in early.

Where we are today

Schema in active draft (v0.x). Reference implementations in production at one development manager. Two foundational working-group docs (this governance model and the dictionary versioning policy). No consortium membership yet, no formal TSC yet, no certifications.

Where we want to be

A working consortium with seats per stakeholder domain. A TSC ratifying RFCs against a predictable release cadence. A growing corpus of conformant apps publishing manifests against the dictionary. v1.0 as the first compliance target — earned, not declared.

Revision Cycle

Change should be predictable, slow, and visible.

Real estate operates on multi-year timeframes. A development project takes three to five years. An asset lives thirty to fifty. Software vendors plan integrations on multi-year roadmaps. So we are designing the release cadence for the industry's clock, not a SaaS API's. Building codes — IBC, NEC — operate on roughly three-year major cycles for the same reason. We follow that pattern.

Major
3 yr
v1.0 → v2.0 → v3.0

The compliance target

Curated, deliberated, ballot-approved. Breaking changes are concentrated here and earn their place through three years of accumulated adopter feedback. Apps declare conformance against a major version.

Minor
1 yr
v1.0 → v1.1 → v1.2

Additive only

Annual, or as needed. New optional entities, new optional properties, new enum values, new modules. Apps that conformed to v1.0 remain conformant in v1.1 — they may simply ignore the additions.

Patch
v1.1.1 → v1.1.2 → …

Corrections, anytime

Typo fixes, description clarifications, mapping corrections. The schema is unchanged. No re-certification or migration required.

Variances are the input pipeline for the next major.

Breaking changes should be earned. Between major releases, adopters file variances through three channels — app manifests, RFCs, and pilot-project gap reports. Twelve months before each major, the variance corpus is triaged: anything appearing in three or more independent implementations is auto-promoted to an RFC draft for the working groups to review. This is how a community-built standard stays community-built — the standard tracks the implementations, not the other way around.

  • App-manifest variancesEvery conformant app publishes a manifest declaring which entities and properties it implements and where it diverges — flagged as proposed addition, rename, deprecation, or implementation-only.
  • RFC submissionsLarger proposals — new entities, new modules, structural reorganization — enter through the RFC process, tagged with a target release so reviewers know what is on the docket.
  • Pilot gap reportsPilot projects file structured gap reports after each phase: what could not be expressed, what was ambiguous, what required workarounds. These feed directly into the next-major triage.
Compatibility Rules

What counts as a breaking change.

Within a major version, RELM is always backward compatible — an app that conforms to v1.0 is automatically conformant with v1.1, v1.2, and so on. Across majors, breaking changes are documented and tooled with a machine-readable rename map and JSON-LD context aliases so v1.x documents can be transformed to v2.0 without manual editing.

Breaking — major release only

  • An entity is removed or renamed.
  • A property is removed or renamed.
  • A required property is added to an existing entity (without a documented default).
  • A property's type changes in a non-widening way (e.g. string → integer).
  • An enum value is removed.
  • A relationship's cardinality is tightened (e.g. 0..* → 1..*).
  • A constraint is added that would invalidate previously valid data.

Non-breaking — fair game any minor

  • A new entity is added (no existing entity references it as required).
  • An optional property is added to an existing entity.
  • A new enum value is added.
  • A relationship's cardinality is loosened (e.g. 1..1 → 0..1).
  • A description, mapping, or note is updated.
  • A typo is fixed.
  • A property is marked status: deprecated with a replacement pointer.
Standards Maturity

Every integration carries a level.

RELM aligns with a stack of external standards — IFC, COBie, MISMO, MITS, OSCRE, bSDD, CSI, AIA, JSON-LD, OGC. Each integration is at a different stage of maturity. We publish the level honestly, so an adopter can tell what they are getting: a hand-derivable mapping, a validating artifact, or an artifact that has been through a real production system. No alignment claim without evidence.

0
Identified

On the roadmap

The standard is recognized as relevant to RELM. Source entities may exist as stubs. No artifacts yet.

Signals intent only.

1
Crosswalk

Mapping exists

A property-by-property mapping document maps RELM properties to standard properties with cardinality and notes. Gaps are explicitly listed.

Hand-derive an export.

2
Artifact

Validating artifact ships

A working implementation artifact (context, template, payload, sample) exists and passes automated validation against the standard's schema.

Structurally valid output.

3
Tested

Real system consumes it

The artifact has been validated against a real downstream system. Concrete evidence: a COBie sheet imported into an FM platform, a MISMO fragment accepted by a lender, an IFC export opened in Revit.

Works end-to-end.

4
Certified

Formal conformance

The criterion for this rung: formal conformance testing passes where the external body offers it — e.g. buildingSMART certification, MISMO review, bSDD Status=Active. No RELM integration has reached this level yet. Some standards cap at L3 by design.

The Foundation's name is on it.

Honest framing. As of v0.8, no RELM integration has reached Level 3. The most mature alignments — CSI MasterFormat, AIA G702/G703, IFC, JSON-LD, and MISMO — sit at Level 2 (Artifact), validated structurally but not yet run end-to-end through a third-party consumer. MISMO reaches L2 via the @relm/adapter-mismo bidirectional adapter (a focused ConstructionLoan subset, not full conformance). bSDD is at Level 1 (Crosswalk). COBie, MITS, and OSCRE are at Level 0 (Identified), awaiting their first crosswalk document. CityGML, DTDL, and BCF are roadmap candidates with no crosswalk yet.

Promotion is one-way within a major version, and a new minor version resets the obligation: if a context targets v0.8 at Level 2, and v0.9 changes the shape, the v0.9 context starts back at Level 2 and re-earns Level 3 / 4 through testing.

Commitments & Open Questions

What we are promising. What is still open.

What we commit to

The rules we will honor.

  • Backward compatibility within a major. If an app conforms to v1.0, it stays conformant through v1.1, v1.2, and every subsequent minor.
  • Five-year support per major. A major release is supported for five years post-publication. Two adjacent majors are always live — v1.x remains supported for two years after v2.0 ships.
  • Tooled migrations across majors. Each major ships with a migrations/ directory: machine-readable rename map plus JSON-LD context aliases so v1.x documents transform to v2.0 without manual editing.
  • Stable URIs. Once an artifact ships in a tagged release, its URL path remains stable. Corrections happen by superseding the artifact in a later version, never by re-pointing.
  • Open licenses, forever. Schema under CC BY 4.0. Code under Apache 2.0. The standard cannot be acquired or closed.
Open questions

What we are still working out.

  • Consortium incorporation. Legal status as a 501(c)(3) nonprofit is planned but not yet filed. Until then, governance is exercised informally by the founding members.
  • TSC composition. One seat per stakeholder domain is the target. Exact membership criteria, term lengths, and tie-breaking procedures are open for community input before v1.0.
  • CI enforcement. The freshness workflow defines validators for every artifact type. The GitHub Actions wiring to run them on every PR is partial — full coverage is a v0.9 commitment.
  • Spatial-data track. OGC API-Features, GeoJSON, and W3C SDW currently float across modules. Whether spatial gets its own standards/spatial/ track or stays per-module is open.
  • External-body relationships. Formal MOUs with buildingSMART, MISMO, CSI, and others are aspirational. We will pursue them as the consortium incorporates.
Founding Members

Started by practitioners. Built for the industry.

RELM was founded by development professionals who experienced the data problem firsthand — and decided to do something about it.

Founding member profiles coming soon.

Get Involved

The standard is only as good as the community behind it.

RELM needs practitioners, technologists, and institutions who live with this data problem every day. There are three ways in.

01 — Working Groups

Join the working groups

Each schema module is developed by a domain working group — owners, lenders, GCs, architects, operators, and regulators. Working groups meet monthly, vote on proposals, and own the peer review process for their domain.

Forming now: ProformaModel · ConstructionFinance · ContractManagement · PhysicalAsset · Operations · Compliance.

Apply to Join →
02 — Contribute

Contribute to the schema

Review open RFCs, submit pull requests, report issues, and help shape the data model. Domain expertise in any part of the development lifecycle is valuable — prior knowledge of IFC or JSON-LD is welcome but not required.

The schema, issue tracker, and RFC process are public on GitHub.

GitHub →
03 — Pilot

Pilot the standard

The RELM schema is validated through real projects. If you are an owner, developer, lender, GC, or platform vendor willing to apply the schema on a live or recently completed project, we want to hear from you.

Pilot partners get direct access to the TSC and co-authorship credit on the v1.0 publication.

Become a Pilot →
Support the Work

Fund the infrastructure the industry needs.

RELM is funded by member organizations, individual supporters, and foundation grants. No revenue from proprietary licensing. Every dollar goes to schema development, governance operations, and community tools.

Community
Free
Individual practitioners
  • Schema access (CC BY 4.0)
  • GitHub participation
  • Working group observer
  • Monthly newsletter
Get Started
Practitioner
Coming Soon
Owner / Developer
  • Working group voting member
  • RFC co-authorship
  • Pilot program access
  • Listed as supporting member
  • Direct TSC access
Join →
Institutional
Coming Soon
Firms & platforms
  • TSC seat (voting)
  • Named schema contributor
  • Logo on website & publications
  • Priority RFC review
  • SDK early access
  • Annual co-working session
Inquire
Founding Sponsor
Coming Soon
Foundations & major sponsors
  • Named founding sponsor
  • TSC co-chair eligibility
  • Dedicated working group
  • Joint press & publications
  • All institutional benefits
Contact Us
Contact info coming soon