If you understand nothing else on this board, understand this diagram. Everything else is detail underneath it.
Reasonably understood as being in Colchester
Own identity, naturally relevant to a Colchester day out
Belongs to another future town
Flagged here first so Liam doesn't have to go looking. Still proposal-stage examples, not yet approved, full rules and the rest of the product definition on Foundation →
A shopping-centre kiosk, but for an entire town, on your own phone.
The original IndoorMaps thinking always had a fourth layer beyond the three surfaces: the data itself becoming valuable, real movement and demand intelligence a council or a licensing partner would pay for on top of the map/website/kiosk product. That layer needs real footfall, did someone actually walk somewhere, how long did they stay, not just what they searched or clicked.
Getting real footfall needs one deliberate decision, not yet made: consent-gated browser geolocation, QR re-scan inference across multiple physical points (scan at the station, scan again at the attraction), or a different vendor/approach entirely. Each has real cost and privacy tradeoffs worth a dedicated pass when it's actually needed, not before. Named on Bank so it doesn't get assumed as already solved.
The rules that decide what belongs in WhatToSee, the geography, the entity model, and the data schema the Colchester dataset gets built on. Proposal stage, not yet approved, see the end of this tab for what still needs sign-off. The map is completed Phase 1 infrastructure, not the focus here, see Map System.
Every level above is a real field in the schema from day one.
Essex/England never need a consumer page just because the data supports it. Colchester and Area are the only levels live today.
Reasonably understood as being in Colchester
Own identity, naturally relevant to a Colchester day out
Belongs to another future town/area
Four real statuses on every record: Include Include as nearby Review Exclude
An important part of the product, and deliberately an attribute, not a top-level category.
| Independent café, example | |
|---|---|
| Category | Eat & Drink |
| Type | Café |
| Independent | Yes |
| Local | Yes |
| Area | Town centre |
| Good for | Coffee, lunch, quick stop |
| Situations | Visitors, rainy day, local favourite |
Plus a separate local: yes/no field. A small Essex chain can be local without being independent, the two are different axes, not one.
A physical location someone may visit
The operator, may run several Places
Something happening at a date/time
A walk, trail or itinerary
Neighbourhood or district grouping
An editorial grouping, a Guide
Activity / Experience is treated as an attribute or type, not a seventh core entity Reconsider if the real dataset proves otherwise. Don't over-engineer this ahead of evidence.
Navigation ≠ Category ≠ Entity type ≠ Attribute ≠ Situation ≠ Filter ≠ Collection
| Colchester Castle | |
|---|---|
| Entity | Place |
| Category | See & Visit |
| Type | Museum / historic attraction |
| Attributes | Indoor, paid, historic |
| Situations | With kids, rainy day, visitors |
| Collections | Historic Colchester, Things to do with visitors |
Full breakdown of the seven layers, with the navigation/taxonomy items themselves, on Website Architecture. This matters because we do not want hundreds of unnecessary categories or URLs.
Fifteen field groups on the Place record, expand any card for the actual proposed columns.
Linked tables, not columns on Place, because a single column can't hold them cleanly:
Full column list, plus the Event and Route tables: PRODUCT-DEFINITION-AND-DATA-SCHEMA-PROPOSAL-11sep2026.md.
| Fact | Typical source |
|---|---|
| Opening hours | Official venue |
| Coordinates | Geographic source |
| Accessibility | Venue / accessibility source |
| Editorial recommendation | WhatToSee |
| Event date | Event organiser |
Different facts about the same Place can, and usually do, have different sources. One place_field_sources table, not source columns bolted onto every field.
Local Gems is its own dedicated research pass, not folded into the category sweeps, it needs the community-source method in section 15, not ordinary search.
Pass 1's objective is coverage. Pass 2's objective is quality. Don't let perfecting one record slow down finding the next.
| Field | Colchester Castle | Indep. café * | Castle Park playground | Riverside walk * | Highwoods Country Park | Local pub * | Hidden gem * | Colchester Arts Centre |
|---|---|---|---|---|---|---|---|---|
| Type | Museum | Café | Playground | Route | Open space | Pub | Mural / landmark | Arts centre |
| Category | See & Visit | Eat & Drink | Do & Explore | Do & Explore | Do & Explore | Eat & Drink | See & Visit | See & Visit |
| Ownership | Public | Independent | Public | n/a, route | Public | Independent | Informal | Charity |
| Why included | Major heritage | Independent, local | Free family activity | Free outdoor | Large free green space | Local character | Local knowledge | Genuine cultural venue |
| Duration | 1-2 hours | Quick stop | Quick stop | 1 hour | Half day | Quick stop / evening | Quick stop | Evening |
* Illustrative example, not asserted as a verified real business, the sweep finds the actual ones.
The map is a branch off this trunk, consuming the data, not the trunk itself. See Map System for the Phase 1 / Phase 2 detail.
WhatToSee isn't a database built once and left alone. The structured data is the foundation, running it needs a real weekly local editorial operation on top.
Dog walks, independent cafés, beer gardens
This weekend, Bank Holiday, half term
Two hours in Colchester, rainy afternoon
New openings, coming soon, recently opened
A walk and lunch, half-day itinerary
Dutch Quarter, Castle Park, Independent Colchester
/blog/. Someone browses WhatToSee by what they want to discover, not by whether something happened to be written as an article. Everything lives in one of the six formats above.One permanent evergreen hub shows the current live list. Recurring dated moments (Bank Holiday, Christmas) get one evergreen slug refreshed every year, not a brand-new URL each occurrence, so the site never accumulates hundreds of dead weekly pages.
Indoor, cheap, winter walks
Half term, Valentine's
Spring walks
Easter, family activities
Bank holidays, beer gardens
Outdoor events, parks
Summer holidays, festivals
Picnics, festivals
What's new, autumn
Half term, Halloween
Christmas markets, lights
Festive food, pantomimes
Plus Bank Holidays, school holidays, Mother's/Father's Day and major local festivals layered on top.
What's happening. Review next 2-4 weeks, add/update events.
Local data. New places, closures, changes, records due for verification.
Best / guide. One strong evergreen discovery piece, created or updated.
Weekend. What's on this weekend, family ideas, live music.
Discovery / new. Something new, overlooked, independent or interesting.
"Best dog walks in Colchester" references real Place/Route entities (Highwoods, specific routes, specific parks), each keeping its own location, facilities and dog-suitability data. The Guide supplies the narrative and judgement, the database supplies the facts.
Idea Seasonal Researching Ready Live Update due Retired
An idea does not need a full brief to enter the bank, minimum viable capture is the title, why it's interesting, and what data it connects to.
What would somebody actually want to click, save, send to somebody, search for, or suddenly decide to go and do? Part strong local guide, part the better end of BuzzFeed-style publishing.
What exists?
Why might somebody care right now?
A pub's own data (live music, beer garden, Sunday lunch, dog friendly, independent, outdoor seating) can each seed a different piece:
First warm weekend, heavy rain, heatwave, snow
Bank Holiday, half term, Valentine's, Christmas
New opening, closure, festival announced
Everyone wants beer gardens, parents need half-term ideas
Adam or Liam notices somewhere interesting
"Colchester has 17 independent bakeries" is itself editorial
Capture first, decide later. Nobody needs to decide immediately whether something deserves a full piece.
"That's interesting, let's do something on that." "People are going to want to know about this next weekend." "I didn't know Colchester had that, other people probably don't either." That instinct is part of the product, not a distraction from the database.
Confirmed no problem, proceeding as WhatToSee, one-sentence definition above.
The specific place names in section 2 are examples, need explicit approval before the sweep uses them as the real boundary.
Recommended dropping "Local Gems" as a category, made it an attribute + filter + Guide instead. Needs a yes.
Recommended no separate Experience/Activity entity. Needs a yes, or evidence to revisit.
Which get URLs vs Guides vs filter-only in section 7, proposed not locked.
The 15 field groups and 5 linked tables in section 9, ready to become the actual spreadsheet/database structure once approved.
The Monday-Friday example is illustrative, needs a real decision on cadence once collection starts.
The same three-column split as Big Picture, expanded into what each surface actually delivers to its own audience.
| Who | What they get |
|---|---|
| Planning at home | Search, editorial, What's On, New, directory, before they've left the house |
| Standing in town | Scan, search, map, directions, in seconds, no install |
| Family | Audience and weather-aware filtering (rainy day, toddlers, free) |
| Shopper | Exact-entity search ("M&S") treated differently from inspiration search |
| Resident | What's New as a genuine repeat-visit reason, not a tourist-only site |
Not "advertise your business here." A town-wide digital map, search, directory and wayfinding layer, deployed via QR at car parks, stations, the high street and information boards, with honestly-labelled aggregate demand data as a byproduct, not the pitch itself.
Every business gets an unclaimed profile by default, findable whether or not they've ever heard of WhatToSee. Claiming and verifying is free. Paid tiers (later) enhance visibility, they never buy inclusion. See Data Model and Bank for the claim/verify/enhance ladder.
What gets more valuable as more towns are added: the structured place/event schema itself (reusable everywhere), the map style system (reusable everywhere), the pattern of what data sources work per town (learned once, applied faster each time), and eventually, if it ever gets there, a real cross-town local-intent dataset no single competitor currently assembles. That last piece needs real footfall, not just search/click intent, which isn't built yet, see the end-game section on Big Picture.
Information architecture, page types, categories, situations, guides, navigation, and how it all expands to a second town. The map appears where it needs to, at launch-minimum scope, detailed separately on the Map tab.
| Level | Needed? |
|---|---|
| England / country | No. Nothing to say at that level that isn't said better per-town. |
| Region / county | Not manufactured as a page. Only if real cross-town editorial demand shows up, and even then it's a guide, not a navigation tier. |
| Town | Yes. This is the real unit. Colchester, then each new town. |
| Neighbourhood / area | Not yet, see Areas below. Revisit only once a town is large enough that its name alone is too broad. |
The actual pattern, not just the page-type list below. This is what Liam should build against directly.
Bank, not built: /colchester/areas/{area-slug}/, /colchester/routes/{route-slug}/, /colchester/claim/.
Three different systems, easy to conflate, each answering a different question. Getting this confused is how "Explore" ends up built twice, once as a nav label and once as an accidental page nobody meant to create.
What's in the header/footer, a handful of items
What defines the URL structure
The mental model for the UI, not a page count
"Explore" is a nav label and a behaviour, it is not its own page, it points at the category hubs. "Find" is a behaviour (search), not a category. Liam should not build a literal /explore/ or /find/ page expecting them to be distinct architecture, they're framing layered on top of the category/situation hubs and site search.
The rule that stops this becoming 100 thin pages. Apply it per situation tag before it gets a URL.
| Treatment | Rule | Example |
|---|---|---|
| URL | Evergreen, real standalone search demand, own indexable hub | Rainy day, Free, Family friendly, Dog friendly |
| Guide | Editorial, a written case for a specific list, not just a filtered query | Colchester after dark, Best of Castle Park |
| Filter only | Long-tail combination, would be thin if indexed on its own | Free AND family AND rainy day, any two-situation intersection |
Nearly every URL on the site is one of these. Categories and situations produce hub pages by filtering the same place data differently, they are not separate content. Utility pages (About, Accessibility, Contact, legal) sit outside this model on purpose, not classified as taxonomy.
Town picker, how it works
/colchester/, the flywheel in one page
See, Do, Eat & Drink, Shop, Find
URL-tier only: rainy day, free, family friendly, dog friendly
Standalone URL per place, currently sheet-only
Single event, links to its venue place
Editorial, curated place lists
Today, tonight, this weekend
Just opened, opening soon
/colchester/map/, Phase 1 scope, see Map tab
/for-towns/, the B2B pitch
Only if a town outgrows one hub
Phase 2 map product, not this pass
Free claim/verify flow
The distinction that keeps the taxonomy honest. Get this confused and every new "collection" becomes an ad-hoc category, and the URL structure rots.
One place carries one primary category, which drives its canonical URL, and can carry secondary categories too (Castle Park is primarily See but legitimately also Do). Secondary categories add a place to more than one category hub without changing its address. Situations are separate again, many per place, driving filters, guides, and map pre-filtering.
The editorial layer, human-curated, distinct from algorithmic situation filtering. A guide is a written case for a specific list of places, situations produce that list automatically.
Map is a persistent header item on every page, not a feature buried in a menu, this is already fixed site-wide. It does not get a second, bigger visual treatment beyond that, per the "don't let the map dominate" principle.
The core Find / Explore / Inspire / What's Happening / What's New journeys, plus the menswear and QR examples, are detailed on the User Flows tab, not repeated here.
On-site search already treats exact-entity queries ("M&S") differently from inspiration queries ("rainy day ideas"). For external AI-search retrieval, every Place, Event, and Guide carries structured data (see Data Model), so category hubs, situation hubs and guides are independently citable, not just the map.
Full ladder and the "never buy existence" rule are on Product Model and Bank, this is just the page-type consequence: a claim flow exists as a page type, banked for now.
The same reused-vs-new split as the Map System tab, applied to the whole site, not just the map layer.
The day-to-day working view. Completed foundation first (click through, these are real and live), then the actual proposed pages underneath Build Now / Next / Bank, matching Build Plan.
/colchester/places/{slug}//colchester/explore/see|do|eat-drink|shop|find/53 seeded places across See/Do/Eat/Shop/Find/Event/New: real landmarks (Colchester Castle, Castle Park, Mercury Theatre, Arts Centre, firstsite, both stations) at real coordinates, plausible independents for the rest, nothing presented as confirmed fact that isn't. That's enough to prove the model, not a verified Colchester business directory, don't treat it as one when sharing this externally.
The map matters, but it is one part of the site, not the whole product. Phase 1 below is what's needed to launch. Phase 2 is named and parked, not detailed, on purpose, see Website Architecture for where it sits in the IA.
The one separation worth holding precisely: get it wrong and every new town is a rebuild, not a data add.
Technology: Mapbox GL JS today. MapLibre is a live open-source alternative on the same style spec, so nothing built is wasted either way, but it's a P2 cost/lock-in decision, not a launch blocker.
Named so it doesn't get quietly re-proposed as if new later, not scoped or estimated here.
Reviewed and confirmed: these are the right five. Shown below with where each one actually lives today.
| Behaviour | Example | Lives where |
|---|---|---|
| Find | "M&S", "menswear", "toilets" | Map search, exact-entity and category matching already built |
| Explore | Map-led browsing | The flagship map, "Everything" filter |
| Inspire me | Best things to do, rainy-day ideas | Best of Colchester on the hub, needs the standalone template |
| What's happening | Today, tonight, this weekend | What's On section on the hub, links to map filter, needs its own page |
| What's new | Just opened, opening soon | New section on the hub, links to map filter, needs its own page |
Built and working end to end. Not yet built: mode choice (walk is the only option today, drive/public transport are real Directions-API parameters, straightforward to add), multi-stop itineraries, "next stop" continuation.
Built: the map already accepts ?entry= for QR-source context and ?q=/?cat=/?tag= for pre-filtered arrival. Live demo: /colchester/map?q=menswear&entry=high-street →
The full canonical Place schema, the 15 field groups and the linked tables including field-level provenance, now lives on Foundation, so it sits next to the geography and inclusion rules it depends on rather than duplicated here. This tab covers what's specific to Event and to the New/Opening freshness gap.
Fields: start/end time, date, recurring, category, audience, price, booking, location, town, status, source, last checked.
The full page is live at /for-towns/ →, this is the architecture behind it.
Town-centre information is fragmented across paper maps, tourist boards and inconsistent signage. The product: a digital town map, search, directory and wayfinding layer, one QR network covering the whole town.
Visitor and resident utility, local business discovery, modern wayfinding, current data (not a static PDF map), aggregate demand signals, honestly labelled.
Search-led intent and discovery/editorial engagement are genuinely different signals. Don't force discovery browsing through a fake search funnel just to make one clean chart.
wtsTrack() wired at every real interaction point (search_submitted, results_shown, filter_selected, place_viewed, direction_request, while_you_are_here_click, page_view with entry-source). Lands in window.WTS_EVENTS and the console today, shaped correctly for a real analytics wire-up, no dashboard built, wasn't asked for yet.The honest risk, stated plainly, then what changes to avoid it.
The map moved from a placeholder canvas to real styled Mapbox with a drawn route, and is now treated as completed Phase 1 infrastructure, not ongoing work. The map preview moved up on the hub, "Map" can no longer disappear from mobile navigation, content links into map filters instead of sitting isolated, and a dedicated council page exists. That's real movement, the open gap now is the website's own architecture, not the map.
The town hub is still built as homepage sections (Best of, What's On, New) rather than as gateways into real pages with their own URLs and depth. Category hubs, situation hubs, standalone place pages and guides exist as a data model and a plan, not yet as built pages. That's the honest gap, and it's exactly what Build Plan's P0 now targets directly, not the map.
This changed from an earlier draft where map items filled P0 positions 1-8, which accidentally told Liam to keep prioritising work that's already done. Corrected below.
Attractive, not required for V1. Keeping them visible here so they don't get quietly re-proposed as if new.
Scan-and-go stays the model unless a real reason to install ever appears. Not decided by technology enthusiasm.
Not manufactured to fit a hierarchy. Only if real editorial demand appears.
Real P2 decision once cost or lock-in actually bites, style JSON transfers directly, no wasted work either way.
Current system works, hasn't been comparison-tested the way the fleet's mature B2B sites have.
Enhanced profile, promoted event, featured position, sponsored editorial, ticket affiliate. Needs the "never buy existence" line kept explicit whenever built.
Near me, walking times, open-now intelligence, dynamic routes, multi-stop journeys, time/weather filtering, personalised discovery, itineraries, clustering, richer visual design, event overlays, "make me a day". Full list on Map System, deliberately not designed in detail yet.
A place shouldn't stay "New" forever. Rule not yet defined.
Event scaffold exists (wtsTrack), no visualisation layer, wasn't asked for.
The actual data-product end-game, consent-gated geolocation or QR re-scan inference across multiple points. Deliberately not started, see Big Picture.