WatchlineNYC

Making NYC landlord ownership visible
conversationally, with its uncertainty labeled

Robert Flagg — mathematician turned trustworthy-AI engineer I make AI systems trustworthy by grounding them in knowledge graphs

An open source project, built on JustFix's Who Owns What

Agenda

Where we're headed

1The Problem — Holding landlords accountable

2How Who Owns What builds portfolios

3Two failure modes — false splits & false merges

4Resolving false splits — probabilistic record linkage

5Resolving false merges — the beneficial owner group

6Next steps

The Problem

Holding landlords accountable

102 E 7TH ST LLC

11 AVENUE B LLC

124 RIDGE LLC

134 ORCHARD LLC

17 GAY LLC

151 RIVINGTON HLDGS

159-161 STANTON LLC

17 W 103RD LLC

145 E 26 LLC

1590 LEXINGTON LLC

124 RIDGE LLC

…107 names

→

STEVEN CROMAN

one operator

118 buildings. 107 different LLC names. Almost one shell per building — each named for its own address, none of them "Croman."

A tenant can't find their real landlord. A journalist can't map the empire. An agency can't add up the violations.

Source: Who Owns What's own "Steven Croman" portfolio (#87254); LLC names from NYC PLUTO owner-of-record. AG case: public record.

(~45s) NYC ownership is fragmented by design. Each building sits in its own single-purpose LLC, usually named after the address — so on paper there's no "landlord," just a scatter of shells. Take Steven Croman: a landlord the AG investigated, who pleaded guilty and served jail time — about as public and documented as a bad actor gets. In Who Owns What's OWN Croman portfolio, those 118 buildings are held under 107 different corporate names — nothing in that list says "Croman." Tools like Who Owns What already re-assemble a lot of this — that's what I build on. But if it takes work to see it for a FAMOUS operator, the quiet ones are effectively invisible — to tenants, reporters, and the agencies meant to hold them accountable.

How Who Owns What builds portfolios

A WoW “portfolio” is a connected component of a landlord graph

1 · Nodes — one per building's owner/officer contact: a (name, business address) drawn from HPD registrations → their contacts (head officer / owner).

2 · Edges — CONNECTED_BY_ADDRESS (same business address) and CONNECTED_BY_NAME (same name, corroborated by a nearby address).

3 · Portfolio — a connected component: everything transitively linked.

JustFix — Who Owns What (portfoliograph): HPD registrations + contacts → landlords_with_connections (self-join on shared name / business address) → connected components.

(~55s) The baseline everyone here knows — JustFix's Who Owns What, the open-source tool this builds on. The key thing to see is that it's a GRAPH problem. NODES first: every building files an HPD registration, and each registration lists contacts — head officer, owner, agent. WoW takes the owner/officer contact and makes a node keyed on that person's name plus their standardized business address — so a node is a (name, business-address) pulled straight from the registrations and contacts tables. EDGES next: draw one between two nodes on either of two rules — CONNECTED_BY_ADDRESS when they share a business office, or CONNECTED_BY_NAME when they share a name backed by a nearby address. Then a "portfolio" is just a CONNECTED COMPONENT of that graph — everything transitively linked, like the four ringed here; the two on the right are a different component, a different portfolio. Notice what that component actually captures: an OPERATIONAL NEXUS — who registers and manages together — not title. A genuinely strong first pass, and what makes the invisible visible. But hold onto the mechanism, because it's exactly where it breaks: lean on a shared address and you fuse unrelated owners who merely use the same managing agent — a FALSE MERGE; require a shared address or name and a real owner who leaves neither drops off the graph entirely — a FALSE SPLIT. Those two are the rest of the talk.

The problem this talk is about

Two ways to be wrong

Both come from the same rule — connect on shared attributes. Lean on it and you fuse strangers; require it and you lose real owners. The rest of the talk: fix each without breaking the other.

