<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>hexagons_world-assertions.txt</title>
  <script>
    (() => {
      let storedTheme = null;
      try {
        storedTheme = localStorage.getItem("theme");
      } catch (error) {}

      if (storedTheme === "dark") {
        document.documentElement.dataset.theme = "dark";
      }
    })();
  </script>
  <link rel="stylesheet" href="/%25latex/styles.css">
</head>
<body class="document-page">
  <button class="theme-toggle" type="button" aria-label="Switch to dark mode" title="Dark mode">
    <svg class="theme-icon theme-icon-moon" viewBox="0 0 24 24" aria-hidden="true">
      <path d="M20.4 14.5A8.2 8.2 0 0 1 9.5 3.6a8.7 8.7 0 1 0 10.9 10.9Z"></path>
    </svg>
    <svg class="theme-icon theme-icon-sun" viewBox="0 0 24 24" aria-hidden="true">
      <circle cx="12" cy="12" r="4"></circle>
      <path d="M12 2v2M12 20v2M4.9 4.9l1.4 1.4M17.7 17.7l1.4 1.4M2 12h2M20 12h2M4.9 19.1l1.4-1.4M17.7 6.3l1.4-1.4"></path>
    </svg>
  </button>
  <script>
    (() => {
      const button = document.querySelector(".theme-toggle");

      const setTheme = (theme) => {
        const isDark = theme === "dark";
        if (isDark) {
          document.documentElement.dataset.theme = "dark";
        } else {
          document.documentElement.removeAttribute("data-theme");
        }

        button.setAttribute("aria-label", isDark ? "Switch to light mode" : "Switch to dark mode");
        button.setAttribute("aria-pressed", String(isDark));
        button.title = isDark ? "Light mode" : "Dark mode";

        try {
          localStorage.setItem("theme", isDark ? "dark" : "light");
        } catch (error) {}
      };

      setTheme(document.documentElement.dataset.theme === "dark" ? "dark" : "light");
      button.addEventListener("click", () => {
        setTheme(document.documentElement.dataset.theme === "dark" ? "light" : "dark");
      });
    })();
  </script>
  <header class="site-header">
    <a class="back-link" href="/outline/hexagons_world/">Back to directory</a>
    <h1>hexagons_world-assertions.txt</h1>
    <p class="path-label">outline/hexagons_world/hexagons_world-assertions.txt</p>
  </header>
  <main class="document-shell">
    <pre class="document-text">## Assertions

	hexagons.world is a global addressing system
		it covers the planet in nested hexagons
		each deeper level adds one more word
		so you can describe both:
			broad landscapes
			and precise points

	example
		banksia-coast-swan-gumnut-leaf-flow
			feels like somewhere on the southwest coast of Australia
			softly local, specific, and human

	the words should feel right for the place
		flora
		fauna
		landforms
		cultural texture
		not random syllables — actual things that live there or feel like there

	a global addressing system is just useful
		people can talk about the same place
		even if they don’t share a language or map platform
		it becomes a common layer that other tools can rest on

		for Peaceful Foundation
			hexagons.world is the shared backdrop
				common local mapping system
				common vocabulary between projects
				way to show progress of campaigns
				neutral reference point for “where”

				integration
					hexagons.world is woven into every Peaceful Foundation project
						as a calm pattern in the background
							showing place
							showing change



	statistics
		hexagons become more than names
			they carry numbers people can rally around
				“how much this hurts here”
				“what’s improving”
		each project can read and write
			quietly, in the background



### Geometry

		the planet is covered in seamless hexagon layers
			each layer subdivides into smaller hexagons within it
		why hexagons?
			they appear in nature (bees, basalt, bubbles)
			they tessellate without gaps
			they minimise distortion better than squares on a sphere
		compared to squares
			hexagons feel less “grid”
			and more “landscape”

		hierarchy
			wide landscapes down to single points:

			level 0 (macro)         → ~1,000 km
			level 1 (landscape)     → ~100 km, 1 word
			level 2 (region)        → ~10 km, 2 words
			level 3 (district)      → ~1 km, 3 words
			level 4 (neighbourhood) → ~100 m, 4 words
			level 5 (spot)          → ~10 m, 5 words
			level 6 (point)         → ~1 m, 6 words

			we call these hex0 to hex6

			shorter sequences
				give a broad sense of place
			longer sequences
				give fine precision

		UX
			level 0 is rarely shown
				it can appear on hover or when zoomed far out
			search and suggestions
				biased to the user’s current map view
				so names feel anchored to where you are, not abstract




### Assigning words

	we want names that feel like the place itself
		not random words that “sound nice”
		but things that match what’s actually there
		so someone reading the sequence feels:
			“yes, that fits here”

	natural-first at broad levels
		at level 0 (~1000 km)
			use large-scale markers:
				flagship animals
				biome-wide plants
				continental landforms
			every region gets an anchor that feels unmistakably local

		at level 1 (~100 km)
			still mostly natural:
				common tree families
				regional animals
				rivers, ranges, coasts
			this is the level where people recognise home terrain:
				coastal vs inland
				forest vs plain
				mountain vs basin

		at levels 2–3 (~10 km, ~1 km)
			begin blending natural + cultural:
				local rivers, parks, ridges
				familiar species
				recognisable land textures
			the vocabulary “zooms in” with the landscape
				feels closer to neighbourhood than continent

	levels 4–6 (~100 m → ~1 m)
		here most places don’t have famous features
			so we use calm, human-scale words:
				brick, shade, frame, bench, dune, basalt, reef, fern
			plus programmatic descriptors for uniform areas:
				forest, road, slab, scrub, dune, harbour-edge
		we still:
			avoid homophones and tongue-twisters
			keep it readable to a 12-year-old
			keep tone neutral and kind


	building the word lists

		we need a global directory of real things that live in each place
			not vibes
			not marketing
			but actual flora, fauna, landforms, textures, and features

		sources
			UNESCO biosphere reserves
			WWF ecoregions + biome classifications
			GBIF species occurrences
			IUCN species ranges
			OpenStreetMap natural + land-use data
			climate + terrain sets (e.g. Copernicus, SRTM, HydroLAKES)
			local open-data where available

		process
			merge all inputs into consistent JSON
				for each hex at each level, list:
					candidate flora
					candidate fauna
					landforms + water features
					environmental textures
			normalise names into short, simple, translatable words
				avoid species names that are:
					overly rare
					overly technical
				stay with recognisable, stable items where possible

		deriving local dictionaries
			for each continent
				build a broad dictionary
			for each region
				narrow to biome-specific subsets
			for each hex
				keep a small place-specific list

			the result is a “key” per hex:
				flora:     3–12 items
				fauna:     3–10 items
				landforms: 2–8 items
				textures:  2–6 items

		entropy + uniqueness
			combined lists provide millions of possible unique words
				more than enough for Earth at all scales
			most hexes need only a single word per level
			the system has comfortable headroom
				for uniqueness
				for localisation
				for future refinement
			and it leaves room for community renaming later


	filtering across levels

		level 0 (1000 km)
			use strongest biome-wide signals:
				flagship species
				iconic landforms
				climate-wide textures (arid, boreal, monsoon)
			words should be obvious to anyone familiar with the region:
				“yes, that’s our coast / desert / range”

		level 1 (100 km)
			filter down to regional markers:
				river systems, ranges, coasts
				common tree families
				widely recognisable animals
			ensure the word fits:
				“this slice of country, not that one”

		level 2 (10 km)
			narrow again using:
				land elevation
				vegetation clusters
				hydrology (streams, wetlands, lakes)
				terrain (basalt, dune, escarpment, valley)
			names begin to match what people actually see in daily life

		level 3 (1 km)
			final natural tuning + light human context:
				parks, ovals, ridges, coves
				localised species lists
			this is the first level that can feel neighbourhood-specific

		level 4 (100 m)
			most cells have few distinctive features
				so names blend:
					local texture (scrub, slab, pine, reed)
					soft human-scale words (shade, bench, brick)
			tight dedupe ensures contrast with neighbours
				so adjacent cells feel different enough to orient with

		level 5–6 (10 m → 1 m)
			programmatic generation:
				forest/road/ocean derived from parent tone + masks
				benches, trees, hydrants, fixtures at 1 m where data exists
			where real objects exist, we use them
			where they don’t, we rely on calm fillers:
				no moralising
				no harsh connotations
				just clear, small descriptors


	rules for assignment

		nature &gt; judgement
			prefer calm natural terms when possible
			avoid loaded, evaluative words for normal places

		one sensory word per hex
			avoid hush–calm–quiet stacking
			keep sequences varied and memorable

		no near-homophones
			avoid confusing pairs in spoken form
			especially across common languages

		translation-safe
			simple stems, cross-language stability
			avoid idioms that collapse in other languages

		contrast with neighbours
			deduplicate by population weight + adjacency
			denser areas get extra care so names don’t blur together

		readable by children
			words should be understandable to a typical 12-year-old

		portable
			must work offline, on-device, deterministically
			the same place always gets the same words

	special cases

		uninhabited or uniform areas
			derive deterministic lists:
				sea, desert, ice, deep forest, tundra
			reduces noise in sparse regions
			keeps naming cheap and predictable

		urban density
			if too many similar cells
				blend in more human-scale descriptors:
					brick, shade, bell, frame, bench, tile
				so you don’t get endless “slab–slab–slab”

		expect refinement
			community renaming allowed
				with reasoning and consensus
			early land rush expected
				people will perfect names for their place
			descending versioning prevents churn later
				names settle over time
				but can still adapt when the world does



#### Computational assignment of hexagon names

		goal
			assign good, stable names to every relevant hexagon level
			using a repeatable, open process

		approx dictionary mix
			Flora                → 25%
			Fauna                → 25%
			Landforms            → 20%
			Atmosphere &amp; texture → 15%
			Human &amp; built        → 10%
			Emotional/abstract   →  5% (sparingly)

			for each broad region (e.g. Australia, Europe, Asia, Africa, Americas)
				use locally familiar sets
				so words feel native, not imported

		deterministic design
			words should be:
				short, common, translatable
				no suffix chains
				no near-homophones
				emotionally neutral (calm, natural)
				recognisable to a 12-year-old
				not overused filler words

			practically
				hex4–hex5–hex6 combinations are unique most of the time
					given someone’s current view
					and basic location hints

		levels 0–3
			populated 10 km → inhabited 1 km: ~15–25 million cells

			process
				combine JSON sources locally:
					biome
					terrain
					species presence
					human settlement
				use light LLM passes to:
					rank descriptors
					reject bad fits
				progressively dedupe by:
					population
					contrast with neighbours
					regional diversity

			CPU work
				straightforward joins and scoring
				runs fine on batches / spot instances

		level 4 (100 m)
			within populated 10 km cells only
				~35–45% of area actually inhabited
				≈ 500–900 million populated 100 m hexes

			for each hex
				attach sparse “what’s there”:
					POIs
					admin types
					distances to known features
					climate hints
				most hexes have 0–1 strong items

			compute
				joins + aggregation + distances
				~600–1,200 vCPU-hours (spot, cheap)
				primarily CPU-only work
					many simple mathematical operations
					little generation

		level 5 (10 m)
			process only inhabited L4 parents (~700 million)
				~100 L5 per L4 → ~70 billion potential cells

			optimise
				use on-device determinism for uniform areas
					forest, road, ocean derived from parent tone + local mask
				precompute only necessary 10–20%
					~7–14 billion L5 cells

			context inputs
				roads/footpaths
				carparks / slab
				land-use
				green edge
				vectors/geometry
				parcels/addresses where available

			compute + storage
				~6k–10k vCPU-hours (spot)
				deriving dataset:
					≈ 80–140 GB (binary)
					(plus more if JSON)
				names-only shards:
					≈ 60–160 GB

		level 6 (1 m)
			object-driven, not area-driven
				trees, hydrants, benches, fixtures
				~100–300 million points globally

			cheap to refresh
				monthly deltas cost cents

			storage
				compressed JSON:
					few to tens of GB

		total (order of magnitude)
			L0–L3: ~$50–$150
			L4:     ~$18–$60
			L5:     ~$180–$300
			L6:     ~$6–$48

			total one-off build:
				~$250–$550 on spot compute

			ongoing lean storage:
				~$17–$24/month


	hexagons.world tiles the whole planet from Level 0 (~1000 km) down to Level 6 (~1 m). In theory that gives us hundreds of trillions of level-6 cells. In practice, we don’t store them.

	Many hexagons can be generated on demand from a deterministic recipe: level, coordinates, parent theme, and a fixed set of wordlists. If nobody ever looks at a given metre, it never touches disk.

	Storage is only needed when a hex stops being “purely deterministic”. If people debate an indicator, attach metadata, or give a local name that doesn’t come from the recipe, that hex gets a row. Everything else remains virtual.

	The result is a very dense conceptual grid, but a very sparse dataset. Levels 0–3 hold most of the stored indicator values and metadata; Levels 4–5 only store a thin scattering of overrides; Level 6 is almost entirely deterministic, with overrides reserved for special or people naming metres.


