## Alternatives

hexagons.world assumes that people will find value in seeing the world through a common grid, that data can be presented clearly and neutrally, and that communities will use it as a starting point for local action. But if any of these slip, the model can shift.


// hexagon maps





- calling it something other than What if? - Private
	// could be better, since institutions might adopt better
	// but: it's not ready yet though


## Data Access

	the expectation is that useful, reliable data is open and available
	but if official sources are patchy, locked, or manipulated
		→ rely more heavily on community-collected data and local partners
		→ use public surveys, NGO reports, and academic studies as primary inputs
		→ archive and mirror important sets so they remain accessible
		→ mark weak areas clearly, so gaps are visible instead of hidden

## Trust

	the plan is that neutrality and open presentation builds trust
	but if people suspect bias or agenda
		→ emphasise radical transparency
			— sources linked directly from each indicator
			— formulas, priors, and weightings made public
			— methods explained in plain language alongside technical notes
		→ make raw data and model outputs downloadable so anyone can check them
		→ keep indicator design open to challenge: “how should this be weighted?” becomes part of normal debate, not a side-channel

## Indicators and Weightings

	the assumption is that the core indicators (homelessness, poverty, malnutrition, illness, distress, heat, pollution, unsafety, disengagement) are broadly acceptable, even if imperfect
	but if there is strong disagreement or local pushback
		→ allow alternate indicator sets and “views” (e.g. climate-heavy, health-heavy) as first-class overlays, not hidden hacks
		→ publish clear change-logs when definitions or inputs shift, so no one feels the numbers are moving secretly
		→ keep the default set conservative and stable, but let regions trial experimental indicators in parallel
		→ accept that some communities will only adopt a subset of indicators that feel legitimate to them

## Privacy and Harm

	the model assumes that publishing per-hex statistics is helpful and does not stigmatise people living there
	but if some hexes are clearly harmed by visibility
		→ coarsen the map for sensitive indicators (aggregate to bigger hexes or blur boundaries)
		→ add noise or wider uncertainty for small populations or vulnerable groups
		→ allow “shielding” of specific hexes where publishing detail would be unsafe
		→ keep raw microdata off the map entirely; only show aggregates with uncertainty

## Engagement

	the model assumes that students, academics, NGOs, and regular people will use the map
	but if uptake is slow or skewed toward institutions
		→ make the site pleasant to visit on its own
			— playful zooming, clean layers, simple comparisons
		→ seed early use cases with Peaceful projects and friendly partners
			— QuitEasily (recovery participation per hex)
			— Reasonable.Diet (affordable nutrition and food access)
			— LearnStuff.Today (local skill and volunteering maps)
		→ treat institutional adoption as optional amplification, not the main audience
		→ ensure even a casual visitor with no project affiliation can get something useful in one or two clicks

## Action

	the assumption is that better statistics will drive local action
	but if numbers remain abstract
		→ link hexes directly to campaigns and options in each place
			— Calm.College events where loneliness or distress run high
			— Reasonable.Diet posters or co-ops where malnutrition spikes
			— local meetups or mutual-aid points where poverty and unsafety cluster
		→ show small before/after traces when campaigns shift an indicator, even slightly
		→ let groups run simple “what if?” scenarios from the map itself, so planning and proof live in the same place

## Identity and Naming

	the aim is that hexagons.world feels like a clear, neutral way of looking at the world, with names that “fit” the place
	but if it is dismissed as “just another map project” or if naming becomes contentious
		→ lean into practical use:
			— make it easy to locate yourself and your community
			— use hex-words as meeting points and reference in other Peaceful tools
		→ use deterministic word lists and public rules so people can see *why* a name was chosen
		→ support local word-sets and translations, with clear versioning, when communities want names that better reflect language and culture
		→ if a name is clearly unfit or harmful, allow a calm, documented rename process rather than freezing it forever