(~45s) The same mechanism from the last slide breaks in exactly two directions. FALSE MERGE, on the right: three buildings with three different real owners all list the same business address — because they all use the same managing agent. WoW's CONNECTED_BY_ADDRESS rule links them, the connected component swallows all three, and now one "portfolio" is really three owners — you over-count, and you can smear one owner's violations onto another. FALSE SPLIT, on the left: one owner holds three buildings in three shell LLCs, each with a different registered name and a different office — nothing to match on, so there are NO edges. WoW sees three separate components — three portfolios — and the real owner is fragmented, effectively invisible. Same rule, opposite failures: lean on shared attributes and you merge strangers; require them and you split a real owner. The whole rest of the talk is how we fix each of these — WITHOUT trading one failure for the other.

False split — in the wild

One owner, six Who Owns What portfolios

The same man at the same two offices — split by floor labels, a name spelling, and a dropped digit

#	Registered office — as filed in HPD	Name filed	Filings	Buildings
1	424 WEST 51 ST — “GF” · “GROUND” · “2 FL”	STEVEN / STEVE CROMAN	5	118
2	740 BROADWAY — “—” · “2” · “2 FL”	STEVE / STEVEN CROMAN	3	5
3	4 WEST 51 ST ⚠ a couple of digits dropped from 424	STEVEN CROMAN	1	1
4	424 WEST 22 ST	STEVEN CROMAN	1	1
5	424 BROADWAY	STEVEN CROMAN	1	1
6	632 BROADWAY	STEVEN CROMAN	1	1
	6 fragments — all “Steven Croman,” one owner		12	127

Every row is the same man at the same couple of offices. Who Owns What splits him six ways on clerical noise — a floor label, a name spelling, a missing digit — because exact name-and-address matching can't bridge any of it.

WatchlineNYC discovery graph — WoW-equivalent components over CONNECTED_BY_NAME ∪ CONNECTED_BY_ADDRESS; owner identity unifies them to 127 buildings. See the live map · docs/cases/croman.html.

(~50s) A false split you can't wave away as an edge case — the most notorious landlord in New York. Ask Who Owns What for "Croman" and you don't get one portfolio, you get SIX. Here's why, filing by filing: every one is Steven — or Steve — Croman, at basically two offices, 424 West 51st and 740 Broadway. But look at the office field as HPD has it: filed as "GF," then "GROUND," then "2 FL"; the name as both STEVEN and STEVE; and one building filed from "4 West 51" — a couple of digits dropped from 424. WoW matches on exact name and address, so each clerical variant becomes its own node, and the connected components fall into six portfolios — 118, a 5, and four singletons, 127 buildings in all. Our identity layer bridges that noise and reunites all 127 — the next slides are how.

The engine — fixing false splits

Probabilistic record linkage

Decide whether two records are the same owner from many partial clues — not one exact match

Record A
CROMAN · 9 E 38 ST · 10016

Record B
CROMAN · 9 EAST 38 STREET STE 600 · 10016

last name exact & rare ✓✓ · street fuzzy ~ · zip exact ✓ → match probability ≈ 0.99 → same owner (the exact-match rule would split these)

①Compares field-by-field, in degrees — exact / fuzzy / mismatch on name, house number, street, zip — so typos and variants still match

②Weighs the evidence (Fellegi–Sunter model) — agreement on a rare value counts more than a common one → a calibrated match probability, with weights learned unsupervised (no labels)

③Scales, with a precision dial — “blocking” compares only plausible pairs, so it runs over millions of records; we set the threshold high — link only on strong evidence

The open-source engine behind our CONNECTED_BY_SPLINK edges — it links the fragments exact-match rules miss, reuniting an owner WoW splits.

Splink — open-source probabilistic record linkage, UK Ministry of Justice · moj-analytical-services.github.io/splink