#### Oceans, deserts and large ranges

		scope
			large uninhabited areas:
				oceans, deep desert, tundra, ice sheets, high mountain belts
			places where:
				almost no-one lives
				almost no-one navigates to metre precision
			goal:
				stable unique names
				without consuming the place-specific vocabulary
				needed for areas where people actually live

		level 1–2 (biome-fitted)
			use broad natural markers that genuinely belong here:
				ocean:
					currents, swell, shelf, fin, drift, krill
				desert:
					dune, mirage, wadi, thorn, sand, ridge
				ranges:
					ridge, spur, snow, granite, scree, pass
			unique per band
			lightly descriptive
			not heavily curated the way inhabited areas are

		level 3 (simple natural descriptors)
			defined from deterministic lists above if inside size
			still loosely tied to the biome:
				ocean:
					tide, foam, kelp, brine
				desert:
					silt, grit, dune, shale
				range:
					crag, ice, frost, stone
			calm, monotone, neutral
			these act as the last “biome-aware” words

		level 4–6 (deterministic filler categories)
			deep cells in empty regions use:
				large filler dictionaries
				separate from:
					flora
					fauna
					human-scale pleasant vocabulary
					unpleasant industrial vocabulary
			words are:
				neutral
				calm
				stable
				not evocative of nature
				not moralising
				not tied to the place
			purely deterministic:
				hex-level + coordinates → pseudo-random index → word
			unique enough, but repeats allowed in deep emptiness

		filler categories
			wide global lists (~thousands each)
			deterministic but not “meaningful”

			1. simple objects
				handle
				strap
				latch
				bolt
				wrench

			2. shapes + forms
				pillar
				ridge
				prism
				loop
				taper

			3. process words (calm, not industrial)
				fold
				wash
				grow
				turn
	            draw

			4. tool/fixture fragments (neutral)
				lever
				panel
				socket
				clip
				wire

			5. many, many different words

		traits of filler sets
			short
			translation-safe
			neutral to mild in tone
			no emotional charge
			no connotations of harm or pollution
			no nature words
			no synonyms of harshness used in unpleasant places

		why this approach
			we preserve high-quality nature words
				for inhabited and visited areas
			we avoid burning good vocabulary
				on trillions of empty hexes
			people still get:
				stable, unique-enough sequences
				for navigation or referencing
			but without cluttering:
				cultural words
				place-specific ecology words
				neighbourhood textures

		end result
			level 1–2 → biome-aware
			level 3 → simple natural texture
			level 4–6 → neutral deterministic fillers
			empty regions become:
				light
				stable
				predictable
				not over-described
				and not competing with words meant for human places


#### Unpleasant places

	Globally, unpleasant zones are tiny (&lt;0.5% of Earth), but they cluster. In highly industrialised corridors — such as parts of eastern China — 20–40% of 1 km hexes may classify as unpleasant. At the country level this still collapses to ~2–5%, and globally it’s far below 1%.

	tone
		words are:
			monosyllabic where possible
			heavy and textural
		they describe harshness
			without overt moralising.

	categories
		unpleasant places sit in themes such as:
			waste
			extraction
			sprawl
			noise
			industry
			agri-overreach
			disaster-damaged zones

	assignment rules
		classification leans on:
			population + building density
				to split pleasant vs unpleasant
			road surface coverage
				to pick up sprawl along road corridors areas
			land-use gradient
				residential → procedural
				mega-retail / logistics → unpleasant
		near sensitive spaces:
			homes
			schools
			clinics
		we fade or override harsh terms
			so the map can report local hardness
			without smearing people’s homes or care spaces.

	ocean rubbish patches (special theme)
		in ocean garbage-gyre areas,
			levels follow a fixed pattern:

			level 0 → endangered species (hidden from general UI)
			level 1 → sea / ocean / brine / depth
			level 2 → gyre / current / shelf / trench
			level 3 → swirling / converging / tangled
			level 4 → faded / cracked / brittle
			level 5 → plastic / oil / silicone / polymer
			level 6 → bottle / straw / net / cap / fragment

		this produces calm but unsettling phrases, for example:
			faded bottle cap
			tangled net fragment

	examples
		example mappings stay simple and direct:

			1 km landfill
				→ dump
			100 m carpark
				→ cracked
			1 m bitumen hot spot
				→ boil
			a lone tree at 1 m in an otherwise harsh area
				→ shade

	pleasant human / procedural
		pleasant human-scale built areas (homes, civic, cultural, older cores, workplaces)
			use the same gentle inventory as elsewhere:
				brick, shade, bell, frame, bench, file
		these are:
			normal human places,
			procedural but not hostile,
			and sit on the “pleasant” side of the split.

	infrastructural / mechanical (unpleasant)
		infrastructural belts and harsh built fabric:
			highways
			shopping slabs
			industrial belts
			derelict or extractive zones
		draw from a deliberately rougher set:
			slab, slick, drum, vat, slag, rot

	overall shape
		unpleasant naming is:
			localised,
			used sparingly,
			and tuned to report harshness
				where it genuinely dominates the physical environment.
		the aim is:
			to notice and map strain,
			without labelling whole neighbourhoods or communities
			as unpleasant in themselves.





### Style and design language

	the map should feel:
		friendly
		readable
		and quietly close to the real world.

	it is not a satellite viewer.
	it is not a dense GIS client.

	it should feel a little like:
		a calm 'video game' map of your area,
		one breath of “cartoon”,
		but still clearly your streets, trees, and coastline.


	base appearance

		the base map is built from:
			land and water
			roads and paths
			buildings and parcels where available
			vegetation and shade
			hexagon boundaries (subtle, optional)

		these are drawn as:
			flat, clean shapes
			with light shading for depth,
			not photo textures.

		visual priorities:
			streets and paths stay clear
			text remains legible at all scales
			overlays (heat, events, indicators) sit on top without fighting the base.


	colour and tone

		colour choices are:
			soft
			stable
			and high-contrast enough to be used all day.

		land and water:
			land is warm-neutral
			water is calm and distinct, not neon.

		vegetation:
			shown as steady greens,
			with darker tones for denser cover.

		built areas:
			low-saturation greys and browns,
			so statistics and routes can stand out.

		people can choose themes:
			high-contrast for work use
			soft for evenings
			dark-friendly options for night.

		the defaults avoid:
			aggressive colour schemes
			visual noise
			and sudden redesigns.


	light, depth, and “feel”

		to avoid a flat diagram look,
			tiles include light depth cues:

			subtle building footprints
			soft outlines on major roads
			light relief shading from terrain (where data allows)
			shadows or darker strokes under tree clusters.

		this gives:
			a hint of three-dimensionality,
			without going into full 3D rendering.

		the result should feel:
			recognisably like your town,
			but cleaner and calmer than an aerial photo.


	hexagons on the map

		hexagon layers are:
			drawn lightly above the base map,
			never as a heavy grid.

		at low zoom:
			only coarse hex levels (hex0–hex2) appear,
			and only when people ask to see them.

		at neighbourhood and street level:
			hex3–hex4 can appear as:
				soft outlines
				or tap/hover targets
			showing names and statistics when needed.

		at metre-level:
			hex5–hex6 are mostly invisible,
			except when people are doing precise work.

		the visual rule:
			place first, hexes second.
			people should see their area,
				not a board game.


	raster tiles instead of constant recompute

		most people do not need live-rendered vector tiles.

		for base maps, we use:
			pre-rendered raster tiles by zoom and region,
			derived from a stable vector base.

		advantages:
			cheap to serve and cache
			works well on older phones and e-ink devices
			predictable performance in low-bandwidth settings.

		when overlays or routes change,
			they are drawn on top,
			without having to regenerate the base.


	multi-scale generalisation

		as people zoom out:
			small streets are removed
			minor features are merged
			labels thin out.

		as they zoom in:
			more detail appears,
			but still with clear hierarchy.

		this avoids:
			the “everything at once” feeling common in GIS,
			while keeping each zoom level readable on its own.


	statistics and overlays

		indicators and other overlays:
			colour the hexes,
			not the whole world.

		design:
			fill or outline at hex level
				with strength mapped to indicator values.
			opacity mapped to certainty
				(as in the statistics section).

		the base map stays:
			consistent and calm underneath,
			so people can still orient by real-world cues.

		examples:
			heat (warm overlays on hexes)
			unsafety at night (subtle glows along routes)
			trees and shade (green density above base greens).


	satellite imagery (optional and slow)

		by default:
			people do not see satellite imagery.

		they can choose a:
			“photo” layer for inspection,
			which:

				loads more slowly,
				is pulled only for the area they are viewing,
				and is clearly marked as imagery.

		this keeps normal use:
			lightweight
			offline-capable
			and not dependent on heavy imagery services.


	locality and caching

		tiles are:
			cached on-device where possible,
			so commonly used areas load instantly.

		in some environments,
			tiles can also be served from:
				local nodes
				or regional mirrors,
			reducing load on central servers.

		this is an implementation detail,
			not a user-facing feature,
			but it keeps the map fast in the places people live.


	special environments

		low-bandwidth / older devices
			use raster tiles with reduced detail,
			limited animations,
			simplified fonts.

		e-ink devices
			high-contrast themes only
			strong outlines
			pure greyscale, no shading that depends on colour.

		night
			optional dark palette
			reduced glare
			routes and overlays still clearly separated.


	end point

		the map looks:
			like the place you live,
			in a calmer, cleaner form.

		it is easy to read,
			does not change style unexpectedly,
			and can run well on almost any device.

		hexagons, statistics, and events layer on top,
			without ever overwhelming the feeling of “this is my area on a map”.







### Communities



#### Ownership of word lists and hexagon names

	purpose
		most names are deterministic and derived from data.
		but people on the ground often know places better than any model.
		this layer lets communities:
			add local detail,
			fix mismatches,
			and give places the names they actually use.

	how local naming works
		people can stand inside a hexagon
			(open app, GPS lock)
			and propose a name for that cell.
		name can reflect:
			a landmark,
			a school,
			a creek,
			a building,
			a patch of bush,
			something widely recognised.
		potentially an AR mode
			point camera,
			tag what you see,
			propose a simple label.
		names stay short, neutral, and translation-safe.

	slider for “local vs deterministic”
		each proposed name includes a slider:
			how much this overrides the deterministic seed.
		most cells:
			keep deterministic name + small human note.
		for culturally strong places:
			local name can fully replace deterministic word.
		this keeps the map mostly stable,
			while letting important places speak for themselves.

	land rush (epoch 0)
		initial period when:
			people can walk around,
			claim cells,
			suggest names,
			and attach brief notes.
		goal for people
			populate early community names,
			especially in inhabited areas.
		larger hexes (hex2–hex3) require:
			multiple people,
			from different nearby points,
			to propose or confirm names.
		after the initial rush,
			epoch closes,
			and the naming slows into normal governance.

	governance and review
		all proposals are tied to a peaceful passport.
			light skin in the game,
			prevents drive-by vandalism.
		reviewers (volunteers) check for:
			off-purpose proposals,
			duplicated content,
			harmful or political language,
			place names that break rules.
		for larger hexes (hex2, hex1):
			require multiple attestations,
			ensuring the name fits the region,
			and isn’t one person’s personal nickname.

	community signals
		other people can:
			approve (“this fits”),
			soft-disagree (“not quite right”),
			or propose alternatives.
		no ratings,
		no leaderboards,
		no public fights.
		just calm signals to help people see what locals actually use.

	preventing abuse
		restrictions:
			no nasty words
			no political slogans,
			no personal attacks,
			no duplicates that cause confusion.
			allow searching the global word list
		if someone repeatedly proposes harmful names:
			their privilege to propose names is paused.
		most cells remain deterministic,
			so only places people care about get human naming.

	level-based trust
		hex5–hex6 (very small)
			single local name often enough,
			as long as it’s factual:
				bench,
				birch,
				school-gate,
				court-entrance.
		hex4 (100 m)
			require at least one additional confirmation.
			place-scale details:
				corner store,
				footpath bend,
				playground.
		hex3 (1 km)
			require multiple locals
			neighbourhood names,
			parks,
			cultural landmarks.
		hex2–hex1
			higher bar:
				regional rivers,
				long-standing areas,
				coast segments.
			must be stable,
			uncontroversial,
			and actually used by residents.

	integration with deterministic names
		deterministic backbone stays intact:
			biome words,
			flora/fauna,
			territorial textures.
		local additions layer on top,
			replacing or modifying only where people care.
		this prevents large-scale drift,
			while allowing high-fidelity local detail.

	after land rush → epoch 1
		once the initial wave settles:
			all accepted names freeze into versioned state.
		new proposals come more slowly,
			only for mismatches or genuine local needs.
		versioning ensures:
			names are stable over time,
			but can still adjust when the world does.

	end point
		a global naming system that:
			remains mostly deterministic,
			is open to human correction,
			and reflects what people actually call the places they live in.
		names become a gentle collaboration:
			between data,
			landscape,
			and the people who walk through it every day.




