The LAIRE Framework

Boards are not deciding whether members will begin using AI. Members are already using it in production work, often through general-purpose tools that sit outside a board-defined identity, permission, retention, provenance, and audit layer.

The RPR 2026 AI Adoption Survey also found that 92% use AI now or plan to, 71% identify time savings as its leading value, and 68% save at least one hour per week. The survey was self-reported by 225 U.S. NAR-member real estate professionals, so it should not be generalized as a census of every market. Read the full RPR survey .

The survey does not directly measure board oversight. The governance conclusion is an inference: when adoption is already embedded in member workflows, the practical choice is no longer AI versus no AI. It is governed, permissioned paths versus unmanaged workarounds with weaker visibility and fewer shared controls. What members can already delegate is measurable: HomieBench v6 benchmarks twelve frontier models across 100 supervised REALTOR® workflows.

The detailed answers sharpen that inference. In Q5, 38.74% reported using market analysis or pricing tools and 22.52% reported AI CMA tools. In Q7, 30.63% reported analyzing market trends and 24.32% reported running CMAs or pricing conversations. One qualitative respondent also said they use AI heavily when processing trends from MLS® listing data. The survey does not establish how common it is for members to paste MLS® listing data, client, or transaction data into a model, but it demonstrates enough high-stakes use to make data-flow controls urgent.

Since the first edition, the regulators moved

Governance is no longer only a board decision. Between the July 2026 edition of this paper and September 2026, associations, regulators, and legislatures on both sides of the border published specific expectations for AI in real estate practice, and every one of them said the same thing in its own vocabulary: the tool changes the workflow, not the duty. The full map is in Section 20; four dates set the tone.

Adoption is ahead of governance. Waiting does not preserve the status quo; it cedes the control surface.

Every day that an approved AI workflow remains unavailable, another member still has a listing to explain, a market analysis to prepare, or a client to serve. The demand for help does not wait for the access framework. If the practical route is to export a report, paste records into a chatbot, or connect an assistant to a logged-in browser, the decision about where protected information goes falls to that individual and their chosen vendor. The absence of an approved path does not remove the workflow. It can remove the institution from the workflow.

This is the central urgency behind LAIRE. Boards and associations have invested in trusted records, permissioned distribution, professional accountability, and consumer confidence. A member improvising an AI workflow can move information beyond those controls in seconds. Each additional unmanaged copy can add another processor, retention policy, access point, and unresolved question about deletion. Retrofitting governance after that distribution has occurred is harder than checking permission before the first request.

The protection paradox: caution can increase the exposure it seeks to prevent

Boards face a real governance and ethical dilemma. They must avoid enabling unauthorized use of data, yet they must also consider the foreseeable consequences of leaving members without a workable authorized route. Concern about AI can delay governed integrations; those delays can encourage workarounds; and the resulting incidents can deepen concern about AI. Without a practical alternative, that cycle can reinforce itself.

1. 1. Legitimate concern

   The institution sees privacy, licensing, accuracy, and security risks and limits access.

2. 2. Unmet demand

   Members still need to finish the work, while the permitted route is unavailable, unclear, or cumbersome.

3. 3. Improvised access

   Some members turn to copy-and-paste uploads, exports, unofficial connectors, or broad browser sessions.

4. 4. Weaker oversight

   The provider has less evidence about downstream recipients, purposes, retention, and reuse; uncertainty reinforces hesitation.

This is a structural risk wherever approved access lags adoption. It is not a finding that any particular board caused a breach or that members are excused from their obligations. REALTORS® remain responsible for following professional rules and applicable agreements, including when a workaround feels harmless or its restrictions are poorly understood. Institutional stewardship also requires evaluating how people actually complete their work. A restriction is stronger when it is paired with a usable, enforceable way to do the permitted task.

The industry already has a basis for that response. CREA’s AI position supports responsible adoption and collaboration, while TRREB’s June 2026 statement describes its support for responsible AI and investment through PropTx. LAIRE proposes a practical access architecture to advance those objectives. Discussion or review of this paper does not establish adoption, endorsement, or certification by either organization.

Data leakage begins with unauthorized disclosure; training is a separate downstream risk

A copied listing report, client note, or transaction document may contain information the member can view but cannot authorize a third party to retain or reuse. Uploading it to an unapproved service can breach the applicable licence, confidentiality duty, consent, or brokerage policy even if the AI produces an accurate answer. TRREB’s May 2026 AI guidance addresses cut-and-paste practices and client-data protection. BCFSA’s guideline also calls for informed consent, vendor diligence, and attention to storage and secondary use.

Some consumer products or account settings permit inputs to be used for model improvement; others exclude that use by default. The relevant questions are which product received the information, under whose account, on what terms, with which settings and downstream processors. OpenAI’s data-use policy distinguishes individual services from business products and the API, which exclude training by default unless opted in. Anthropic’s commercial policy also excludes training by default, with stated exceptions. Price alone is not a compliance test.

A no-training commitment addresses one use of data. It does not supply missing disclosure rights or eliminate conversation history, stored files, caches, logs, subprocessors, or unauthorized redistribution. The nine retention surfaces in Section 7 remain separate controls. Once data has left the approved boundary, revoking access cannot be assumed to recall every copy or reverse any training that has occurred.

Evidence boundary: the adoption survey above establishes usage and reported concerns, not the prevalence of unauthorized uploads, breaches, or model training on protected information. The failure pathways described here are a risk analysis supported by published guidance; they are not an estimate of how many REALTORS® or boards are noncompliant.

Usability is part of the control system

The approved route must compete with the convenience of the workaround. A policy that asks every REALTOR® to interpret several vendors’ terms, configure credentials, and judge the permissions of every field before doing routine work asks individual members to recreate vendor diligence and data-governance checks for every task. Education remains necessary; the product should perform the repeatable checks.

Members should be able to find an approved connection, sign in with their existing identity, authorize a clearly described task, and get a useful result in a familiar workflow. The service should resolve entitlements, limit fields, preserve attribution, and record the access automatically. If a request is outside scope, explain the limit and offer a permitted next step. Consequential approvals must remain explicit and meaningful. Remove needless setup work while preserving the decisions that require an accountable human.

This creates a practical alignment of incentives: REALTORS® gain speed and confidence; brokerages gain supervision; and boards, associations, and other data providers gain evidence about how their approved capabilities are being used. Measure successful task completion, time to connect, repeat use, avoidable denials, and member-reported workarounds. A connector that exists but is rarely usable leaves much of the governance gap intact.

The recommended route: a governed API, with MCP for approved AI connections

An API is the service interface that carries a request and its result. Model Context Protocol (MCP) gives AI applications a common way to discover and call tools. The recommended pattern is complementary: enforce policy in the underlying service and expose a narrow set of those same capabilities through an MCP adapter where approved AI clients support it. The adapter and service can be delivered together; the controls must remain effective through every interface.

Boards do not need to replace their systems of record or publish an unrestricted data feed. They can work with existing vendors to expose permitted searches, secure report views, and approved aggregate calculations. Where applicable, the RESO Web API provides an existing data-access foundation; access still depends on the provider’s licensing and permissions. An available endpoint does not itself authorize an AI workflow.

MCP is an integration standard, not a guarantee of compliance. Its authorization specification defines transport-level authorization, and its security guidance prohibits token passthrough. LAIRE additionally requires server-enforced business permissions and an approved receiving environment. Returning protected records through MCP to an unapproved consumer chat can recreate the original disclosure problem through a newer interface.

Visibility should improve stewardship without creating another sensitive data store

A governed call can tell a provider which authorized principal used which capability, for what declared purpose, against which permitted data class, under which policy, and with what result or denial. Aggregate patterns can identify demanded services, recurring permission failures, suspicious extraction, and capabilities worth investing in. This is evidence the provider may never receive from a spreadsheet pasted into an unrelated AI account.

That visibility has limits. A declared purpose is a claim to validate, and a call log cannot prove every downstream use. Approved-client controls, contracts, testing, and investigation remain necessary. Audit metadata should be proportionate, access-restricted, and retained for a defined period; it should not become a second repository of client conversations, offers, or confidential listing remarks. Measure activity through the governed route and use member feedback and incident reporting to assess what remains outside it.

The next board decision should fund a usable path

The one-year roadmap in Section 12 remains the staged implementation plan. Its first 90 days should produce accountable decisions and a testable route, with a limited live pilot only when rights and controls are ready. This mobilization agenda can begin before every standards annex is complete:

