doxa-maps/data
doxa-maps-88655c70 8313f766b6 Bridge candidates as evidence, and no spoken bridge for a Deaf community
The curated bridge covers 168 of Doxa's 369 with nothing, because it comes from
a curated subset rather than from the data. A candidate IS computable for the
rest: the largest language in their country carrying both Scripture and the film.

WHAT I COULD NOT COMPUTE, AND THEREFORE DO NOT CLAIM. Ranking those candidates
needs a notion of "is this a lingua franca", and neither available proxy
survives contact. By GROUP COUNT, Oman picks Swahili — two groups — for an
Arabic-speaking people. By SHARE OF PINNED POPULATION, a 10% floor REFUSES Urdu
in Pakistan at 7.3%, the national language, because few Pakistani groups are
pinned as Urdu speakers. That is the same bad-denominator mistake this map
already fixed on the choropleth. So no strength is invented: the candidate ships
with its group count and its share, under column names that say "candidate",
and a reader who knows Pakistan can see Urdu at 7.3% and know what to do with it.
A score would have thrown it away on their behalf.

AND THE ERROR CAUGHT BEFORE SHIPPING. The candidate logic was offering 89 Deaf
groups a SPOKEN language — Deaf Afghans to Turkmen, Deaf Arubans to Dutch. That
is not a weak bridge, it is not a bridge, and a mobiliser acting on it would be
sent to do something that cannot reach the people. This build already refuses to
search GRN for sign languages because GRN publishes audio; the candidate logic
had inherited the gap. Now: 92 Deaf groups are offered none, and their gap is
named as the access problem it is.

Of the 369 with nothing: 168 curated bridge, 107 computed candidate, 92 Deaf,
2 with neither.
2026-09-25 08:40:25 +00:00
..
external-bundles Data out of public/: sources live in data/, the web-root is generated 2026-09-16 01:24:41 +00:00
people-groups All People Groups loads fast on a light map; the Vision Card becomes a true funnel from data 2026-09-25 07:18:30 +00:00
posters The poster print preview rasterises too, and a deployment can ship sources without rasters 2026-09-24 08:07:22 +00:00
pplr PPLR data maps (WIP): move the ten PPLR research views into plugin-designs 2026-09-25 06:33:49 +00:00
tables Bridge candidates as evidence, and no spoken bridge for a Deaf community 2026-09-25 08:40:25 +00:00
vendor Vendor Vue for the gallery shell, so the self-hosted rung finally exists 2026-09-22 04:59:30 +00:00
README.md Complete app-profiles->plugin-designs sweep across comments/docs; build green; layouts kept at root (load-bearing) 2026-09-17 18:18:19 +00:00

data/ — the bundler's source-of-truth data

The law: data lives here; public/ is generated. Every folder in data/ is copied into the served web-root by the build (internal/generate-tree.mjs), exactly like the per-profile data in plugin-designs/*/data/. You should be able to rm -rf public/ and get it all back with bun run build.

Folder Served at What it is
people-groups/ /assets/people-groups/ People-group datasets (CSV/JSON) the maps read at runtime
vendor/ /assets/vendor/ Third-party runtime assets (e.g. table libraries)
posters/ /assets/posters/ Rendered poster webp set (heavy pipeline output; poster walls fetch these)
tables/ /assets/tables/ The MERGED served table set (its index.json is the merge; per-profile plugin-designs/*/data/tables are build-time sources)
external-bundles/ not served Prebuilt map IIFEs vendored from sibling projects (not built here); only the optional layouts/ shell mounted them, so the build no longer copies them into public/

Don't edit anything under public/ by hand — change it here (or in plugin-designs/*/data/, layouts/*/assets/) and rebuild.