#### Community organisations and activities

    	what this is (and isn’t)
    		peaceful foundation does not run events
    		we build tools so people can find what’s already happening
    		local groups, councils, clubs, faith communities, co-ops run the activity
    		the map just makes it easier to see, join, and keep good things alive

    	things already happening nearby
    		local groups
    			church teas, knitting circles, youth groups
    			mens sheds, womens groups, language circles
    			community gardens, repair cafés, walking clubs
    		councils and services
    			free buses, community centres, libraries, pools
    			hall bookings, workshops, info sessions
    		most people never hear about these
    		most of them depend on word-of-mouth and paper posters

    	what the map shows
    		each hex has:
    			public events and recurring activities
    			public facilities from councils
    			quiet local things that volunteers have surfaced
    		anyone can:
    			see what’s on
    			see access notes (e.g. step-free, kid-friendly, cost if any)
    			see basic description and timing
    		signed-in people can:
    			add to their calendar
    			RVSP through peaceful passport

    	seeing details (gated softly)
    		peaceful passport needed to see:
    			— exact meeting point
    			— organiser contact details
    			— RSVP button
    		reasons:
    			— avoid mass scraping and spam
    			— give organisers a calm sense of how many might show up
    			— keep some friction between bad actors and vulnerable groups

    	vouching (organisations)
    		groups need local vouches to show full details
    			existing organisations vouch for new ones
    			quiet, factual: “this group is real and does what it says”
    		upstart groups:
    			explain what they’re doing
    			get at least one local vouch
    		vouching is:
    			per-organisation, not per-person
    			visible as simple counts, not as scores
    			reviewable if a group drifts from its purpose

    	history (events, not ratings)
    		no stars, no “good/bad” scores
    		event history shows:
    			— how many times it has run
    			— roughly how many people have attended before
    		optional neutral confirmations:
    			— “this event happened on this date”
    		names not shown
    		no comments, no reviews
    		keeps a factual record without turning it into a popularity game

    	safety and harm reduction
    		people are lightly trained (through guides and prompts) to:
    			notice controlling or outcome-focussed behaviour
    			leave if something feels wrong
    			flag concerns quietly to peaceful foundation community and staff
    		events that start to feel:
    			overly coercive,
    			predatory,
    			secretly recruiting,
    			heavily ideological,
    		can be:
    			reviewed,
    			de-listed,
    			or asked to clarify purpose
    		goal:
    			make it easy to find calm, low-pressure spaces
    			reduce room for predatory setups without drama

    	role of volunteers
    		volunteers don’t create their own brand of events “for PF”
    		they:
    			help offline groups get onto the map
    			find knitting circles, seniors groups, local clubs
    			offer to list events and keep info up to date
    			respect each group’s tone and autonomy
    		especially useful for:
    			elder-run activities with no web presence
    			mailing-list-only communities
    			“we’ve always done it this way” groups that still welcome newcomers

    	councils and facilities
    		map shows:
    			libraries, pools, community centres, BBQs, shaded parks
    			free buses and shuttle routes
    			public toilets, fountains, basic amenities
    		programmers and volunteers:
    			scrape council websites
    			import open data where possible
    			tag facilities into the right hexes
    		this lets:
    			people see what their area already offers
    			soft pressure build for better services where gaps are obvious

    	example: perth free beach bus
    		personal anecdote:
    			my girlfriend only found out late that Perth had a free beach bus
    				it ran up and down the coast to different beaches
    				anyone could hop on, no ticket
    			hardly anyone knew it existed
    				no clear map
    				no simple listing
    			ridership stayed low
    			the service was cancelled
    		why it matters:
    			the bus wasn’t a bad idea
    			it just wasn’t visible
    			hexagons.world exists so things like that:
    				are easy to find,
    				get used,
    				and have a fair chance to survive

    	overall flow
    		people open the map and see:
    			what’s happening in their hex
    			what facilities their council already provides
    		if they care, they:
    			sign in,
    			see details,
    			RSVP,
    			turn up,
    			and quietly confirm the event happened
    		organisations:
    			own their events,
    			get gentle feedback via attendance,
    			share hosting load over time
    		peaceful foundation:
    			stays in the background,
    			keeps the map honest,
    			and helps good local things stay visible



	// pulling the data from physically close by






### Technical ethos and architecture

hexagons is the best example of our technical design methodology

	it covers the whole Earth, from broad regions down to metre-scale places
	but it doesn't need to store the whole Earth as if every metre needs its own permanent record

the whole thing should feel enormous from the outside, but remain pretty simple underneath

	the core principle is:

		compute what can be computed
		store only what must be remembered
		fetch only what is needed
		cache what people actually use

	this keeps the system:
		cheap
		fast
		local
		offline-capable
		and difficult to centralise too tightly


#### "get the client to do it"

		the default instinct should be:
			get the client to do it
				modern devices are powerful
				a phone or laptop can already handle many things
					that older systems would have pushed to a server

			the client should compute:
				hex geometry and hit-testing
				applying styling
				zoom-level generalisation rules
				visibility rules for minor roads, paths, labels, and overlays
				basic route rendering
				basic routing where the graph for the current region is already on-device
				deterministic interpretation of uniform areas like road, forest, ocean, slab, and similar local masks where that data has already been packaged efficiently.

		the server should not be asked
			to do work the device can do calmly by itself
			Only store what cannot be cheaply recomputed.

	If data is missing, the system should fall back to deterministic generation rather than fail.
		it should still render something usable
			not perfect
				but coherent
			good enough to navigate
		a missing layer should not break the map
			it should simply reduce confidence
				or reduce detail
		the map should degrade gracefully

	if a feature requires:
		constant global syncing
		heavy central storage
		fragile live coordination
		or a server round-trip for ordinary use
	it is probably wrong
		not always wrong
			but suspicious

			the question should be:
				can this be deterministic?
				can this be cached?
				can this be local-first?
				can this be sharded?
				can this be optional?
			can this fail without breaking the whole system?
		if the answer is no too often
			the feature may not belong in the core architecture

			we actively should prefer:
				small pieces
				clear rules
				local computation
				replaceable layers
				slow coordination
				and durable defaults

				compared with
					large services
					hidden dependencies
					global state
					and constant server authority


	// download the map like openstreetmaps does


	If a feature requires global coordination, heavy storage, or constant syncing, it is probably wrong.



#### Shards and torrenting

		the non-technical version is:
			people torrent the map between themselves

		not necessarily literally one protocol
			and not necessarily pure peer-to-peer

			but conceptually:
				each piece can be
					verified
					cached
					fetched from wherever is fastest
				“a graph of small immutable pieces, continuously recomposed and fetched from wherever is fastest”

		as a nested addressing system (whereby a larger hexagon has smaller hexagons tiling within it)
			lends itself well to sharding
			people already understand the geography
				because the storage shape roughly follows the place shape
				however, the delivery layer does not need to exactly match the public naming layer

				the user-facing system should stay simple:
					hex names
					places
					indicators
					routes
					local records

				the distribution layer can be more pragmatic, with:
					shards
					blocks
					manifests
					regional bundles
					epoch files
					content hashes

			the public map should feel human
			the storage system can be boring and efficient


##### Types of Shards

			the world is broken into many small immutable pieces, and each device or node keeps the pieces most relevant to its place, purpose, and recent use.

			A shards tag should let you infer enough about it that you can decide whether it is relevant before downloading everything.

				So the shard tag should encode or point to:

				- where it is
				- what scale it is for
				- what sort of data it contains
				- which version family it belongs to

				It means the system should make it easy to know, from a compact descriptor or manifest, roughly what area, scale, and kind of data something pertains to. This aligns with your broader UX principle that names and suggestions should feel anchored to where the user is, not abstract.


###### Snapshots

				coarse regional bundles
				used to bootstrap devices and peers

				they might include:
					base map data
					coarse geometry
					regional wordlists
					stable public layers
					common routing graphs
					low-resolution indicators

				these help a device become useful quickly


###### Overrides

				small records layered over the deterministic base

				hexagons.world defines hex0–hex6 everywhere on Earth: from ~1,000 km down to ~1 m. In theory that’s on the order of 10¹⁵ cells. In practice, almost all of them are deterministic. Themes and wordlists are derived from open data (UNESCO, ecoregions, land-use, climate, species) plus a coordinate-based seed.

				A hex only stops being “purely deterministic” when a group of people override something – a local name, a tag, an indicator edit, metadata, or a photo. Even if we gave every inhabited 1 km and 100 m cell special attention, that’s roughly a billion hexes out of hundreds of trillions – about one in a million. Everything else is maths, not storage.


					they include:
						community names
						local metadata
						factual traces
						facilities
						events
						organisation records
						indicator corrections
						accepted edits
				these should remain tiny relative to the full grid


###### Epochs

				versioned descriptions of the current rules of the world

				they describe:
					active dictionaries
					indicator methods
					naming rules
					style rules
					shard versions
					data source versions
					model versions

				they let peers know:
					what they are serving
					what version they are using
					whether they are out of date
					how to reproduce a result


###### Local Bundles

				practical packages for a place people actually use

					for example:
						a campus
						a suburb
						a town
						a city
						a region

					these are what devices and community nodes
						will most naturally keep around


###### Indexes

				small searchable layers

				they support:
					autocomplete
					local search
					place lookup
					facility lookup
					hex-name lookup

				these should be independently replaceable so search can improve without repackaging the whole map


##### Shard Names and Manifests

			a shard should be understandable before someone downloads it
			a device should be able to ask:
				is this near me?
				is this at the scale I need?
				does this contain the kind of data I want?
				is this the current version?
				is this compatible with my local cache?

			a shard tag should encode or point clearly to:
				where it is
				what scale it covers
				what kind of data it contains
				which epoch it belongs to
				which version family it uses

			Any single shard or block must be small, simple, and independently usable
					fast transfer, easy caching, composability into more relevant sharding



###### Good Enough Before Perfect

				We must always render a usable approximation before complete.

					a person opening the map should see:
						a coarse map first
						then local names
						then useful roads and paths
						then facilities
						then photos and richer details
						then heavier overlays

						emergency or navigation-relevant data should arrive before decorative data
							first useful render
							then better detail
							then richer local context
							then historical completeness
								(and historical archives can be on demand)

						local search should work before historical archives






##### Transport

			pure peer-to-peer is elegant in theory but messy in practice
				people go offline
				home networks are strange
				mobile connections vary
				NAT traversal is annoying
				some regions have weak infrastructure

			instead, we should fetch from three sources at once:

				local-first
					the user’s own cache
					nearby peers
					LAN devices
					community nodes

				regional nodes
					universities
					libraries
					councils
					community servers
					soft infrastructure

				fallback CDN / HTTP
					ordinary servers
					object storage
					edge cache
					simple reliable downloads

			this is more about always fetching from the fastest trustworthy source
				not always fetch from the most ideologically "pure" source

				local-first is best when it works
				regional mirrors are good when they exist
				plain HTTP is fine when it is the most reliable option

				the architecture should be decentralisable without making normal use fragile

					A person’s device stores what it uses.
					A local node stores what its community uses a lot.
					A regional mirror stores what a broader region depends on.
					And the deterministic backbone means nobody has to store everything. That fits your principle that deep hexes are mostly generated, lightly stored, and served through local mirrors or peer-to-peer methods only where needed.

			This works because the technical architecture mirrors natural human behaviour and aims to be a map that behaves like a community does
				people naturally pin what they use, so:
					Perth users naturally cache Perth shards
					universities cache their campus + city
					NGOs cache regions they care about
				Over time:
					data becomes geographically local because usage is local

			this gives us
				near-zero storage explosion
				strong locality
				offline capability
				graceful decentralisation
				plus a simple mental model

	A university, town, or neighbourhood node can keep the blocks for its own area pinned locally. Then nearby users tend to fetch nearby data from nearby providers. That does not happen because the data is “from their town” in a sentimental sense; it happens because peers in that area are more likely to cache and provide that shard, which improves resilience and often latency too.



#### Storage within communities

			how much storage within each community?

			how might we store it??


				local storage should follow use

				people naturally cache what they use
				communities pin what they depend on
				regional mirrors keep what larger areas need

				the system should not try to store the whole world everywhere

				instead:

					a person’s phone stores:
						1–10 GB

					a local node stores:
						50 GB–1 TB

					a regional mirror stores:
						1–20 TB

					the global sharding system stores:
						sparse accepted records
						hashes
						version history
						public datasets
						metadata
						moderation state
						content-addressed shards


##### What Takes Space?

		For one local community, a sane storage breakdown might look like this:


		| Layer                         | What it contains                                       | Typical size |
		| ----------------------------- | ------------------------------------------------------ | -----------: |
		| POI records                   | name, category, location, opening hours, contact, tags | 10–200 MB    |
		| Events + recurring activities | community meals, clubs, free buses, workshops          | 10–500 MB    |
		| Local notes / access info     | step-free, quiet, kid-friendly, cost, seating          | 10–200 MB    |
		| Menus / service lists         | mostly text, and small images for menu items image     | 100 MB–10 GB |
		| Photos                        | listing images, local verification, shopfronts         | 2 GB–2 TB    |
		| Map tiles                     | offline raster/vector tiles for the area               | 1–100 GB     |
		| Routing graph                 | walking, cycling, driving, transit graph               | 100 MB–20 GB |
		| Historical changes            | old listings, event history, accepted edits            | 100 MB–50 GB |
		| Search index                  | local place search, autocomplete                       | 100 MB–10 GB |



###### Stuctured Local Data

					structured local data is small

						a café listing with:
							name
							opening hours
							category
							accessibility notes
							menu text
							local tags
							short descriptors

							might only be:
								5–50 KB

						council facilities
							stay durable
							because they are public infrastructure

						community organisations
							require vouching
							stay visible while active
							can become archived if inactive

						local notes
							stay small and structured
							avoid long comment threads
							prefer simple access facts

						tiles
							cached aggressively
							regenerated from stable source data where possible