• Assign an owner and a deadline. Bring data licensing, legal, privacy, security, technology, brokerage supervision, and member experience into one accountable program. Publish permitted uses and a clear route for requesting additional capabilities.
• Start with the work members already do. Inventory common AI tasks and existing workarounds with members and vendors. Choose one high-demand, bounded workflow, such as a permissioned listing search with secure rendering, and document its rights and data flows.
• Build and test the approved connection. Use synthetic data until permission and controls are established. Verify identity, field restrictions, retention, extraction limits, malicious-input handling, audit events, and revocation before protected data enters a pilot.
• Make adoption and oversight joint success criteria. Publish a simple onboarding path and review task completion, member uptake, repeat use, denials, incidents, and control performance. Expand only when the evidence supports it; remedy friction that keeps pushing work outside the approved route.

Boards concerned about AI data misuse should treat a usable, governed API and, where appropriate, an MCP connection as a priority for data protection. They can procure or jointly develop that access through existing providers under clear, consistent requirements. The case for action does not depend on proving that every member is breaking a rule. It rests on a foreseeable exposure, established professional duties, and the opportunity to bring useful work into an environment where permission can be checked and accountability can be demonstrated.

The industry’s responsibility is to make the permitted path work well enough that members choose it—and to make every permitted action accountable.

Agentic AI is becoming an interface through which consumers and professionals discover information, compare options, make decisions, and initiate action. In real estate, the interface that captures the question also captures commercially valuable intent: preferences, search refinements, objections, timelines, affordability constraints, and next steps.

Boards and MLS® system operators therefore face two risks at once. Blanket prohibition can push members toward ungoverned consumer tools and workarounds. Unrestricted access can transfer protected listing, client, and transaction data into systems that were not designed to govern it. Neither extreme is durable.

The AI may receive capabilities. It must not receive custody.

LAIRE—Layering Agentic Intelligence on Real Estate, the proposed standard first published as RAILS—keeps protected data in its proper system of record while exposing narrowly scoped, identity-bound, purpose-bound, auditable capabilities. Models may search, summarize, prepare, validate, or request an action. They do not receive feed credentials, become the CRM, persist a shadow listing database, create the authoritative contract in an unapproved sandbox, or apply a signature.

The result is a model-agnostic architecture that combines zero trust, least privilege, purpose limitation, split-channel secure rendering, deterministic computation, human approval for consequential actions, immutable audit events, and capability-level vendor certification.

Version 2.0 adds two things the first edition could only anticipate. Section 20 maps the AI guidance published by regulators, boards, and associations in 2025 and 2026 to specific LAIRE controls, so a board can see which requirement each control satisfies. Section 21 argues that the enforcement surface has moved: model providers and agent harnesses now refuse non-compliant real estate work before any regulator sees it, which makes compliance-native execution the only reliable path to capability. We designed Homies that way, and we hope the rest of the industry builds the same way.

Organized real estate was built around cooperation: competing professionals shared inventory under common rules for attribution, access, display, accountability, and data quality. That cooperative infrastructure also created an information advantage. AI and open distribution are reducing the marginal cost of basic access and interpretation.

The professional does not disappear when information becomes cheaper. The professional’s comparative advantage moves toward fiduciary alignment, judgement under uncertainty, negotiation, risk ownership, service coordination, and accountable execution. The board’s advantage changes in parallel: from information scarcity toward identity, permission, provenance, quality, interoperability, auditability, and revocation.

The market is already showing this shift. In October 2025, Zillow and OpenAI launched a conversational listing experience inside ChatGPT. Zillow says it controls the rendered experience, does not send OpenAI a raw U.S. listing-service feed, and preserves listing-service attribution and field controls. That architecture is a live example of a capability being made available without transferring feed custody. See the primary announcements from Zillow and Zillow’s industry explanation .

In June 2026, HouseCanary described a national expansion of Google’s mobile home-discovery program using listings from participating U.S. multiple listing services with broker and agent attribution. The announcement is evidence of real-estate discovery moving into a horizontal intent layer, although it should not be read as proof of any architecture beyond what the publisher describes. See the HouseCanary announcement .

Tool-connected AI is also becoming portable. OpenAI’s Apps SDK is built on the Model Context Protocol; Anthropic describes MCP as an open standard for connecting AI systems to external tools and data. These facts do not prove that every portal will integrate with every model. They do establish the interface pattern: natural-language request, controlled tool call, external system, structured result, and rendered experience. See OpenAI and Anthropic .

The choice is not “AI or no AI.” It is whether adoption happens inside a governable perimeter or outside one. Governed access creates new diligence and enforcement work, but it also gives boards a path to set requirements, certify capabilities, monitor use, revoke access, and keep professional accountability visible.

Custody exists when a model provider, agentic harness, or vendor application can persist, redistribute, train on, broadly index, or become an alternate source of truth for protected data. Capability exists when an authenticated actor can request one defined business action through a controlled service with bounded input, output, purpose, retention, and side effects.

Every capability should declare its eligible actors, allowed purpose codes, data classes, result ceilings, risk tier, human approval requirement, retention class, audit events, failure behaviour, and revocation path. Credentials remain at the gateway or system of record; they never enter model context.

• The model is never the system of record.
• Protected data is purpose-bound and minimized.
• Credentials and signing keys never enter model context.
• Deterministic services calculate and validate where correctness matters.
• Consequential actions remain attributable to an authorized human.
• Every access is observable, revocable, and auditable.
• Interfaces remain model-agnostic to reduce platform lock-in.
• Human-rights, privacy, and professional duties are enforced by design.

A workable policy must stop treating “real-estate data” as a single class. Listing, client, and transaction data carry different permissions, risks, and authoritative systems. LAIRE applies the same boundary to all three while preserving those differences.

Split-channel secure rendering

Protected listing detail does not always need to enter the model’s natural-language context. The model can receive a count, an opaque widget reference, policy metadata, and a secure view URL. The user interface then retrieves the authorized listing component directly from the IDX, VOW, DDF, brokerage, or board-controlled origin. The display channel and the model channel remain separate.

This pattern is compatible with existing permission-based distribution models. CREA describes REALTOR.ca DDF® as a managed, permission-based service in which broker owners control how listing content is shared. RESO publishes current Web API and Data Dictionary specifications that can provide common vocabulary for capability schemas. See CREA DDF® and RESO specifications .

LAIRE separates probabilistic interpretation from identity, authorization, calculation, recordkeeping, and binding execution. A model may infer what a user is trying to achieve; it does not decide whether the user is entitled to achieve it.

The policy and identity plane evaluates the subject, action, resource, data class, purpose, consent, jurisdiction, time, and risk tier. The capability gateway then asks the authoritative application to perform the action. The default response is the minimum sufficient projection—not the entire underlying resource.

allow = policy(
  subject,
  action,
  resource,
  data_class,
  purpose,
  consent,
  jurisdiction,
  time,
  risk_tier
)

result = minimize(authoritative_data, purpose, role, consent, policy)

This architecture follows the same direction as zero-trust systems: no implicit trust based on location or ownership, explicit authentication and authorization, and policy focused on users, services, and resources. NIST SP 800-207A further describes granular application-level policy enforcement through gateways and service identities. See NIST SP 800-207 and NIST SP 800-207A .

REALTORS® and brokerages already use authorized IDX websites and applications to present listing information under applicable agreements, board rules, display requirements, and participant control. Coding agents can also modify website code. LAIRE combines those facts without creating a new raw-data entitlement: the approved IDX application remains the only runtime permitted to hold credentials, query live listing data, enforce field and display rules, and render the result.

NAR’s current IDX policy describes authorized display through participant-controlled websites, mobile apps, and other approved mechanisms, requires the participant to control how listings are displayed, and states that access to a U.S. multiple listing service database may not be given to an unauthorized person or entity. See NAR IDX Policy Statement 7.58 . In Canada, CREA describes DDF® as a permission-based distribution service and a Member Website Feed for listing display on a member-controlled website; see REALTOR.ca DDF® .

The coding agent changes the experience. The approved IDX application controls the data.

The model may help create a custom buyer-search page, neighbourhood experience, listing comparison, property page, or deterministic home-evaluation workflow. It can edit React components, templates, schemas, tests, mock fixtures, explanatory copy, and approved parameterized query definitions. It must not receive the raw feed, reuse feed credentials, query the live database, create a shadow index, or copy bulk listing data into model memory.

capability: idx.page.render
actor: participant_controlled_website
agent_visibility: [schema, mock_fixture, query_definition, rendered_metadata]
agent_prohibited: [feed_credential, live_database, raw_payload, bulk_export]
runtime:
  execute_query: approved_idx_application
  enforce: [field_permissions, attribution, freshness, display_rules, rate_limits]
output:
  returns: [rendered_page_ref, result_count, data_as_of, provenance]
deployment:
  tests_required: [query_bounds, prohibited_filters, attribution, stale_data, extraction]
  human_approval: required

