The Usage Rights Problem: Making Real Estate Data Governance Machine-Readable for APIs, Analytics, and AI

The fact that data is present in your warehouse does not mean every product, employee, model, or AI agent is allowed to use it in every way.

This is the sixth and final deep dive in the Databright Cloud Solutions Property Intelligence series.¹ The preceding articles addressed Property Identity, Semantic Consistency, Temporal Truth, Source Provenance, and Unstructured Evidence.

Those layers answer which property, what the fields mean, when they were true, where they came from, and what evidence supports them.

Data possession and data permission are different concepts

A data lake can contain information delivered under many different contracts and policies:

Flattening all of these into one unrestricted enterprise table creates governance debt.

The real estate standards community is actively working on this problem

In 2026, RESO expanded its work on Hierarchical AI Governance & Machine-Readable Usage Rights. Its Research & Development workgroup described a goal of creating machine-readable contract terms for AI model data usage⁸, while the broader governance effort began considering general non-AI data governance rules as well.²³

RESO product updates describe examples of data-license constraints such as training, derivation, and retention traveling directly with the data rather than remaining only in external agreements.⁴

At RESO’s 2026 Spring Conference, machine-readable rights and AI governance were explicitly discussed as a way for AI systems to respect content rights through transparent usage flags.⁵

Rights must be expressed in terms of actions

A binary field such as allowed = true is too weak.

The same asset may allow some actions and prohibit others:

W3C ODRL provides a useful policy model

The W3C Open Digital Rights Language (ODRL) is a machine-readable policy model for expressing Permissions, Prohibitions, and Duties over assets. Policies can also include parties and constraints such as temporal or spatial conditions.⁶

ODRL is not a real-estate-specific license standard, but it demonstrates the correct architectural idea: rights are structured rules over assets, parties, actions, duties, and constraints—not prose that a runtime cannot evaluate.

Rights are hierarchical

A policy may apply at different levels:

A platform needs inheritance rules that answer whether a more specific rule overrides, narrows, or adds to a broader agreement.

This is one reason RESO’s current work uses the term hierarchical governance.²

Rights decisions depend on more than the data asset

A production policy engine may evaluate:

A machine-readable property-data policy

Conceptually, a policy might state:

The engine can represent that as several independent rules rather than one ambiguous yes/no flag.

“AI use” is not one action

One of the most important distinctions in the emerging discussion is that AI-related use cases are materially different.

A contract that permits AI-assisted listing input may not necessarily permit model training. A rule permitting visual search tags may not necessarily permit image redistribution.

RESO’s 2025–2026 discussions reflect this distinction by separately considering training/learning permissions and AI enhancement workflows.⁴⁷

Media needs rights separate from structured listing data

Photos, videos, virtual tours, and floor plans often have different rights and copyright considerations from textual listing attributes.

A platform should therefore avoid applying one feed-level policy indiscriminately to:

• property attributes;
• agent remarks;
• listing photographs;
• generated thumbnails;
• image-derived structured features;
• embeddings;
• AI-enhanced media.

The Media Resource and the original source provenance need to remain visible to the rights engine.

Derived data creates the hardest policy question

Suppose a platform combines:

What rights govern the score?

The answer depends on the actual agreements and the degree to which the output is considered a permitted derivation. Architecturally, however, the requirement is clear: the score must know which upstream sources contributed to it.

This is why Deep Dive 04—Source Provenance—is a prerequisite for rights-aware intelligence.

Derived assets need policy inheritance

A useful rights engine should propagate policy obligations through transformations.

The exact legal interpretation must be defined by the agreements. The platform’s role is to retain enough provenance and policy metadata to enforce the organization’s approved interpretation consistently.

Policy conflicts need deterministic resolution

If one upstream source permits an action and another prohibits it, the runtime cannot guess.

A policy framework should define strategies such as:

W3C ODRL itself includes concepts for policy conflict strategies, reinforcing the need for deterministic conflict behavior in machine-readable policy systems.⁶

Retention should be executable, not calendar reminders

Contracts frequently contain requirements that data be removed, stopped, or retained only for a defined period.

The platform should be able to calculate:

Build a Policy Registry

Contracts and policy terms should be translated into governed machine-readable records with links back to the authoritative agreement.

Put policy evaluation in the runtime path

That applies to:

• REST and GraphQL APIs;
• warehouse queries;
• BI exports;
• download jobs;
• feature engineering;
• model-training pipelines;
• vector/embedding creation;
• RAG retrieval;
• AI-agent tool calls;
• generated media workflows.

AI systems need a policy-aware data gateway

A common architecture today sends whatever a user can search directly into an LLM.

A safer architecture evaluates rights before retrieval and again before output.

This avoids a situation where data that is licensed for internal analytics silently becomes part of an externally generated AI response.

Maintain a training-data eligibility registry

Model training is too consequential to rely on “everything in the lake unless excluded.”

Create a governed registry that classifies assets as:

Defaulting unresolved rights to “eligible” creates unnecessary risk.

AI-altered media needs disclosure and policy controls

RESO’s February 2026 workgroup update recommended best-practice guidance for disclosing when listing data or photos have been altered by AI and continued evaluating permissions related to listing data and photos.⁷

A media pipeline should track:

• original asset;
• transformation type;
• AI provider/model;
• generated/edited asset;
• required disclosure;
• allowed display contexts;
• original-media retention policy.

Every decision should be auditable

A policy engine should log:

Policy changes need impact analysis

Suppose a vendor renews its agreement and changes a rule from:

to:

With provenance and lineage, the platform can identify which:

• derived tables;
• scores;
• APIs;
• customer exports;
• models;
• embeddings;
• AI agents;

depend on that source and require remediation.

Rights governance needs measurable controls

Recommended rights-aware property architecture

A practical implementation path

The complete Databright Cloud Solutions Property Intelligence trust stack

The six problems in the original Real Estate Data Intelligence Gap article are not independent. They form a dependency chain.

The result is a governed Property Intelligence Layer

This is the difference between a large real estate database and a property intelligence platform.

Close the loop: governance must travel with intelligence

The industry has spent decades making more property data available.

The next challenge is making that data trustworthy enough for automated decisions and AI.

The six-part Databright Cloud Solutions Property Intelligence series can be summarized with six questions:

If a platform can answer all six consistently, it has moved beyond collecting property records.

It has built a foundation for trusted, explainable, and governable property intelligence.