(~55s) So how do we fix that false split? The identity engine is Splink — an open-source probabilistic record-linkage library from the UK Ministry of Justice. Not our invention; a well-established tool. The idea: instead of demanding an exact name-and-address match like the baseline, it compares two records field by field in DEGREES — exact, fuzzy, or mismatch — and weighs each agreement by how much evidence it actually carries. Agreeing on a rare surname is strong; agreeing on a common one is weak. It sums those into a calibrated match PROBABILITY, and it learns those weights unsupervised — no labeled training data. Blocking keeps it fast over millions of records. Look at Croman's two office registrations: "9 E 38 St" versus "9 East 38 Street Ste 600." The exact-match rule sees two different addresses and splits them; Splink sees the same rare name, a fuzzy street match, the same zip, and says 0.99 — same owner. And it's a DIAL: we set the threshold high, precision-first, so we only merge on strong evidence — which matters, because the other failure mode is merging strangers.

False split — resolved

Add `CONNECTED_BY_SPLINK`, recompute the components — Croman is whole

WatchlineNYC map: Steven Croman's 127 buildings resolved to one owner, versus Who Owns What's six portfolios

Same landlord graph, one new edge type. The Splink matches bridge the typo'd offices and name variants WoW's exact rules can't — one filed from 4 WEST 51, another from 424 WEST 51 — so the connected component now spans the lot: 6 portfolios → 1 owner, 127 buildings.

WatchlineNYC discovery graph — owner identity via connected components over CONNECTED_BY_NAME ∪ CONNECTED_BY_ADDRESS ∪ CONNECTED_BY_SPLINK. Toggle vs. Who Owns What live on the map.

(~45s) Same graph as two slides ago — same nodes, same name and address edges — with ONE addition: the CONNECTED_BY_SPLINK edges from the model we just met. Those edges do exactly what the exact-match rules couldn't: they bridge Croman's typo'd office variants and his name spellings, because Splink scores them as the same owner with high probability. Add those edges and re-take connected components, and the six WoW fragments collapse into a single component — one owner, 127 buildings. That's the whole false-split fix in one picture: we didn't throw away WoW's signals, we added a probabilistic one on top, and the portfolio comes back together. On the live map this is a toggle — Who Owns What's six colors on one side, our single owner on the other.

False merge — in the wild

One WoW portfolio, seven owner groups

Twenty-seven buildings self-file from a single Lakewood office — Who Owns What reads them as one owner.

Owner — beneficial owner group	Filed under	Bldgs
Joe Nebenzahl	JOE · JOSEPH NEBENZAHL	7
Abraham Miller	ABRAHAM · ABARAHAM MILLER	7
Jeanette Padilla	JEANETTE PADILLA	4
Nathan Obstfeld	NATHAN OBSTFELD	4
Vanessa Soria	VANESSA · VANEESA SORIA	3
⚠ singleton	NATHAN OBTFELD — a 1-letter typo	1
singleton	BENYOMIN FISCH — one building, unmerged	1
Who Owns What: “one owner”	235 River Ave, Lakewood NJ	27

A shared back-office is an operational nexus, not an owner. Who Owns What's one portfolio is really seven owner groups — five families plus two one-building singletons (one of them a typo of Obstfeld).

All 27 buildings file HPD registrations from 235 River Ave, Lakewood NJ (self-filed — not a registered agent). Owner groups from the WatchlineNYC discovery graph. See the live map: the Miller portfolio.

(~45s) Here's the false merge in the real data. Twenty-seven buildings all list the same HPD registration address — 235 River Avenue in Lakewood, New Jersey — so Who Owns What's shared-address rule fuses them into one portfolio, one owner. But read the owners: Nebenzahl, Miller, Padilla, Obstfeld, Soria — five different families, each filed under its own name variants: Abraham versus Abaraham Miller, Joe versus Joseph Nebenzahl. They just share a back-office; I checked, it's not a registered agent, just an address small landlords self-file from. Then two one-building singletons the linkage left on their own — Benyomin Fisch, and "OBTFELD," a one-letter typo of Obstfeld we honestly left split. Seven owner groups where Who Owns What sees one. Precision-first: we'd rather leave a straggler than merge two owners by mistake. Next: how we compute these owner groups so the office stops standing in for the owner.

