`docs/deep-research-report.md`

144 lines
# Address-Centric Record Design for a Property-History Platform

## Executive summary

Yes — each address should become its own record. But the real key is that the **address cannot be the only identity key**. For a serious property-history product, the canonical record has to be **place-first and time-aware**: one “place” record linked to normalized addresses, parcel identifiers, structure snapshots, permit events, transaction events, business occupancies, archival maps, photos, and source provenance. That is especially important in Los Angeles County, where the assessor exposes parcel search and map search, the recorder keeps deed records but does **not** provide online address-based access to those records, the city planning system exposes zoning and permit-history context, and Beverly Hills has its own property and permit systems plus a local history collection. citeturn30search0turn30search4turn30search1turn30search13turn24search0turn31search0turn31search1turn31search2

I cannot help compile or expose **current celebrity home addresses** or other sensitive residential-location data. The buildable, durable version of your idea is to make the product **historical, archival, parcel-based, and provenance-heavy**: “this property was associated with X in year Y,” “this building permit changed the structure in year Z,” or “this commercial address previously housed A, then B, then C,” rather than “here is where a living person lives now.” The county recorder’s lack of online address-based access is itself a reminder that residential-location sensitivity is real, and your platform should adopt that privacy posture by design. citeturn30search1turn30search5turn30search13

## What the primary record should be

The right root object is not “celebrity,” not “owner,” and not even “listing.” It is a **Place record**.

A strong Place record should include five layers.

| Layer | What it stores | Why it matters |
|---|---|---|
| Canonical identity | internal `place_id`, normalized street address, alternate address strings, geocode, jurisdiction | Addresses get reformatted; your own stable key should not |
| Parcel identity | assessor parcel number, parcel geometry, parcel version history, split/merge lineage | Parcels change over time; address-only systems break when parcels split or merge |
| Built-form identity | year built, effective year, structure type, square footage, lot size, unit count, style tags | Users think in buildings, not just lots |
| Event ledger | deeds, permits, sales, remodels, demolitions, business openings/closures, historic designations | This is the “story engine” |
| Provenance | source system, source URL, capture date, confidence score, copyright/license, human review status | Without provenance, “history” becomes rumor |

The most important modeling decision is to keep **addresses, parcels, structures, and occupancies separate**. One parcel can have multiple addresses. One address can refer to different structures across time. One structure can hold multiple commercial tenants over decades. One person or business can be associated with a place for only a bounded time window. If you collapse those ideas into one table, the data will become unusable as soon as you ingest serious history data.

In Los Angeles County, that temporal design is not optional. The county exposes current parcel boundaries and also maintains parcel-change data, which is a signal that parcel versioning belongs in the core schema from day one. The county’s open parcel layer covers roughly 2.4 million parcels, and the assessor portal describes detailed information for roughly 2.7 million properties. citeturn1search11turn4search1turn1search3turn4search0

## The official source stack you should anchor to

The right approach is to treat archival and social sources as **discovery layers**, while official systems remain your **system-of-record layers**.

| Source layer | Best anchor source | What it gives you |
|---|---|---|
| Parcel and assessment | entity["organization","Los Angeles County Assessor","county assessor office"] | parcel lookup, assessment context, map search, AIN/APN linkage, current parcel geometry context citeturn30search0turn30search4turn30search12 |
| Deeds and transaction documents | entity["organization","Los Angeles County Registrar-Recorder/County Clerk","county recorder office"] | deed history and recorded documents, but **not** clean online address search; you need name/year/document workflows or purchased copies citeturn30search1turn30search9turn30search13turn30search17turn30search21 |
| Zoning and planning context | entity["organization","Los Angeles City Planning","city planning department"] | zoning, land use, planning applications, and building-permit-history context through ZIMAS and related systems citeturn24search0turn30search2turn30search6turn30search10turn30search22 |
| Beverly Hills property operations | entity["organization","City of Beverly Hills","municipal government"] | property lookup by address/APN/permit number, permit records, interactive GIS, and issued-permit datasets updated nightly citeturn31search0turn31search1turn31search3turn31search6turn31search19turn31search22 |
| Local archival depth | entity["organization","Beverly Hills Public Library","Beverly Hills, CA, US"] | photographs, surveyor field books, maps and plans, newspapers, and local research collections that make “this used to be…” possible citeturn31search2turn31search12 |
| Historic map layer | entity["organization","Library of Congress","federal library"] | Sanborn fire insurance maps and HABS/HAER-style architectural photo documentation for older structures and neighborhoods citeturn30search3turn30search7turn30search19 |
| Discovery / lead generation | entity["organization","Vintage Los Angeles","Los Angeles history media"] | excellent for stories, leads, and cultural memory, but it should feed a verification workflow rather than publish directly into your truth layer citeturn33search0turn33search6turn33search10 |

