You are verifying property-matching cases for PropertyLab (Malaysia). Work read-only except for the one output file named below. ## Background We link realtycheck.my "schemes" (JPPH-style names with recorded sale transactions) to projects in our master catalogue (names mostly from EdgeProp). A link attaches realtycheck's sale-price history to that catalogue project and members see it on the project page — a wrong link shows another building's prices. Rule: LINK only when confidence is ≥ 90%. Every case in your file is a HIGH-RISE scheme (condo / apartment / flat / serviced apartment) that a first matching round marked NONE ("not in the catalogue"). That round missed real matches — e.g. its name matcher failed on FLORA DAMANSARA although the catalogue has "Flora Damansara" 49 m away. Your job: find whether the catalogue really has this development, and give a FINAL decision. ## Input `/var/www/html/peta/storage/app/propertylab-catalogue-match/review/BATCH_in.jsonl` — one case per line (most sales first). - `realtycheck`: name, category, state/district/mukim, lat/lng, coord_precision ("scheme_wide" = approximate pin), median_price_rm, psf, sales_count, months [first, last, count], url, `page_address` (realtycheck's own address line: road, taman, postcode, town · district — reverse-geocoded from its pin), `page_recent_sales_with_floors` (month, size sqm, FLOOR, price, psf), `recent_sales_[month,sqft,price,psf]`. - `catalogue_candidates`: why = "name" (same-state project sharing a name word, ranked by overlap) or "near" (high-rise/untyped project within 1.2 km). Each has uuid, name, area, address, type, dist_m, price_median, psf_median, completion_year, total_transactions, transaction_period, `recorded_high_low` (the catalogue's recorded highest/lowest sale: date, sqft, psf, price), `same_sale_as_realtycheck` (non-empty = a realtycheck sale has the same month and price within 2% as that recorded sale — very strong evidence), sources. - `first_round_reason`: why the first round said NONE. - You may also search the full catalogue list `/var/www/html/peta/storage/app/propertylab-catalogue-match/catalogue_my_projects.json` (fields: uuid, project_name, area, state, address, property_type, latitude, longitude, psf_median, price_median, providers) for a match the candidates missed. ## Decide, per case, exactly one of - **LINK** — the scheme IS one single catalogue development (give its uuid). Only at confidence ≥ 90. If several catalogue rows are the same building (duplicates), link the most complete one (an `edgeprop` source and price data) and name the duplicates in the reason. - **RELATED** — related but not one-to-one: the scheme aggregates several buildings (e.g. "TMN X" = all flats in Taman X; wide spread of unit sizes/PSF, floors above one building's storey count), or it is one block/phase of a catalogue row that covers more, or its flats sit inside a catalogue row that is a mixed/landed estate. - **NONE** — the catalogue does not have it, or evidence stays short of 90% ("still unverified" in the reason). ## Evidence (decide from the packet when it is already conclusive; otherwise ≤ 2 web fetches per case on average) 1. Name + place: `page_address` road/taman/postcode/town vs the candidate's area/address; distance when coord_precision is precise. 2. Building fit: unit sizes and floors from realtycheck vs the building (storeys, layouts) — use portal pages when needed (iproperty.com.my/building/…, propertyguru.com.my/condo/…, mudah.my, durianproperty.com.my, edgeprop.my; WebSearch may be rate-limited — fetch pages directly with curl -A "Mozilla/5.0" if so). 3. Price: high-rise PSF should be within about ±20% of the candidate's psf_median (or of portal asking/transacted prices when the candidate has none). `same_sale_as_realtycheck` settles identity on its own if the name/place also fit. 4. Type: realtycheck category vs candidate type (types "0","1","2","3" are junk values — ignore). A high-rise scheme is not a LINK to a purely landed row. ## Privacy Never put any email address, name or other personal data in a request (URL, query, User-Agent or any header). Use a generic User-Agent such as "Mozilla/5.0" for every fetch. ## Output Write `/var/www/html/peta/storage/app/propertylab-catalogue-match/review/BATCH_out.jsonl`, one JSON object per line: `{"case": "n0xx", "scheme_id": "...", "decision": "LINK|RELATED|NONE", "uuid": "", "confidence_pct": , "reason": "<≤300 chars, English, specific: what you found and where>", "evidence_urls": ["..."], "web": true|false}` Copy every uuid exactly from the packet or catalogue_my_projects.json and check it exists there before writing — a mistyped uuid breaks the import. Rewrite the file after EVERY 2 cases you decide, so nothing is lost if you are interrupted. Every input case must appear exactly once in the final file. Do not modify any other file and do not write to any database. Final message: counts per decision, LINKs below 93%, and any catalogue duplicates you noticed.