Resolving false merges

The beneficial owner group

A shared business address tells you who operates together — not who owns.

Don't ask one signal two questions!
A shared office answers “who operates together?” — never “who owns?” So ownership gets its own node, built from its own edges.

Beneficial owner group = connected components over CONNECTED_BY_SPLINK ∪ CONNECTED_BY_DEED (ownership signals) — it ignores CONNECTED_BY_ADDRESS. Worked example: the Miller map — one Lakewood office, seven owner groups.

(~55s) This is the answer to the obvious challenge — "doesn't your system just merge everything into big portfolios?" No; here it does the opposite. Who Owns What links landlords that share a business address — and a shared office is a real, useful signal: it tells you who OPERATES together, the operational nexus. The mistake is asking that one signal a second question it can't answer — "who OWNS this?" A dozen unrelated landlords can self-file from the same back-office; the address says nothing about ownership. So we stop overloading the signal. We add a new node type — the beneficial owner group — and connect it with its OWN edges: CONNECTED_BY_SPLINK, our probabilistic identity linkage, and CONNECTED_BY_DEED, from the property record. Crucially those edges ignore the shared address. So the same office that WoW read as one portfolio resolves into two distinct owners here — Rivera and Chen — each its own owner group. One signal, one question. If you want the real, messy version, the footer links the Miller map: one Lakewood office that WoW reads as a single owner, resolved into seven owner groups.

False merge — resolved

Drop `CONNECTED_BY_ADDRESS`, recompute the components — the false merge vanishes

WatchlineNYC map: Who Owns What's single Miller portfolio (27 buildings, one owner) resolved into seven distinct owner groups

Owner identity is built from SPLINK ∪ DEED — it never uses the shared-office edge. Recompute connected components without CONNECTED_BY_ADDRESS and the one fake portfolio falls apart into its real owners: 1 WoW portfolio → 7 owner groups, 27 buildings.

WatchlineNYC discovery graph — owner groups via connected components over CONNECTED_BY_SPLINK ∪ CONNECTED_BY_DEED (CONNECTED_BY_ADDRESS excluded). Toggle vs. Who Owns What live on the Miller map.

(~40s) The mirror image of the Croman fix. There, we ADDED an edge to reunite a split owner. Here we DROP one — the shared-office edge — and recompute. Who Owns What paints these 27 buildings as a single portfolio, one owner, because they all register from 235 River Avenue. But owner identity is built only from the ownership signals — Splink identity matches and deed transfers — and it never looks at the shared address. Recompute connected components on those edges and the one fake portfolio dissolves into seven separate owner groups: Nebenzahl, Miller, Padilla, Obstfeld, Soria, and two singletons — including the Obtfeld typo we left honestly split. On the live map it's a toggle: Who Owns What's one color, versus our seven. Same algorithm, the shared office simply isn't an ownership edge.

Owner groups — why CONNECTED_BY_DEED

Some owners are held together by nothing but the deed

Citadel Estates bought 15 Brooklyn buildings on one 2008 deed ($58.4M), then re-titled each into its own $0 shell — a Deadhead's roll-call (Ripple, Scarlet Begonias, Stella Blue…) — registered under three different people.

15 Brooklyn buildings colored by three registrants — without the deed edge the owner group splits three ways; the 2008 Citadel deed reunites them into one owner

No shared name, no usable address (their one shared office is a masked aggregator we ignore), no Splink match. Strip CONNECTED_BY_DEED and this owner group shatters into three. The deed is the only thing keeping the true owner whole — which is why the owner group is SPLINK ∪ DEED.

Owner group OG-67966 — a deed_only clique (CONNECTED_BY_DEED; no name/address/splink among the three). One 2008 ACRIS deed + $0 restructuring. Toggle without deed ↔ one owner on the Citadel map.

