Local Edition

Every store in a chain gets its own weekly special, sound brief, local partner and event night, chosen from what its block over-indexes on in Qloo's taste data, with the evidence on every item.

Comment

Inspiration

Chains win on consistency and lose on feeling local. Head office cannot know 200 neighbourhoods, so every store gets the same specials, the same playlist and the same event calendar, while the independent café next door knows its block. The knowledge a store manager has about their corner, what the people around it lean toward, is exactly what Qloo measures. Local Edition turns it into a weekly routine for head office: one meeting, every store, each with its own week and the reason for every choice.

What it does

Every week, Local Edition gives each store in a chain its own edition, built from what its block over-indexes on compared with the rest of the city:

  • Special: one drink or bite, always a variation of an item the chain already sells, so the store can run it that week.
  • Sound brief: what to play in the room, with artists this block leans toward, kept inside a popularity band so the room sounds local, not top-40.
  • Local partner: a nearby place worth a tie-in, chosen from the places Qloo returns near the store and ranked by fit to the chain's own taste, with an offer idea.
  • Event night: something to host, tied to a real event near the store that week when one is found.

Every item carries its evidence: the Qloo call, the tag or entity, and the score. Head office sees every store on one map, compares any two stores side by side ("why does Williamsburg get a different week from the Upper East Side?"), and approves, edits or regenerates per store. Each approved store gets a one-page staff card in plain words, and each store's event nights reach its team through a private calendar feed.

The user is the operations or brand team at a multi-store chain. They sign off every store on one screen, and every choice comes with its reason.

How Qloo is used

Qloo decides what is true about each block; the model plans and writes from what Qloo returned. Every call goes through one server-side client on hackathon.api.qloo.com. These are the calls the live app makes:

Qloo call Signals and parameters What it decides in the product
GET /v2/insights, filter.type=urn:tag, per store signal.location = the store's point (WKT POINT), filter.tag.types = one of seven tag families (ambience, neighbourhood character, good-for occasions, cuisine, specialty dishes, menu highlights, music genres), take=20 The block's character. What the people around this exact corner lean toward.
GET /v2/insights, filter.type=urn:tag, city baseline signal.location.query = the city, the same filter.tag.types, take=50 The baseline. Each tag's lift is the store's affinity minus the city's, so a store is described by what it leans toward more than New York, not by what everyone likes. The top tags per kind become the chips on the map and the input to every item.
GET /v2/insights, filter.type=urn:entity:place filter.location = the store's point, filter.location.radius in metres (default 1,200), signal.interests.entities = the chain's taste anchors, optional filter.tags from the block profile, filter.exclude.entities The local partner. Candidates are only places Qloo returns near the store, ranked by affinity to the chain's taste; a partner is never invented.
GET /v2/insights, filter.type=urn:entity:artist signal.location, signal.interests.entities = the chain's anchors, filter.popularity.min 0.2 and filter.popularity.max 0.7, bias.trends=low, optional genre filter.tags The sound brief. Artists this block leans toward, inside a popularity band, so the room feels local rather than top-40.
GET /v2/insights, filter.type=urn:entity:brand signal.location, filter.tags=urn:tag:genre:brand:food_and_beverage, filter.popularity.max 0.8 Pairing context. Food and drink brands that over-index around the block, which the agent can use when it shapes a partner offer.
GET /v2/insights twice, bias.trends=off and bias.trends=high the same place or artist query near the store What is rising. An entity that climbs when trends are weighted. The agent may say it is "rising in Qloo's data", never "rising on this street".
GET /v2/trending signal.interests.entities = the rising artists, filter.start_date/filter.end_date = the last 12 weeks Momentum behind a rising artist (velocity and population percentile), shown as evidence. Not asked for places.
GET /v2/analysis/compare a.signal.interests.entities and b.signal.interests.entities = each store's top local places, filter.location.query = the city, model=descriptive Store against store on the Compare screen: the taste two stores share, next to our own tag-lift diff showing what only one block has.
GET /search brand names the chain types at setup The chain's taste anchors: real brands it resembles. Their Qloo IDs become signal.interests.entities in the place, artist and rising calls above.

How the pieces join: the agent (NVIDIA Nemotron on Nebius) calls these as tools one store at a time. The special is the chain's menu item whose embedding sits closest to the block's over-indexing cuisine and flavour tags, so the Qloo tag is the reason for the special. The partner comes from the Qloo place list. The sound brief comes from the Qloo artist list. A reviewer model reads all stores together and sends back any store whose edition repeats another's, so stores stay as different as their blocks.

The evidence model. Every Qloo answer is stored as an evidence row: the endpoint, the exact parameters, the score (affinity, lift or popularity), a one-line summary and the time Qloo answered, labelled "Live call" or "Cached live Qloo answer". Every edition item carries the IDs of the rows behind it, and Why this? opens them in the evidence drawer. An item without Qloo evidence is not shown.

Every Qloo call runs live against the hackathon API, and answers are cached for 14 days. Only store coordinates, entity IDs and tag URNs are sent to Qloo, never customer data.

What makes it Qloo-powered

Local Edition runs on the taste of the block, not on demographics. Demographics say who lives near a store; they do not say which drink to put on the board, which artists to play or which neighbour to partner with. Qloo's location-signalled insights do: what the people around one corner lean toward in food, ambience, music and places, measured against the whole city. Each of those tags and entities turns straight into this week's special, sound brief and partner. And because it is taste, not identity, nothing about any customer is sent or inferred.