## Community Ownership

	the design assumes that people will improve the map instead of fighting over it
	but if naming or stats are pulled into culture wars
		→ require effort and reasoning for suggested changes, not just votes
		→ prioritise input from people who live in or work on a place, rather than external brigades
		→ keep a clear separation between:
			— the stable, reference layer everyone can rely on
			— experimental layers where people can try bolder ideas
		→ make it easy to fork the *view* (alternative themes, overlays) while keeping the base data calm and boring

## Sustainability

	the expectation is that a static, lean setup keeps costs minimal
	but if infra needs grow with adoption
		→ allow torrents, peer-to-peer distribution, and local mirrors so regions can host their own copies
		→ let devices cache or share maps offline, treating the site more like a dataset than a service
		→ add dynamic backends only where needed (e.g. “what if?” runs, live overlays), with static snapshots as fallback
		→ keep the open, hex-level view free even if paid tools grow around it

## Epoch

	the naming system assumes the world changes slowly enough that a single version can stay useful for decades
	but if the world meaningfully shifts after names have “burned in” — climate, language, borders, or culture — the map can move in epochs

		→ define explicit epochs in the API
			— epoch 0: first global roll-out of names and indicator baselines
			— epoch 1, 2, …: later revisions when the underlying world has clearly changed
		→ treat a new epoch as a calm naming land-rush:
			— keep deterministic rules and local dictionaries
			— invite communities to refine names and word-sets to match the new reality
		→ keep older epochs queryable for research and history
			— you can always see what a hex was called and how it looked before
			— but everyday tools default to the current epoch so normal users don’t feel churn
		→ only advance epochs when necessary
			— broad, global changes
			— or clear consensus that the map no longer reflects how people actually speak about place

	this way, hexagons.world can stay stable enough to trust, and flexible enough to keep feeling true.







### Hexagons Enterprise

// potential future offering

Many organisations have sensitive workloads that must be hosted locally and air-gapped for compliance reasons.

	minesites
	utilities
	medical and health networks
	insurance and reinsurance
	large transport and logistics operators
	government departments and central agencies

“If you handle regulated data, require air-gaps, or employ compliance teams, choose Enterprise.”

We offer a scenario engine in your own environment, with full auditability, privacy guarantees, and dedicated support.
Everything runs where you decide: your racks, your VPC, your compliance rules.



### What This Actually Is

	full scenario engine, self-hosted
		the same hexagon grid,
		the same functional language and sequences
		the same flow diagrams and logic trees,
		deployed entirely inside your environment.

	unlimited internal datasets
		attach:
			internal warehouses,
			GIS layers,
			operational logs,
			sensor feeds,
			research datasets,
			address or asset registers.
		data lives under:
			your storage,
			your access controls,
			your retention policies.

	unlimited users and scenarios
		no per-seat licensing.
		no limits on scenario count.
		no caps on how often you can re-run a model or variant.

	full compliance logging
		every run can record:
			input datasets and versions,
			recipe and parameter set,
			machines used,
			and all outputs.
		exportable traces:
			suitable for regulators, auditors, and internal risk teams.

	own compute, own cluster
		run everything on:
			your HPC cluster,
			your Kubernetes estate,
			your private cloud,
			or dedicated bare metal.
		you decide:
			where jobs land,
			how capacity is sliced,
			which teams get priority.

			NGOs care about:
				transparency
				reproducibility
				shared public maps

			Enterprises require privacy, auditing, traceability

			Corporates care about:
				“no raw internal data leaves our VPC ever”
				“every scenario must have a compliance-grade audit log”
				“results must be reproducible for regulators ten years from now”
				“sensitivity analysis must be quantifiable”
				“risk teams need exportable JSON traces”



### What You Can Use It For

