Result row emittedCharged for each ResultRow (one Idealista listing) written to the dataset, deduped by (country, listing_id). MEASURED 2026-08-31 with two 100-row scale runs of src.main (the product, not recon) against madrid-madrid/ES: enrichAgencyContact=false (run ZnasXvRmHtHN8QLhx, 100/100 rows, settled cost $0.265274, 0.0283 GB residential = 0.29 MB/row, $2.65/1,000 COGS) vs. enrichAgencyContact=true (run xfEy3LDqdVWn1G3SU, 44/100 rows before its internal 600s per-country deadline, settled cost $2.011924, 0.2316 GB residential = 5.39 MB/row, $45.73/1,000 COGS — ~17x). Both runs confirmed RESIDENTIAL via scripts/os/run_usage.py and both settled stable after a 5-minute wait (no further drift). enrichAgencyContact now defaults to false (src/models.py, .actor/input_schema.json) because a second finding makes the expensive path a non-starter regardless of price: 0 of the 44 enriched rows in this run, and 0 of the 3 rows in the original QA run DEREkShO6HBt0DCFx, carry ANY additional field (agency_name/agency_phone/listing_owner_type/agent_reference_id/rooms/bathrooms/etc. all null) — the detail-page JSON-LD/agency-block selectors in src/parser.py were apparently never validated against a real idealista detail page, so the extra navigation is pure cost with zero customer value today. This price ($0.005/row = $5.00/1,000) is set against the default (enrichment-off) path only: at $2.65/1,000 measured COGS it clears cost with a healthy margin (80% dev-share revenue $4.00/1,000 minus $2.65/1,000 COGS = ~$1.35/1,000 net). No separate price is set for enrichment — it stays available in the schema (opt-in, clearly flagged as non-functional) but is not monetized as a value-add until a follow-up fix makes it actually extract data; see CHANGELOG 0.1.3 and the idealista-property-scraper entry history in scripts/publish_actors.py.
