CrossCue

Ask fewer audience questions. Make smarter festival schedules.

Comment

Inspiration

Björk and Moonlight overlap. Is separating them worth moving three sessions? CrossCue uses Qloo cultural evidence to surface that choice, previews both valid schedules, and lets the organizer decide. Nothing moves without approval.

Try the public app · Explore the public source

The example is Fieldnotes Festival, a fictional event with eight sessions, four music showcases, four film blocks and two rooms. Its bookings, timetable and operational constraints are invented for the demonstration. The artists, films and Qloo API evidence are real. These are hypothetical bookings, not an announcement of performances or screenings.

An organizer already has to satisfy room, timing and availability constraints. A cultural connection raises a different question: is protecting this pair worth the disruption? CrossCue puts that decision and its cost in front of the person running the programme.

What it does

In the recorded demo, Björk runs from 17:00–18:00 while Moonlight runs from 16:30–18:30. Qloo ranks Moonlight 1st among the four films for Björk, and Björk 2nd among the four artists for Moonlight. These are directional ranks within those shortlists, not audience-overlap probabilities.

Follow the decision in the app:

  1. Choose Analyze cultural conflicts, then inspect Why this question? and the Qloo query evidence.
  2. Compare Protect with Allow. Protect separates this pair by moving Björk to 18:30, Kendrick Lamar to 21:00 and Daft Punk to 23:30: three 90-minute shifts, 270 minutes in total. Allow permits overlap and keeps this baseline unchanged; it does not force an overlap.
  3. Preview a choice and inspect Before and After. The saved timetable stays unchanged during preview.
  4. Explicitly confirm the preview to approve the decision. The server recomputes and independently validates the result before saving it.
  5. Inspect what moved and why, then export the validated programme, decisions, changes and evidence.

The organizer can also Defer, leaving placements unchanged while consuming one question. CrossCue asks at most two questions per run. It skips pairs whose protection is infeasible or whose two best valid schedules are identical. After the main Protect repair, no useful further question remains. The Fully locked example demonstrates a valid zero-question outcome.

How I built it

Qloo supplies the cultural relationships that the timetable cannot: it resolves the artists and films and returns contextual artist-to-film and film-to-artist rankings. Those directional ranks select and order candidate pairs. Consequence testing then decides whether a pair is worth asking about.

The deterministic solver owns placement; a separate validator checks the proposed schedule. The organizer owns approval. The live workflow uses deterministic tool orchestration and has no internal LLM. An external agent can inspect the programme, test a pair and explain approved changes through three typed, read-only tools; applying changes is not an agent tool.

The React and TypeScript interface presents the timetable, evidence, side-by-side choices and preview. A Cloudflare Worker keeps Qloo requests and credentials on the server. D1 stores each visitor's programme separately.

Challenges I ran into

The hardest design problem was turning a Qloo-supported relationship into a useful organizer decision. A highly ranked pair can still lead to the same schedule under both choices. Testing both schedules before asking became the central mechanism.

A small change can also cause a cascade. Moving Björk forces later showcases to move to preserve room-turnover rules. The preview needed to expose that whole cost before the organizer committed to it.

Accomplishments I'm proud of

The public demo connects cultural evidence to an inspectable choice, an approved repair and a downloadable result. It also knows when to stop: a locked timetable produces no feasible question, and the main repair leaves no useful further question.

The controlled comparison below measures question effort and schedule disruption in one fictional programme. It does not establish better cultural recommendations or attendee outcomes.

What I learned

Qloo gave the workflow its cultural starting point: a relationship across music and film that the timetable alone cannot supply. Showing the cost of acting on that evidence made the organizer's question concrete.

What's next for CrossCue

The next step is a real organizer evaluation: which relationships matter to them, and which repairs are worth the disruption? That feedback should guide larger scheduling domains and programme imports. Attendance, revenue and satisfaction benefits have not been measured.

Technical evidence and limits

Scheduling guarantee. The solver enumerates all 256 assignments in this demo's declared finite domain. It satisfies room eligibility, finite start options, durations, 15-minute same-room turnover, locks and accepted protections, then minimizes moved sessions, total absolute start-time displacement and a stable canonical tie-break. Its minimum is exact within that domain, not over arbitrary times or rooms. The independent validator does not reuse solver feasibility code.

Controlled comparison. The frozen protocol and recorded results use the same synthetic festival, constraints, solver, two-question cap and simulated always-Protect policy:

Selector Questions Valid repairs Distinct sessions moved Final displacement
Qloo-assisted 1 1 3 270 min
Metadata-only 2 2 3 270 min
Blind LLM-only 2 2 2 180 min

Qloo asks fewer questions in this case; the LLM arm moves fewer sessions and leaves one actionable pair after its question budget. The metadata baseline is sparse: 15 of 16 pairs tie at zero token similarity, so canonical tie-breaking substantially affects its result. There are no ground-truth audience labels and no measured attendance, revenue or satisfaction benefit. Residual actionable pairs are an operational diagnostic across all 16 pairs, not evidence that an organizer should protect them.

LLM input was isolated from Qloo and timetable data. One actual generated ordering is replayed; the exact provider model ID and inference latency were not exposed. Metadata tags were authored in that blind context; its selector is deterministic token similarity, not an LLM call. Replay time excludes provider acquisition, so it supports no provider speed claim. All three arms share consequence filtering and the same optimizer; valid schedules do not establish cultural accuracy.

A separate consequence-filter ablation keeps the Qloo ordering fixed: asking its top two pairs directly produces two inconsequential questions; testing consequences first produces one actionable question. This tests the workflow mechanism in this programme, not cultural prediction accuracy or universal Qloo superiority.

Recorded release evidence. Existing October 30 records for tested and deployed application revision aca964bf85ee718c9b5676a209e8cda99389c660 include 42 passing unit tests, a production build, 250 independent solver-oracle cases, 54 public-browser assertions and 11 axe states, actual exports and an external read-only tool-client trace. The release manifest, hosting check, submission receipt and 60-check ledger retain their actual dates and revision boundaries. The skeptical review preserves the original findings and scope. These are historical release checks, not tests newly rerun for this presentation edit.

Demo and evidence limits. Eight fixed sessions and two placement options each make this a deliberate demonstrator, not a general festival planning suite. No screening licensing, actual booking, capacity modeling, ticketing or attendee survey exists. No organizer study establishes demand, cultural relevance or first-use usability. Qloo-supported relationships are useful to investigate, not authority to infer an individual's taste. Preference-aware scheduling has prior art; originality is claimed for this integrated workflow.

Qloo evidence retains query context and original retrieval times, including on cache hits. Missing results remain missing, provider failures never silently become fixtures, and response hashes are reproducibility references, not provider signatures. Event quotas were not documented in the access email; the app enforces its own conservative ceiling. The application source is MIT-licensed; Qloo provider data retains its applicable terms.

Built With

Share this project:

Updates

Submission history