Hexagons Enterprise is general-purpose.
Anything that can be expressed as data over space, or over a set of entities, can be turned into recipes.

	geospatial and planning
		urban and regional planning
		transport networks and rerouting
		heat, shade, and microclimate mapping
		pollution and exposure surfaces
		risk overlays for insurance and finance

	physical and environmental analysis
		simplified physics and environmental models
		energy demand and load curves
		water drawdown and recharge scenarios
		failure surfaces and tailings risk

	operations and logistics
		fleet and field routing
		maintenance clustering and scheduling
		asset condition and replacement planning
		“what if this depot / pipe / feeder failed?” chains

	exploratory and quantitative research
		teams can:
			prototype new indicators,
			test assumptions,
			explore sensitivities,
			and share recipes internally,
		without rebuilding tools from scratch
		or outsourcing everything to consultants.

		you're still going to need an expert to review everything
			especiallly if it's mission critical

			*Mining scenarios:*
				tailings risk surfaces
				rehabilitation plan modelling
				water drawdown scenarios
				community well-being offsets

			*Energy utilities:*
				heat stress → energy demand
				outage vulnerability
				renewable placement scenarios

			*Insurance:*
				hazard × vulnerability × exposure overlays
				seasonal climate perturbation scenarios
				multi-return-period modelling

			*Agriculture:*
				soil moisture shifts
				crop rotation scenarios
				pest spread modelling



the pattern
	subject-matter experts
		put “how we think about this” into recipes (or sell building or reviewing of them)
	front-line staff and managers
		run those recipes through:
			maps,
			flow diagrams,
			and simple before/after views,
		instead of wrestling with a full GIS stack.




### How It Feels to Use

	for domain experts
		it feels like:
			a safe, shared place to express models in code,
			with enough structure that others can run them correctly,
			and enough transparency to defend results years later.

	for people on the ground
		it feels like:
			opening a map of the area they know,
			selecting a scenario,
			tweaking a few sliders,
			and seeing clear, explainable before/after views.

	for frustrated ArcGIS / consultant-tool users, this feels good because:
		– you never fight for licences or seats
		– you never wonder which hidden layers are turned on
		– you can explain results to a non-technical colleague
		– you can say “this is exactly what we assumed” in a meeting
		– the tool fits around your expertise, instead of hiding it
		plus gives the best data



### Pricing

- USD $12,000 per month
- USD $120,000 per year (when billed annually)

	no negotiation.
	no upsells.
	no arbitrary constraints.
	no limits on:
		users,
		scenarios,
		or internal machine-node count.

	A relief compared to ArcGIS (“finally something simple and honest”).
	A bargain compared to GEE and other private-compute setups.
	Cheap compared to consultants ($50k–$300k per project).

	Large organisations already expect six-figure software budgets.
	This is less than typical enterprise GIS,
		and far simpler.







#### Private and Enterprise Support