###### Photos

				The funny little storage consideration is photos. A café listing with name, opening hours, categories, accessibility notes, menu text, tags, and a few descriptive “vibes” might only be 5–50 KB as structured data. That is basically dust.

					But add photos:
						A compressed web photo might be 200 KB–1 MB.
						Ten photos per place means 2–10 MB per place.
						100,000 places with ten photos each becomes roughly 200 GB–1 TB just for images.

					using menus as an example
						Menus are smaller unless stored as PDFs or images. Text menus might be only 10–100 KB each. PDF/image menus can be 500 KB–5 MB each, which adds up but still usually loses the fistfight to photos.

						so the rule is:
							store text where possible
							compress images aggressively
							keep only useful photos
							expire or downsample weak media over time

							from my experience, it feels risky having the menu as data instead of being able to review the pdf
								track:
									last updated
									how many people confirmed it
									whether prices are stale

								this is a core and important thing, so people can be prompted at a cafe to check the menu and look at a random item from the menu to see if it is correct

									or can rescan the menu to import the data using OCR

				But, photos are still useful!
					just have a set number depending on the place
						which is able to be determined via consensus
						so less for a cafe, just enough to give the vibe
						but more for different sections of a park

					Photos expire or compress unless attached to verified durable places.
						nice photos confirmed from other people
							 this also means that photographers (or hobbysts) can take the best local photos
						not everyone needs to have *their* photos for everything, which would balloon into too many
						nice photos slowly but surely depreciate over time, so people can be prompted to take new ones, so people can take more and replace older ones, so that everyone gets a turn to take some, if they want to




##### How Much Space Is Needed?

			For a realistic “local community directory and map” with cafés, facilities, events, pictures, menus, community groups, local notes, and offline tiles, I’d use this planning estimate:

			Small community / campus: 10–50 GB
			Suburb or town: 25–150 GB
			Small city: 100–500 GB
			Large city: 500 GB–3 TB
			Metro region: 2–10 TB

			That is for a genuinely useful local layer, not a bare database. The bare structured records would be far smaller. The rich human layer is what requires storage.


			The practical design rule should be:

				A person’s phone stores 1–10 GB (or less; unless they have the space to share)
				A local node stores 50 GB–1 TB.
				A regional mirror stores 1–20 TB.
				The global sharding system stores everything sparse, deduped, and content-addressed.

				People naturally cache what they use, universities cache campus and city shards, NGOs cache regions they care about, and deterministic generation prevents the whole thing turning into a bloated planet-hoarding dragon. Your notes already describe this as “people naturally pin what they use,” with local nodes and regional mirrors storing what their communities depend on.




##### Storage Modes

			1. Minimal local bundle

			This is enough for the app to work locally and feel alive.

			For a town, campus, or neighbourhood: 1–10 GB.
			For a whole city: 20–100 GB.

			This includes core listings, local facilities, simple events, compressed map tiles, and maybe one or two photos per important place.


			2. Comfortable community node

			This is what a university, library, council, community server, or local volunteer node might pin.
			For a town or campus: 20–100 GB.
			For a city: 100 GB–1 TB.

			This stores richer photos, menus, event history, local routes, council facilities, cached tiles, and maybe some local indicator layers. This seems like the sweet spot. Big enough to be useful, small enough that normal hardware can host it.


			3. Rich archive / local mirror

			This is the “we keep nearly everything” version.

			For a town: 100 GB–500 GB.
			For a city: 1–5 TB.
			For a metro region: 5–20 TB.

			This includes lots of photos, historical snapshots, offline tiles across many zoom levels, routes, old menus, imported council datasets, and local imagery. This is less phone-friendly, but fine for a university server, NAS, library server, or regional mirror.


###### Responsibilites Within Different Storage Modalities



					always local
						basic map
						local search
						nearby POIs
						local facilities
						upcoming events
						walking and cycling graph
						user’s saved areas

					cached when needed
						photos
						menus
						richer place pages
						old events
						detailed overlays
						satellite or photo layers

					stored by community nodes
						local full directory
						offline region bundle
						council imports
						community organisations
						verified event history
						local imagery

					global canonical store
						accepted records
						hashes
						version history
						public datasets
						metadata
						moderation state
						sparse overrides



###### Retaining Data

				As an architectural question: What gets stored forever, what gets cached, what expires, and what needs local human confirmation?

				For hexagons.world, the default can be:

					Photos expire or compress unless attached to verified durable places.
						+ confirmed from other people
							+ this also means that photographers can take the best local photos
							+ not everyone needs to have photos for everything, which would balloon into too many
					Events expire into light history.
					Menus are stored as text where possible, not giant PDFs.
						+ last updated
						+ confirmations from other people
					Council facilities stay durable.
					Community organisations need vouching.
					Local notes stay small and structured.
					Tiles are cached aggressively but regenerated from stable source data.

				That way, the local map can feel rich without becoming a planet-sized attic full of unlabeled boxes.


### Statistics

	hexagons carry statistics that people can understand and act on

	each hexagon
		does not get a single composite score
		it holds one value per core indicator
			so every place has:
				nine main numbers
				plus uncertainty for each
		this keeps the picture:
			clear
			honest
			harder to game

	all inputs, weights, and methods are open
		anyone can:
			check
			criticise
			suggest improvements
		indicator definitions change slowly
			with a clear public record

	core 9 local indicators

		1. homelessness
		2. poverty
		3. malnutrition
		4. physical illness
		5. mental distress
		6. heat
		7. pollution
		8. unsafety
		9. disengagement

	negative wording is intentional
		it’s easier to see where help is needed
		each value shows:
			“how much this hurts here”

	for each indicator
		we keep:
			plain-language definition
			clear units (%, rate, or index)
			list of input sources
			quality score + uncertainty band
		so people can see both:
			confidence
			and gaps


		every indicator is a living estimate, built from multiple kinds of evidence, with visible confidence, open methods, and community correction.



#### Data types

		every indicator is a living estimate
			built from multiple kinds of evidence
			not one perfect source

		the map should show:
			what we think is true
			how well we think we know it
			what the estimate is based on
			what would make it better

		inputs can include:

			open public datasets
				census data
				health data
				environmental data
				planning data
				transport data
				housing data
				school and service data where available

			remote and environmental signals
				satellite imagery
				tree cover
				urban heat
				green space
				lighting at night
				pollution
				noise
				water
				shade
				surface data

			local organisation inputs
				non-government organisations
				councils
				universities
				community groups
				food banks
				clinics
				shelters
				libraries
				faith groups

			community surveys
				small local surveys
				micro-check-ins
				student projects
				volunteer observations
				questions asked by local groups

			factual traces
				a garden was planted
				a free bus was added
				a shaded path was improved
				a community meal started
				a fountain was installed
				a local organisation began serving an area

		not all inputs are equal

			some are precise
			some are partial
			some are old
			some are local but hard to verify
			some are broad and reliable
				but too coarse to explain street-level reality

		so each input carries metadata:

			source
			date collected
			geographic resolution
			method
			update frequency
			known limitations
			privacy level
			confidence score
			which indicator it affects

		the system should never simply ask:
			is there data?

		it should ask:
			what kind of data is this?
			how recent is it?
			how local is it?
			how reliable is it?
			what does it miss?
			what would improve it?


#### Confidence and uncertainty

		confidence should be visible
			not hidden inside the model

		the goal is not:
			to pretend every hexagon has perfect data

		the goal is:
			to show the best current estimate
			and the strength of the evidence behind it

		distinction

			input confidence
				how much we trust a particular source

			indicator uncertainty
				how sure we are about the final estimate for that hexagon

		examples

			heat
				fresh satellite data
				tree-cover data
				surface temperature
				local shade data
				likely higher confidence

			loneliness
				national averages
				weak proxy signals
				limited local survey data
				likely wider uncertainty

			food access
				supermarket distance
				food prices
				transport access
				food bank data
				community meal data
				gets stronger when local organisations contribute current information

		each indicator can be shown as:

			estimate
				the current value

			range
				the plausible band

			confidence
				how strong the evidence is

			freshness
				how recently it was updated

			dispute state
				whether locals, researchers, or organisations have questioned it

		people should be able to tell the difference between:

			a strong estimate
			a weak estimate
			a disputed estimate
			an outdated estimate
			a locally improved estimate

		weak data becomes an invitation

			if food access data is weak
				a local group can survey:
					supermarkets
					community kitchens
					food banks
					staple prices
					transport access

			if green space data is weak
				volunteers can verify:
					parks
					shade
					trees
					paths
					public seating
					usable open space

			if loneliness data is weak
				a university or local organisation can run:
					careful surveys
					privacy-preserving check-ins
					small group studies
					local service mapping

		the point
			people can see not only where things may be bad
			but where the data itself is thin


#### Improving estimates

		statistics are not fixed reports
			they are shared local models
			that improve over time

		process

			start with broad public data
			add environmental and spatial signals
			compare with local knowledge
			invite corrections and better sources
			update the estimate
			update the confidence score
			keep the old version in the record

		example

			a hexagon might begin with:
				a rough poverty estimate
				from national or regional data

			later it may improve through:
				local service data
				food price data
				transport access
				school data
				housing data
				community surveys
				organisation inputs

			the value changes
				but so does the confidence behind it

		this means the system can improve
			without pretending to be finished

		old estimates remain visible
			as part of the version history

		people can ask:
			what changed?
			why did it change?
			which source changed it?
			did the real world change,
				or did the data improve?

		this matters because:
			better data should not look like magic
			and uncertainty should not look like failure

		it should feel normal that:
			early estimates are rough
			local evidence improves them
			methods get refined
			confidence increases slowly
			disagreement leaves a useful record


#### Collaborative statistics

		local statistics become better
			when different people improve different parts of the model

		no single group owns the truth

		roles

			statisticians
				test the model
				debate weightings
				check which variables actually predict the outcome
				make uncertainty visible
				remove variables that add noise

			local organisers
				check whether estimates miss obvious local realities
				notice missing facilities, services, and local conditions
				connect numbers to lived experience

			institutions
				contribute stable datasets
				share aggregate programme data where appropriate
				help maintain continuity over time
				use the same grid in reports and planning

			volunteers
				find missing public data
				verify local amenities
				update facilities, events, and traces
				help keep local records fresh

			residents
				point out mismatches
				answer small surveys
				notice when a number does not match local experience
				suggest better local sources

			data journalists and researchers
				explain uncertainty
				compare places carefully
				make methods understandable
				help the public see what the numbers do and do not mean

		the estimate gets better because:
			many people can inspect the same number
			question the same evidence
			and add better information over time

		disagreement should be useful
			not hidden

		when people disagree
			the system should capture:
				what is disputed
				who is disputing it
				what evidence they point to
				whether the dispute affects the estimate
				or only the interpretation

		the aim is not perfect certainty

		the aim is:
			a public system where uncertainty is legible
			disagreement is useful
			and better evidence can steadily replace weaker evidence



#### Indicator design

		indicator design starts wide

		for each indicator
			collect all relevant variables
			then slowly reduce them
			into a smaller, more stable model

		process

			collect possible inputs
				public data
				environmental signals
				local organisation data
				survey data
				factual traces

			review which variables help
				which ones predict the outcome
				which ones are redundant
				which ones add noise
				which ones create bias

			local sanity-checking
				does the estimate miss obvious local realities?
				are there known gaps?
				are some groups invisible in the data?
				are proxy signals misleading here?

			statistical review
				test weightings
				check uncertainty
				compare similar places
				record assumptions
				publish method changes

			public revision
				proposals stay open
				changes are versioned
				old methods remain visible
				alternative models can be compared

		the goal is:
			a small, stable set of inputs
			that most people can understand
			question
			and live with
			even when they disagree on the details


#### Bayesian hexagons

		priors + signals + neighbour pooling
			outputs are distributions with uncertainty
				not just single numbers

		ingredients + signals
			priors:
				national or census baselines
			local signals:
				satellites
				admin data
				digital traces (carefully throttled)
				NGO inputs
			covariates:
				density
				travel time
				education
			neighbour pooling:
				~6 adjacent hexes

		model shape (plain English)
			start with prior
			update with signals
			pool with neighbours
			report, for each indicator:
				mean
				interval
				uncertainty score

		design choices + ethics
			partial pooling
			monotone priors (values from 0–100%)
			missing-not-at-random adjustments
			temporal smoothing
			open priors, weights, intervals
			aggregates only; digital signals rate-limited

		data sources + scale
			satellites
			demographics
			surveys
			admin datasets
			digital traces
			shocks (fires, floods, etc.)

			UI:
				colour = estimate
				opacity = certainty
			roll-ups carry uncertainty upward
				not just point estimates

		improving over time
			micro-surveys at local scales
			lightweight NGO “crumbs”
				simple, small inputs
			community feedback loop
				dispute values
				suggest evidence
			stats evolve with reality
				not just with code


#### Measurable change

		why this matters
			statistics are only useful if people can see them move.
			not as a scoreboard,
			but as a quiet sense that things can improve.

		neutral indicators
			change must reflect the real world,
				not activity inside any organisation,
				not volunteer counts,
				not participation metrics.
			indicators stay independent and grounded in:
				satellites
				admin data
				local reports
				environmental signals
				clearly defined inputs
			so improvement comes from conditions changing,
				not from who shows up.

		how change is detected
			each indicator updates as:
				new signals arrive,
				models rerun,
				local conditions shift.
			some indicators move quickly (heat, shade),
			others slowly (poverty, distress).
			every update includes:
				the estimate,
				the uncertainty,
				and the confidence behind it.

		traces (light, factual)
			hexagons keep simple notes when something verifiable happens:
				a fountain installed
				a garden expanded
				a free bus reinstated
			these are not ratings,
				not endorsements,
				not tied to groups.
			they’re just quiet context
				for why a number might have shifted.

		avoiding skew
			no indicator uses:
				organisation size,
				community activity,
				or platform engagement.
			those signals stay separate.
			the statistics themselves stay neutral
				so confidence isn’t confused with enthusiasm.

		reading change
			people can compare:
				before → after,
				one hex → nearby hexes,
				similar places elsewhere.
			this helps them see:
				where things are improving,
				where strain remains,
				and what patterns might be forming.

		precision and scale
			some inputs exist at metre resolution
				(heat, shade, noise, tree cover)
			and are then averaged upward.
			this lets people:
				notice small improvements,
				understand where gaps are,
				and act at a scale that feels human.

		picture over time
			each hex shows:
				the current indicator,
				its trend,
				its uncertainty,
				and a few factual traces.
			no scoring,
			no gamification,
			no pressure.
			just a calm, honest sense of direction.