(~45s) This is the deed edge doing what nothing else can — inside our own ownership layer, no Who Owns What comparison needed. Citadel Estates bought fifteen Brooklyn buildings on a single 2008 deed, then re-papered each into its own single-purpose LLC — named after Grateful Dead songs — every transfer at zero dollars. Today they register under three different people. They share one back-office, 1330 Eastern Parkway, but it's a 33-landlord aggregator, so we correctly IGNORE it — using it would fuse strangers, the Miller mistake we just saw. Once the address is masked, there is nothing left for name or Splink to grab: three different names, twelve differently-named shells. So the ONLY thing that reveals these as one owner is the deed. Strip CONNECTED_BY_DEED and this owner group shatters into three separate owners. That's why the beneficial owner group is built from SPLINK UNION DEED — the deed is load-bearing exactly where masking the aggregator address would otherwise leave the true owner invisible. A lead, not a verdict: three registrants, one grantor chain, all at zero dollars.

WoW Portfolios vs Beneficial Owner Groups

The same algorithm over different edge sets

Community detection never changes — connected components over one landlord graph. Swap the edge set and you swap the question: operate together vs own together.

Both are connected components in the WatchlineNYC discovery graph. WoW portfolio edges: CONNECTED_BY_NAME ∪ CONNECTED_BY_ADDRESS; beneficial owner group edges: CONNECTED_BY_SPLINK ∪ CONNECTED_BY_DEED. (We also add SPLINK to the portfolio layer to heal false splits — earlier slides.)

(~50s) Here's the whole architecture in one picture — and the reassuring part is how little new machinery it takes. A WoW portfolio and a beneficial owner group are computed the EXACT same way: connected components in a landlord graph — the same algorithm JustFix already uses. The only thing that changes is which edges you feed it. On the left, the WoW portfolio: edges are CONNECTED_BY_NAME and CONNECTED_BY_ADDRESS, the operational signals — who registers and offices together. Run components over those and L1, L2, L3 fall into one portfolio; L4, L5 into another. On the right, the SAME five nodes, but now the edges are CONNECTED_BY_SPLINK — our probabilistic identity linkage — and CONNECTED_BY_DEED, from the property record. Run the same algorithm over THOSE edges and you get different communities: L1 with L2, L4 with L5 — and L3 pops out on its own. L3 shares the office, so it's in the portfolio, but it's a different owner, so it's its own owner group. That's the entire idea: don't invent a new algorithm, just stop overloading one edge set with two questions. Operational nexus and ownership are different communities in the same graph.

The close

What's next?

On the ~39,500 buildings both systems group, we differ both ways — ~780 of our owner-groups unify what WoW splits · ~620 WoW portfolios split across ours. Which of those are improvements? The blind eval decides — and it isn't run.

What's not done yet

The blind accuracy eval is built, not run — ~530 pairs need adjudication.
This is a prototype, not a shared service.
A conversational front-end to give access to non-technical users like journalists, tenant advocates, watchdog agencies, and the general public.

Where I need help

Running the ~530-pair blind eval — ground-truth portfolios, adjudication time, or a co-adjudicator.
Feedback on the new graph model.

Thank you! (Q&A)

(~55s) Let me close where I started. Everything you've seen produces LEADS, not verdicts — a pointer to a question a human should investigate, never a claim that a named person owns something. In the demo you'll see it refuse to cross that line; that refusal is the most important feature in the system. And let me be straight about what I HAVEN'T done — the resolver is precise on a labeled set, and it diverges from Who Owns What at scale, both ways: roughly 780 of our owner-groups unify buildings WoW splits, and about 620 WoW portfolios split across ours. But that's DIVERGENCE, not accuracy — I have NOT run the blind, adjudicated head-to-head that tells you who's right where we disagree. It's built; it needs ground truth and hands. This isn't a service you can use yet. So the reason I'm really here: I'd love your help — ground-truth data, adjudication time. Some of this probably belongs back in Who Owns What. And I'd value your read on the three-layer idea. I'm new to this world, the tool is the contribution, and I'm hoping to build the next part WITH people in this room. Thank you.