We will mirror the software support approach taken by rsync.net -- a storage company providing a

	direct line
	your ticket will be handled by software engineers and geospacial engineers.
		we will employ them from countries around the world.
			they will have the ability and right to end a call at any time
			can also talk back to the customer if they're being unreasonable
				like, not being intentionally mean or demeaning

				speaking personally, I've never had a bad support call because I was able to joke around with the customer
					nobody wants to ring IT
					and so you want to empathise with someone
						but instead of the corporate "that sounds really frustrating"
							instead "aw that sucks"
					and sometimes, there have been mutliple random issues in a day. like a phone issue then a printer issue and then a projector issue
						and saying something like "oh what have you done now!" (provided you have good repour with the customer

				but supposing that a client is being beligerent and harrassing
					in many industries there is amphetamine abuse
						and I can imagine one of our staff members receiving abuse over the phone
						we will brief customers on the fact that staff are permitted to block customers
							since we're allowed to do that in everyday life, and work is a part of life too
						then, they can switch to email support while we review the call recording and the explanation
					we're not so money hungry as to compromise our employees for something
				we wil ask our customers to 'play fair' and live by our values, too.

		we'll ask customers and organisations to 'play fair'
			defining reasonable support limits
			and amount of queries


	links back into our value that we will speak the truth
		salespeople
			"our software can do that!"
				what that actually means is that "sign up with us for a lot of money, then pay us more money and we will make our software do that."





	if on site technicians required
		we will work with a local supplier


if we need to change pricing for big clients and tailor to them, then we will
	but we will engineer the software and defer to experts they hire where we can






#### Hexagons Enterprise Adoption



Great follow-on question. Hexagons Enterprise is a different beast from “What if – Private”, so the adoption story and the questions you need to ask are a bit different.

Below is a way to think about global adoption for Hexagons Enterprise: who could run it, how many there might realistically be, and what questions to explore to get out of fantasy and into a real forecast.

I’ll treat “Hexagons Enterprise” as: a hosted or sovereign instance of the hexagons stack for a whole network (country, state, NGO, university, large company) where they become the “platform operator” for many downstream users.

1. Global universe for Hexagons Enterprise (who could logically run an instance?)

Enterprise here is not “every org that uses the tool”, it’s the ones that host platforms other people plug into. Rough segments:

A. Sovereign / public sector platforms
• National governments (approx. 200 countries)
• Subnational governments with real autonomy: states, provinces, Länder, regions (a few thousand worldwide)
• Large cities/metro authorities that already run serious data portals (maybe the top 500–1,000 cities by population/economy)

B. Statistical / planning bodies and multilaterals
• National statistics offices and planning commissions
• Central banks and similar macro-data stewards
• Multilateral agencies (UN agencies, World Bank, regional development banks, OECD-like bodies)

C. Large NGOs / foundations / donor consortia
• Big INGOs with multi-country operations (health, education, climate, humanitarian)
• Major foundations and philanthropic networks
• Donors / funding agencies who already mandate indicators/reporting (USAID, FCDO, EU instruments, etc.)

D. Large universities and research networks
• Flagship universities that already host national / regional research infrastructures
• Methodology networks (e.g. global health metrics, education measurement consortia)

E. Corporates and utilities with systemic footprint
• Energy, water, telecoms, large retailers, banks that explicitly link their work to community-level indicators
• Sector alliances (e.g. utility associations, banking associations) that might run joint platforms

Order-of-magnitude “could be enterprise host one day”:

• Sovereign/national: ~200
• Subnational/regional with realistic digital capacity: maybe 300–1,000
• Big cities: maybe 300–700
• Multilaterals + statistics + central institutions: ~100–300
• Big NGO/foundation/donor networks: maybe 200–500
• Major universities/research networks capable of hosting: maybe 200–500
• Corporates/sector platforms that are values-aligned: maybe 300–1,000

You’re under a few thousand plausible platform operators in the entire world. That’s good: Enterprise is meant to be small-N, high-leverage.

2. How Hexagons Enterprise is different from “What if – Private”

What if – Private
• Single organisation workspace.
• They bring their indicators (or select from global ones), run scenarios privately.
• Adoption lives at the “team/org” level.
• It’s mostly about usability, pricing, and pain-relief for planning/reporting.

Hexagons Enterprise
• A whole instance or cluster.
• It may set or host canonical indicator taxonomies for a country / sector / network.
• It can serve hundreds or thousands of downstream What-if workspaces.
• Adoption lives at the “infrastructure / governance” level: someone chooses Hexagons as the rails others run on.

So instead of “how many orgs will use the tool”, you’re asking “how many entities will run the rails”, and then “how many orgs sit atop each rail”.

3. Key questions to decide whether a segment is a real Enterprise candidate

For each potential platform operator, ask:

A. Data authority and mandate

1. Do they already define or steward indicators that many others must follow?
   • National stats office defining SDG-style indicators.
   • Ministry/agency mandating indicators for funded projects.
   • A big NGO that defines a measurement framework for all its country programmes.

2. Are they responsible for open data portals, national dashboards, or public scorecards?
   • If yes, they’re already a platform operator in another guise.

B. Technical posture and constraints
3) Do they have existing infrastructure that could host Hexagons (cloud, sovereign cloud, on-prem)?
4) Are they allowed to run external open-source or vendor platforms, or do they need strict data residency and audits?
5) How risk-averse is their IT/security apparatus?
• “We can’t host anything new” vs “We love predictable, auditable, well-scoped platforms.”