### Distributed volunteer compute

	the core hexagons.world stack does not need much compute

	that is the point of the architecture

		most hexes are deterministic
		deep layers are generated when needed
		clients do as much as they reasonably can
		local data is cached close to where it is used
		shards are small and independently fetchable

	the shared compute layer exists for something else

		not ordinary map rendering
		not every route
		not every tile
		not constant server-side processing

	it exists for heavier public-interest work:

		refining global statistics
		rebuilding indicators when methods improve
		processing large open datasets
		running public What if scenarios
		modelling heat, shade, pollution, food access, and similar local conditions
		creating calm, predictable ways to pool spare computing power

	the useful framing is:

		we do not need enormous compute
			to keep the map alive

		but if people can safely donate compute
			then the public layers can become much better over time


		the shared compute layer exists for something else:
			refining global statistics
			running heavy analyses that help local communities
			create a calm, predictable way to pool power worldwide

	shape of the system
		small operating system (trimmed MINIX)

			why MINIX?
				free and open-source
				small
				heavily documented
				microkernel-based
				designed around reliability, flexibility, and security

				MINIX 3 is built around a tiny microkernel
					with much of the operating system running as isolated user-mode processes
						keeps the kernel small and services separate
							this contains failure
						avoid unnecessary system power
						make each piece easier to reason about

					MINIX also has unusual educational value
						it's been used for teaching operating system design and has been documented in detail
						large parts of the source have historically been explained alongside the design
						it has papers, notes, books, and examples around it

					that makes it useful for a project where:
						people may want to understand the system
						volunteers may want to audit it
						developers may want to trim it
						AI tools may help explain and modify parts of it
						the operating system should remain legible rather than mysterious

				this is why a trimmed MINIX-like system is appealing
					smaller than a general Linux distribution
					more inspectable than a normal desktop OS
					more purpose-built than asking volunteers to run random services
					more aligned with embedded and appliance-style use

			but, the first implementation does not need to be 'pure'
				it just needs to work
					use POSIX and small utilities
					allow shell scripting
					let people contribute from any ordinary terminal
					keep the core jobs portable across systems
				it can be a little messy at first
					as long as the interfaces stay boring and stable
			eventually become portable

		boots anywhere: spare machine, VM, old laptop, gaming rig, phone (light)
		log in with peaceful passport → node joins the pool

	data, storage, and jobs
		large public dataset repository
		sharded across nodes via torrent-style sharing
		triple redundancy per region
		tasks written in a small functional language
		clear inputs, clear outputs, no surprises
		nodes run tiny slices of global jobs


#### What Is the Compute Pool For?

		shared compute is best suited to jobs that are:

			batchable
			parallel
			public
			reproducible
			slow-tolerant
			useful to many people

			example global jobs
				white roofs and urban heat modelling
				tree cover and planting potential
				heat island maps
				integrations of many datasets to refine indicators
				full re-runs of all indicators when methods improve

		it's definitely not trying to be:
			a real-time cloud provider
			a replacement for all servers
			a marketplace for compute
			a crypto-style mining network
			a way for hardware owners to gain power

			it behaves more like:

				slow but enormous
				resilient
				best-effort
				geographically distributed
				aligned with the people using the system



#### Shape of the Compute Pool

		a person or organisation can donate spare compute

		that might come from anywhere, such as:
			spare machines
			laptops
			desktops
			gaming rigs
			university servers
			donated datacentre machines
			or a phone doing light work

		the node runs a small, constrained environment

			trimmed operating system
			minimal dependencies
			clear job runner
			no unnecessary services

		the person logs in with Peaceful Passport
			not to gain status
			not to earn credits
			not to control the network
			but to make contribution accountable


##### Processing Distributed Data

			the node joins the shared pool
				it receives small slices of public jobs
			it downloads only the datasets needed for the task

			it computes the result
				then returns:
					output
					job version
					input hashes
					method version
					node identity
					runtime metadata

			this way, we can always know:
				what was computed
				from which inputs
				using which method
				under which version
				by which accountable node


##### Designing Distributed Compute Jobs

			job code must be small, declarative, reviewable
			no arbitrary network access
			nodes see only what they need to compute
			prevents harmful or off-purpose workloads

			jobs should have:
				clear inputs
				clear outputs
				no hidden network access
				no arbitrary side effects
				no surprise dependencies
				no private data unless explicitly authorised

			if a job cannot be explained clearly
				it probably should not run on the public pool



##### Deterministic Verification

			determinism is what makes the trust model work

			the same inputs
			with the same method
			under the same version
			should produce the same result

			that means work can be checked
				not by trusting the node
				but by recomputing the job

			this changes the meaning of duplicated work
				duplication is not always waste
				sometimes duplication is verification

			if they agree
				confidence increases

			if they disagree
				the system flags the result
				telling the network that something needs checking here

			the question becomes:
				did someone compute dishonestly?
				did a node fail?
				did the method contain ambiguity?
				did the input dataset differ?
				did the job need stricter reproducibility?


##### Redundant Work

			some work should be deliberately doubled up
				especially:
					indicator refreshes
					statistical rebuilds
					public What if outputs
					high-impact environmental layers
					results that may affect public interpretation
					results used by institutions or local organisers

			possible verification pattern:
				ordinary job
					one node computes
					random spot checks happen later
				important job
					two or three nodes compute independently
					results must match within defined tolerance
				disputed job
					more nodes recompute
					method and inputs are reviewed
					result stays marked as disputed until resolved

			the system does not need to duplicate everything
				it only needs enough overlap
					to make cheating unattractive
					and errors visible

			because anyone can theoretically recompute the work
				fraud becomes fragile

				a false result has to survive:
					open inputs
					versioned methods
					random recomputation
					other nodes
					public inspection
					and future reruns

				that is a hard environment for funny business



##### Peaceful Passport and Accountability

			Additionally, peaceful passport gives identity to contributing compute
				Peaceful Passport gives nodes accountable identity
					it does not make their outputs automatically trusted

				the output is trusted because:

					the job is reproducible
					the inputs are known
					the method is versioned
					other nodes can recompute it
					mismatches are visible

				Passport helps with:

					rate-limiting
					abuse prevention
					reputation for reliability
					pausing bad nodes
					contacting operators when something breaks

				but Passport should not create:

					compute aristocracy
					leaderboards
					voting power
					governance weight
					public status games

				a reliable node can be quietly trusted more
					for scheduling purposes

			but that trust should remain operational, not political, nor for clout or power


##### Local-first Usefulness

			shared compute should help the contributor’s own area first where possible
				if someone donates compute in Perth
					their node may naturally help process:
						Perth map shards
						local heat indicators
						local routing layers
						nearby public scenarios
						Western Australia datasets
				not exclusively
					but preferentially where it makes sense
				this gives contribution a local feeling
					the person is not just helping an abstract global machine
					their computer becomes a small anchor for the place they live
				this also improves the network
					because local compute often pairs naturally with local storage
					the same node might:
						cache local tiles
						pin local datasets
						serve nearby users
						process nearby indicators
						help keep local tools fast

			benefits for normal people
				runs calmly in the background
				helps their own hex first
				shards local map tiles so neighbours see results faster
				their phone and computer become small anchors for their local area



##### Scale and Resiliency

			aim for a million nodes:
				people’s computers
				gaming rigs
				phones (light compute + sharding)
				donated datacentre nodes
			jobs are asynchronous
			cluster remains stable even as nodes join/leave



###### Paid and Donated Compute

					volunteer compute should handle what it can

					but some work needs guarantees

						for example:

							institutional deadlines
							private What if jobs
							large urgent rebuilds
							service-level commitments
							sensitive datasets
							commercial or council work

						those should use:

							dedicated compute
							paid compute
							private compute
							or mixed compute

						the clean distinction is:

							public best-effort work
								can use the shared pool

							private or guaranteed work
								uses dedicated resources

						this prevents volunteer compute
							from becoming an invisible subsidy
							for private institutional needs

						public contribution should improve the commons

						not quietly run someone else’s paid workload



##### Feedback for Contributors

			people who donate compute should be able to see that their contribution was useful
			but it should be private and calm
				for example:
					your node helped refresh heat indicators in this region
					your node helped complete public scenarios this month
					your node helped verify a statistical rebuild
					your node helped serve local shards to nearby users
			this should not become:
				a leaderboard
				a public ranking
				a status badge based on quantity
				a competition

			theme underneath
				people realise:
					a shared compute layer is powerful in its own right
					they are part of something large without effort
				minix-based OS is also personally useful:
					they can run their own small tasks on it
					local workloads can stay local
					phone can connect and treat their machine as a tiny personal cloud
				nothing complex:
					the same OS that powers hexagons.world
					also becomes a calm, private space for people to run things they care about
					without ads, tracking, or noise

			end state
				a shared global compute layer focussed on hexagons.world
				plus a calm personal computer for people themselves
				fast, local, minimal, human
				built on the same microkernel that keeps the whole ecosystem simple


#### Beeswax

		what beeswax is (and isn’t)

			“Beeswax” is a quiet metaphor for shared giving.
			it is a way to talk about:
				donated compute
				donated storage
				donated datasets

			it is not:
				a currency
				a credit system
				a way to earn status or power

			people and organisations give what they can
				because they want to support the commons
				not because anything is owed in return



		shared compute commons

			people and organisations can donate:
				spare CPU
				spare GPU
				spare storage
				public or shareable datasets

			this powers:
				public What if scenarios
				global indicator refreshes
				data preprocessing and cleaning
				heavier background simulations

			the pool is:
				elastic
				best-effort
				built from many small contributions

			it is similar in spirit to:
				Folding@home
				BOINC
				volunteer mirrors
				community-run infrastructure

			no one “gets” anything special for donating
				the work just happens,
				and everyone benefits from better public tools.



		no credits, no scores

			we do not:
				track “how much” each person donated as a score
				show leaderboards
				rank contributors
				tie contribution to voting, influence, or control

			this avoids:
				virtue signalling
				competition and “top donor” games
				wealth or hardware turning into power

			the culture is about "helping if you can"
			not:
				“prove you helped more than others”.



		how contribution is shown

			on a person or organisation profile
				we may show small, optional badges such as:
					🌱 contributes compute
					📦 contributes storage
					📊 contributes data
				also available on people's passports for people contributing
					(organisations shouldn't use passports, they're for people)

			we do not show:
				numbers
				historical totals
				public counters

			the signal is:
				“this person helps keep the lights on”

			not:
				“this person is more important than others”.



		global view

			at the system level
				we may show aggregate figures only, such as:

					“X organisations and Y people donated compute this month”
					“the commons processed N public scenarios this week”

			these are about:
				the overall health of the commons
				the scale of shared work being done

			they are not:
				tables of individual contributions
				or any form of ranking.



		private feedback (optional)

			people who donate compute may see quiet, private notes such as:
				“your node helped complete N public scenarios this month”
				“your donated compute helped refresh heat indicators in these regions”

			these are:
				only visible to them
				not shareable widgets
				not intended as social proof

			the purpose is:
				to show that their contribution was actually used
				without turning it into something to perform or optimise.



		governance stays separate

			governance is tied to:
				peaceful passports
				and whatever voting rules sit above them

			we do not:
				weight votes by any kind of donation
				give extra say to donors
				create proxy or delegated power via contributions

			people who donate compute, storage, or data:
				have the same formal voice
				as everyone else with a passport.



		scheduling and fairness

			public What if jobs:
				run on the shared pool
				on a best-effort basis
				and wait in the queue when the pool is busy

			there are no:
				priority lanes
				paid “fast tracks”
				hidden weighting by donor identity

			if an organisation needs guaranteed



	How else might compute be useful?

		// excess volunteer compute

		purpose
			the core hexagons.world map and public indicators stay free.
			paid layers exist for work that:
				needs heavier computation,
				involves private data,
				or requires dedicated support and uptime.

		summary

			Maps
				calm navigation and local planning.
				base map, simple routing, and local tiles are free.
				a small subscription covers:
					deep custom routing,
					full offline regions,
					and heavier comfort/safety workloads.

			API
				small, boring place-and-statistics + tiles API.
				generous free tier for students, open-source, and small apps.
				usage-based pricing close to raw cost at scale.

			What if – Public
				scenario builder over public indicators and datasets.
				runs on the shared volunteer compute pool.
				flat personal / organisational subscriptions,
					no per-job billing.

			What if – Private
				the same recipes and diagrams,
				but with your own datasets and private compute.
				organisational subscription + neutral compute top-ups,
					for councils, NGOs, and teams with sensitive data.

		principles
			paid tools:
				exist to cover running costs and create donations
				do not control governance,
				and do not lock in data.
			people can:
				start on the free layers,
				move into paid offerings when their work demands it,
				and step back out without losing their maps, recipes, or results.