RESO notes that its Web API can execute live queries for immediate results in web applications and defines an IDX payload as the structured fields needed for display on an IDX website. LAIRE places that live query and payload handling inside the authorized application boundary—not inside model context. See the RESO Web API overview .

• The website or approved application—not the model—is the data recipient and runtime.
• The coding agent receives schemas, fixtures, and opaque result references, not feed credentials.
• Live queries execute server-side under participant identity, purpose, and policy.
• Rendered pages preserve attribution, freshness, filtering, display, and access requirements.
• Every deployed code or query-definition change is tested, reviewed, versioned, and reversible.
• Boards can audit and revoke the application capability without granting access to the model.

LAIRE is not only a listing-search architecture. The same capability-without-custody boundary applies to the repetitive workflows that REALTOR® tools are beginning to automate. Each workflow needs a named action, authorized actor, purpose, minimum data, deterministic checks, human boundary, audit event, and revocation path.

Agent-to-agent showing booking: ShowingTime API, BrokerBay API, Touchbase API, Aligned Showings API, SentriKey Showing Service API, Instashowing API, and Showingly MCP

Showing coordination is a strong candidate for a board-defined agent-to-agent profile. A buyer agent’s AI should be able to ask a listing agent’s authorized service for permitted availability, submit one traceable request, receive an approval, counter-time, or decline, and reconcile both calendars. Neither model needs the other REALTOR®’s password, browser session, seller instructions, alarm code, lockbox data, or full client record.

The workflow crosses REALTOR® identity and delegation, listing status, buyer context, calendars, seller or tenant approval, appointment state, secure access instructions, notifications, and feedback. That makes a normal browser session too broad and an unstructured chat between bots too weak. The system of record must authorize and execute each state transition.

Review the current publisher material for ShowingTime+ , BrokerBay , Touchbase , Aligned Showings , SentriKey Showing Service , Instashowing , and Showingly API and MCP access . Zillow’s Real-Time Touring also documents a ShowingTime-integrated consumer and agent flow; see Zillow .

1. 01

   Delegate

   Each REALTOR® authorizes their own agent with a short-lived, tenant-bound token and explicit showing scopes.

2. 02

   Discover

   The buyer-side agent reads permitted slots without receiving seller notes, alarm data, or lockbox credentials.

3. 03

   Request once

   A create call carries buyer-context reference, requested slots, purpose, trace ID, and idempotency key.

4. 04

   Apply listing policy

   The listing-side service checks status, showing rules, calendar conflicts, and required human or seller approval.

5. 05

   Reconcile

   Both sides receive the authoritative status by webhook; calendars update from the appointment reference.

6. 06

   Reveal securely

   Only after confirmation, entitled users retrieve time-bound access instructions through a separate secure channel.

framework_version: laire/2.0
profile_schema: laire-capability-profile/1.0
capability: showing.request_create
eligible_roles: [licensed_realtor, authorized_assistant]
required_scopes: [showing:availability_read, showing:request_create]
delegation:
  subject: realtor_id
  tenant: board_or_brokerage_id
  token_ttl: short
input:
  listing_ref: opaque
  requested_slots_max: 3
  buyer_context_ref: crm-scoped
  idempotency_key: required
policy:
  listing_status_current: required
  calendar_conflict_check: required
  agency_and_consent_state: required
output:
  returns: [request_ref, status, expiry, secure_instruction_ref]
  model_visibility: no_lockbox_or_confidential_instructions
human_review: required_on_exception
audit: signed_tamper_evident_events
revocation: immediate

• showing.availability_read
• showing.request_create
• showing.request_respond
• showing.request_reschedule
• showing.request_cancel
• showing.instructions_render_secure
• showing.feedback_submit

AI Follow Up Boss, AI GoHighLevel, AI Lofty CRM, AI kvCORE / BoldTrail, Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, and Top Producer

Search demand is clustering around specific REALTOR® tools, but the governance unit should remain the capability. The 84-system integration directory maps this landscape with documented access status for every system. Follow Up Boss documents a REST API and signed webhooks. HighLevel exposes contacts, conversations, calendars, opportunities, payments, and a broad webhook catalogue. Lofty documents developer access to leads, listings, transactions, communications, and AI features. BoldTrail is the current ecosystem name associated with kvCORE. Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, Top Producer, HubSpot, Salesforce, and other CRMs vary in partner access, object coverage, and commercial terms.

LAIRE should make those differences explicit while preserving common actions: crm.person_match, crm.note_create, crm.task_create, crm.appointment_create, crm.stage_propose, and crm.opt_out_record. See the developer materials for Follow Up Boss , HighLevel , and Lofty .

AI offer writing in SkySlope, CREA WEBForms, Lone Wolf Transactions, zipForm, TransactionDesk, dotloop, Form Simplicity, DocuSign, and Authentisign

Offer preparation is where a convenient browser workaround can become an authoritative legal-document problem. Common Canadian and U.S. systems include SkySlope, CREA WEBForms powered by TransactionDesk, Lone Wolf Transactions (zipForm Edition), Lone Wolf Transactions (TransactionDesk Edition), dotloop, Form Simplicity, Authentisign, DocuSign, Brokermint, Paperless Pipeline, Glide, and brokerage-specific compliance portals. The approved form library, brokerage rules, identity, audit, and exact document version must remain attached to the workflow.

CREA describes CREA WEBForms as an end-to-end document and transaction-management product powered by TransactionDesk. Product access through a member interface does not itself authorize an agentic browser to reuse that member’s credentials or session.

Several vendors already provide safer integration paths. SkySlope documents transaction-management APIs and an Offers API; Lone Wolf publishes partner APIs for TransactionDesk, zipForm, Transact, and Deals; dotloop documents an OAuth 2.0 public API; Form Simplicity documents scoped transaction endpoints; and DocuSign exposes its eSignature REST API. See SkySlope , SkySlope Offers , Lone Wolf , dotloop , Form Simplicity , and DocuSign .

A board or brokerage may also approve a self-hosted signing service such as DocuSeal , which documents on-premises deployment plus API and webhook support. Open source does not by itself establish legal validity, security, insurance coverage, retention compliance, or approved-form rights; those still require diligence and policy. Nano-PDF is an open-source AI PDF-editing CLI that recreates pages and restores searchable text with OCR. It may help with nonbinding presentation material, but it is not an e-signature or transaction system of record and should not generate or mutate authoritative offer forms. See the Nano-PDF project description .

• forms.template_read
• transaction.draft_create
• transaction.fields_propose
• transaction.validate
• esign.envelope_create_draft
• transaction.dispatch_approved

Form copyright and field mapping: user entitlement and vendor permission

OREA owns its standard forms and clauses. Its public terms permit specified member uses, restrict modification and transfer, and require a separate written licence for software functionality beyond downloading or printing. They contain no express exception for a member uploading a form into an AI SaaS. See the OREA Standard Forms Terms of Use .

California is stricter. C.A.R.’s copyright policy limits its standard forms to a member’s individual use in their own transactions and prohibits exporting blank forms from a forms-filling platform, modifying pre-printed text, posting blank forms, and placing the forms in any other software program, with one exception: a completed form in locked PDF format saved in connection with a transaction. Since the 2019 sale of zipLogix, C.A.R. has licensed the forms to additional platforms and brokerages on the condition that they maintain the content exactly as provided. Texas shows the other end of the range: TREC-promulgated contracts are public records anyone may use, while Texas REALTORS® forms are copyrighted and member-only. See C.A.R.’s copyright policy and terms-of-use reminder .

LAIRE therefore requires two checks: the REALTOR® is entitled to use the instrument, and the vendor is permitted to perform the requested processing. Calling the vendor a service provider, assistant, or form-filler does not transfer the member’s licence. Separating transaction facts, mapping code, template content, and signing authority makes those checks easier to enforce; it does not replace them.

framework_version: laire/2.0
profile_schema: laire-capability-profile/1.1
capability: forms.fields_map
risk_tier: 4
eligible_roles: [licensed_realtor, authorized_assistant]
template:
  source: approved_platform | separately_licensed_vendor
  platform_api: partner_gated_where_documented
  identifier: platform_verified_form_id
  revision: platform_verified_revision
  master_template: immutable
  copyright_notice: preserved
  vendor_hosted_blank_template: prohibited_without_association_licence
input:
  schema: apso-fields/1.0
  mapping_manifest: [field_id, value, source_ref, confidence]
  mapping_target: approved_platform_data_model | separately_licensed_fields
  clause_selection: permitted_library_with_professional_review
authorization:
  vendor_agreement_ref: required
  publisher_rights_ref: required
  tenant_and_user_entitlement: checked_per_request
  processors_and_harnesses: approved_by_policy
validation:
  required_fields: deterministic
  parties_price_deposit_dates: deterministic
  revision_matches_platform_current: required_else_fail_closed