C. Governance and politics
6) Would hosting a multi-indicator platform be politically charged?
• E.g., QUOKKA-style scorecards: do they see that as empowerment or as dangerous ranking?
7) Are they willing to share indicator definitions and mappings publicly, or must everything be internal?
8) Do they want to be seen as neutral stewards, or are they politically aligned actors that others might distrust?

D. Ecosystem structure
9) Do they have a network that would actually use it?
• For a country: thousands of municipalities, NGOs, departments.
• For an INGO: dozens of country offices and partners.
• For a research network: many labs, ministries, and external partners.

10. Are they currently struggling to coordinate that network’s data and planning?
    • Fragmented spreadsheets, inconsistent indicators, conflicting baselines.
    • Repeated “please fill in this reporting template (again)” emails.

E. Incentives and pain
11) What job would Hexagons Enterprise do that nothing else is currently doing well? Examples:
• Simplify indicator governance (one catalogue, many uses).
• Give all funded projects a consistent “what if” environment.
• Turn open data from static CSV dumps into living planning surfaces.
12) Do they gain political, reputational, or financial advantage by offering this platform?
• Stronger grant portfolios.
• “Modern, evidence-based” branding.
• Lower internal coordination costs.

F. Procurement and lock-in fears
13) How do they usually procure platforms? RFP, pilot then contract, or “we build everything ourselves”?
14) Are they terrified of vendor lock-in and black-box scoring?
• This is where your open source / open spec / clear exit path story matters a lot.
15) Can they sign multi-year agreements, or are they on 12-month cycles?

These questions will quickly filter out 80–90% of your theoretical base and leave a few dozen to a few hundred truly viable Enterprise hosts.

4. Global adoption ranges for Hexagons Enterprise (order-of-magnitude)

Think of three horizons: “anchor instances” and then how much they cover.

A. Sovereign anchors (countries or equivalent)
Universe: ~200 countries.

• Conservative scenario:
– 3–5 early adopters (likely wealthier democracies with strong open-data cultures, or one “wildcard” country that wants to leapfrog).
– 10–15 over a decade if everything goes well.

• Middle scenario:
– 10–20 in 10–15 years, concentrated in regions with strong digital-government programmes.

• Ambitious but still plausible:
– 30–40 countries running some flavour of Hexagons Enterprise (maybe also regionally: EU-level, AU-level, ASEAN-like, etc.).

B. Subnational / city-level anchors
Universe: high hundreds to a couple of thousand plausible state/province/metro governments with mature digital capability.

• Conservative:
– A handful of “lighthouse” cities and one or two states per early-adopter country: maybe 20–50.

• Middle:
– 50–150 subnational/city instances, often aligned with national indicator frameworks.

• Ambitious:
– 200–300 over a long horizon, especially if powered by off-the-shelf sovereign cloud offerings.

C. NGO / foundation / donor anchors
Universe: maybe 200–500 strong candidates.

• Conservative: 5–15 large NGO/foundation/donor networks.
• Middle: 20–50.
• Ambitious: 70–100 (if indicator-centric funding becomes standard and Hexagons is one of the default rails).

D. University / research network anchors
Universe: maybe 200–500.

• Conservative: 5–10 (flagship applied-research groups and “data for good” centres).
• Middle: 20–40.
• Ambitious: 50–80.

E. Corporate / sector anchors
Universe: a few hundred to a thousand plausible, values-aligned candidates.

• Conservative: 5–10 (utilities, big food/retail, telecoms, banks with strong ESG + community focus).
• Middle: 20–40.
• Ambitious: 50–100.

If you sum these in three scenarios over, say, 10–15 years:

• Very conservative:
– 20–50 Hexagons Enterprise instances globally.

• Middle:
– around 80–200 instances.

• Ambitious but not sci-fi:
– maybe 250–500 instances across all segments.

Note that this is “hosts”, not end-orgs. Each Enterprise instance can support:

• Dozens to thousands of What-if Private orgs.
• Hundreds to tens of thousands of end users.