### Maps

	we will build the best maps app
		useful
		local
		yours

	it sits on the same hexagons.world grid and statistics
		but feels like a calm, personal tool
			for navigating a more local world

	most maps applications are not really yours
		you use them every day
		but you do not control how they look
		how they behave
		or what they optimise for

	the problem is not only features
		it is incentives
			the map provider decides what matters
			the user adapts afterwards
		when a large map changes its colours, routing, or interface
			people often hate it
			but they have almost no recourse
		they can complain
			or leave
		but leaving usually means giving up things they have come to rely on

	open alternatives help
		but they usually do not yet feel complete enough
			they may be admirable
			and more ethical
			but still miss the polish, speed, or practical layers people expect
		so most people remain inside tools they did not choose in full

	the result is a strange relationship
		maps are among the most intimate tools people use
			where they walk
			where they meet
			how they get home
			what they notice around them
		but the experience is centrally decided
			not locally shaped
			not personally owned
			not meaningfully adaptable

	we want to build the best maps application
		not just a good one
		not just a private one
		but one that is genuinely better to use



#### What a Better Map Should Be

		a better map should not just be:
			open
			private
			or well-intentioned
		it has to work well enough that people actually keep using it

		it should be:
			clear
			fast
			private
			customisable
			locally useful
			reliable offline
			and pleasant enough to open every day

		the map should feel like a tool you control
			compared to a service that keeps changing around you


##### Why Current Maps Feel Frustrating

			most people rely on maps constantly

			they use them to:
				get home
				meet friends
				find shops
				check transport
				walk at night
				travel somewhere unfamiliar
				plan errands
				avoid getting lost

			but the experience is mostly decided elsewhere

				users usually cannot control:
					major interface changes
					colour changes
					routing assumptions
					which places are emphasised
					how much visual clutter appears
					what data is collected
					or how local information is ranked

				when a big maps app changes something
					people may dislike it
					but often keep using it anyway

				because switching maps usually means losing:
					search quality
					routing quality
					saved places
					place data
					transit information
					and general reliability

			open-source alternatives are important
				but often still feel incomplete for everyday use

			so the aim is not:
				“an ethical map that people tolerate”

			the aim is:
				a map people prefer using




##### Customisable by Default

			people use maps in different ways
			so there shouldn't be one fixed default for everyone

			a person should be able to choose:
				how much detail appears
				which colours are easiest to read
				which layers are shown first
				what kinds of routes they prefer
				how much movement or animation the app uses

			examples:

				e-ink mode
					high contrast
					low detail
					clear outlines
					no colour-dependent information

				night mode
					lower glare
					clearer route lines
					lighting and safety layers easier to see

				field-work mode
					terrain
					access tracks
					land use
					boundaries
					facilities

				cycling mode
					incline
					surface quality
					protected lanes
					traffic stress
					shade

				low-bandwidth mode
					cached tiles
					simpler graphics
					less live data
					still usable offline



			there is no single best map view
			there are many good ones
			and people should be able to shape the one they live with

				customisation shouldn't mean endless settings
				but instead,
					a few clear presets
					with simple controls
					that let the map fit the person’s life
				and then they can tailor them to how they see fit




##### Deterministic Routing

			the fastest route is not always the best route

			hexagons.world already provides a rich local layer
				common addressing
				local indicators
				place-based statistics
				and a shared reference for what is happening where
			that gives us a base most maps do not have
				a map is not just roads and search
				it can also understand context
				texture
				local conditions
				and what people nearby actually care about

				with volunteer compute and open data
					we can support useful routing layers that are normally ignored
				for example
					shade on the way home
					lighting at night
					daytime heat retention
					local quietness
					or comfort by time of day
				some of this can come from
					satellite imagery
					thermal readings
					lighting data
					land cover
					footpath and tree data
					local contributions
				some can run on-device
					where privacy or responsiveness matters
				some can run through distributed compute
					where heavier shared processing is useful

			this is in opposition to one hidden system deciding the “best” route
				people should be able to combine clear building blocks
					more shade
					more lighting
					less traffic stress
					more hills
					flatter paths
					quieter streets
					better footpaths

			this is especially useful for:
				women walking at night
				children and teenagers
				older people
				people with a disability
				cyclists
				people walking in hot weather
				people carrying groceries
				people who are tyred or stressed
				people in unfamiliar areas

			this matters because preferences are highly personal
				one cyclist may want more hills in the morning
					to push harder and wake up properly
				the same person may want a flatter route home in the evening
				another person may prioritise benches
					water
				or smooth surfaces

				deterministic here does not mean rigid
					it means understandable
					composable
					and stable
				people should know why a route appeared
					what tradeoffs produced it
					and how to change it

			a route should explain its tradeoffs
				for example:
					“3 minutes longer, but more lighting”
					“slightly longer, but more shade”
					“avoids steep hills”
					“uses quieter streets”
					“fewer road crossings”
				this makes routing feel understandable instead of mysterious

			this lets the map answer questions that are quietly important
				not “what is the fastest route?”
				but:
					what feels safest tonight?
					what keeps me coolest in summer?
					what route is nicest when I am tyred?
					how do I get home in a way that feels good?

			therefore, a person should be able to adjust the route without fighting the app


##### For Local Communities

			a better map should show what is useful nearby

				not only:
					major businesses
					highly ranked places
					paid listings
					or globally popular results

				it should make local things easier to find:

					libraries
					public toilets
					water fountains
					community centres
					parks
					shaded areas
					free buses
					food banks
					community meals
					repair cafés
					local clubs
					quiet study spaces
					safe meeting places
					cheap local food options

				many useful things already exist
					but are hard to discover

				they may be on:
					council websites
					paper posters
					Facebook pages
					church newsletters
					student noticeboards
					old PDFs
					or word-of-mouth

		you can begin to ask
			would people in this area support better lighting here?
			do people repeatedly choose this shaded corridor?
			where are the quiet routes people already trust?

		this makes maps more than navigation
			they become a way of noticing what local life needs
		not in an abstract way
			but directly through movement
			preference
			and everyday use


##### Private by Design

			maps reveal sensitive parts of life

			they can show:
				where someone lives
				where they work
				where they worship
				where they get help
				where they recover
				who they visit
				what routines they follow

			so the default should be:
				minimise tracking
				process locally where possible
				store less
				sync only what is needed
				make sharing deliberate

			personal route preferences should be private
			saved places should be exportable
			local caches should work without needing an account

			Peaceful Passport can be used where identity is useful
				such as RSVPs
				vouching
				or contributing edits

			but ordinary map use should not require
				constant identity



##### Calm Vibe

			the app should be easy to read quickly

			it should avoid:
				visual clutter
				constant popups
				ads
				engagement tricks
				unnecessary notifications
				dark patterns
				sudden redesigns

			the map should prioritise:
				streets
				paths
				labels
				route clarity
				local facilities
				and whatever layer the user has chosen

			if someone opens the app while stressed
				it should help them decide what to do next
				not add more noise


##### Works Offline

			a useful map should keep working when the internet is bad
				people should be able to download their neighbourhood, campus, town, or a travel area
			in fact, our app makes you download the map to their device
				local nodes can help with this
					a campus, library, council, or community server
						can keep local map data available nearby

			this makes the map more reliable
				in places where mobile data is expensive
				or inconsistent



##### Optional Paid-tier Using Distributed Volunteer Compute

			pretty much everything that can run on someone's device, should run on their device
				and is completely and entirely free
					deterministic routing
					local information

			we will charge one dollar per month
				and make it feel like one dollar a month everywhere
					adjusted into local currency
						(i.e - 1 ringit, one euro, one australian dollar)
			for features that could use the global compute pool to create donations for useful features
				for example:
					deeper route personalisation
					shade-first routing
					multi-stop errands
					comfort-aware routing
					advanced personal layers
					heavier recomputation
			(these would feed into the undercurrent, expanded in the peaceful foundation people section)


##### The Aim

			the aim is to build a map that is:
				good enough to replace normal maps for everyday use
				private enough to trust
				customisable enough to fit different lives
				local enough to show what people usually miss
				calm enough to use when stressed
				and open enough that people are not trapped

			it should help people:
				get around
				find useful local things
				move more safely
				avoid unnecessary stress
				and understand their area better

			not by asking them to join a platform, but just by being a better map





#### As an app

		the app should already do almost everything most people need
			and do it privately
			and do it calmly
		for most everyday use
			that means a clear base map
				directions for walking, cycling, driving, and transit
				offline tiles for your local area
				and local layers such as events and council facilities
		none of this should feel special
			it should just feel like a competent map
			that works properly
			without ads, tracking, or engagement tricks

		a lot of the value is in the small touches
			not because they are flashy
			but because maps are habitual tools
		if the colours are slightly harder to read
			you feel that every day
		if the map keeps foregrounding the wrong things
			you feel that every day too
		so a good map should let people set a few simple preferences
			and then mostly forget about them
		what matters is not endless tweaking
			but the feeling that the map quietly fits you

##### Customisable

			maps should not be stock-standard
				people move through the world differently
				so they should not all inherit the same defaults
			someone should be able to set:
				how the map looks
				how routes are preferred
				what layers appear first
				and what kinds of places or conditions matter more to them

			this begins with appearance
				map appearance is not fixed
				because legibility is not fixed either
			some people need high contrast for work
				quick reading
				stable colours
				clear visual hierarchy
			others want softer palettes in the evening
				or warmer tones for walking days
			the point is simple
				a map should be easy to read in the conditions people actually use it in
				not only in the designer’s preferred view

			it also extends to overlays
				because different people are looking for different things in the same place
			one person may care about tree cover and shade
				especially in summer
			another may care about heat, noise, or event density
			another may want council facilities surfaced clearly
				libraries
				pools
				community centres
				BBQs
				free buses
				shuttles
			these layers should be easy to toggle
				easy to combine
				and easy to ignore when they are not useful

			customisation should also shape routing
				not just appearance
			people should be able to express practical preferences
				avoid hills over a chosen gradient
				avoid carparks after dark
				show local co-ops and repair cafés before big chains
			these are not exotic requests
				they are ordinary differences in how people live
			a map becomes much more useful
				when it can reflect those differences directly

###### Who It Really Helps

				this matters most for people who rely on maps heavily
					not just people checking directions occasionally
				for some people
					a map is a constant background tool
				and small improvements compound quickly

				people whose work depends on maps
					drivers
					couriers
					mobile technicians
				benefit from stability first
					high-contrast colours
					clear hierarchy
					and routes that respect time, fuel, and stress
				they do not need novelty
					they need something readable
					predictable
					and fast to parse

				people on foot or bike often want something different
					comfort matters at least as much as speed
				quiet streets
					shade
					gardens
					footpaths
					protected bike lanes
				can matter more than shaving off a minute
				for them
					the best route is often the one that feels nicest
					or safest
					or least draining

				people running errands and ordinary life
					groceries
					chemist
					post office
					library
				need the map to support sequences of movement
					not just isolated trips
				they are often planning within walking distance
					or around what they can carry
					or around a day that does not assume a car
				a better app helps life fit together
					not merely travel happen

				people who want calmer and safer movement
					especially at night
				need something else again
					routes that reflect how places actually feel
					not only how roads are classified
				the route people are willing to take after dark
					is often not the nominally shortest one
				a better app should understand that
					and make it easy to act on it



#### Useful features

			a better maps app should not only help people get somewhere
				it should help them move through a place well
			that means:
				showing paths that make local movement easier
				understanding transit as part of ordinary life
				and describing places in ways that are actually useful
			the goal is not feature accumulation
				it is a calmer and more truthful experience of place

##### Walking and Cycling Paths

				walking and cycling are where many maps still feel thin
					especially compared with what people actually need in daily life
				the obvious road route
					is often not the best route on foot
					or by bike
				small connectors matter
					footpaths
					laneways
					cut-throughs
					trails
					quiet side streets
					protected bike links
				these are often the parts of a city
					that make local life feel possible without a car

				this is one of the quiet strengths of openstreetmap-derived systems
					they are often better at the fine-grained texture of movement
				not because they are magical
					but because people on the ground add the paths they actually use
				that means the map can become closer to lived reality
					especially for:
						walking
						cycling
						campuses
						inner suburbs
						town centres
						parks
						and everyday local travel

				a better maps app should take these paths seriously
					not treat them as secondary to roads
				for many people
					the useful question is not:
						what is the fastest route a car could take nearby?
				but:
					what is the nicest route on foot?
					what is the safest route on a bike?
					where is the shaded path?
					where is the quiet way through?
				this is where maps start to feel like they understand human movement
					rather than just transport infrastructure

##### Public Transit

				public transit should not feel bolted on
					or like a fallback for people who do not drive
				for many people
					transit is the structure of everyday movement
				but the useful journey is rarely just:
					stop
					line
					stop
				it is usually:
					walk there
					wait there
					change there
					finish the last stretch somehow

				a better maps app should understand the whole trip
					not only the formal transit segment
				that means helping someone see:
					how far the walk really is
					where the awkward transfer is
					where there is shade or shelter
					where the last stretch becomes unpleasant
					where several errands fit naturally into the same trip

				the best transit integration feels like the map understands the network
					not just the timetable
				it helps people think with transit
					rather than merely receive transit directions
				that is especially important in local life
					where people are not only commuting
					but combining:
						work
						groceries
						libraries
						post office
						childcare
						and meeting others
				a map becomes much more useful
					when transit is treated as part of everyday life
					rather than a separate mode pasted onto the side