That stack lets you do two different products at once.

For **residential history**, you can build parcel timelines, permit histories, renovations, architect/designer notes, historic survey designations, and former notable associations if they are genuinely historical or otherwise already public. For **commercial history**, you can make the address itself the hero: “current occupant,” “previous occupant,” “first known use,” “permit eras,” “photo gallery by decade,” and “map layers by year.”

## Privacy and editorial guardrails

If you want this to become a durable subscription product rather than a liability magnet, you need explicit editorial rules.

The first rule should be simple: **no database of current celebrity home addresses, current private residences of living individuals, or inference-based occupancy claims**. That includes “everybody knows” neighborhoods, paparazzi-style reporting, and social-media breadcrumbs. The product should be about **property history**, not stalking infrastructure.

The second rule should be that every human or business association is stored as a **claim with dates and evidence**, not as an eternal truth. For example:

- “Associated with [person/business] from 1968–1974”
- “Listed in local survey as contributor to historic district”
- “Construction permit issued in 1997”
- “Commercial tenant shown in city directory/newspaper ad in 1983”

The third rule should be that every claim gets a **source class**:

- **Tier A**: government or institutional record
- **Tier B**: library/archive/map/photo collection
- **Tier C**: verified secondary source
- **Tier D**: social/discovery lead awaiting confirmation

That means a social post can trigger research, but it cannot become public fact until it is tied back to stronger evidence. This is the difference between a fun nostalgia product and a trustworthy research product.

## How to handle the big-data side

“Each address is its own record” becomes powerful only when the storage model is event-driven.

I would structure it like this:

1. **OLTP core** in PostgreSQL with PostGIS  
   Store `place`, `address`, `parcel`, `structure`, `business`, `person_association`, `event`, `media_asset`, and `source_citation` tables.

2. **Append-only event ledger**  
   Never overwrite history. Insert new events with `valid_from`, `valid_to`, `recorded_at`, and `source_id`.

3. **Search index**  
   Push address strings, parcel IDs, former business names, architect names, neighborhood tags, and alternate spellings into a search engine such as OpenSearch or Elasticsearch.

4. **Object storage for media and map tiles**  
   Store scans, historical photos, and georeferenced map layers outside the relational database, with only references and rights metadata in SQL.

5. **Graph edges for stories**  
   A lightweight graph model on top of SQL helps answer questions like “show all properties connected to this restaurant brand,” “show businesses that cycled through this block,” or “show addresses linked to the same architect.”

6. **Confidence and review workflow**  
   Every record should carry `confidence_score`, `review_status`, and `public_visibility`. That gives you a clean separation between raw ingestion, editorial review, and public publishing.

This model also supports the business idea you described earlier. The same `place_id` can power a free public page, member comments and chat, a paid owner-controlled landing page, and an API object for enterprise customers. One canonical record; many monetization surfaces.

## The first dataset I would build

The smartest first dataset is **not** “current celebrity homes.” It is:

**“Address histories for a tightly bounded pilot geography, with verified public history and strong archival support.”**

For your use case, that means:

- a Beverly Hills pilot geography,
- parcel-first ingestion from county and city systems,
- permit and zoning enrichment,
- local-history media attachment,
- business-occupancy timelines for commercial addresses,
- and a **notable-association table limited to historical, landmarked, or otherwise non-sensitive associations**.

A good minimum public record for one address would look like this:

```json
{
  "place_id": "pl_bh_000001",
  "canonical_address": "123 Example Dr, Beverly Hills, CA 90210",
  "alternate_addresses": [],
  "parcel_ids": ["apn_here"],
  "geometry": {"lat": 0, "lng": 0},
  "jurisdiction": "Beverly Hills",
  "structure_snapshot": {
    "property_type": "single_family",
    "year_built": 1928,
    "lot_size_sqft": 18000,
    "building_area_sqft": 6200
  },
  "events": [
    {"type": "permit", "date": "1954-06-12", "summary": "addition/remodel"},
    {"type": "sale", "date": "1978-03-04", "summary": "recorded transfer"},
    {"type": "business_occupancy", "date_range": "1981-1987", "summary": "former tenant"}
  ],
  "notable_associations": [
    {"type": "historical_only", "date_range": "1940s", "summary": "verified historical association"}
  ],
  "media_assets": [
    {"type": "historic_map", "year": 1950},
    {"type": "archival_photo", "year": 1938}
  ],
  "provenance": [
    {"source_class": "government", "confidence": 0.98},
    {"source_class": "archive", "confidence": 0.90}
  ],
  "privacy_class": "public_history_only"
}
```

That is the foundation worth scaling. It gives you the “lots of big data” upside, while staying aligned with public-record workflows, archival depth, and privacy boundaries that official systems themselves already signal. citeturn30search1turn30search13turn31search0turn31search3turn31search2turn30search3