So even 50–100 Enterprise anchors, if well-distributed, could realistically underpin thousands of active organisations and hundreds of thousands of people doing scenario work.

5. How Enterprise and What-if Private interact in your adoption model

Important mental split:

• What-if Private: how many organisations and people play.
• Hexagons Enterprise: how many ecosystems become “native” to hexagons rails.

A rough way to model the interplay:

1. Pick an Enterprise type (e.g. national government).
2. For each Enterprise instance, estimate:
   – Number of potential downstream organisations (municipalities, NGOs, departments).
   – % that will ever sign up for What-if Private under that umbrella.
   – Average users per org.

You then get adoption like:

Enterprise_instances × (Org_per_instance × Adoption_rate × Users_per_org)

Example shape (not exact numbers):
• 30 national Enterprise instances
• Each with 200–1,000 potential downstream orgs
• 10–20% adoption per country over time
• 10–50 users per org

You quickly get consistent orders of magnitude like “a few thousand orgs, low millions of users” without needing every country on Earth.

6. Concrete question set to build a realistic forecast for Hexagons Enterprise

If you want to tighten estimates for an actual deck / plan, here are the practical questions to go and answer, segment by segment:

1. Segment sising
   • How many credible candidate hosts in each segment in Region X?
   • Which 10–20 named entities in each segment feel most aligned?

2. Readiness / friction score
   For each named candidate, score 1–5 on:
   • Indicator authority (do they actually set or steward indicators?)
   • Technical readiness (cloud/on-prem capacity, digital track record)
   • Governance receptivity (open data history, willingness to be neutral steward)
   • Ecosystem size (how many orgs would actually connect?)
   • Pain level (are they currently drowning in spreadsheets, incompatible indicators, and donor templates?)
   • Procurement hostility (how painful to get a platform agreement?)

3. Strategic priority
   • Which candidates, if they hosted Hexagons Enterprise, would unlock the biggest downstream impact or credibility?
   • Which ones would serve as reference cases for others in their region/segment?

4. Adoption pathway
   For each high-priority candidate, sketch:
   • Entry point: grant, pilot, open-data collaboration, university partnership, etc.
   • Minimal viable Enterprise: what’s the smallest useful thing they can host (e.g., one QUOKKA metric set, one sector, one region)?
   • Year 1 → Year 3 expansion: more indicators, more regions, more orgs.

5. Bounds and pacing
   • Given your team capacity, how many Enterprise instances can you realistically deploy and support per year without collapsing?
   • What’s the maximum number of concurrent Enterprise clients before you need a dedicated team or partner network?

Answering those questions even for a few countries/segments will give you a much sharper feel for whether you’re aiming at 20, 50, or 200 Enterprise instances as a long-term ceiling.

If you’d like, next time we can pick one segment (e.g. “national + state level in OECD-ish countries”) and actually walk through a concrete scoring model so you can see “we probably top out around X Enterprise instances in this band” instead of carrying around “hundreds of millions of councils” in your head.

---

Yep, let’s actually put numbers on it.

Below is a concrete, worked estimate for global Hexagons Enterprise adoption over, say, a 10–15 year horizon, using explicit assumptions instead of vibes. I’ll give you:

* How many Enterprise hosts in a low / mid / high scenario
* Rough breakdown by type (states vs NGOs vs universities etc.)
* What that implies for downstream What-if workspaces and actual people using it

You can always tweak the assumptions later, but this at least gives you a sane “order-of-magnitude box” to think in.

---

First, the universe I’m assuming

These are the rough counts of entities that could, in principle, host a Hexagons Enterprise instance one day:

* National governments: 200
* Subnational/state/province governments with real digital capacity: 800
* Big city / metro authorities with proper digital teams: 600
* Multilaterals + national statistical / planning bodies / central institutions: 250
* Large NGOs / foundations / donor networks: 400
* Major universities / research networks that can host infrastructure: 400
* Large corporates / sector platforms (utilities, banks, telecoms, etc.) that are values-aligned: 600

Total “could be an Enterprise host if the stars align one day”: about 3,250.