##### Vibes Instead of Reviews

				most review systems flatten places too harshly
					a single number collapses too much reality
				restaurants are not one-dimensional
					food
					price
					service
					cleanliness
					speed
					atmosphere
					noise
					portion size
					dietary options
				a rating of "4.2”
					hides all of these trade-offs
				it tells you very little
					except where something sits inside a ranking culture

###### Criticisms of Star-based Restaurant Reviews

					a single number collapses everything
						different experiences become indistinguishable
					good food and bad service
						and average food with friendly staff
					end up flattened into comparable scores
						even though they are different kinds of place

					ratings punish the wrong things
						people rate from mood
							expectation
							price sensitivity
							or one bad incident
						not from any stable standard
					cheap places are often dragged down
						when compared unfairly with expensive ones
					and serious issues get misclassified
						a hygiene or safety problem
						is not the same thing as “bad restaurant”
					but the system pushes everything into one bucket

					averages create harsh cliffs
						people think in thresholds
							not gradients
						4.5 feels good
						4.0 feels uncertain
						3.5 feels bad
					small differences start to feel socially enormous
						and dropping below a visible threshold can damage a place badly
					this creates fear for owners
						and a harsh comparison culture around ordinary local businesses

					reviews become something to manage
						rather than something to learn from
					places start chasing ratings
						requesting positive reviews
						filtering unhappy customers
						smoothing perception
					fake or inflated reviews emerge
					and the focus shifts
						from improving the place
						to protecting the score

					early reviews lock perception
						the first 20 to 50 reviews
						can shape long-term reputation
					it becomes hard to recover from early negatives
						even when the place improves
					the rating looks stable
						but the reality underneath may have changed completely

					outliers distort meaning
						1-star outrage
						5-star hype
					enter the same average
						even when they refer to totally different kinds of experience
					the system cannot distinguish severity
						or type
					a safety issue
						and a moment of enthusiasm
					should not be treated as equivalent inputs

					stars also discourage nuance
						people stop describing what a place is like
						and start reducing it to symbols
					rich detail gets lost
						price
						portion
						atmosphere
						context
					which is exactly the information other people actually need

					the deeper problem is that stars do not match real decision-making
						people choose based on situation
					cheap meal
						date night
						quick lunch
						dietary needs
						somewhere open late
					a single rating does not answer these questions
						so the format is misaligned with actual use

###### Better System: Describing Instead of Ranking

					the map should help people understand places
						not rank them globally
					that means characteristics should replace scores
						or at least come first
					a place can be described by:
						price level
						portion size
						food style
						speed
						vibe
						dietary options
						noise
						whether it suits groups or quick stops
					this makes trade-offs visible
						which is what people actually need in practice

					critical flags should stand apart clearly
						not disappear into an average
					hygiene problems
						safety issues
						accessibility problems
						misleading behaviour
					should be shown directly
						and unambiguously
					these are not “part of the vibe”
						they are important facts

					short situational summaries are often more useful than scores
						cheap and filling
						slow but high quality
						busy at lunch
						student spot
						open late
					these phrases help someone understand a place quickly
						in a way that is much closer to real choice

					local context should also be visible
						surfaces everyday places
							family-run places
							student spots
							late-night options
							quiet local favourites
					without ranking them against abstract global standards
					the point is not:
						is this one of the best restaurants in the world?
					but:
						is this the kind of place I want right now?

					written reviews can still exist
						but as optional depth
					stories
						edge cases
						specific experiences
					should be preserved
						not collapsed into a single number
					that keeps nuance available
						without making it the whole interface

###### Simple but Honest Trade-off

						stars succeed because they are simple
							fast to scan
							low effort to understand
						but they are simple by flattening reality
							which is exactly the problem

						characteristics are richer
							and more truthful
						but they must still remain legible
							at a glance
						so the design challenge is:
							keep clarity
							without collapsing everything into one ladder

						that probably means small visual language
							little logos
							short descriptors
							clear flags
						so someone can see quickly
							what a place is like
							and choose based on what matters to them

				end point

					the goal is not to rank places
						but to understand them
					show what a place is like
						not how it compares globally
					highlight what matters
						not what averages out
					and let people choose based on their situation
						not a number



#### Local directories and fulfillment

			joke reference cool thing: fulfillment isn't something you buy, and it's not centreed on one place

			a good local map should help people find what already exists
				not only route them between places they already know
			a lot of local life is technically visible
				but practically hidden
			it sits across:
				old council pages
				scattered websites
				group chats
				noticeboards
				Google results
				and people’s memory
			the problem is often not that a place lacks useful things
				but that they are hard to discover
				hard to compare
				and hard to fit together

			this matters because local life is not one destination at a time
				it is usually a chain of small needs
			groceries
				post office
				chemist
				library
				somewhere to sit
				somewhere to eat
				somewhere to fix something
			these things already form a pattern in people’s day
				but most maps still treat them as separate searches
			a better map should help them cohere
				so the area around someone starts to feel usable
				rather than merely searchable

##### Errand Planner

				an errand planner is one of the simplest ways a map can become more helpful
					not by being dramatic
					but by reducing friction in ordinary life
				it should group errands in a way that respects:
					time
					stress
					transport method
					and what someone will actually be carrying
				the best route for a person on foot with groceries
					is not the same as the best route for a cyclist
					or a parent with a pram
					or someone ducking out between other obligations

				this also creates room for local preference
					the planner can favour nearby places
					co-ops
					repair cafés
					or small local businesses
				not because the system is moralising
					but because many people would prefer to support what is near them
						if the map made it easy enough
				a map becomes much more useful
					when it helps daily life fit together in one legible plan
					rather than leaving people to improvise from four tabs and three apps

##### Local Guidance

				the map should also help explain what “local” means in practice
					because local life looks different in different places
				in one region
					local may mean a walkable strip of shops
				in another
					it may mean a town centre plus a weekly market
				in another
					it may mean a few recurring places spread across driving distance
				the point is not to impose one idea of local
					but to make each local pattern more visible

				this is especially useful for recurring things
					markets
					repair days
					community meals
					pop-up services
					seasonal events
				these often matter more to daily life
					than permanent listings alone
				but they are also easier to miss
					because they sit in weak local channels
						Facebook pages
						posters
						group chats
						council calendars
				a better map should help people notice what is already happening
					before adding more noise to the place

##### Council and Facility Integration

				council and civic facilities are often more useful than they seem
					but also more hidden than they should be
				libraries
					pools
					community centres
					shaded parks
					public toilets
					fountains
					BBQs
					free buses
					shuttle routes
				are not glamourous features
					but they shape whether a place feels liveable
					especially for:
						children
						older people
						students
						people without cars
						and anyone trying to spend less money

				these kinds of facilities should sit naturally inside the map
					not buried in PDFs
					or fragmented across bad council interfaces
				when a person can actually see:
					where the fountain is
					where the toilets are
					where the library is
					where there is shade
					where the free bus runs
				the area starts to feel more supportive
					and more human
				that is part of what a local map should do
					not just represent a place abstractly
					but make it easier to live there

##### Businesses

				local businesses should also be represented in a more useful way
					not merely as names on a commercial layer
				for many people
					the useful question is not just:
						is there a café here?
				but:
					what kind of café is it?
					is it open?
					is it cheap?
					is there seating?
					does it have the kind of food I want?
				even simple things like café menus
					can make a map much more practical
				because they turn a place from a pin
					into an actual option

				this matters more in local life than in destination travel
					people making everyday decisions
					often do not want generic prominence
				they want:
					what fits
					what is open
					what is nearby
					what makes sense right now
				a better local business layer should help with that
					without turning the map into an advertising marketplace

##### Programmers and Volunteers

				a lot of this layer can be built gradually
					through open data
					small parsers
					local tagging
					and practical contributions
				programmers and volunteers do not need to solve everything at once
					they can create minimal ways of pulling useful data from places
						where allowed
					import open data
					and tag facilities into hexes
				this work is not glamourous
					but it is exactly the kind of work
					that makes a map feel grounded and alive

				it also suits the structure of hexagons.world
					because the work can accumulate locally
				one area gets better library data
				another gets markets and repair days
				another gets better walking links
				another gets café menus and local notes
				the result is not one giant central database arriving complete
					but a map that gradually becomes more useful
					as people add the kinds of detail that actually matter where they live

##### End Point

				this lets people see what their area already offers
					before assuming nothing is there
				and where gaps are obvious
					quiet pressure can build for better local life
				the point is not only information
					it is legibility
				a better local map makes a place easier to understand
					easier to use
					and easier to care about


#### Rocky

			similarly to Clippy in the context of reasonable.diet, Rocky is a small programmable helper
				Rocky wants to help you sniff out your local community
				and, for you to go on an adventure with your dog
					as dogs collectively cannot believe that we're not exploring more of the world around us

			Rocky exists to make the map more personal
				not by becoming a personality
				and not by pretending to be intelligent in a vague way
			the point is much simpler
				people should be able to define what “better” means for them
					in a clear
					local
					and understandable form
			for one person
				better may mean:
					avoid stairs on weekday mornings
					prefer shade between 10am and 3pm
					avoid school zones at pickup time
			for another
				it may mean:
					prefer routes with trees and back streets
					avoid carparks after dark
					bias toward quieter streets
			these are small preferences
				but they shape whether a route actually feels good

			the important thing is that Rocky does not guess
				it does not invent a hidden profile of the user
				and it does not quietly optimise on their behalf
			people tell Rocky what matters
				and Rocky applies those preferences openly
			that makes the relationship much calmer
				because the map is not pretending to know better
				it is simply helping someone express what they already know about themselves

			this uses the same tiny shared functional language
				as Reasonable.Diet
			that matters because the preferences stay:
				declarative
				safe
				local to the user unless shared
				and stored on-device
			the user is not managing a maze of settings
				or training a mysterious assistant
			they are just writing down
				in a small and inspectable way
				what kind of movement feels better to them

			Rocky then turns those preferences into scoring functions for routes
				not AI drama
				not chatbot theatre
				not a black box
			just a clear layer
				that rewrites how routes are ranked
				and lets people understand why a route appeared
			if a route is favoured because it has more shade
				or fewer stairs
				or quieter streets
			that should be legible
				not hidden inside a system that only outputs answers

			this also means Rocky can stay modest
				it does not need to speak constantly
				or interrupt
				or perform friendliness
			it can simply sit there as a tool
				helping someone gradually shape the map
				until it fits their life better
			in that sense
				Rocky is less like an assistant with agency
				and more like a small layer of programmable preference
					with a friendly face

			some of these preferences are cheap to apply
				others require real computation
			especially when they interact with:
				shade
				heat
				lighting
				time of day
				or more complex route trade-offs
			but that is a compute question
				not a product philosophy question
			the product philosophy stays the same
				the user defines what better means
				the system applies it clearly
				and the route becomes something closer to their own judgement
					than a generic verdict from above



#### Serendipity

			a good map should leave room for small pleasant surprises
				not because surprise is a product feature
				but because local life is often richer than the shortest route suggests
			most maps are built to remove uncertainty
				which is often useful
			but in doing so
				they can also flatten the experience of moving through a place
			every route becomes a corridor
				and everything nearby becomes background

			Serendipity is a small corrective to that
				not by interrupting people
				and not by trying to maximise engagement
			just by occasionally noticing:
				there is a quiet garden if you detour two minutes
				you are walking past something happening nearby
				this route is shaded for most of your walk
			these are not recommendations in the aggressive sense
				they are gentle observations
			the map is not trying to capture attention
				it is just helping the world feel a little more present

			this matters because local life is often already there
				people just do not notice it
			a hidden garden
				a small event
				a nicer side street
				a patch of shade
				a public bench
				a quiet place to pause
			these things can make a place feel much more alive
				but only if they surface at the right moment
			not as content
				but as possibility

			the tone matters a lot
				Serendipity should not feel gamified
				or persuasive
				or needy
			no streaks
				no points
				no pressure
				no “people also visited”
				no manipulative framing
			just simple, human-scale suggestions
				that can be turned off entirely
			if someone wants a pure routing tool
				they should have one
			if they want a map that occasionally helps them notice something nice
				they should have that too

			in this sense
				Serendipity is not really about novelty
			it is about helping people recover a slightly more local way of moving
				where the world is not only a set of destinations
				but also a field of small possibilities
			the map does not need to make life exciting
				it only needs to make it a little less flat


#### $1 per month

	most of the map is free
			because most of what people need can already run on-device, privately and often offline

		but some kinds of routing do create real compute cost
		deep personalised routing
			well-lit paths at night
			shade-first maps at high resolution
			multi-stop errands with many constraints
			and regular recomputation as new data comes in
		all require more than a quick local calculation
			especially when they incorporate:
				time of day
				heat
				lighting
				surface quality
				errand sequencing
				or shared environmental modelling
		these sit in a paid layer:
			$1 per month
			or whatever feels like $1 where people live
			the same price everywhere in emotional terms, not currency terms


##### Compute Integration

			the global volunteer compute pool can run:
				shade modelling at high resolution
				urban heat and cool islands
				incorporating global satellite data
				beautiful route selection
				heavy errand-sequencing tasks
			these deeper jobs do not need to run from scratch for every person
				they can run asynchronously on shared compute
				results flow back into everyone’s maps
				and are cached for reuse
			that keeps the system efficient
				and makes the heavier work collectively useful
				rather than wastefully duplicated

			on-device
				short and medium routes can usually run fully offline
				with privacy preserved by default
			longer or more complex routes
				can be sketched locally
				with shared compute refining the heavier edges
			this keeps the whole thing:
				fast
				private where possible
				and deeper where useful