output:
  returns: [draft_ref, mapping_manifest_ref, provenance]
  model_visibility: field_values_only
human_review: exact_version_approval_required
prohibited: [unauthorized_template_use, silent_preset_rewrite, notice_removal, unapproved_training_or_indexing]
audit: signed_tamper_evident_events

• User entitlement and vendor permission are separate. Neither is inferred from access to a PDF or an API key.
• Transaction facts, mappings, templates, and clause libraries have distinct rights and processing rules.
• Preserve the master template and notices. Any permitted transaction-specific amendment must remain visible and attributable.
• Every mapping binds to a form identifier and revision and fails closed when the platform’s current version differs.
• Clauses come from the association’s standard clause library; custom clauses are flagged for licensed and legal review.
• LAIRE requires deterministic validation followed by professional review of the exact draft; any contractual accuracy obligations must also be recorded.

Jurisdiction profiles carry the forms facts. The ca-on profile records OREA’s member terms and the platform-licence requirement; us-ca records C.A.R.’s locked-PDF exception and licensed-platform rule; us-tx records that TREC contracts are public and Texas REALTORS® forms are member-only. A vendor operating in all three cannot use one forms policy, but it can use one architecture.

Do the platform APIs actually exist?

Yes. Access models differ by product: some require a partner agreement, while others document developer registration and user consent. The references below describe supported transaction data and document operations; they do not establish unlimited field access or publisher rights. Verify field propagation for each form and revision in the approved sandbox before promising automatic completion.

Target the approved platform’s data model and test the resulting draft. If an operation or tenant is unavailable, request an approved integration or establish the rights for independent processing. Neither downloading a PDF nor switching to browser automation supplies missing permission. See the reference documentation for TransactionDesk , zipForm , Transact , dotloop , SkySlope Forms , and Form Simplicity .

AI social media for REALTORS®: OpusClip, SumoClip, Higgsfield, Zernio, and ManyChat

A governed social agent can transform approved source material with AI clipping, create disclosed synthetic assets or presenter variants, obtain exact-artifact human approval, publish through official platform APIs, manage permitted comment and DM workflows, and write qualified leads back to the CRM. It should not scrape social dashboards, invent listing facts, reuse media without rights, impersonate a REALTOR®, or continue a conversation outside platform and consent rules.

The follow-up Homies Research paper, The Real Estate Social Media AI Agent Stack, covers OpusClip, SumoClip, Supo, Higgsfield AI clones, the Zernio API, ManyChat, CRM integration, cost, measurement, and human-review controls in detail.

A model request necessarily processes some input during inference. “No data in the model” is therefore useful shorthand but not an enforceable specification. The policy must enumerate every place protected information may persist.

A defensible vendor matrix identifies retention by endpoint and feature, training and feedback status, memory defaults, file lifecycle, cache behaviour, trace redaction, human-review exposure, subprocessors, residency, deletion verification, encryption, and incident obligations. Consumer accounts should not be used for protected workflows.

In Canada, organizations subject to PIPEDA must address accountability, identified purposes, consent, limiting collection, limiting use/disclosure/retention, accuracy, safeguards, openness, access, and challenge rights. Provincial law and sector-specific rules may also apply. See the Office of the Privacy Commissioner of Canada .

The proposed rule is precise: protected real-estate data may not be used for training, fine-tuning, model improvement, feedback, persistent memory, reusable retrieval indexes, model-managed files, or long-lived application state unless every party with the legal authority to permit that use has done so. Transient processing must be minimized, purpose-bound, encrypted, contractually protected, and subject to the shortest available retention.

Traditional application security remains necessary, but an agent adds instruction interpretation, tool selection, workflow state, and cross-system action. Controls must assume that retrieved content can be hostile and that a fluent model output can still be wrong or manipulative.

The OWASP Top 10 for Agentic Applications 2026 provides a useful cross-industry baseline. NIST’s voluntary Generative AI Profile organizes risk work around governance, mapping, measurement, and management. LAIRE translates those foundations into real-estate-specific data and action boundaries; it does not replace either framework.

Audit events should be append-only and include trace ID, actor, tenant, capability, purpose, risk tier, resource reference, request/response hashes, policy version, authorization result, approval reference, outcome, and retention class. Raw protected payloads should not be logged by default.

A model can help a professional reason about a result, but it should not free-form a CMA, filing deadline, disclosure decision, binding form, or protected-field determination. Deterministic services should calculate comparable filters, distances, date windows, prices, adjustments, mortgage figures, taxes, deadlines, required fields, signature completeness, and document hashes.

{
  "result_ref": "cma_01J...",
  "source": "approved-vow-service",
  "retrieved_at": "2026-07-14T14:21:08Z",
  "data_as_of": "2026-07-14T14:19:55Z",
  "policy_version": "board-agentic-policy-1.2",
  "tool_version": "cma-service-3.4.1",
  "calculation_version": "adjustments-2.0",
  "model_visibility": "metadata_only",
  "human_review_required": true
}

Agentic interfaces can amplify discrimination when they accept protected-class preferences, infer them from proxies, or translate vague language into demographic steering. The design rule is consistent even where specific protected grounds differ: do not accept, infer, optimize, or conceal protected-class criteria.

• Maintain prohibited-feature and proxy-feature catalogues.
• Log the objective criteria that include or exclude each result.
• Explain trade-offs rather than rank communities as good or bad.
• Test recommendations and ad delivery for disparate patterns.
• Escalate ambiguous requests to an authorized human.
• Apply the specific law and professional rule of each jurisdiction.

Ontario’s Human Rights Code protects equal treatment in buying, selling, and renting housing on Code-protected grounds. In the United States, HUD guidance identifies risks including denying housing information, differential terms, and steering through digital advertising. See the Ontario Human Rights Commission and HUD’s digital-platform guidance . Implementers must verify current local law rather than reuse either list as a universal rule.

A vendor may be suitable for secure listing rendering and unsuitable for transaction dispatch. A brokerage tool may be approved to create a CRM task and prohibited from bulk export. Certification should therefore attach to a capability, data class, actor, purpose, and risk tier—not to a logo.

Evidence should include architecture and data-flow diagrams, a field-level data inventory, model and subprocessor lists, retention matrices, training-use commitments, tenant-isolation tests, OAuth scopes, tool schemas, red-team results, fair-housing or human-rights testing, approval design, audit-event catalogues, incident response, business continuity, kill-switch procedures, deletion evidence, and software/AI bills of materials.

API first, MCP second, CLI for supervised operations

API, MCP, and CLI are complementary interfaces, not interchangeable security claims. Certification should follow the underlying capability and identity chain across every interface.

From feed governance to capability infrastructure

The same institutions that created permissioned distribution can expose controlled search, valuation support, statistics, geographic intelligence, rendering, compliance validation, attribution, and provenance endpoints. The strategic product is no longer only a feed. It is a governed capability platform that lets new interfaces operate on board-defined terms.

The safest adoption path increases capability only after the preceding control layer has been demonstrated. Boards should begin with inventory and a narrow read-only path, not a high-risk transaction automation showcase.

1. 0–90 daysPhase 1

   Policy and inventory

   Map systems and data classes; identify shadow AI; define prohibited uses; create legal, privacy, security, technical, and member governance.

2. 90–180 daysPhase 2

   Read-only and showing pilot

   Certify narrow search, secure rendering, and showing-availability capabilities; test injection, extraction, attribution, field permissions, and revocation.

3. 180–270 daysPhase 3

   Agent-to-agent workflows

   Add idempotent showing requests, deterministic CMA/statistics, and purpose-bound CRM tools with shared audit events and privacy-impact review.

4. 270–365 daysPhase 4

   Transaction preparation

   Integrate approved forms platforms; bind human approval to immutable document versions; keep dispatch platform-side.

5. Year 2Phase 5

   Standards and scale

   Publish an Agentic Access Profile, align schemas with RESO concepts, support multiple vendors, and operate red-team and incident-sharing programs.

Keeping the human in the loop: safe integration in one workflow

The tier progression stays abstract until it is applied to a single consequential workflow. Take the one members care about most: writing an offer.

In the first phase, the AI prepares structured field proposals inside a supervised harness. An approved form service selects the current template and runs deterministic checks; the REALTOR® opens the draft in the system of record, reviews it, and completes the signing flow themselves. The model’s autonomy ends at a proposed draft. Nothing reaches a client that the REALTOR® did not personally review and move.

In the second phase, the approved transaction API creates the draft from governed forms, records the AI-proposed fields, validates the instrument, and routes the exact version for signature. One rule changes: the signing order. The document goes to the REALTOR® before the client. The REALTOR®’s exact-version approval or professional attestation is recorded before the client ever sees it. Its legal effect depends on the instrument, the signer’s authority, and the jurisdiction; LAIRE does not turn an internal approval into a signature or representation that local law does not recognize. Accountability becomes a verifiable property of the workflow rather than a procedural checkbox.