This is not “orgs using the tool”; these are the relatively few entities that might actually run a whole instance.

---

Scenario 1: Low adoption (things work, but slowly and in a few pockets)

Assumed adoption rates by segment:

* National gov: 3%
* Subnational/state: 2%
* Big cities: 2%
* Multilateral/stat: 5%
* NGO/foundation/donor: 3%
* University networks: 2%
* Corporate/sector platforms: 2%

That gives:

* National govs: 6
* Subnational/state: 16
* Big cities: 12
* Multilateral/stat: 12–13
* NGO/foundation/donor: 12
* University networks: 8
* Corporate/sector: 12

Total Hexagons Enterprise instances: about 80.

What that implies downstream (low):

* Assume each Enterprise host has ~100 plausible downstream orgs (municipalities, NGOs, departments, etc.).
* Only ~10% of those ever actually adopt a What-if workspace under that umbrella.
* Each adopting org ends up with ~20 active users.

Result:

* ~800 organisations actually running What-if under Enterprise rails
* ~16,000 people actively using it globally

This is “it worked, but stayed quite niche and slow.”

---

Scenario 2: Mid adoption (solid success without global domination)

More optimistic but still sane adoption rates:

* National gov: 8%
* Subnational/state: 5%
* Big cities: 5%
* Multilateral/stat: 12%
* NGO/foundation/donor: 8%
* University networks: 6%
* Corporate/sector platforms: 5%

That gives roughly:

* National govs: 16
* Subnational/state: 40
* Big cities: 30
* Multilateral/stat: 30
* NGO/foundation/donor: 32
* University networks: 24
* Corporate/sector: 30

Total Hexagons Enterprise instances: about 200.

Downstream (mid case):

* Each Enterprise instance reaches ~200 plausible orgs.
* Around 20% of those actually adopt a What-if workspace.
* Each adopting org has ~30 active users on average.

Result:

* ~8,000 organisations actively using What-if under Enterprise rails
* ~240,000 people using it globally

This is the “serious but still quiet” success case: a couple of hundred Enterprise rails underpinning a few thousand orgs and a quarter-million people doing scenario work regularly.

---

Scenario 3: High adoption (you become one of the default rails)

Ambitious but still not sci-fi adoption rates:

* National gov: 20%
* Subnational/state: 15%
* Big cities: 15%
* Multilateral/stat: 30%
* NGO/foundation/donor: 20%
* University networks: 15%
* Corporate/sector platforms: 10%

That gives roughly:

* National govs: 40
* Subnational/state: 120
* Big cities: 90
* Multilateral/stat: 75
* NGO/foundation/donor: 80
* University networks: 60
* Corporate/sector: 60

Total Hexagons Enterprise instances: about 525.

Downstream (high case):

* Each Enterprise instance has ~400 plausible orgs.
* 25% of those adopt a What-if workspace.
* Each adopting org has ~40 active users.

Result:

* ~52,500 organisations actively using What-if
* ~2.1 million people using it globally

This is the “Hexagons is one of the standard ways people think about local outcomes” case.

---

How to read these numbers

If you accept these assumptions as roughly in the right ballpark, then:

* Hexagons Enterprise hosts:

  * Likely range over 10–15 years: something like 80–200 if things go well, up to ~500 if you really nail it.

* Organisations using What-if on those rails:

  * Likely: low thousands of orgs.
  * High: tens of thousands of orgs.

* Individual humans doing “what if” work:

  * Likely: low hundreds of thousands.
  * High: a couple of million.

That’s all without touching mass consumer at all; it’s entirely a professional / institutional layer.






#### Hexagons Enterprise Pricing



insurance & catastrophe modelling

agriculture supply chains

ESG reporting

logistics companies

utilities (water, power)

renewable deployment organisations




#### Costs

	coordinating
	implementation

	irl technicians


#### Pricing

- $12,000/mo
- $120,000/yr


#### Uptake


##### Low


##### Medium


##### High


#### Revenue Estimates




non-government organisations
companies
small companies