Property search that turns vague investor intent into real filters.

Property recommendations fail when filters are guessed.

Investors rarely search like a rigid form. They ask for “small multifamily near a university, light renovation, seller financing possible, under 900k.” If the app guesses fields from a prompt, it can hallucinate metadata, ignore owner context, or miss listings whose useful signals live outside the main listing table.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

{
  "listingId": "prop-1844",
  "assetType": "duplex",
  "city": "Austin",
  "priceUsd": 820000,
  "capRate": 5.8,
  "hasSellerFinancing": true,
  "description": "Light renovation duplex near a university corridor.",
  "OWNER_PROFILE": { "ownerType": "private_seller", "timeline": "60_days" },
  "NEIGHBORHOOD": { "name": "North Campus", "walkScore": 82 },
  "MARKET_SIGNAL": [{ "kind": "rent_growth", "value": 8.2 }],
  "COMPARABLE": [{ "compId": "comp-77", "priceUsd": 790000 }]
}

Working example

Turn investor intent into an ontology-grounded listing match.

The app reads RushDB ontology first, converts the investor request into valid listing filters, then returns exact property matches with connected owner and market-signal context.

INVESTOR_PROFILE inv-42
  intent: "Duplex or small multifamily in Austin under 900k, light rehab, seller financing helpful"

PROPERTY_LISTING prop-1844
  assetType: duplex
  city: Austin
  priceUsd: 820000
  capRate: 5.8
  hasSellerFinancing: true
  MARKET_SIGNAL rent_growth: 8.2

{
  "labels": ["PROPERTY_LISTING"],
  "where": {
    "city": "Austin",
    "assetType": { "$in": ["duplex", "small_multifamily"] },
    "priceUsd": { "$lte": 900000 },
    "capRate": { "$gte": 5.5 },
    "hasSellerFinancing": true
  },
  "limit": 25
}

{
  "listingId": "prop-1844",
  "assetType": "duplex",
  "priceUsd": 820000,
  "matchedBecause": [
    "Austin",
    "under 900k",
    "seller financing available",
    "cap rate >= 5.5"
  ]
}

TypeScript SDK

Discover the ontology before building the filters.

The useful pattern is not prompt-only recommendation. Load the live labels, values, and ranges first, then translate investor intent into filters that exist in the project.

Implementation blueprint

Build the property-intelligence matching path.

Use this sequence to add recommendation intelligence to a property marketplace without turning free-text prompts into guessed listing metadata.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.