Seminole Hard Rock Watch
Watches the secondary ticket market for upcoming Hard Rock Live shows at a
configured Seminole Hard Rock property. Uses an ai: arm to judge value
against typical pricing for that venue rather than a flat threshold —
because Hard Rock Live pricing varies wildly by act, but the venue's typical
floor / mezz / balcony ratios are fairly stable.
What it does
On each fire:
- The check calls a ticket-pricing endpoint for upcoming shows at the
configured Seminole Hard Rock property (default
hollywood-fl). - The
ai:arm receives the listings JSON and a prompt that bakes in: - The venue identity ("Seminole Hard Rock Hollywood FL"). - That venue's typical price floors per section. - Concert-specific "good deal" criteria (buyer-regret drops, off-section listings, late-window supply-vs-demand). - If the AI flags one, notify with reasoning + full listings. Else stay quiet.
Why no season-ticket-holder dumping
Hard Rock Live is a concert/event venue, not a sports team. The "season-ticket holder selling individual games" pattern doesn't apply here — each show is a one-off. Late drops still happen, but for different reasons: - Initial buyers overpaying at on-sale, then trying to recoup. - Shows that didn't sell out the room having day-of marketplace supply. - Act-quality mismatches with venue size (smaller draw than expected).
This monitor is calibrated for those patterns rather than the
sports-season-holder pattern in event-price-watch.
Which property are you watching?
Hard Rock Live operates at multiple Seminole Hard Rock properties. The
venue= URL parameter in monitor.yaml's check.args.url selects which:
venue= value |
Property |
|---|---|
hollywood-fl |
Seminole Hard Rock Hotel & Casino Hollywood, FL |
tampa |
Seminole Hard Rock Hotel & Casino Tampa, FL |
tulsa |
Hard Rock Hotel & Casino Tulsa, OK (Seminole-owned) |
sacramento |
Hard Rock Hotel & Casino Sacramento at Fire Mountain |
cincinnati |
Hard Rock Casino Cincinnati |
The AI prompt currently bakes in Hollywood FL specifics (capacity, typical price floors, "rock/country/comedy/Latin/R&B" act mix). For a different property, edit the prompt to match that property's:
- Venue capacity (changes "obscure act = upper balcony cheap" baseline).
- Typical act genres booked there.
- Per-section price floors — these vary by market. Tampa runs ~10-20% cheaper than Hollywood for comparable acts; Tulsa cheaper still.
Data-source setup
Same scraper / API endpoint pattern as event-price-watch.
Your endpoint needs to accept a venue filter and return upcoming-show
listings within a windowDays range.
Expected published bindings from the scraper:
| Binding | Expected value |
|---|---|
{{check.listingsJson}} |
JSON array of listings: [{ showName, showDate, section, row, price, listingUrl, note }, ...] |
{{ai_reasoning}} |
Set by the AI-arm; explains the flagged listing(s). |
A minimal listing record:
{
"showName": "<artist>",
"showDate": "2026-06-15",
"section": "Floor B",
"row": "12",
"price": 85,
"note": "",
"listingUrl": "https://marketplace.example.com/listing/abc123"
}
The note field is where obstruction tags, alcohol-included, or
"VIP package" extras go — surface those to the AI so it can disqualify or
correctly value them.
Edit before installing
In monitor.yaml:
check.args.url— setvenue=to your property and point at your scraper.- The
ai:prompt — adjust the venue name, capacity context, and typical price floors to match the property you picked (see table above for which Seminole properties have Hard Rock Live). when[0].do[0].subject/body— adjust copy.- Schedule: daily is plenty. Concert listings move slowly until the final 72 hours; once a day catches the long-tail drops without burning LLM budget.
Bindings used
{{check.listingsJson}}— JSON array of upcoming-show listings.{{ai_reasoning}}— AI's explanation when it flags a listing.{{monitor.firedAt}}— fire timestamp.
Tools used
http— core InTouch HTTP task type.- AI assistant (Anthropic / OpenAI / Gemini / Ollama).
Pattern showcase
Venue-aware AI valuation — the AI prompt encodes the specific venue's pricing model, not a generic one. This is the right shape any time the "good deal" definition depends on knowledge that's static per-installation but varies across users (different venue, different stock portfolio, different industry). Bake the per-venue knowledge into the prompt at install time; the data source stays generic.
Related monitors
good-seat-ai-watch— sports-event variant (lower bowl / mezz / upper bowl floors instead of Hard Rock Live's floor / loge / balcony).event-price-watch— single-event raw threshold, no AI.gameday-firesale-watch— last-hours panic-drop detection.