The pattern generalizes across every tier in this framework. As autonomy increases, the human checkpoint does not disappear; it moves earlier and its consequences get heavier. The AI may earn more of a workflow only where the accountable human’s commitment is captured by a mechanism that cannot be skipped: a signature order, a document hash, a step-up approval. Section 14 shows the hash-bound version of the same idea, where approval binds to the exact document version and any later mutation invalidates it.

Phase two does not remove the human. It records the licensee’s exact-version approval before the client ever sees the AI-prepared instrument.

Success metrics should be operational: policy violations prevented, field-minimization rate, attribution correctness, tool-call failure rate, human-review completion, revocation time, incident detection time, unauthorized extraction resistance, and member time saved—not raw prompt volume.

The following clauses are starting points for jurisdiction-specific drafting. They are deliberately technology-neutral and preserve existing duties.

Natural-language policies are necessary but insufficient. Each approved capability should have a machine-readable profile that certification tests can exercise.

framework_version: laire/2.0
profile_schema: laire-capability-profile/1.0
capability: cma.prepare
risk_tier: 2
eligible_roles: [licensed_realtor]
required_scopes: [cma:prepare]
purpose_codes: [seller_evaluation, buyer_analysis, brokerage_review]
input:
  schema: cma-request/2.1
  max_records: 50
output:
  model_visibility: metadata_only
  returns: [cma_ref, secure_view_url, expiry, provenance]
human_review: required_before_share
retention_class: audit_metadata_only
revocation: immediate

For transactions, approval must bind to an immutable artifact. A later mutation must invalidate the approval and force a new review.

function dispatchApproved(documentBytes, approval) {
  assert(approval.expiresAt > now())
  assert(sha256(documentBytes) === approval.documentSha256)
  assert(currentActor.id === approval.reviewerId)
  assert(policyAllows("transaction.dispatch", approval.purpose))

  // The approved platform holds the signing credential.
  return transactionPlatform.dispatch(documentBytes, approval.id)
}

Production implementations should use asymmetric signatures or a managed key service, short-lived tokens, replay protection, step-up authentication, and explicit audience and tenant binding. Samples in this paper illustrate control shape; they are not production security code.

A login proves that someone authenticated. It does not prove which human authorized an agent, which legal entity operates it, which runtime executed the call, or whether it could delegate the work again. LAIRE therefore treats the human principal, brokerage, agent application, runtime workload, vendor, and downstream agent as distinct actors. No agent may collapse that chain into the REALTOR®’s identity or pass the same bearer credential through multiple services.

framework_version: laire/2.0
profile_schema: laire-delegation-profile/1.0
delegation_id: del_opaque
issuer: board_authorization_service
human_principal: realtor_opaque
accountable_organization: brokerage_opaque
agent_client: registered_app_opaque
runtime_workload: attested_workload_opaque
tenant: board_or_mls_opaque
audience: https://showing.example/capabilities
capabilities: [showing:availability_read, showing:request_create]
purpose: buyer_showing
jurisdiction_profile: ca-on/1.0
consent_ref: consent_opaque
parent_delegation: null
subdelegation: prohibited_by_default
issued_at: 2026-09-03T14:00:00Z
expires_at: 2026-09-03T14:10:00Z
proof: issuer_signature_and_sender_binding

This profile adopts the direction of the MCP authorization specification , which binds tokens to a target resource and forbids token passthrough, and the IETF’s OAuth token exchange and DPoP mechanisms. LAIRE adds the real-estate principal, tenant, purpose, consent, license, jurisdiction, and subdelegation fields needed for professional accountability.

Agent-to-agent interoperability requires both sides to agree on what happened when a request pauses, conflicts, expires, retries, or partially succeeds. LAIRE maps its real-estate lifecycle to the base task model in the Agent2Agent protocol and defines domain outcomes that generic agent protocols do not decide.

• Idempotency keys are scoped to the tenant, actor, capability, and normalized request; reusing one with different content fails closed.
• Every mutable resource carries a version or ETag. A stale reschedule, cancellation, offer, or instruction update returns a conflict instead of overwriting newer state.
• Retries declare whether the prior attempt committed, use bounded exponential backoff, and never turn a transport timeout into an assumed business failure.
• Push events and webhooks are signed, timestamped, replay-protected, ordered or explicitly sequence-numbered, and recoverable through authoritative status polling.
• Deadlines, approval expiry, slot holds, timezone, cancellation policy, and compensation ownership are machine-readable.
• The platform publishes a reconciliation operation so both agents can recover after partial delivery, disconnection, or webhook loss.

Property entry is a separate, higher-risk capability

A confirmed appointment establishes eligibility to request entry; it does not deliver entry authority to the model. Lockbox, alarm, occupancy, access-note, and door-event data remain outside prompt, memory, trace, screenshot, and browser-replay surfaces.

framework_version: laire/2.0
profile_schema: laire-property-access-profile/1.0
capability: showing.entry_instruction_redeem
requires:
  appointment_state: confirmed
  appointment_ref: exact
  recipient: authenticated_entitled_human_or_bound_device
  property: exact_listing_ref
  time_window: just_in_time
  step_up_authentication: required
delivery:
  channel: outside_model_context
  forwardable: false
  reveal_to_agent_runtime: false
  screenshot_and_log_capture: prohibited
controls:
  one_appointment_one_credential: required
  door_event_audit: required_when_supported
  emergency_revoke: immediate
  offline_fallback: board_approved_human_process
retention: access_metadata_only

Safety ceilings also apply to scale. Each tenant sets per-task and daily limits for bookings, cancellations, messages, signatures, exports, compute, and paid calls. Abnormal velocity, fan-out, repeated denials, resource exhaustion, and denial-of-wallet patterns pause the capability before a financial or operational limit is crossed.

An append-only log is useful but not sufficient. A certifiable event must be portable, tamper-evident, privacy-minimized, and understandable without access to the vendor’s internal prompt history. Evidence follows the business action across API, MCP, CLI, queue, webhook, and agent-to-agent boundaries.

{
  "specversion": "laire-evidence/1.0",
  "event_id": "evt_opaque",
  "event_type": "showing.request.completed",
  "occurred_at": "2026-09-03T14:04:12Z",
  "trace_id": "w3c_trace_context",
  "task_id": "task_opaque",
  "tenant": "board_or_mls_opaque",
  "human_principal": "realtor_opaque",
  "accountable_organization": "brokerage_opaque",
  "agent_client": "registered_app_opaque",
  "runtime_workload": "attested_workload_opaque",
  "capability": "showing.request_create",
  "purpose": "buyer_showing",
  "policy_version": "board-policy/4.2",
  "delegation_id": "del_opaque",
  "approval_ref": "approval_opaque",
  "input_digest": "sha256:...",
  "output_digest": "sha256:...",
  "model_and_tool_versions": ["model:registered", "mcp:2.1"],
  "authoritative_result_ref": "appointment_opaque",
  "outcome": "completed",
  "previous_event_digest": "sha256:...",
  "issuer_signature": "jws:...",
  "sensitive_payload_logged": false
}

Continuous authorization, incident response, and change control

Short-lived credentials reduce exposure but do not solve a compromise that occurs during their lifetime. Issuers need a signed security-event channel for account disablement, license or employment change, consent withdrawal, device compromise, vendor suspension, and emergency property-access revocation. The OpenID Shared Signals Framework offers a standards-based model for continuously communicating such changes.

Capability controls protect systems. They do not by themselves protect a person who receives a wrong message, inaccessible recommendation, discriminatory outcome, missed deadline, or document they did not understand. LAIRE adds a consumer-rights layer to every consequential profile.

Responsibility must be allocated before failure

Contracts should assign incident investigation, consumer remediation, missed-deadline handling, defence, indemnity, cyber coverage, errors-and-omissions coverage, evidence production, and regulatory cooperation. A generic statement that every party remains responsible is not an allocation model.

Jurisdiction profiles—not one North American rule

The core standard remains technology-neutral, while signed jurisdiction profiles bind capabilities to locally reviewed rules. A profile identifies the applicable privacy, human-rights or fair-housing, electronic-signature, recording-consent, forms-licensing, agency, advertising, recordkeeping, anti-money-laundering, sanctions, and unauthorized- practice-of-law requirements. Canadian profiles should explicitly map applicable federal and provincial privacy rules and FINTRAC duties; United States profiles should map federal and state privacy, fair-housing, e-signature, recording, OFAC, licensing, brokerage, and forms rules.

