Your find-deals system — drawn like one of your wiring diagrams

Same idea as a motorcycle harness: parts = boxes, connections = wires. These are the real parts and the real path. The bright wire is the one I connected today.

Why this matters: this is the SAME kind of drawing as your motorcycle harness — boxes and wires. Your software is built that way, so it can draw itself. And this is just the find-deals slice: your full system map is 915 parts and 2,437 wires — the exact same drawing, just bigger.

The blown-apart engine kind of drawing is the other job — that one needs the real 3D shape of each part, so it's a bigger build we work toward.

What each part is — click any part to open it up

Top is the picture. Open a part and you drop one level: what it is → its real files → what it calls, what sets it off, and why it makes that call.

Visitor's page — the page a stranger lands on

What it is: the public web page where someone types what they want (a cap-rate, a tenant type) and hits a button.

The file: the find-deals web page (lives in the front bundle).

It calls: → the Front door — "here are my criteria, send me deals."

What sets it off: the visitor clicks "find deals."

Why it makes that call: the page can't find deals itself — it hands the request in and waits for the ranked list to come back.

Front door + guard — checks the request, lets it through (the wall)

What it is: the one doorway between the public and your private engines. It checks each request and shapes every answer so nothing private leaks out.

The files: api_portal.v3.20260606.py (the new wire) — which loads api_portal.v2.20260524.py (the door itself).

It calls: → the Deal finder, by handing the request to find_deals_api_router. This is the wire I connected today.

What sets it off: a request arrives at the door (the address /v1/find-deals).

Why it makes that call: the door's whole job is to pass allowed requests inward and carry the answer back out — safely.

Deal finder — finds + ranks the matching deals

What it is: the part that searches the deals and sorts them best-to-worst for the visitor's criteria.

The files: find_deals_api_router.v1.20260602.py — which runs stnl_find_deals_engine.v1.20260602.py (the ranker).

It calls: → Money math, once for each candidate deal.

What sets it off: the Front door passes the request in.

Why it makes that call: it can't rank a deal without its dollar numbers, so it asks Money math to crunch each one first.

Money math — runs the dollar numbers (underwriting)

What it is: the financial calculator — value, yearly income, return (IRR) — for a single deal.

The file: nnn_underwriting_engine.v1.20260517.py.

It calls: → the Deal list, to pull the deal's details.

What sets it off: the Deal finder asks it to score a deal.

Why it makes that call: it needs the raw facts (rent, tenant, terms) before it can do the math.

Deal list — what it searches (~50 sample deals for now)

What it is: the stored list of deals the system searches. Right now ~50 practice deals; later, a live paid source.

The file: nnn_deal_structure_database.v1.20260517.json.

It calls: nothing — it's data. It just sits there and gets read.

What sets it off: Money math (or the finder) reads it when it needs deals.

Why: it's the source — no list, no deals to find or rank.