Blueprint: property intelligence
Property search that turns vague investor intent into real filters.
Zillow-like products can use RushDB as the structured intelligence layer behind recommendation systems: PROPERTY_LISTING, OWNER_PROFILE, INVESTOR_PROFILE, MARKET_SIGNAL, COMPARABLE, and NEIGHBORHOOD records stay connected while the app translates human-language requests like "duplex under 900k with seller financing" into fields such as assetType, priceUsd, capRate, and hasSellerFinancing that actually exist in the schema.
Property Intelligence For Real-Estate Marketplaces is a RushDB blueprint where an app reads live PROPERTY_LISTING schema before translating human-language investor intent into grounded filters, connecting listings to owners, comps, neighborhoods, and market signals.
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 PROPERTY_LISTING fields from a prompt instead of checking schema, it can hallucinate metadata like nonexistent assetType values, ignore OWNER_PROFILE context, or miss listings whose MARKET_SIGNAL and COMPARABLE data live outside the main listing record.
Before
- Search forms force investors into rigid filters
- Semantic-only search misses exact budget, cap-rate, and financing constraints
- Owner, comp, and market-signal data live outside listing recommendations
- Frontend teams need backend joins for each new matching experience
With RushDB
- Schema exposes the real listing fields, ranges, values, and graph paths
- Human-language intent becomes validated filters plus optional semantic search
- Listings connect to owners, comps, neighborhoods, market signals, and investor profiles
- Thin marketplace UIs can render matching cards, explanations, and saved-search alerts
Graph intelligence on ingest
Incoming data becomes queryable graph context.
PROPERTY_LISTING records arrive with nested MARKET_SIGNAL data such as rent_growth, alongside separate INVESTOR_PROFILE and OWNER_PROFILE records. RushDB normalizes priceUsd, capRate, and hasSellerFinancing as typed, filterable properties, links each listing to its owner and market signals automatically, and exposes schema so the app can ground free-text intent in fields that actually exist before querying.
01
Normalize listing fields on arrival
RushDB types priceUsd, capRate, and hasSellerFinancing as each PROPERTY_LISTING and MARKET_SIGNAL payload is imported.
02
Auto-link owners and signals
Nested MARKET_SIGNAL entries and related OWNER_PROFILE, COMPARABLE, and NEIGHBORHOOD data connect to the listing without manual joins.
03
Enrich investor context
Suggested-relationship analysis links INVESTOR_PROFILE and SEARCH_INTENT records to matching listings across price, financing, and location signals.
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.
Review suggested relationship patternsData 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.
Listings, owner context, investor intent, comps, and market signals can vary by source while staying queryable together.
{
"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 schema-grounded listing match.
The app reads RushDB schema 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 schema 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.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
schema = db.ai.get_schema_markdown({
'labels': ['PROPERTY_LISTING', 'INVESTOR_PROFILE', 'SEARCH_INTENT', 'MARKET_SIGNAL'],
}).data
db.ai.indexes.create({'label': 'PROPERTY_LISTING', 'propertyName': 'description'})
db.records.import_json({
'label': 'PROPERTY_LISTING',
'data': {
'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'},
'MARKET_SIGNAL': [{'kind': 'rent_growth', 'value': 8.2}],
},
})
matches = db.records.find({
'labels': ['PROPERTY_LISTING'],
'where': {
'city': 'Austin',
'assetType': {'$in': ['duplex', 'small_multifamily']},
'priceUsd': {'$lte': 900000},
'capRate': {'$gte': 5.5},
'hasSellerFinancing': True,
},
'limit': 25,
})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.
- 01Import PROPERTY_LISTING records with OWNER_PROFILE, MARKET_SIGNAL, COMPARABLE, and NEIGHBORHOOD context
- 02Store INVESTOR_PROFILE and SEARCH_INTENT records for saved searches
- 03Load schema before translating human-language intent into filters
- 04Combine exact filters with semantic search over listing descriptions when useful
- 05Render matched listings, explanations, and saved-search alerts from RushDB results
Build path
- Keep property matching grounded in available labels, properties, values, and ranges.
- Use exact filters for budget, location, asset type, financing, yield, and status constraints.
- Use semantic search only for fuzzy preferences such as style, renovation language, or neighborhood feel.
- Present recommendations as marketplace matching support, not investment advice or valuation guarantees.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Labels and properties
Discover property-listing labels, filterable fields, values, and ranges before translating human search intent.
Open docsProperties API
Inspect property metadata and load distinct values or ranges for marketplace filters.
Open docsSemantic search
Combine natural-language preferences with exact constraints such as price, asset type, location, and financing.
Open docsHow it works
Build the smallest useful workflow first.
01
Load the live property schema
Read listing fields, numeric ranges, enum-like values, and relationship paths before translating a human-language request.
02
Build grounded filters
Convert intent into filters over fields that exist: city, asset type, price, cap rate, financing, owner timeline, renovation level, or market signal.
03
Explain each match
Return the listing plus connected owner, comp, neighborhood, and signal records that explain why it matched the investor or homeowner goal.
Know where it fits.
Exact constraints plus fuzzy preference
Budget, location, yield, status, and financing should be exact filters. Semantic search belongs on descriptive text and soft preferences.
No invented metadata fields
Agents and recommendation services should inspect schema before querying, so they only use property fields, values, and graph paths available in RushDB.
Questions developers ask.
Next step
Start with one focused workflow.
Related use cases
Explore all use casesCommercial lease portfolio memory
Query lease terms, renewal dates, and escalation clauses across a whole portfolio instead of re-reading PDFs per building.
Explore lease portfolio memoryAI-powered apps
Add search and connected-data features without another sync pipeline.
Explore AI-powered appsAnalytical workloads
Move from ingest to KPI trends, dashboard drill-downs, and connected operational context.
Explore analytical workloads