jurisdiction_profile: ca-on/1.0
facts:
  participant_license_jurisdiction: CA-ON
  brokerage_jurisdiction: CA-ON
  property_jurisdiction: CA-ON
  consumer_residence: collected_only_if_required
  communication_parties: [CA-ON]
  instrument_type: offer_to_purchase
  recording_or_transcription: false
decision:
  allowed_capabilities: policy_engine_result
  required_disclosures: policy_engine_result
  required_human_roles: policy_engine_result
  retention_and_hold: policy_engine_result
  decision_source_version: counsel_approved_ruleset

This is a policy-routing structure, not legal advice. Counsel must approve each profile, legal claims must be re-verified, and the technical system must fail closed when the required jurisdiction or authority cannot be determined.

The research paper explains the architecture. The standard package defines compliance. LAIRE v2.0 therefore separates the framework version from independently versioned capability, delegation, task, property-access, evidence, jurisdiction, and test profiles. A prose-aligned product must not market itself as certified.

framework: laire/2.0
implementation: vendor_product_and_version
conformance_class: C3
profiles:
  capability: laire-showing/1.0
  delegation: laire-delegation-profile/1.0
  task: laire-task-profile/1.0
  evidence: laire-evidence/1.0
  jurisdiction: ca-on/1.0
test_pack: laire-conformance/1.0.0
tested_build_digest: sha256:...
certifier: independent_or_board_approved
issued_at: 2026-09-03
expires_at: defined_by_certification_policy
limitations: machine_readable
evidence_url: public_verification_record

The v2.0 standards package

• LAIRE Delegation Profile: principal, workload, audience, purpose, subdelegation, token exchange, sender binding, and continuous revocation.
• LAIRE Task Profile: lifecycle states, concurrency, idempotency, deadlines, signed events, retries, cancellation, reconciliation, and compensation.
• LAIRE Property Access Profile: appointment-to-entry separation, just-in-time human delivery, device binding, emergency revocation, and access evidence.
• LAIRE Evidence Profile: canonical event envelope, trace propagation, tamper evidence, privacy minimization, export, retention, correction, and legal hold.
• LAIRE Conformance Kit: schemas, registries, test vectors, adversarial fixtures, reference adapters, certification classes, and public verification records.
• Accountability and Jurisdiction Annexes: consumer notice and recourse, responsibility allocation, contract controls, insurance evidence, and counsel-approved local rule profiles.
• Regulatory Alignment Annex (new in v2.0): the regulator-to-control map in Section 20, the media provenance capability, and jurisdiction profile skeletons for us-ca, ca-bc, ca-on, and ca-qc.

The first edition of this paper argued that boards had to act before the interface shift finished. In the months since, they did, along with regulators and legislatures on both sides of the border. Between January 2025 and September 2026 the California Attorney General, the California Department of Real Estate, the California Association of REALTORS®, the National Association of REALTORS®, the Canadian Real Estate Association, the British Columbia Real Estate Association, the BC Financial Services Authority, Quebec’s OACIQ, TRREB’s PropTx, Milwaukee’s Metro MLS, and the legislatures of California, Wisconsin, and Colorado all published something specific about AI in real estate practice. None created an AI exemption. None banned AI. Every document restated existing duties, accuracy, disclosure, confidentiality, supervision, and fair housing, and told licensees that those duties travel into every tool they use.

We analyse the three association releases in companion notes: C.A.R.’s AI Resource Hub, CREA’s AI guidance, and BCREA’s brokerage guidance. This section consolidates all of them into one map from regulatory expectation to LAIRE control.

What version 2.0 adds to the standard

Two gaps became visible once the regulators wrote their expectations down. The first edition governed listing data as search results and rendered views; it did not name media as its own capability, and AB 723, the DDF® terms, and the MLS® photo rules are all about media. The first edition also described jurisdiction profiles abstractly. The 2025–2026 guidance gives four of them concrete content.

• media.augment_labelled: a Tier 2 capability that classifies every alteration at creation time, binds the augmented asset to its original, renders the required disclosure, and keeps the original first in the record.
• forms.fields_map: a Tier 4 capability that verifies user entitlement and vendor permission, maps structured transaction facts, preserves the master template and notices, and binds review to the licensed form revision.
• us-ca jurisdiction profile: AB 723, the DRE bulletin’s supervision and licensed-activity rules, FEHA and Regulation 2780, the CCPA automated decision-making rules, and the bot-disclosure statute.
• ca-bc jurisdiction profile: BCFSA Rules 28, 30, 33, 34, 40, and 41, the Personal Information Protection Act, and BCREA’s brokerage expectations.
• ca-on and ca-qc jurisdiction profiles: TRESA advertising and disclosure duties with PropTx image rules; OACIQ’s disclosure expectations with Quebec Law 25’s automated-decision notice.
• A disclosure event type in the evidence profile so transparency can be demonstrated, not asserted.
• A supervision export so an accountable organization can review per-licensee tool activity without receiving prompts or protected payloads.

framework_version: laire/2.0
profile_schema: laire-capability-profile/1.1
capability: media.augment_labelled
risk_tier: 2
jurisdiction_profiles: [us-ca/1.0, ca-crea-ddf/1.0, ca-on/1.0]
input:
  original_asset_ref: required
  alteration_class: [corrective, virtually_staged, element_added, element_removed, element_changed]
output:
  returns: [augmented_asset_ref, original_asset_ref, alteration_class, disclosure_text, disclosure_placement]
  original_first_display: required
  opt_in_overlay: required_where_ddf_applies
  latent_provenance_mark: preserved
prohibited:
  - training_on_listing_media
  - replacing_original_in_record
  - routing_content_to_external_public_ai_app
human_review: required_before_publish
audit: signed_tamper_evident_events
revocation: immediate

A profile is not a legal opinion. Each jurisdiction profile is a skeleton that a board’s counsel must complete and sign before a capability may claim it, and the system must fail closed when it cannot determine which profile applies. That discipline is what lets a national product respect the fact that BCFSA, the DRE, CREA, and OACIQ all mean slightly different things by the same word.

The first edition assumed that enforcement would arrive the way it always has in real estate: after the fact, through complaints, audits, and discipline. Something else happened first. The organizations that build the frontier models wrote the regulators’ expectations into their own terms of use, and then into the behaviour of the models and the agent harnesses around them.

• Anthropic’s usage policy, effective September 15, 2025, classifies decisions about housing eligibility, leases, and home loans, and legal interpretation and guidance, as high-risk uses. They require review by a qualified professional before anything is finalized or disseminated and disclosure to the consumer that AI is involved. The policy also prohibits presenting AI output as human-generated and bypassing product guardrails.
• OpenAI’s usage policy update of October 29, 2025 prohibits providing tailored advice that requires a licence, such as legal advice, without appropriate involvement of a licensed professional, and prohibits automating high-stakes decisions in sensitive areas, including housing, without human review.
• Anthropic’s browser agent is prohibited from bypassing CAPTCHAs, entering sensitive data, executing financial transactions, and scraping facial images; it screens every action with safety classifiers before it runs; and it makes the user responsible for third-party terms of service, including restrictions on automated access.
• In our own engineering on frontier harnesses, we have watched a harness’s safety classifier deny an action that touched credentials even when the operator asked for it explicitly. The refusal is not a bug report. It is the product working as designed.

Put those facts next to the regulators’ documents and a pattern appears. The DRE says AI doing licensed work is an unlicensed assistant; the model providers require a licensed professional in the loop. CREA and BCFSA say disclose material AI influence; the usage policies require disclosure at the start of a session. AB 723 and the DDF® say label the media and keep the original; the AI Transparency Act requires latent marks from the generators. WAV Group and Metro MLS say automated extraction through a member’s session violates the rules; the browser agents refuse to bypass access controls and hold the user to the site’s terms. Regulators and model providers converged on the same rules from opposite directions, and the model providers enforce theirs in milliseconds.

The consequence is easy to state and hard to overstate. A workflow that only works by borrowing a login, scraping a portal, impersonating a licensee, or auto-deciding about a person increasingly does not run. The model declines, the harness blocks the action, the platform’s terms forbid it, and the regulator’s guidance says the licensee owns the failure anyway. Each new safety layer at the model provider removes capability from a harness built around those shortcuts and adds capability to a harness that never needed them, because a compliant harness already satisfies the new layer. Non-compliant systems lose ground with every model release. Compliance-native systems gain it.

Compliance is no longer the cost of using AI in real estate. It is the interface through which capable AI will agree to work.