The product cannot exist without Qloo. Ask a plain language model for a local week and you get "Williamsburg is hip", the same seasonal latte for every store, famous artists from its training data and partner names that may not exist; ask it why two stores of one chain should differ and it can only guess. Take Qloo out of Local Edition and every item loses its evidence, so every item is dropped: there is no special, no sound brief, no partner and no comparison left to approve.

How we built it

  • Qloo layer: a typed client with zod-validated responses, one parser per endpoint, the lift computation against the city baseline, and a 14-day response cache in KV.
  • Agent: NVIDIA Nemotron 3.5 Super VL on Nebius Token Factory runs the tool loop and reads menu-board photos; Nemotron 3 Ultra reviews the whole chain; Nemotron 3.5 Lightning writes the copy and staff cards; Qwen3 Embedding 8B joins menu items to Qloo tags and ranks partners. Average model spend this week: $0.0064 per store edition.
  • Guardrails: a live check on every line in the app, and NVIDIA NeMo Guardrails in a Nebius Serverless Job (its recorded eval caught 40 of 40 red-team phrases and wrongly blocked 0 of 10 ordinary ones). No health, diet, allergen or identity claims get through.
  • Events: Tavily finds this week's events near each store, cached for 7 days.
  • Platform: Next.js on Cloudflare Workers and Pages with D1, KV, R2, Durable Objects and Workflows, a weekly cron that rebuilds every store, and a private .ics calendar feed per store. Vitest and Playwright test suites (142 test files). MIT licence.

All code was written during the hackathon; the first commit is 29 Oct 2026.

Challenges we ran into

  • Making "local" a number. Raw affinity near a store mostly repeats what the whole city likes. Subtracting a city baseline from the same urn:tag query is what made Williamsburg and the Upper East Side come out different.
  • Rising has no location in /v2/trending. So "rising near this store" is the same location query run with bias.trends off and high, and /v2/trending adds momentum for artists only, because it answers 400 for places.
  • Compare has no per-side location. Each side of /v2/analysis/compare is that store's own top local places from a location query.
  • Narrow filters. A tag or genre filter can return only a handful of places or artists near one corner, so the tools widen to the unfiltered Qloo answer, filter matches first, and record that in the evidence.

Accomplishments that we're proud of

  • Every item on screen traces to a Qloo call a judge can open.
  • Two stores of one chain get two different weeks from their own Qloo answers, and Compare puts the two blocks' taste side by side.
  • Every special starts from the chain's own menu, so an edition can run the week it is approved.
  • A reviewer model reads the whole chain at once and sends back any store whose week repeats another's.

What we learned

  • The most useful Qloo output for an operator is the difference: not "what does this block like" but "what does it like more than the city, and more than our other store".
  • A popularity band on artists is what separates a local-feeling room from a top-40 one.
  • Rules that never bend (no item without evidence, no health claims, no identity) make the output faster to trust and approve.

What's next

  • Each special's sales feeding the next week's edition, so the chain learns which block signals sell.
  • More cities, each chain's own rebuild day, and templates for gyms and hotels.

Try it: testing instructions for judges

No account is needed. Open https://localedition.pages.dev and press Try the sample chain. Each visitor gets a private copy of Kettle & Kiln, eight coffee stores at real New York corners. Kettle & Kiln is sample business data, labelled Sample in the app; it is not a customer. Signing up (email and password, free) is optional and only needed to keep a chain of your own.

A 2-minute tour:

  1. Portfolio: every store on one map, each with its own edition and its block's top Qloo taste tags.
  2. Open a store (Williamsburg is a good start) and press Why this? on any item to open the evidence drawer: the Qloo endpoint, its parameters, the tag or entity, the affinity and lift, and when Qloo answered.
  3. Compare: pick two stores to see the taste their blocks share and what only one has.
  4. Approve all on a store, then open its Staff card.

Qloo calls are live, and answers are cached for 14 days. Each evidence row is labelled "Live call" or "Cached live Qloo answer" with the time Qloo answered.

Qloo submission requirements

  1. Functional demo application: https://localedition.pages.dev. It is live and works end to end with no account: press Try the sample chain to open the portfolio map, each store's edition with its Qloo evidence, Compare, approvals and the staff card.
  2. Public code repository: https://github.com/JoelOnBeat/local-edition-qloo. It holds all source code and assets, and the README has the run instructions (npm install, then npm run dev with the Qloo, Nebius and Tavily keys in .env.local).
  3. Text description: the story above covers the key features (a weekly special, sound brief, local partner and event night for every store), what the agent does (it calls Qloo as tools store by store, writes each item only from what Qloo returned, and a reviewer checks the whole chain), and what makes it Qloo-powered (see "How Qloo is used" and "What makes it Qloo-powered").
  4. External hosting: hosted on Cloudflare Workers and Pages at https://localedition.pages.dev, publicly reachable, with no private access or local setup needed.
  5. Open-source licence: MIT. The LICENSE file is at the repository root, so GitHub shows "MIT license" in the repository's About section.

Built With

  • cloudflare-d1
  • cloudflare-durable-objects
  • cloudflare-kv
  • cloudflare-pages
  • cloudflare-r2
  • cloudflare-workers
  • cloudflare-workflows
  • maplibre
  • nebius-serverless-jobs
  • nebius-token-factory
  • nemo-guardrails
  • next.js
  • nvidia-nemotron
  • openfreemap
  • playwright
  • qloo
  • qloo-insights-api
  • qwen3-embedding
  • tavily
  • typescript
  • vitest
  • zod
Share this project:

Updates

Submission history