Appendix · the live agent

Conversational — by design, not free-form

The agent orchestrates queries; it doesn't reason about people

Guarantees enforced in code — not asked of the model:

Asks the graph, never answers from itself — plain English → parameterized, read-only queries; it reports only what a query returned, every inferred element carrying its caveat.
"Who owns this?" returns both — recorded owner and apparent controller, labeled — and flags when they disagree.
Read-only, access-gated — writes/admin refused; deep investigation only for vetted users (fail-closed).

You can't manufacture false certainty about a person if you only ever report what a sourced, labeled query returned.

Enforced in the tool-visibility layer, not a prompt — the records themselves (violation text, ACRIS JSON) are a prompt-injection surface.

Appendix · live demo · pinned to a public landlord

Ask it about Steven Croman

Watch it label every layer — sourced vs inferred — and refuse to overclaim

① "Who owns 17 Gay Street?" → the three layers

Three labeled layers, one answer: 17 GAY LLC (sourced) · Steven Croman (inferred) · unified owner — 12 fragments, 127 buildings (inferred, a lead not title).

② "And who manages it — same as who owns it?" → manager ≠ owner

Centennial Properties NY (114 buildings) — "a manager is not an owner." Management ≠ ownership.

③ "So can I report he legally owns all 127?" → leads, not verdicts

It declines — "not a legal determination… only a title search or court finding could support that." Leads, not verdicts.

If projection fails: pre-recorded capture + screenshots as backup. Data: BBL 1005930008 → owner group OG-105462 (12→127) · manager Centennial (114).

Backup · likely pushback

Two fair questions

"We live in SQL — what does the graph add?"

Concede: most of the pipeline is SQL — WoW is Postgres, the linkage is DuckDB.
The graph earns its place for the transitive, multi-relationship parts: connected-component owner identity · N-hop "who connects to whom" across owner/manager/deed layers · graph analytics.
"Count violations per owner" → SQL. "Everyone within 3 hops across four link types, ranked by centrality" → graph.

"We don't trust AI."

Good — neither do I, for claims about people.
The real inference is transparent statistical linkage (measured precision), not a neural net.
The language model is a read-only front door — it makes no claims; the public record does. Ignore it and read the sourced records.
Its main job is to not falsely connect people.

Both answers share one core: the substance is the public record + a transparent, measured linkage step. The graph and the LLM are tooling around it — each earning its place, everything labeled sourced vs. inferred.

SQL question — concede hard: most of this IS SQL. WoW is Postgres, Splink is DuckDB, every conditions aggregate is a GROUP BY. The graph earns its place in three spots that are awkward or slow in SQL, not impossible: (1) transitive closure — the owner-identity layer IS connected components over the identity edges, one call in a graph, a recursive-CTE headache in SQL; (2) heterogeneous N-hop traversal — "start at this building, walk out across shared-owner/manager/address/deed links, who do I reach" is one graph pattern, a per-hop per-edge-type union in SQL; (3) graph data science — centrality, community, link-prediction run natively. If someone says "you could do it with recursive CTEs or Apache AGE" — concede: you can; it's a convenience/performance + agent/GDS substrate call, not a capability SQL lacks. AI question — AGREE with them; skepticism is correct. Separate the two AIs: the thing that decides who's the same owner is an auditable STATISTICAL model whose precision we measure — not a neural net; the language model is only the front door and never invents an answer, it reads the record and labels it. "If you don't trust the AI, ignore it — read the sourced records it points you to; the findings don't depend on it." And the trust-builder: the tool's main job is to NOT falsely connect people (the Miller case). Name the honest limit yourself: the accuracy eval isn't run yet.