This is why we describe LAIRE as layering agentic intelligence on real estate rather than replacing anything. The systems of record, the licensed humans, the boards, and the regulators stay where they are. The intelligence is layered on through capabilities those parties can see, approve, audit, and revoke, which is precisely the shape the model providers now insist on too. Anyone who wants to maximize what AI can do in this industry has to build for that shape. We designed Homies this way from the start: delegated identity instead of passwords, scoped capabilities instead of scraping, disclosure instead of impersonation, human approval instead of automatic decisions, evidence instead of screenshots. We would rather compete with an industry that builds the same way than watch it learn this from refusals and enforcement actions, and we hope to see others doing the same.

The preceding sections set the architectural guardrails, policy language, and adoption path. Several practical layers remain underspecified. Boards, MLS® system operators, and vendors that adopt LAIRE early will need to fill these gaps before certification can be enforced consistently and before consequential workflows can be trusted at scale.

Schemas, certification, and accreditation mechanics

Capability manifests need a published schema, a conformance test suite, and a clear accreditation body or bodies. LAIRE should not become a single-vendor seal. The goal is a portable, reviewable profile that a board’s technical, legal, privacy, and security reviewers can audit independently.

• Publish a JSON/YAML capability-manifest schema with typed fields for actor, purpose, data class, input/output bounds, retention class, and revocation.
• Require architecture diagrams, a field-level data inventory, model and subprocessor lists, retention matrices, and training-use commitments.
• Define re-certification triggers: model changes, subprocessor additions, scope expansions, incidents, or material policy updates.
• Make revocation immediate and granular so a board can disable one capability without disabling an entire vendor.
• Publish conformance tests for schema bounds, permission denial, field leakage, bulk extraction, and audit completeness.

vendor: example-cma-vendor
capability: cma.prepare
laire_profile: 1.0
evidence:
  - architecture_diagram.pdf
  - data_flow_diagram.pdf
  - field_inventory.csv
  - model_and_subprocessor_list.csv
  - retention_matrix.csv
  - training_use_commitment.pdf
  - tenant_isolation_test_report.pdf
  - oauth_scopes.yaml
  - tool_schema.yaml
  - red_team_results.pdf
  - fair_housing_test_results.pdf
  - incident_response_plan.pdf
  - deletion_evidence.pdf
  - sbom.json
  - aibom.json

Liability, insurance, and enforcement

The framework states that the model is not the accountable actor, but it does not yet map accountability onto errors-and-omissions coverage, vendor indemnification, or disciplinary enforcement. A REALTOR® who signs an AI-prepared offer needs to know whether their E&O policy covers the AI’s mistake and whether the vendor stands behind its validation logic.

Enforcement should be described as a process: complaint intake, evidence preservation, capability suspension, notice, appeal, and public revocation where warranted. The audit trail described in Section 8 is what makes that process fair and fast.

Fair-housing proxies and consumer disclosure

Section 10 prohibits protected-class criteria, but it does not yet catalogue the proxies that commonly replace them. A request for a “family neighbourhood” or “good schools” can steer by household composition or ethnicity if the system lets those phrases pass through to ranking or ad targeting.

• Maintain a public catalogue of prohibited features and proxy features, with examples: school-quality-only filters, crime-rate steering, ‘family-friendly’ as a ranking signal, and inferred household composition.
• Reject or transform vague criteria into objective, legally appropriate housing attributes: budget, commute, property type, accessibility, lot size, transit, and proximity to named amenities.
• Log the objective criteria that include or exclude each result so the recommendation is auditable.
• Disclose to consumers when they are interacting with an AI, when they are being shown AI-generated content, and how to escalate to a licensed human.
• Test ad delivery and recommendation outputs for disparate impact before and after launch.

Consumer disclosure is not a footnote. If a buyer searches on an AI-powered portal and the model ranks or excludes communities, the consumer should see that the ranking is AI-generated, the criteria used, and a clear path to a human REALTOR®.

Appraisal, valuation, and finance regulation

CMA preparation and market analysis sit close to appraisal and mortgage underwriting. LAIRE needs explicit boundaries so that a governed CMA tool does not drift into unlicensed appraisal or automated underwriting advice. In the United States, appraisal independence rules and the appraisal standards regulated by USPAP and FIRREA create bright lines that an AI must not cross. In Canada, provincial appraisal legislation and lender requirements vary.

• Label every CMA or valuation support output as a REALTOR®-prepared opinion, not an appraisal, and show the assumptions and data-as-of date.
• Prohibit the model from representing itself as an appraiser, automated valuation model, or lender underwriter.
• Keep mortgage pre-qualification, rate advice, and financing recommendations inside licensed mortgage channels.
• Document jurisdiction-specific review: USPAP/FIRREA in the U.S., provincial appraisal acts and lender rules in Canada, and local MLS® valuation policies everywhere.

Accessibility, language access, and small-brokerage equity

Governance programs can become a tax on small brokerages and solo agents. If certification is expensive, integration is complex, and documentation is only in English, the framework will advantage well-resourced incumbents and lock out the long tail of the profession.

• Provide model policy clauses and certification checklists in plain language and, where possible, in the languages spoken in the board’s market.
• Offer a reference open-source capability gateway, conformance tests, and sample manifests so smaller vendors and self-managed brokerages can participate.
• Publish a small-brokerage cost model: minimum viable controls, phased adoption, and free or low-cost audit tooling.
• Require accessibility conformance (WCAG, AODA, ADA) for consumer-facing agentic interfaces and for the approval UX used by REALTORS®.
• Mandate data portability for audit logs, capability manifests, and member settings to reduce vendor lock-in.

Incident response, model evaluation, and RAG controls

Section 8 lists threats; Section 14 lists tests. The missing layer is the operational playbook: who is paged, what is preserved, how a capability is frozen, and how the board is notified. Long-term memory and retrieval-augmented generation also need their own controls.

• Maintain a runbook for suspected prompt injection, data exfiltration, tool misuse, model drift, and connector compromise.
• Define a kill switch that disables a capability or vendor without disabling the member’s core systems.
• Run recurring red-team exercises against the real capability surface, not just the chat interface.
• Benchmark models on real estate tasks under the LAIRE harness; do not rely on generic leaderboards for consequential work.
• Isolate per-tenant retrieval indexes, set expiry and re-indexing rules, and prohibit protected data from entering shared vector stores.

trigger:
  condition: unauthorized_extraction_detected
response:
  - revoke_capability(capability_id, reason)
  - preserve_audit_trail(trace_id)
  - notify_security_team(tenant, actor, capability, timestamp)
  - notify_board_liaison_within(policy.incident_sla)
  - freeze_related_sessions(actor_id, capability_id)
  - open_incident_record(reference: trace_id)

Human-review UX and REALTOR® training

A signature bound to a document hash is strong only if the licensee actually read and understood the instrument. Approval UX must make manipulation, fatigue, and click-through signing structurally difficult. REALTORS® also need training on what to verify when an AI prepares a CMA, offer, disclosure, or social post.

• Show the exact artifact, its provenance, and a diff against any earlier version at the approval moment.
• Require explicit confirmation of key facts: data-as-of date, comparable set, form version, parties, price, deposit, and conditions.
• Use step-up authentication for Tier 4 and Tier 5 actions so the approval is attributable.
• Publish a training module on AI-assisted review: how to spot hallucinated comparables, wrong form selection, and missing disclosures.
• Track human-review completion rates, override reasons, and error catches as operational metrics.

Governance is not finished when the policy is published. It is finished when the controls are testable, the liability is allocated, and the human checkpoint is designed so it cannot be skipped.

The rename is deliberate. RAILS described a mechanism, an interoperability layer, in vocabulary borrowed from software standards and easily confused with a web framework. LAIRE describes the outcome: intelligence layered on the industry’s existing systems, professionals, and rules rather than substituted for them. The name is easier to say in a boardroom, and it is the same architecture.

Consumers will choose convenient interfaces. Professionals will choose tools that save time. Portals and model providers will continue competing for the point at which intent becomes workflow. The durable response is not to pretend that shift can be stopped. It is to define the trust infrastructure through which it operates.

The useful boundary is custody versus capability; persistent storage versus controlled transient processing; autonomous action versus accountable approval; probabilistic explanation versus deterministic calculation; and ungoverned distribution versus auditable access.

Better interfaces should operate through board-defined trust—not around it.

Boards that define identity, permission, provenance, quality, interoperability, auditability, certification, and revocation can protect data while improving member capability. Boards that focus only on yesterday’s interface may preserve the feed while losing influence over tomorrow’s consumer journey.

The immediate obligation is practical: make the approved path usable. Pair clear limits with permissioned capabilities that members can discover, authorize, and use in daily work. Every task brought into that path becomes an opportunity to check rights before disclosure, preserve provenance, and give data providers evidence they can act on. The cost of delay includes the unmanaged workflows that continue while the industry waits.