###### Routing and Comfort

				free routing
					short and medium trips
					computed entirely on-device where possible
					basic comfort rules still applied
				the free layer should already feel complete
					for ordinary daily use

				the paid layer is where routing becomes deeper
					not merely more
						complex multi-stop errands
						heat-aware and shade-first paths
						night-safe walking routes
						cycling with fewer cars and better surfaces
				this is where the map does heavier reflective work
					based on richer and more demanding prefences and environmental inputs

				that also allows more detailed programmable preferences
					avoid elevation above a chosen threshold
					avoid steep downward slopes when raining
					prefer gardens or river paths when time allows
					avoid areas flagged as unsafe at night
					avoid industrial shortcuts and carparks
					prefer local shops instead of chains within a chosen detour
				these are not different in kind
					from the simpler preferences elsewhere in the app
				they are just more computationally expensive
					when combined with changing conditions
					and the full route graph

		the important thing is that the pricing stays honest
			people are not paying for artificial scarcity
			or for a deliberately weakened free product
		they are helping cover the genuinely heavier layer
			while keeping the broader map:
				free
				calm
				privacy-safe
				and widely usable


#### An Amount as a Frictionless-agree
			≈ 0.5%–1% of a typical daily wage
       				rounded to a common small denomination.
       				plus market clustering
       				- one euro
       				- one pound
       				- one *(five halalas as the feeling)* riyal
       				- 10k rupiah
       				- 50k peso
       				- 10 lira

			the point is not precision
				it is that the amount should feel negligible
				and ordinary
				in the place where someone lives


			this matters because one dollar a month
				does not feel like ordinary software pricing
			it feels more like:
				a contribution
				a tip
				a membership
				a quiet way of keeping something useful alive
			that changes the relationship completely
				especially when the map is already useful
				and the operator is clearly non-extractive
			people are not being cornered into paying
				they are opting into the heavier shared layer
				while the core map remains free for everyone



	end state is that Maps becomes

		a calm, modular, human-centred navigation system
		tuned to each person,
		deeply local and quietly supportive,
		refined by shared compute,
		offline-first and privacy-safe,
		and optionally, costing about a single dollar a month, everywhere.












### Application Programming Interface

an application programming interface (commonly referred to as an API) is ...

although anyone can run the deterministic and manual datasets themselves,
	most developers just want a small, boring API:
		a place-and-statistics endpoint
		and a map-tiles endpoint.
	hexagons.world offers both.


the main aim is getting more people using hexagons

	building different things



#### First use and developer experience

			the first request does not require an account or key.
				people can paste a curl example from the docs
				and immediately see:
					a hex name,
					its level and location,
					and a small statistics sample.

			this open first request is intentional:
				it shows what the system is for
				without any sign-up wall,
				and keeps the first-time developer experience calm and quick.


#### Free tier

			each key includes a generous free allowance
				on the order of 100k data requests per month.

			this is enough for:
				student projects,
				open-source tools,
				small production sites,
				and modest apps.

			per-request cost
				a typical data request costs roughly:
					about 0.000002 cents in infrastructure
					(ten-millionths of a cent per call).

				at that rate:
					100k free requests ≈ 0.2 cents of raw cost,
					and 1,000 developers each using their full free tier
						≈ a couple of dollars of raw API work,
					before we add any safety margin.

			this means:
				we can comfortably offer the free tier
					to hundreds or thousands of developers,
				so people can try ideas, build small tools,
					and teach with the API
				without the project being under financial strain.




#### hexagons/data

	First, a data API. Its job is to turn coordinates, hex IDs, and place references into stable identifiers, names, geometry, and per-hex indicators. The notes already define the rough shape: point to hex, hex to point or bounding box, hex to neighbours, and hex to core indicators plus uncertainty. It should be deterministic, low-latency, human-readable JSON, and avoid hidden composite scores. It should only return place data and aggregated per-hex statistics, not broad regional modelling or heavy “what if” workloads.

		hexagon to coordinates

		coordinates to hexagon

		statistics and uncertainty

		purpose
			turn “where” into:
				hex IDs
				human-readable names
				per-hex statistics.

		endpoints (shape, not syntax)
			point → hex
			hex → point / bbox
			hex → neighbours
			hex → core indicators + uncertainty.

		behaviour
			deterministic and cacheable
			low-latency
			small, human-readable JSON
			no hidden composite scores.

		scope
			place data and aggregated per-hex statistics only.
			large-area aggregations and “what if” workloads
				live in the What if section,
				not the core data API.


#### hexagons/tiles


		purpose
			serve tiles that make hexagons and indicators visible on a map.


	The “best” way is not to send images, but to send instructions + data and let the client draw the map.





		behaviour
			pre-rendered raster tiles for most use
			optional vector tiles where needed
			designed to work on:
				low-bandwidth links,
				older phones,
				e-ink devices.

		scope
			tiles expose:
				hex boundaries,
				indicator buckets,
				basic labels.
			precise values still come from the data API,
				not from reading tiles back.




			server sends:
			hex IDs
			styles
			rules
			client generates the map

			Pros

				extremely lightweight
				aligns with your deterministic system
				almost zero bandwidth for large areas
				perfect for e-ink / low-power

			Cons

				requires custom renderer
				harder to standardise
				more work upfront





#### Static hexagons as a service

		// apis usually having to compute live data
		// hexagons is entirely static




##### Running Costs

			per-request cost
				individual calls are extremely cheap,
					on the order of 0.000002 cents per data request.

			platform cost
				the real expense is the platform around them:
					warm datasets and caches,
					global edge access,
					monitoring,
					backups,
					and some headroom for bursts.

				we assume:
					roughly a few hundred USD per month
					to keep the API healthy at global scale,
					budgeting around $400/month
						as a comfortable target that covers:
							core infrastructure,
							thousands of free-tier projects,
							and room for growth.


##### Authentication


			anonymous access
				small per-IP limits:
					enough for exploration, demos, teaching, and tests.
				soft rate limiting protects the API from obvious scraping and loops.

			keys
				one key per project.
				higher, predictable limits.
				clear usage graphs and email alerts when use spikes.

			protections
				rate limits and simple behavioural checks
					to catch automated sweeps and abuse.
				no invasive device fingerprinting,
					just enough to keep the service healthy
					while respecting privacy.




##### Pricing

			usage-based
				billing is metered on actual requests,
					with separate meters for:
						data calls,
						tile requests.

			calculation
				each billable unit is priced as:
					the measured per-request cost
					plus a small markup (around 6-10%),
					with that percentage decreasing at higher volumes.

			result
				small projects pay little or nothing.
				mid-scale projects pay a few dollars a month.
				heavy users pay close to raw cost at scale,
					without surprises or complex tiers.


				intent

					the API should feel:
						simple to try once,
						safe to build real software on,
						and boringly predictable if you're paying.

					running the API is treated as:
						shared infrastructure for hexagons.world itself,
						for other Peaceful Foundation projects,



### What if? - Private


	a general-purpose scenario tool
		built on a pool of compute, standardised inputs, and deterministic hexagon layers
		anyone can use it to run simulations, forecasts, or what-if scenarios
			across environmental, social, economic, and operational domains
		from local organisers to small businesses to universities
			to explore how changes might affect real-world outcomes
		an extremely adaptable resource that continues to get better

	what it is
		the same calm infrastructure as public What if
			same hexagons, recipes, flow diagrams, and versioned methods
		but inside a private workspace
			where you bring your own data,
			run on dedicated compute,
			and keep everything compliant and explainable

	why it exists
		public What if is enough for many people
			students, researchers, non-profits, local organisers
		but some organisations:
			handle private data,
			need predictable turnaround,
			or must show clear audit trails to funders and regulators
		these groups are usually caught between:
			heavy GIS stacks,
			custom consultant tools,
			and nothing at all
		this is the middle ground:
			the same calm interface,
			but with your own data,
			isolated compute,
			and clear compliance

	data and permutations
		the system can import many kinds of data
			geospatial, geothermal, statistical, physical, environmental, operational
		much of it is sharded globally
			computers that hold certain data types can run computations on what they have
		this creates endless useful permutations:
			satellite imagery + heat + well-being indicators,
			census + local surveys + transport access,
			physics simulations + land-use + building stock,
			sensor networks + vacancy rates + social outcomes
		we define the operations through the same small functional language
			so the environment stays controlled and inspectable
		we cannot predict every use
			the tool becomes more versatile as more datasets intersect
		if an organisation wants to contribute data to the pool
			it can be made public where relevant
				improving estimates for everyone
			or kept private inside their workspace
		this also creates another way to support the project:
			useful private sequences and recipes
				eventually help refine what the public layers can do


#### Elastic compute pool

		all compute sources form a single shared resource layer
			public compute,
			private infrastructure,
			volunteer nodes
		workloads are scheduled across them
			based on data sensitivity, job size, runtime needs, and availability
		this turns globally distributed machines into a calm, elastic fabric

		global datacentre capacity
			high-reliability machines in managed infrastructure
			used for private workloads, larger simulations, and predictable scheduled jobs

		volunteer compute pool
			idle machines donate capacity:
				spare GPUs, gaming PCs, home servers, unused workstations
			these run non-sensitive workloads, public-data simulations, and low-priority background jobs

		organisations donating resources
			a systems administrator runs a provisioning script or installs a small worker service
			the worker reports available CPU, GPU, memory, storage, reliability, and utilisation
			integrates with Xen, ESXi, Hyper-V, KVM, and container clusters
			the node joins the pool
			another quiet way to donate to the commons

#### Who is this for

		local councils
			staff who need a live map of their area,
			basic indicators already prepared,
			and a way to test ideas without learning full GIS
		community organisations and researchers
			people who collect surveys, service data, or case notes,
			have a sense of "what might help",
			but struggle to pull data into one place, run scenarios, and show funders clear before/after views
		smaller companies and services
			for example:
				a plumbing company that wants to see where jobs cluster,
				optimise routes,
				and spot streets with repeated failures
			they do not want geospatial tooling
			they want a map, a few sliders, and clear outputs they can act on


##### What Organisations Get

			private workspace
				the same hexagons, indicator layers, recipes, and flow diagrams as the public system
				but with your own datasets attached
			own data
				upload:
					surveys and research datasets,
					service usage logs,
					sensor readings,
					internal spreadsheets and reports,
					address or point data
				address and point data is automatically aggregated to hexes
					with masking where needed
				private datasets:
					stay inside your workspace,
					are never written back into the shared public indicators,
					and never leave the environments you choose
			shared recipes
				people inside your organisation can:
					share recipes and templates,
					reuse standard flows,
					and keep a common understanding of "how we estimate this"
			flow diagrams and logic trees
				every scenario still shows a simple flow diagram and logic tree
				staff can see step by step:
					which datasets were used,
					how they were combined,
					and which assumptions drove the outputs
				without opening code or reading a technical specification

#### How jobs run
		compute modes
			for each job you choose:
				run purely on your own machines,
				run on a small private cluster in your cloud account,
				or run on datacentre capacity we manage
		private data
			jobs that touch your datasets:
				run only in the environments you select,
				with no raw internal data ever leaving those boundaries
		public-only jobs
			if a scenario uses only public indicators and open datasets:
				you can run it on the shared volunteer pool,
				or keep it in your private environment for consistency
		job sising and scheduling
			each job declares:
				which hexes it will touch,
				which datasets it will hit,
				which transforms it will apply
			the system estimates:
				runtime band,
				compute weight,
				and cost class
			before you press "run"
				so there are no surprises


#### Compliance and audit trail

		for regulated and grant-heavy work,
			What if – Private offers a clear audit trail for every scenario
		you can export:
			input summary
				which datasets were used, what time-window or version
			flow diagram + logic tree
				every step from raw inputs to outputs
			assumptions
				parameters, thresholds, and any manual overrides
			results
				per-hex outputs, aggregates, and simple charts or tables
		this matters when you need to:
			explain results to a regulator,
			show a funder what changed,
			or revisit a scenario years later and re-run it under updated assumptions
		to someone frustrated with ArcGIS or consultant tools,
			this feels different:
				you never fight the UI,
				you never wonder "what did I turn on?",
				you can explain results to another person,
				you can say "this is what we assumed" without embarrassment,
				the tool respects your intelligence
		the goal is to feel like thinking with the system
			not through it

#### Pricing

		Workspace
			$20 per month for a private workspace
			plus $5 per active contributor
				viewers are free
			for researchers, civic hackers, NGO staff, and consultants using public and light private data
			includes:
				larger scenario scopes,
				more active jobs,
				better exports,
				collaboration features
			still on public or shared compute by default
				unless you move into dedicated private capacity

		Honey
			heavy compute top-ups for private or guaranteed work
			priced flat and transparently
				never expire
			price equals raw compute + storage + transfer + systems administration
			no hidden margin
			you pay for isolated, reliable compute
				not for priority over public work

#### Reaching interested people
		the hexagons map already has meaningful public data layers
		as organisations begin exploring their own areas,
			local dashboards emerge naturally
		councils, research teams, and community organisations
			can discover the system simply by examining their region
		in many cases the first interaction is not "What if – Private"
			it is just a hexagon map of their area with indicators already visible
		once people begin asking "what happens if we change this?"
			the What if engine becomes the natural next step
</pre>
  </main>
  <footer class="site-footer">
    <a class="back-link" href="/outline/hexagons_world/">Back to directory</a>
  </footer>
</body>
</html>
