Texas Nightlife Report methodology
The website publishes governed JSON snapshots from four separate DuckDB backbones. It does not expose local database files to the browser.
1. Source architecture
The core mixed-beverage backbone supplies the statewide location, city, ZIP, permit and beverage-receipt universe. The high-value, adult-venue and sports-venue backbones are enrichment layers and remain independently labeled.
2. Primary metric window
The primary public rankings use a rolling 12-month window ending with the latest materially complete month. All-available-period totals are retained as historical context and are not silently substituted for the current ranking window.
3. Place and venue identity
ZIP and city summaries aggregate published source records. Sports-venue records may use canonical venue identity where the sports backbone provides one. High-value signals are signals for review and should not automatically be described as verified venue categories.
4. Empty or unavailable layers
A configured database with no publishable relation produces an empty JSON array and a visible status. It does not crash the entire website, and it does not borrow records from another layer to conceal the gap.
5. Core calculations
- Total receipts: sum of mixed-beverage receipts in the selected window.
- Beer, wine and liquor: sums of the corresponding source fields.
- Permits: distinct TABC permit numbers in the selected window.
- Outlets: distinct published venue or location identities.
- Revenue per permit: total receipts divided by distinct reporting permits.
6. Publication workflow
The included PowerShell publisher validates each path, inspects DuckDB relations, selects the governed or best-supported relation, exports JSON and writes a connection manifest. SQL is passed without a UTF-8 byte-order mark to prevent the DuckDB initialization error that affected earlier inspection scripts.