Product claims are factual only to the extent supported by the linked publisher. The LAIRE architecture, tiers, policy language, and roadmap are proposals by the authors. Legal requirements vary and must be re-verified before adoption. The regulatory, association, and model-provider sources added in version 2.0 follow the technical standards.

1. 01

   CREA

   Trademark protection and competition: REALTOR®, REALTORS®, and MLS®
2. 02

   CREA

   How to properly use the MLS® trademark
3. 03

   TRREB

   AI Do’s, Don’ts, and Don’t You Dare (May 28, 2026)
4. 04

   TRREB

   Welcomes launch of Canada’s new national artificial intelligence strategy (June 9, 2026)
5. 05

   Anthropic

   Commercial products: is my data used for model training?
6. 06

   Zillow

   Zillow debuts the real estate app in ChatGPT (Oct. 6, 2025)
7. 07

   Zillow

   How the app preserves listing reach and industry rules (Oct. 9, 2025)
8. 08

   OpenAI

   Introducing apps in ChatGPT and the Apps SDK (Oct. 6, 2025)
9. 09

   Anthropic

   Introducing the Model Context Protocol (Nov. 25, 2024)
10. 10

    A2A Project

    Agent2Agent Protocol specification and task lifecycle
11. 11

    Model Context Protocol

    Authorization specification (Nov. 25, 2025)
12. 12

    Model Context Protocol

    Security best practices and token-passthrough prohibition
13. 13

    IETF

    RFC 8693: OAuth 2.0 Token Exchange
14. 14

    IETF

    RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
15. 15

    IETF

    RFC 9700: Best Current Practice for OAuth 2.0 Security
16. 16

    OpenID Foundation

    Shared Signals and Continuous Access Evaluation
17. 17

    W3C

    Trace Context: distributed trace propagation
18. 18

    OpenTelemetry

    Semantic conventions for traces, logs, metrics, and events
19. 19

    HouseCanary

    Google Home Discovery national expansion (June 11, 2026)
20. 20

    RPR

    2026 AI Adoption Survey: 82% of real estate agents use AI
21. 21

    OpenAI

    How data is used to improve model performance
22. 22

    OpenAI

    ChatGPT Search
23. 23

    Anthropic

    Consumer data-use choices for Claude
24. 24

    Anthropic

    Enabling and using web search
25. 25

    Zillow

    Real-Time Touring and ShowingTime-integrated booking
26. 26

    ShowingTime+

    Real-Time Availability API for brokers
27. 27

    BrokerBay

    MLS-wide showing-management ecosystem
28. 28

    Touchbase

    Showing availability, confirmation, instruction, and feedback workflows
29. 29

    Aligned Showings

    Scheduling, approvals, calendars, messaging, and routing
30. 30

    SentriLock

    SentriKey Showing Service scheduling links
31. 31

    Instashowing

    Showing-management workflow
32. 32

    Showingly

    REST API and remote MCP access for AI agents
33. 33

    SkySlope

    Transaction-management APIs
34. 34

    SkySlope

    Offers API reference
35. 35

    CREA

    CREA WEBForms powered by TransactionDesk
36. 36

    Lone Wolf

    TransactionDesk, zipForm, Transact, Deals, and WolfConnect API documentation
37. 37

    dotloop

    OAuth 2.0 public API
38. 38

    Form Simplicity

    Scoped transaction API
39. 39

    DocuSign

    Agreement and eSignature APIs
40. 40

    DocuSeal

    Open-source self-hosted signing with API support
41. 41

    Nano-PDF

    Open-source AI PDF-editing CLI
42. 42

    Follow Up Boss

    REST API and webhook documentation
43. 43

    HighLevel

    CRM, conversation, calendar, opportunity, and webhook API
44. 44

    Lofty

    Real estate CRM developer API
45. 45

    NIST

    SP 800-207: Zero Trust Architecture
46. 46

    NIST

    AI 600-1: Generative AI Profile
47. 47

    OWASP

    Top 10 for Agentic Applications 2026
48. 48

    RESO

    Current specifications and supporting materials
49. 49

    RESO

    Web API, IDX payloads, and live web-application queries
50. 50

    NAR

    Internet Data Exchange Policy Statement 7.58 (Jan. 1, 2026)
51. 51

    CREA

    REALTOR.ca DDF®
52. 52

    OPC Canada

    PIPEDA requirements in brief
53. 53

    OHRC

    Freedom from discrimination in housing
54. 54

    HUD

    Guidance on housing advertising through digital platforms
55. 55

    C.A.R.

    Your AI Resource Hub (2026)
56. 56

    California Legislature

    AB 723: digitally altered images in real estate advertising, Business and Professions Code § 10140.8 (effective Jan. 1, 2026)
57. 57

    California DRE

    Winter 2026 Real Estate Bulletin: Artificial Intelligence in California Real Estate
58. 58

    California Attorney General

    Legal advisory on the application of existing California laws to artificial intelligence (Jan. 2025)
59. 59

    California Privacy Protection Agency

    Finalized regulations on automated decision-making technology, risk assessments, and cybersecurity audits (Sept. 2025)
60. 60

    NAR

    Artificial Intelligence in Real Estate hub, policy templates, and advocacy positions
61. 61

    NAR

    AI’s current iteration poses higher risk, and reward, for brokers (June 16, 2026)
62. 62

    NAR

    Make it a policy to protect MLS data from AI misuse (July 15, 2026)
63. 63

    NAR

    What’s real, what isn’t? How to spot deepfakes and AI real estate scams (Aug. 3, 2026)
64. 64

    WAV Group

    The MLS don’t want AI training on data, but it happens every day (Aug. 25, 2026)
65. 65

    CREA

    Artificial Intelligence: transparency, accuracy, accountability
66. 66

    CREA

    CREA supports responsible AI use in real estate (June 1, 2026)
67. 67

    CREA

    DDF® change in terms and conditions: AI augmentations (Aug. 2026)
68. 68

    BCREA

    Brokerage Meeting in a Box: Artificial Intelligence in Real Estate Practice (2026)
69. 69

    BCFSA

    Artificial Intelligence Guideline (Feb. 2024)
70. 70

    BCFSA

    Artificial Intelligence Information
71. 71

    TRREB

    TRREB welcomes launch of Canada’s new national artificial intelligence strategy (June 9, 2026)
72. 72

    OACIQ

    The OACIQ signs the Canadian code of conduct on artificial intelligence
73. 73

    Wisconsin Legislature

    2025 Wisconsin Act 69: disclosure of technology-altered listing advertising (effective Jan. 1, 2027)
74. 74

    New York Department of State

    Trend alert warning homebuyers about AI-generated home listings (Nov. 13, 2025)
75. 75

    Anthropic

    Usage Policy: high-risk use case requirements (effective Sept. 15, 2025)
76. 76

    OpenAI

    Usage policies (updated Oct. 29, 2025)
77. 77

    Anthropic

    Use Claude in Chrome safely: prohibited actions and user responsibilities
78. 78

    OREA

    Standard Forms and Clauses: Terms of Use
79. 79

    C.A.R.

    Standard forms copyright policy
80. 80

    C.A.R.

    Standard Forms terms-of-use reminder
81. 81

    C.A.R.

    C.A.R. expands licensing of C.A.R. Standard Forms
82. 82

    Texas REALTORS®

    Who can use TREC forms (Dec. 11, 2017)
83. 83

    TREC

    License holders must use TREC-adopted contract forms (TRELA § 1101.155; Rule 537.11)
84. 84

    Lone Wolf

    TransactionDesk partner API reference
85. 85

    Lone Wolf

    zipForm partner API reference
86. 86

    Lone Wolf

    Transact API reference
87. 87

    SkySlope

    Forms Partnership API reference
88. 88

    Lone Wolf

    Terms of Service: authorized users, integrations, and usage restrictions
89. 89

    Lone Wolf

    Acceptable Use Policy
90. 90

    Lone Wolf

    API integration portal
91. 91

    OREA / SkySlope

    OREA end-user agreement for SkySlope, including visible amendments (§3)
92. 92

    Lone Wolf

    Data Processing Addendum
93. 93

    RECO

    Professional conduct
94. 94

    RECO

    Confidentiality
95. 95

    OPC

    Processing personal data across borders
96. 96

    Canadian privacy regulators

    Principles for responsible, trustworthy and privacy-protective generative AI

The trademarks MLS®, Multiple Listing Service® and the associated logos are owned by The Canadian Real Estate Association (CREA) and identify the quality of services provided by real estate professionals who are members of CREA. The trademarks REALTOR®, REALTORS® and the REALTOR® logo are controlled by CREA and identify real estate professionals who are members of CREA.

Third-party organization names, original source titles, URLs, and technical identifiers are retained as published. References do not imply endorsement. See CREA’s trademark guidance .