This is a working outline, not the finished essay. The structure, the arc, and the specific points to hit are all here — the prose gets written on top of it. (Verified figures used below: 305,476 buildings, $290B assessed value, 30,251 owners, 14 counties, from the live pipeline export.)

1. The hook: the data is public, and nobody can see it

Open on the core tension — everything you need to find a good multifamily deal is public, just un-joined.

  • Parcel geometry, assessed values, unit counts, owner names, market rents — all exist, scattered across town assessor databases, a statewide GIS layer, and federal rent tables.
  • The gap isn't data access; it's integration. State the thesis: joining these into one schema turns a filing cabinet into a decision engine.
  • Frame the scale up front: all 305,476 multifamily buildings in MA, one 0–100 score each.

2. Starting with MassGIS: what a statewide parcel layer actually is

Ground the reader in the raw material before any analysis.

  • What MassGIS provides: standardized statewide parcels with geometry and land-use codes across all 14 counties.
  • Filtering to multifamily by use code — and why that filter is itself a judgment call worth documenting.
  • The shape and size of the raw extract; why "statewide" changes your tooling choices (you can't do this in a spreadsheet).

3. The joins that create signal

The heart of the data-engineering story — three sources becoming one record per building.

  • Town assessor records → unit counts, year built, assessed value, keyed to the parcel.
  • HUD Fair Market Rents by county and bedroom count → the rent benchmark that makes a yield estimate possible.
  • Why PostgreSQL + PostGIS: spatial joins, county rollups, and geometry queries in one engine instead of stitching tools together.
  • Show a representative (sanitized) join — the moment scattered tables become one analyzable row.

4. The 0–100 deal score

Explain the composite without hand-waving — and defend the design choices.

  • The components: estimated yield against the HUD benchmark, distress indicators, ownership signals, and a data-confidence term.
  • Why confidence is part of the score, not a footnote: a building with thin assessor data must not be able to masquerade as a strong signal.
  • Two-layer ranking: separating "good building" from "good opportunity right now," so quality and timing don't blur into one muddy number.
  • Honest caveat: HUD FMR is a floor, not a market rent — where that under-sells hot submarkets, and how you'd fix it.

5. The ownership graph: who owns a building is a signal

The feature that turns a parcel list into a call list.

  • Owner-name resolution: collapsing hundreds of thousands of parcel records into 30,251 distinct owners.
  • Flagging portfolio holders and absentee owners — the patterns that actually precede a deal.
  • The messy reality of name resolution (LLCs, trusts, typos) and why you treat it as a strong hint, never ground truth.

6. Data-quality traps that silently corrupt a spatial pipeline

The most valuable section for a technical reader — the war stories.

  • Bad geocodes: coordinate-bounds filtering to keep off-map points out of the layer before they skew aggregates.
  • Schema-key drift: how a mismatched key silently rots a join across services, and why keys are now enforced as hard contracts.
  • The general lesson: in a spatial pipeline, failures are quiet — a join doesn't error, it just returns fewer rows than it should.

7. Delivery: heavy database, light site

Tie the architecture to the economics.

  • The database does all the thinking; the public site reads a pre-exported static dataset. The DB never sits in the request path.
  • A daily refresh re-scores and commits the export — every day's rankings reproducible from git.
  • What this buys: a site that's fast, cheap, and can't be knocked over, backing a $290B-of-assessed-value dataset.

8. What I'd do differently / next

Close with judgment — the part hiring managers read closely.

  • Nail the "scored" definition to a single documented threshold.
  • A per-building rent model to replace the HUD floor in hot markets.
  • Close the loop: feed accept/reject review labels back into the scoring weights.
Takeaway to land: the hard part of "AI for real estate" isn't the model — it's the joins, the hygiene, and the honesty about confidence.