Two tables behind the brief's resources view were describing a different dataset from
the map beside them.
"Where Nothing Was Found" still listed 3,457 groups. The map draws 2,901. Its builder
already used the current tier; it simply had not been re-run since audio Scripture and
Bible video started lifting groups out of tier 0. A mobiliser exporting that tab would
have worked through 556 groups who now have a resource. Regenerated, and it matches the
map exactly.
"The Deaf Gap" was worse, and structurally so. It came from the curated 2,106-record
set and reported 73 sign languages, 120 people groups, 19.35M people. The map draws
150 sign languages, 234 groups, 84.2M people. The tab named for the Deaf gap was
missing more than half of it. Rebuilt from the pins - the same index the map draws, so
the two cannot disagree - and it now measures 150 languages, 234 groups, 84,159,050
people, of which 136 languages / 183 groups / 55,199,840 people have nothing found.
Kept deliberately: the bridge rule, verbatim, because it is the most important sentence
in the table - a sign language is bridged ONLY by another sign language, and text or
audio in a spoken language does not reach a Deaf community. That is also why the
related-variety reasoning added for spoken macrolanguages must never be applied to
these rows. Private-use codes are counted rather than hidden: 40 of these languages
carry qaa-qtz codes that no resource pool indexes, so "nothing found" for them is a
statement about the join as much as about the world, and each such row says so.
MY FIRST VERSION OF THIS SHIPPED AN EMPTY TABLE AND MY PROBE PASSED IT. DataTable
renders a { meta, columns, rows } document and the rebuild omitted `columns`, so the
tab drew its header, its "234 rows" caption and five pages of pagination over a
completely empty body. The probe had asserted the caption - a number the page prints
about itself, which is not evidence it drew anything. It now counts rendered rows AND
cells, and is proven against the defect: with `columns` removed it reports 50 row
shells and 0 cells and FAILS; restored, it passes. The row count alone would still have
missed it.
Verified: both tabs' captions match offline counts from the same index (2,901 and 234),
both render real cells, no page errors. Screenshot read.
Its gap number read only eBible and PNG.Bible for text. Faith Comes By Hearing
publishes Bible TEXT on bible.is, and since that landed the page had been telling 766
languages - 2,162 people groups, 1.37bn speakers - that no Scripture was found when
there is text Scripture in their language. The headline falls from 7,106 to 4,944.
This is not the change an earlier note refused. That note kept the pill meaning the
SCRIPTURE gap rather than "no resources at all", because widening it would say
something false about a language that has a film. That reasoning stands and is
untouched. This is the same claim finally counted in full: FCBH text is text Scripture.
full_bible stays eBible-only, because FCBH's row carries no book scope and "full Bible"
is a claim this build cannot make for it. Such a row reads "partial" - Scripture
exists, without overstating how much.
The pill also stopped saying "none found". It always meant the text gap, which was
unambiguous while text was all a row could show; now a row can carry audio Scripture
and a 27-part Bible video and still be pilled "none found". Arabic Moroccan does
exactly that - 29.2M people, a JESUS Film link, an audio Scripture and Matthew to
Revelation on video, labelled "none found". It now reads "no text", which is the same
honest claim and cannot be misread as "nothing exists for these people". The filter tab
and hero line follow.
charts.vue had the smaller version of the same blind spot: its "none" series ignored
Bible video and training, drawing 7 codes as having nothing while the map showed them a
real link.
Verified against expectations computed offline from the same index the pages load: the
list renders exactly 3,338 "no text" pills against an offline count of 3,338, down from
4,031; the country probe still splits Indonesia 348/321. No page errors on either.
Screenshots read.
The country view answered the brief's second requirement with only Scripture and film.
Everything added since - audio Scripture, Bible video, Zume training - was invisible
there, and the predicate deciding which section a group landed in never learned about
them either.
So the same map contradicted itself depending on how you opened it: 559 people groups
covering 61M people sat under "No resource found" in a country sheet while their own
pin sheet showed a live audio Scripture link. Worst affected were Indonesia (63),
Nigeria (47), China (37) and Cameroon (37).
hasAny now counts all five media, and each group row chips audio, Bible video and
training alongside Scripture and film - keeping the type distinctions the rest of the
map insists on, so Bible video still says it is not the JESUS Film and an audio link
still names which media the fileset carries.
The summary above the list was hiding the largest one. It listed "Have scripture" and
"Have film" and stopped, so for Indonesia it showed 77 and 265 while 269 groups there
have audio Scripture - the single biggest medium in that country, absent from its own
summary while the rows underneath displayed it.
Verified against an expectation computed offline from the same index the page loads,
not read off the page: Indonesia splits 348 with / 321 without, matching exactly, and
"without" falls from 384, which is the 63 groups measured beforehand. Chip kinds now
rendered include Film, Scripture, "Scripture, audio, text", "Scripture, audio, text,
video", Bible video and Training. No page errors. Screenshot read.
The gospel-resources gate was found adopting whatever answered on the default port,
which on this machine was an unrelated process from a different worktree. It reported
on a build that was not the one on disk: first a PASS, then a mount timeout that read
exactly like a regression in code nobody had touched. "Answers 200" and "is serving
this checkout" are different questions, and only the second one is the gate's job.
That fix was local to one gate. The same default sits under the rest of them, so it is
now one shared helper, internal/_serves-this-tree.mjs, fingerprinting
public/doxa-maps/manifest.json — which generate-tree rewrites on every build and which
names every bundle and profile in the tree. Different bytes means a different build:
another worktree, or a server someone forgot to restart. Both produce the same lie.
Wired into verify-browser-all, which hands ten gates their base URL and would have
passed the wrong tree to all of them, and into check-a11y-button-names. Both now refuse
with a NOT MEASURED exit rather than producing a confident wrong answer. The gospel
gate keeps its behaviour of starting its own server instead.
Verified in both directions: against the foreign 4173 each prints "serves a DIFFERENT
build than public/" and exits 2; against this tree the aggregator proceeds to its ten
gates and the gospel gate passes.
ONE REPORTED NUMBER WAS WRONG BECAUSE OF THIS. The a11y result recorded earlier in this
flight, "810 buttons, 810 with an accessible name", was measured against the foreign
tree. Re-run against this checkout it is 825 buttons, 825 with an accessible name,
still passing across 21 leaf pages. The conclusion held; the evidence had not been
about this build.
Audited the rest of this flight's browser evidence rather than assuming: the 41 probe
scripts in _qa-cycle all target port 5399, which is served by
serve-strict --directory <this worktree>/public, and the manifest served there is
byte-identical to the local one. Those results stand.
Read top-down, the gap list sent you to "Chinese, Jinyu - 60,310,000 people - nothing
found", then "Chinese, Gan - 41,280,000". Both statements are true about those ISO
codes and both are misleading as priorities: ISO 639-3 files them under the
macrolanguage zho beside cmn, Mandarin, which has Scripture, film, audio and training
here. Measured across the whole map: 84 pins covering 140M people sit at "nothing
found" while a sibling variety of their own ISO macrolanguage carries resources.
Those groups now carry a related-variety note, on the pin sheet and inline in the
ranked list, because the list is the thing that gets read top-down. 63 codes have one.
WHAT IT DOES NOT SAY. It is not a claim of mutual intelligibility, and the wording
refuses to imply one - spoken Jinyu and spoken Mandarin are not mutually intelligible;
what they share is a written standard. Only ISO's own relation is asserted, the reader
is told exactly that, and it changes NO tier and closes NO gap. Tiers are byte-identical
at 2901/4767/4711. The chips still read "none found", because that is still true.
The macrolanguage table is fetched from SIL rather than transcribed, and written
through the snapshot guard like every other catalogue.
Also corrected: the gap list header still said "Audio has never been searched for any
of them". That stopped being true when Faith Comes By Hearing was added, and a stale
caveat misleads exactly as much as a stale number. It now says audio HAS been searched
and these groups have none there either, with GRN still named as the one pool nobody
can look in.
And a gate defect that produced three runs of false signal. verify-gospel-map adopted
any server answering 200 on the default port. Port 4173 turned out to be held by an
unrelated python3 process from another worktree, so the gate reported on a build that
was not this one - first a PASS, then a mount timeout that looked exactly like a
regression in code that had nothing to do with it. Answering 200 is not the same
question as serving this tree. It now fingerprints the served bundle against the bytes
in public/ and refuses to adopt a server whose build differs, starting its own instead.
Proven: it now prints "serves a DIFFERENT build than public/ - not adopting it",
starts its own, and passes.
Screenshot read: the ranked list shows "related: Chinese, Mandarin has resources"
under Jinyu, Gan and Min Bei, and correctly nothing under Deaf Chinese or Deaf
Pakistani, which have no macrolanguage sibling.
Eleven clauses checked that the surfaces AGREE with each other. None checked that any
of it was still true. "Link checked" is a claim about the present tense, and a table
that quietly stops being re-run keeps making that claim on evidence that could be a
year old while every consistency clause still passes. A dead link is the failure a
field worker actually hits, so this is not bookkeeping.
Clause L fails when a shipped URL carries no check date at all, or when the oldest
shipped link was last checked more than 45 days ago, and the message names the exact
command to fix it. Re-running is cheap and resumable now, so the failure is an
instruction rather than an obstacle.
Proven against real data, not only the poison harness: deleting the check date from
one shipped URL is caught ("1 shipped URL(s) carry no check date"), and backdating one
by 120 days is caught ("last checked 120 days ago, past the 45-day limit"). Both
restore clean. Poison self-test now 12/12.
Also checked and deliberately NOT changed: the Arclight harvest keeps a language only
when counts.featureFilm >= 1, and it was worth asking whether that discards coverage.
Of 2,330 catalogue languages, 2,309 already have a feature film. Only 15 carry just a
shortFilm or a series, and exactly one of those - nmg Kwasio, 2 pins, 60k people - is
spoken by a group here with nothing else. Widening the filter would mean typing a
short film as "Film" beside the JESUS Film for a single language. The filter stays.
The registered description still claimed "6/6 clauses must fail"; corrected to 12.
A full pass is ~6,500 requests over a quarter of an hour, and it was killed three
times by system memory pressure - twice at around 2,500 and once at 1,000. Results
lived only in memory until the final write, so each kill threw away every request it
had made. The file on disk survived, which is correct, but the pass never landed and
the bandwidth was spent for nothing.
Every record now carries `at`, the moment it was checked, and the table is written
after each batch. A killed run loses at most one batch, and rerunning with
VERIFY_MAX_AGE_H skips anything already stamped. Writing mid-pass is safe because a
checkpoint only ADDS to or REFRESHES records - it can never shrink the table, which is
the failure the snapshot guard exists for elsewhere.
Proven rather than asserted: killed mid-pass, 300 stamped records survived on disk;
the restart reported "resuming - 600 URL(s) already checked within 24h, 5876 left to
do" and skipped them. The fourth memory kill then arrived unplanned during the real
run and cost 500 records instead of 1,900.
With the pass finally complete, the point of it: bible.is verification switched from a
body-size heuristic to their API two changes ago, but only the URLs added since had
been re-checked. 2,609 of 2,868 records still asserted "verified" on the older basis.
All 2,708 now come from /api/bibles, and none from the heuristic.
The last 160 were neither shipped nor broken - leftovers from filesets no build has
referenced since the FCBH ranking changed, quietly carrying the old method. A full
pass now prunes any record for a URL that nothing ships and nothing proved dead, so
the table means exactly one thing: every URL this map currently ships, plus the
history of everything ever proven dead. Broken records are never pruned; forgetting a
dead link is how it gets shipped again.
That prune sat behind an early exit that fired whenever nothing was stale, so the
first run to reach it reported success and pruned nothing. Removed.
Table: 6,476 records, 6,397 verified, 74 broken and dropped, 5 uncheckable, 0
unstamped, 0 on the old method.
136 of the 150 sign languages here have no resource at all, across 234 people groups
and 84,159,050 people. This tick searched for more rather than assuming, and the answer
is that there are none to find in the open catalogues:
Arclight / JESUS Film 14 sign-language entries across 13 ISO codes - every one of
them was ALREADY in this index
Faith Comes By Hearing none at all, in 3,602 rows
deaf.bible 200, but a 3,894-byte app shell
deafbible.com the same 3,894-byte shell
door.international 200, 114 bytes
So the gap closes through an agreement with Deaf Bible Society or DOOR International,
not through more searching, and every sign-language group now says that in those words
instead of leaving a reader to assume somebody simply had not looked yet.
Two real honesty defects went with it. The provenance line claimed "ebible, arclight,
door43, fcbh" as CHECKED for a Deaf group - eBible and Door43 are text and FCBH is
audio, none of which serves a Deaf group - and named GRN, an AUDIO pool, as the thing
still unchecked, while omitting the two organisations that actually publish for the
Deaf. A sign language now reads "arclight (14 sign languages, all captured), fcbh
(none)" as checked and "deaf_bible_society, door_international - both key-gated" as not.
And the sheet showed a Deaf group an "Audio - none at FCBH, GRN unsearchable" chip:
noise about a medium they cannot use, pushing the one line that matters further down.
It is suppressed for sign languages. Where FCBH does hold something for them it is
text, and that link still shows.
Verified against the data rather than the prose: 150 sign languages, 13 with a film, 0
with a text Scripture, 0 with both - so the standing claim that none yet has both is
still true - and 84,159,050 is the population the page renders. Screenshot read: Deaf
Nicaraguan shows the exhausted-catalogue paragraph naming both ministries, with no
audio chip.
Jehovah's Witnesses publish extensively in sign language and remain excluded. The size
of a gap is not a reason to relax the doctrinal filter.
The FCBH fetcher read per-fileset video scope for 1,666 languages and that file was
committed. A later run, while live.bible.is was rate-limiting, produced 1,103 and
overwrote the good file with the degraded one. Nothing failed, nothing warned, and the
artefact silently lost a third of its content. It was caught only because git status
happened to be read, and the fix was a git checkout.
That is the third time this shape has appeared here:
- a VERIFY_LIMIT smoke run replaced the full verification table with 30 rows;
- dropping a dead link removed it from the corpus, so the next run forgot it was
dead and the build put it straight back;
- this one.
Every snapshot in this bundle is built from a network read, and a network read has a bad
day. The dangerous case is never the run that throws - that leaves the old file alone -
it is the run that half-succeeds and writes anyway.
scripts/_snapshot-guard.mjs now stands in front of every catalogue write. A snapshot may
grow freely and may shrink a little, but losing more than a tenth of the previous run is
treated as a failed fetch: the existing file is left untouched and the script exits 1.
It is deliberately not an equality check, because catalogues do genuinely lose entries
when a publisher retires something, and a gate nobody can satisfy gets switched off.
SNAPSHOT_FORCE=1 is the one loud way past it.
Proven by replaying the exact failure: feeding it the 1,103-entry version refuses the
write, names the real numbers (563 fewer, 13.8%, below the 90% floor) and leaves the
file byte-identical to the good one. SNAPSHOT_FORCE=1 writes it. An equal write passes.
All six fetchers are wired: ebible, arclight, arclight-share-urls, door43, zume, fcbh.
Re-running zume, door43 and ebible for real passes the guard at 52, 208 and 1,237 codes
and produces byte-identical data, so the guard perturbs nothing.
The one exception is the checkpoint write in the resumable share-urls fetcher, which
starts from the existing file as a cache and can only grow. It must now declare itself
with a CHECKPOINT-WRITE-OK marker, so the exemption is a statement rather than an
oversight.
New gate check:snapshot-guard fails if any fetch-*.mjs writes OUT directly without that
marker, or never calls writeSnapshot at all - a guard that is easy to bypass is a guard
that will be bypassed. It refuses to run against an empty file list rather than passing
vacuously, and --poison injects a raw write and requires the check to catch it. Chained
into build:unlocked and its doc copy kept in sync.
The previous change left video_date out because the column does not say what the video
IS. Establishing it took measurement, and the first samples were misleading. Three
video-only filesets all rendered ...S2DV pages opening on "Intro & Garden of Eden" with
Drama/Non-Drama controls, which suggested one Old Testament series. Reading
GET /api/bibles/<bible_id>, which returns the exact books array in one call, for all
1,669 video languages says otherwise:
209 27 parts, Matthew to Revelation (the whole New Testament)
116 27 parts, San Mateo to Apocalipsis (same, Spanish editions)
110 12 parts, Intro & Garden of Eden ... (Covenant, Old Testament)
27 Mark 26 Acts 23 Luke
1,006 distinct scopes in all
Generalising from three samples would have described the bulk of it exactly backwards.
Every link therefore ships its own scope rather than a shared description, and the 3
languages whose book list could not be read were dropped: an undescribed video is not
shipped.
It is typed "Bible video", never "Film". Film on this map means the JESUS Film, and
bible.is itself treats the two as different - its pages call a separate Arclight
endpoint, /api/arclight/jesus-film/languages?iso=..., to find it. So Bible video lifts a
group off "nothing found", which is true, and contributes nothing to the Scripture+film
tier. 1,666 languages carry it: 287 as their own link reaching 4,375 pins and 5.76bn
people, and 1,379 merged into the Scripture link whose media list now reads "audio,
text, video" instead of advertising half of what the page holds.
Verification for bible.is switched from a body-size heuristic to their own API. The page
answers 200 for any id, so the first version compared body sizes against a shell
measured at run time. That was a heuristic on a number the site controls, and it stopped
working when their WAF began answering HEAD with 403 and a 520-byte body for real and
bogus alike. The run-time calibration caught exactly that and ABORTED rather than mark
thousands of links verified - which is the whole reason it was measured and not
hard-coded. The API needs no heuristic: /api/bibles/OKEBSN is 200, /api/bibles/ZZZZZZ is
404. It is a tenth of the weight, it describes the same fileset the page renders, and
GET is used because HEAD is what the WAF blocks.
Also fixed: a fetch with no timeout hung the fetcher for thirteen minutes with no
output. A stall looks exactly like slow work, so every fetch in it now carries a
timeout, and the scope lookups run with bounded concurrency and 403 backoff.
6,404 links screened, 6,557 verified, 74 broken and dropped, 5 uncheckable. Screenshot
read: German shows "Bible video - 12 parts, Intro & Garden of Eden to After the Forty
Years / End Credits" as its own chip, distinct from "Film - link checked".
The FCBH integration used only audio_date. Their rows also carry text_date, and it is
unambiguous - they publish Bible text on bible.is. 698 codes carry text where this map
had no text Scripture at all, reaching 2,176 pins and 1.38bn people. Codes go 2,192 ->
2,400 and the gap falls 2,927 -> 2,908.
ONE LINK PER LANGUAGE, NOT ONE PER MEDIUM. A bible.is fileset is a single page carrying
whatever media it has, so two chips pointing at the same URL would be noise. The link
now states what it carries: 1,465 codes audio+text, 677 audio only, 207 text only.
That last number was a live falsehood. Because the builder never copied the media field
across, all 2,349 bible.is rows were typed "Audio Scripture" - including 207 filesets
with no recording at all. A group with text-only Scripture was being sent to look for a
recording that does not exist. Both the chip and the table type now follow the media.
Ranking is by media count, then AUDIO PRESENT, then recency. The middle term is not
decoration: without it a newer text-only fileset outranks an audio-only one on date
alone and the language silently loses its recording, which is the medium an
oral-preference group actually needs. Measured while it was missing: 3 codes lost audio.
video_date is deliberately left out. The column does not say what the video IS - a Luke
film, a sign-language edition, something else - and counting it as "film" beside the
JESUS Film would assert something nobody here has checked. 400 codes with no film today
carry one, so it is worth establishing later, but not by guessing.
Clause I now accepts BOTH Audio Scripture and Scripture on bible.is, because a fileset
really can be either, while keeping the set closed and keeping Audio Scripture wrong on
every other host. Proven by poisoning both directions: Film on bible.is and Audio
Scripture on ebible.org are each caught. Poison self-test 11/11.
Also verified, not assumed: the brief's requirement that a pin or country click filters
the table. iso=deu shows 4 of 5,889, country=IND shows 502 of 5,889. It works; an
earlier reading of mine that suggested otherwise was measuring the wrong thing.
All 6,117 links screened and verified. Screenshot read: Ninigo (ssg) shows "Scripture,
text - 2012 Wycliffe Bible Translators, Inc." where it would have claimed audio.
Every pin on this map has read "Audio - not searched (GRN)" for its whole life, because
Global Recordings Network sits behind Bunny Shield and answers 403 to everything, its
own robots.txt included. Re-probed this tick: still 403. But GRN was never the only
audio pool.
Faith Comes By Hearing needed no key. Their 4.dbt.io API wants one and answers 422,
which is where the earlier note stopped. Their own recordings-database page does not
use that API - it is client-rendered and pulls a STATIC public file from their CDN,
bible_recordings.json, 3,602 rows of { iso, lang_name, bible_name, bible_id, country,
video_date, audio_date, text_date }, already keyed by ISO 639-3. 2,192 codes carry a
dated audio recording; 2,121 survive verification.
Audio lifts a group off tier 0, unlike Zume, because a people group with an audio Bible
in their own language does not have "nothing" - for an oral-preference group it may be
the most useful thing on the list. It does not create tier 2, which stays reserved for
text Scripture together with film. Measured: 533 pins and 59.5M people leave the gap,
which falls 3,460 -> 2,927. Coverage 72.0% -> 76.4%. 8,094 pins now carry audio.
A 200 FROM live.bible.is PROVES NOTHING and this almost shipped wrong. It answers 200
for a fileset that does not exist, returning a fixed-size not-found shell, so the
discriminator is BODY SIZE and HEAD gives content-length for free. The shell size is
measured at run time, never hard-coded: it was 7,961 bytes on one path and 7,860 on
another within the same hour. Both fetcher and verifier abort if a bogus id ever
returns the same size as a known-good one. It caught 73 dead filesets in FCBH's own
data, all dropped.
The first full pass collected 466 HTTP 403s from bible.is - rate limiting, not dead
links; the same URL answered 200 when retried alone. Requests are now paced per host
and 403/429 retried with backoff, which cut those to 48, and a VERIFY_RETRY_UNKNOWN
pass resolved all 48. Final: 5,882 verified, 73 broken, 5 uncheckable.
Three bugs found and fixed on the way:
- The dead-link drop ran BEFORE the audio merge, so 71 dead filesets attached after the
cleanup and shipped anyway while the pass reported "dropped 0". A cleanup that runs
before the thing it cleans is worse than none, because its count measures an empty
room. Moved after every source attaches.
- A VERIFY_LIMIT smoke run overwrote the real table, destroying the broken-link history
the previous change added. A limit run is now a smoke test that writes nothing.
- The browser gate screened 3,768 of 5,889 links because its harvest never learned the
new field.
Added VERIFY_MISSING=1 so adding one resource costs one request, not a quarter-hour
pass over 5,960 URLs.
Charts, list and map were corrected together: all three still asserted audio had never
been searched, and charts deliberately drew it as a hatched "not measured" row. That
bar is now a real count, decided by hasField() from the data itself. The checked-pools
caveat on every group now names fcbh.
Screenshot read: Uab Meto (aoz) - no Scripture, no film, no stories, not in Zume - now
shows a verified audio link and the caveat lists fcbh as checked.
The Door43 fetcher kept only 3-letter codes and dropped 2-letter ones on the grounds
that turning one into ISO 639-3 would be a guess. The caution was right and the
conclusion was wrong: ISO 639-3 publishes the correspondence itself, in the Part1
column of iso-639-3.tab. The file is now fetched rather than transcribed, so it cannot
go stale, and the run aborts if it comes back with fewer than 150 pairs.
Measured cost of the old behaviour: 32 languages spoken by 2,576 pins - Bengali,
Hindi, Spanish, Amharic, Hausa, English and more - carried Scripture and film but no
Door43 resource at all, purely over a spelling. Door43 reach goes from 169 codes and
1,051 pins to 208 codes and 3,627 pins, 3.58bn people. Table rows 226 -> 391.
ONE EXCLUSION, AND IT IS LOAD-BEARING: a tag with an '-x-' private-use subtag is
skipped on this path. Door43 publishes el-x-koine, Koine Greek, whose base 'el' maps
to 'ell' - Modern Greek, which 13 people groups on this map speak. Folding it in would
have handed those 13 groups a Koine Greek text as though it were their own language.
Region and script subtags (es-419, pt-br, sr-latn, ur-deva, zh-hant) are not private
use and are the same language, so they still fold to the base. Verified: ell is absent
from the index.
Fixed a self-erasing bug in the previous change. Dropping a dead link removed it from
the corpus, so the next verification run never saw it, so the next build put it back -
measured, both links came straight back and REAL URL returned to 8,922. The
verification table is now a RECORD, not a snapshot: it carries forward every URL a
previous run proved broken and keeps re-testing them, which is also what lets a link
the publisher later repairs come back on its own. Proven by dropping them and
re-running: "re-testing 2 URL(s) a previous run recorded broken", still broken, build
now stable across two full cycles.
Clause K's 95% coverage floor is gone, because that floor is exactly how this hid: two
missing URLs out of 3,768 is 99.9%. Every shipped URL must now appear in the record.
Poison self-test 11/11.
All 3,768 links re-verified: 3,761 live, 5 uncheckable, 2 broken and dropped.
Also fixed the chip overflow this change caused - a Door43 entry can be "Aligned Bible
(translationCore-Create-BCS) - Door43 - Portions of both Testaments", which ran off the
edge of a 330px sheet unreadable. Long chips wrap now. Screenshot read: Hindi shows
seven verified Door43 resources, all inside the panel, where it read "none found".
The brief's rule is to verify a URL resolves before shipping it. The table that did
that was written in August against a corpus of 426 links, while the map now ships
3,603 - and the UI matched exactly TWO of them. Two silent causes: its eBible keys
were http:// while every shipped URL now passes through httpsify, and its 306 film
keys were the old ?languageId= URLs that were later replaced wholesale by Arclight
shareUrl deep links. Links that HAD been verified displayed as "unchecked", which a
reader cannot tell apart from "nobody looked".
The old note said the film page was unverifiable by fetch, and for the URL shape it
was written against that was right: ?languageId=13562 and ?languageId=99999999 return
byte-identical HTML, so a status check there is a false green. The shareUrl migration
changed that. A path discriminates:
/watch/jesus/german-standard -> 200, 944,516 bytes
/watch/jesus/pashto-yusufzai -> 200, 810,741 bytes (distinct body)
/watch/jesus/definitely-not-xyzzy -> 404
So 2,049 film links became checkable for the first time. The 5 remaining ?languageId=
URLs stay "unknown" with that reason - never verified, never broken.
Every host was probed with a known-good and a known-bad before being trusted, and all
answer HEAD and discriminate: ebible.org, png.bible, alkitab.pw, jesusfilm.org,
arc.gt, git.door43.org, zume.training. HEAD is deliberate - a GET over 2,049 film
pages is ~1.6GB of someone else's bandwidth to learn a status code. Five negative and
five positive controls run in band and the script aborts rather than write a table if
either arm misbehaves.
Result over 3,603 unique URLs in 365s: 3,596 verified, 5 unknown, and 2 genuinely
dead - arc.gt/092vn (Yakpa, 2 pins) and /watch/jesus/4101 (Zhuang Liujiang, 1 pin),
both re-confirmed 404 with a browser UA and a GET. The builder now drops any link
verification proved dead BEFORE tiers are computed, so a code whose only film is a 404
has no film and its tier says so. The gap filter moves 3,457 -> 3,460, which is
exactly those three pins.
Also fixed: the verification fetch hung off openPin's country branch, so a tap landing
before the country index had loaded left the whole session reading "unchecked". It is
now fetched unconditionally.
Lookup coverage goes from 2/3,605 to 3,603/3,603. New gate clause K fails below a 95%
coverage floor or if any shipped URL is recorded broken; poison self-test now 11/11.
Verified in a browser on the exact case that failed - one immediate pin tap - which
now fetches the table and renders "Scripture - link checked" and "Film - link checked";
screenshot read to confirm both chips are green where they were grey.
Last change joined Zume by exact ISO 639-3 and left pus unjoined, which turned into a
false statement on the map: 13 people groups covering 47.6M speakers read
"Discipleship training - not in Zume's 54" while https://zume.training/pus was live
and in Pashto the whole time. Absence of a variety label is not absence of a resource.
Research for something that selects a variety found nothing that does. The publisher's
launch article scopes Pashto as Afghanistan's other official language and a major
language of northwestern Pakistan, especially Khyber Pakhtunkhwa and parts of
Balochistan - territory spanning all three of pbu, pbt and pst rather than selecting
one. The locale pages declare no language metadata at all: no hreflang alternates, no
BCP-47 tag, and og:locale is the site-wide en_US on every locale including this one.
So it ships as an APPROXIMATE match rather than an exact join or a silence: its own
field, its own dashed chip that reads "Zume, in Pashto (variety not stated)", its own
scope text in the table, never counted as an exact join and unable to move a tier. The
gap filter still cuts 12,379 features to 3,457. It is a curated three-code list, not a
runtime name match - an approximate join a reader cannot see and a gate cannot check is
the one that eventually ships a wrong link.
Why this is defensible here and would not be for film: Zume in Pashto is a written
course in one literary standard, where the pbu/pbt/pst split is largely spoken variety.
The JESUS Film is already in this index under separate per-variety dubs
(pashto-yusufzai, pashto-southern) because a dub differs by pronunciation. The medium
decides.
New gate clause J fails if any code carries both a confirmed and an approximate
training link, or if an approximate entry lacks a url, language or note - that is the
corruption that would make the qualified claim render as the confirmed one. Poison
self-test now 10/10. Both gates also harvest the new field, so its URLs are screened
rather than invisible; the browser gate screens 3,605.
Verified in a browser with three controls: deu renders gm-chip ok with a real href, kri
renders gm-chip meh with no href, pbu renders gm-chip approx linking
https://zume.training/pus and carrying "variety not stated". Screenshot read: the
dashed chip is visibly distinct from both.
The brief names zume.training every tick and an earlier pass recorded the list as
unobtainable. That was wrong. robots.txt Disallows /api/ and the homepage switcher
is client-rendered, both true, but robots.txt also DECLARES a sitemap, and the
publisher maintains /articles/zume-languages for exactly this purpose. Neither is
behind a Disallow. The real figure is 62 locales, not the ~40 estimated: 54 serve a
landing page that answers 200.
The two sources disagree in both directions - Dari and Pashto ship sites but are
missing from the article's table, and eight table rows serve no page yet - so
fetch-zume-index.mjs takes the union and then fetches every landing URL. A locale
ships a link only if its own page answered. Naming and linking stay separate facts.
Pashto is deliberately left unjoined: pus is a macrolanguage, the people-group data
carries pbu, pbt and pst, and nothing the publisher gives selects one.
Training is not Scripture and not film, so it sits in its own field and its own type
and moves NO tier. Measured: the 52 joined languages reach 3,479 pins and 4.78bn
people, and none of them are tier 0 - every Zume language already has Scripture or
film. Folding training into the tiers would have cut the gap count without anyone
having translated anything. The gap filter still cuts 12,379 features to 3,457.
Both gates had a hole this exposed. The coverage gate harvested URLs from s, f and d
only, so the 52 new URLs existed in no pin record it could see; and clause I checked
Film, Scripture and Bible Stories by host but let any other type fall through
unchecked. Both now cover training, and a poisoned row typed Scripture on
zume.training is caught. The browser gate screened 3,550 links and silently ignored
the new ones; it now screens all 3,602.
Verified in a browser with a negative control: deu opens with a chip linking
https://zume.training/de, kri opens with "not in Zume's 54" and no href, no page
errors.
resources-list was the last surface still reading the old 862-language file, and the only
one that BAKED its data in: `import data from './data/resources.json'`, 695KB of JSON
compiled into the shipped JS. Every other profile in this bundle carried that weight,
because they all share one .js — the map paid for the list's dataset on every load.
Fetched at runtime from the pin index instead: 5,067 languages rather than 862, and the
bundle drops 798KB to 317KB, gzip 148KB to 106KB.
★ AND IT RENDERED NOTHING, SILENTLY. I emitted `countries` as a COUNT on the strength of a
comment I wrote in the same edit — "rendered as a count elsewhere in this file" — without
reading the template, which does `l.countries.slice(0, 3).join(', ')`. Result:
"x.countries.slice is not a function", a render-time TypeError Vue logs to the CONSOLE and
does not raise as a pageerror. My probe reported an empty page AND "no page errors", which
is the most misleading pair of signals available here. Only listening for console errors
found it. countries is an array of country NAMES again, resolved through
gospel-by-country with an ISO3 fallback.
★ THE HEADLINE NUMBER MOVED TO 2.99 BILLION and it is true, verified against an
independent count — languages 4,031, groups 7,105, people 2,989,037,834, all three
matching exactly. It is also dangerously misreadable. The largest entries are Javanese
113M, Western Panjabi 101M, Shanghainese 92M, Egyptian Arabic 81M, Cantonese 77M: major
world languages that plainly DO have Scripture, which eBible does not host. Read as "3
billion people have no Bible" it is false; read as "not found in the pools we can reach"
it is exact. The page now names those languages directly under the number rather than
leaving the reader to find the caveat further down.
That figure is also the clearest argument yet for the credentials this build keeps asking
for: the pools that DO carry Javanese and Cantonese Scripture are the ones behind a key.
Verified: no console errors, 1,365 real anchors on ebible/jesusfilm/door43/arc.gt hosts,
and the coverage gate, map gate, dashboard and charts probes all pass.
charts.vue aggregated people-group-resources — 862 languages — while the map beside it
draws 5,067. The charts described a sixth of the corpus and looked authoritative doing it.
Same defect the country sheet had at tick 13, listing 36 groups for Indonesia against 669
pins, and found the same way: by asking which table a surface actually reads.
Now built from the pin index, and every number cross-checked against an independent count
of the same data — 5,067 languages, Scripture 1,036, Full Bible 121, New Testament 1,025,
Film 1,852, Open Bible Stories 101, nothing found 2,758. Six of seven matched exactly.
★ THE SEVENTH DIFFERED BY 2,330,000 AND THAT IS THE INTERESTING ONE. My count said
347,030,459 people behind the gap; the chart said 344,700,459. The difference is exactly
"Arab, Gazan" — the single group with NO ISO 639-3 code. A per-LANGUAGE chart cannot count
a group that has no language, which is correct, but it left the charts and the gaps table
quietly disagreeing by 2.33M. The hero line now says so and points at the table that does
include them. A discrepancy named is a caveat; unnamed it is a contradiction someone finds
later and cannot explain.
THE FOOTER SAID "Pools CHECKED: unknown." over a corpus where we know exactly what was
searched — it was reading meta.sources from the old table. Derived from the codes instead:
"Pools CHECKED: ebible, arclight, door43. Pools NOT checked: grn, api_bible, dbl,
progress_bible." The same understatement the gaps table carried until tick 30.
Audio still renders as not-measured rather than as a zero bar, which is the honest reading
of a pool nobody has looked in — the guard that protects it was rewritten for the new
shape rather than dropped with the old one.
YOUVERSION / BIBLE.COM IS BLOCKED, tried because the brief names it: /languages, /versions
and /api/bible/configuration all return an identical 3,038-byte "Client Challenge" page,
and robots.txt returns that challenge instead of a robots file. Recorded beside GRN as
needing an agreement rather than a scraper.
One self-inflicted note: my edit left an orphaned continuation line and check:sfc-parse
caught it immediately with the right file and line. The build would have failed far from
the edit, which is the failure that gate exists to replace.
Verified: coverage gate, map gate, dashboard and table probes all pass, and the rendered
pools line names all seven pools rather than "unknown".
Checked the new dashboard at phone width before doing anything else, and found a defect I
had been making worse all flight. MEASURED at 390x844: the legend rendered 469px tall over
a 675px map — 69% of the map hidden behind the text describing it — and 484px of a 740px
viewport at 360 wide. The search box added two ticks ago and the pin key added at tick 2
each pushed it further down the screen.
Everything in that legend earns its place on a desktop, where it is 395px of a 900px map
and the map is still legible around it. On a phone the prose has to fold.
Search and the Gap/Resources toggle stay visible, because they are the two controls a
reader actually touches. The key and the caveats fold behind one button — FOLDED, NOT
DELETED. "A red dot can sit on a green country — that is the case worth finding, not a
rendering fault" is the sentence that stops a correct map reading as a bug, so it is one
tap away rather than dropped on small screens.
390x844: legend 469px -> 124px, about 18% of the map, expanding to 507px on demand.
1280x900: no fold button at all and the legend unchanged, so the check discriminates by
viewport rather than always firing.
Also confirmed while there, since a stacked composite is exactly where this goes wrong:
NO horizontal overflow at either 390 or 360 — scrollWidth equals clientWidth at both — and
the dashboard still scrolls to its tables on a phone, 1,999px of document at 390 wide with
8 tabs and 20 rows reachable.
The resize listener is removed on unmount. An element that keeps a window listener after it
is gone is the kind of leak that only shows up in the SPA, where these get mounted and
unmounted as tabs change.
Verified: map gate, coverage gate, and the dashboard, search, filter and scope probes all
pass.
The Driver asked for "a gospel resources dashboard if possible". Both halves already
existed as separate profiles a reader had to know to visit separately — the map answers
WHERE, the tables answer WHAT EXACTLY and give you the list. Neither is improved by being
rebuilt; they are improved by being in one place.
Composed the way this repo already composes: children imported directly and stacked with
StackLayout, as dashboard-plus-grid does, not injected at runtime like stack-demo. Both
children live in THIS bundle, so there is no second script to load and no cross-bundle
version skew — the tables you scroll to are built from the same pin index the map above
them is drawing.
★ IT RENDERED, AND IT WAS UNREACHABLE. Both children are .gt/.gm {position:absolute;
inset:0} — correct when each IS the whole page, and fatal when stacked, because neither
has intrinsic height. The tables section collapsed and the host clamped to exactly one
viewport: MEASURED documentElement.scrollHeight 900 against clientHeight 900, with
scrollTo AND a real wheel gesture both moving 0px. A probe counted 50 table rows and 8
tabs the whole time. Rendered, counted, and invisible to a person is the worst of the
three, and only measuring the scroll geometry caught it.
The tables are made static inside the composite so the section takes its natural height
and the PAGE scrolls — 1,638px of document against a 900px viewport, wheel and scrollTo
both reaching 738. ONE scroll container, not a scroller inside a scroller; this repo has
already fixed the nested-scroll version of this twice. The map keeps a real height,
because a map with no height paints a zero-pixel canvas that reads as "did not load".
TWO FURTHER THINGS THE BUILD TAUGHT. The profile first came out isMap:false, so its leaf
page shipped without the Mapbox script and the map failed with "mapbox-gl not loaded" —
fixed by declaring what it composes in gospel-dashboard.meta.json, the same mechanism
dashboard-plus-grid uses. And the probe's first assertion demanded every pin be rendered;
in a 720px map three sit off-screen, so it now asserts substantially all of them —
queryRenderedFeatures reports the VIEWPORT, not the layer.
Verified: 12,379 pins loaded with 12,376 rendered at 720px, a live canvas, 8 tabs and 50
table rows below the fold and reachable, and the map gate, coverage gate, descriptions,
composite-registration and orphan-gate checks all pass.
The gallery and the plugin-studio — the surfaces a new developer or an inheritor opens to
learn what is here — described a plugin that stopped existing twenty ticks ago.
resources-map read "Every country shaded by how much of its unengaged population has NO
gospel resource": the choropleth, and nothing about the 12,379 people-group pins, the real
per-group links, the search or the gap filter. data-tables read "Two validated tables"
when there are eight. Someone browsing for a tool that maps gospel resources per people
group would not have learned that this is one.
★ AND A LONGER DESCRIPTION WOULD HAVE MADE IT WORSE. generate-tree extracts with
/^\s*\*\s*@([\w-]+)\s+(.+?)\s*$/gm — ONE LINE. A wrapped @description silently ships only
its first line, so my first rewrite ended mid-sentence on the word "and", which is worse
than the stale text it replaced. All four profiles are now a single complete sentence.
THIS IS NOT LOCAL. 27 profiles across the repo ship a description that ends mid-sentence,
including doxa-maps-spa — the flagship SPA — and big-picture, cities-internet and
all-people-groups. check:profile-descriptions asserts a description EXISTS, not that it is
a whole sentence, so all 27 pass. Fixing this bundle takes it to 23. The rest are other
bundles' and are left alone rather than failing a shared gate on work that is not mine;
the measurement is here for whoever owns them.
The gallery also had to be regenerated: it is written by `bun run gallery` from the
manifest, so updating the source docblocks moved the manifest and left the gallery HTML
stale. Both now carry the new text; verified by searching the built gallery for it.
Verified: 4 of 4 profiles in this bundle end in a full stop, the manifest carries the
complete text, the built gallery contains it, and the coverage gate, descriptions gate,
SRI check and map gate all pass.
The performance worry that started this tick was unfounded and measured as such: the new
gaps table reaches first rows in 1,021ms, second-fastest of the four large tabs and ahead
of Gaps & Opportunities at 1,910ms. 901KB raw but 106KB gzipped, and smaller than the
1.8MB tables already shipping. Nothing to fix.
Reading that table found something that did need fixing. 2,608 of its 3,457 rows — 75% —
carried an EMPTY "pools checked" and listed eBible, Arclight and Door43 as NOT checked.
That is backwards. This build scans all three catalogues in full; a code reaching the
naming pass is absent from every one of them, verified — 0 of the 2,248 such codes appear
in any catalogue. "Not checked" reads as "we do not know". The truth is the stronger and
far more useful "we searched three catalogues and it is not there", which is exactly the
distinction a mobiliser needs when deciding where to work.
A FURTHER 849 ROWS had the same understatement in milder form, claiming only "ebible,
arclight" because their records predate the Door43 pass — though Door43 had in fact been
searched for them too. Provenance is now stamped once, uniformly, over every code: the
three catalogues this build actually scans are named as checked, and the four that
genuinely were not — GRN, api.bible, DBL, Progress Bible, all credential-gated — are the
only things the unchecked list ever names. 3,456 of 3,457 rows now state it correctly.
THE ONE REMAINING ROW IS HONESTLY EMPTY and now says why. "Arab, Gazan", 2,330,000 people,
has no ISO 639-3 code in the source at all, so nothing could be looked up — there was
nothing to look up WITH. Two blank cells read as an oversight; the row now reads "no
language code in the source — no lookup possible".
This moves the map's claims in the direction of knowing MORE, not less, which is the rarer
correction here — the previous eleven went the other way.
Verified: 0 rows left with blank provenance, the coverage gate and map gate pass, the gaps
tab still renders with both export buttons, and the country filter still isolates Chad at
94 and Nepal at 54.
Every table in this bundle lists what EXISTS. The map can filter to the gap and rank its
40 largest, but 40 is a preview and a map is not something you hand to a prayer group or
work through in a spreadsheet. There was no exportable list of what is missing.
"Where Nothing Was Found" is that list: 3,457 people groups, 347,030,459 people, 183 of
them speaking a sign language. Largest first, with CSV and JSON export already provided by
the shared table.
IT IS NOT THE EXISTING "GAPS & OPPORTUNITIES" TABLE and could not have been folded into
it. That one is one row per group across the curated 2,106-record set, so it structurally
cannot see these 3,457. It keeps its own job — bridge-language analysis for the groups it
does cover — and this sits beside it.
EVERY ROW CARRIES ITS OWN PROVENANCE: checked_pools and unchecked_pools travel with the
data, so an exported CSV cannot be read as a finding about the world. Rows with an EMPTY
"pools checked" are groups whose language was in no resource table at all, and they say so
rather than looking identical to a group that was searched and came back empty. The meta
states outright that audio has never been searched for any group here.
THE COUNTRY CLICK NOW REACHES IT. The deep-link filter applied only to the resource table,
so a country click could show what a country HAS and never what it lacks — the half a
mobiliser came for. Chad: 94 of 3,457. Nepal: 54. Both match the map's own country sheet
exactly, which is the check that the two surfaces are describing the same groups.
180 ROWS PRINTED A RAW ISO3 IN THE COUNTRY COLUMN — "CHE", plus Canada, Taiwan,
Timor-Leste, Mexico, Argentina. gospel-by-country knows 170 countries and the boundaries
file 162, while the pins span 242. Names now come from people-groups-slim, the source the
pins were built from, so coverage matches by construction rather than by luck; the curated
spellings still win where they exist. 180 -> 1. The one left is Kosovo, whose ISO coding is
genuinely contested across datasets, and its row is named "Deaf of Kosovo" so no reader is
misled — one honest code beats starting a hand-written country table.
Verified: the tab renders 3,457 rows with all eight columns and both export buttons, the
country filter isolates Chad and Nepal correctly, and the coverage gate plus the table and
deep-link probes all pass.
Search made a group findable last tick; nothing made it sendable. A colleague could be
pointed at the map but not at the Fulani group you had just spent five minutes locating —
the Share button emitted the same URL no matter what was open.
It now carries the selection: ?code=<iso639-3>&country=<iso3>&name=<people group>, and the
map reopens that group on load, flying to it.
★ KEYED ON code+country+name, NEVER ON THE PIN INDEX. The index is a position in a
generated table and shifts every time the pins are rebuilt — which has happened eight
times this flight. An index-based link would keep working and silently open a DIFFERENT
people group after the next data refresh. A link that rots into a wrong answer is far
worse than one that breaks, and this map's whole discipline is not handing someone the
resources for the wrong people.
The query rides on ShareButton's embedPath rather than teaching that component about
parameters: it has four other consumers and none of them need this. Zero blast radius.
Verified end to end on the served tree, in a FRESH page rather than the one that made the
link: opening German emits
?code=deu&country=BEL&name=German, and loading that URL reopens German (deu) at zoom 4.2.
NEGATIVE CONTROL: ?code=zzq&country=ZZZ&name=Nobody opens no group at all, so the resolver
discriminates rather than falling back to whatever is first.
The repo's own smoke:share-all passes this bundle — share → reopened <gospel-resources-map>,
canvas:y. It reports one failure elsewhere, my-upg-100-list/upg-100-list "no Share button
found", which predates this flight: commit ca4343c "UPG-100 drops its duplicate share" is
an ancestor of my first commit. Not mine, and left alone.
12,379 dots and no way to reach a named one. Everything built so far answers "show me the
gap" — the filter, the ranked list, the country view — and none of it answers the question
a person actually arrives with: where is Fulani, where is Uzbek. Finding one meant hunting
the map by eye.
The legend now opens with a search that matches a people-group NAME, its LANGUAGE, or its
ISO 639-3 code, because a user turns up knowing whichever of the three they happen to
know. Results carry the tier dot, so you can see before clicking whether that group has
anything. Tapping one flies there and opens it.
SUBSTRING, NOT FUZZY, and that is the load-bearing choice. A fuzzy match over 12,379 rows
returns plausible WRONG groups, and handing someone the resources for a similarly-named
people is precisely the failure this map is careful about everywhere else — it is why the
language join is an exact ISO code and never a name. A search that quietly suggests the
wrong Fulani is worse than one that finds nothing.
Sorted by population, because "Fulani" matches dozens of groups and the largest is the one
most likely meant. Capped at 8 with a count of the rest, so a broad word does not bury the
legend.
Built inline rather than importing library SearchBar: the shared component injects its own
styles, and whether that lands inside THIS shadow root was unverified — an unstyled search
box would have been a worse outcome than eleven lines of CSS in the palette already here.
Verified on the served tree: "fulani" returns 8 rows led by Adamawa and Sokoto Fulani,
the ISO code "deu" returns German and Austrian, a nonsense string returns 0 — so the
search discriminates rather than always matching — and clicking Uzbek moves the map from
zoom 1.3 to 4.2 and opens Uzbek, 28,470,000 people. Coverage gate, the map gate, and the
pins, filter, gap-list and scope probes all pass.
Registering a gate is not enough to make it run. verify:browser-all is invoked NOWHERE in
this repo; build:unlocked runs only `bun run verify`, and verify-all.mjs skips anything
marked browser:true unless --full is passed. That is precisely how two gates rotted here
before — "both had rotted unnoticed precisely because the build chain has never run them".
A gate whose precondition is "remember to start a server first" has a precondition nobody
remembers.
So the precondition is gone. If nothing answers, the gate spawns serve-strict on an
ephemeral port — ephemeral so two gates running at once cannot collide on 4173 — and shuts
it down afterwards. `bun run verify:gospel-map` now works from a clean shell with no setup.
An explicitly named BASE_URL or argv is honoured and never auto-served: a caller naming a
host means it, and quietly pointing at a different tree would be worse than skipping.
Verified — a dead explicit URL SKIPs and starts nothing.
★ THE FAILURE PATH LEAKED A PROCESS AND THE PASS PATH DID NOT. process.exit(1) inside the
try terminates before the finally block's cleanup runs, so a failing run left its spawned
server alive: measured 0 strays after a pass, 1 after a fail. A gate that leaks only when
it fails leaks exactly when someone is re-running it to see what broke. The exit code is
now set, not thrown, and the process exits after cleanup. Re-measured from a clean
baseline: 0 strays after pass, after fail, and after restore.
One scare worth recording: a stray server DID show up mid-test and it was the orphan from
the pre-fix run, six minutes older than the code being tested. Checking its start time
rather than its existence is what told them apart.
Every browser check written for this bundle lived in _qa-cycle/, which is gitignored: a
dozen probes proving the pins render, the sheet opens with real links and the deep link
filters the table — all of which disappear with the working tree. check:coverage-consistent
guards the DATA and cannot see the map at all. The repo has carded orphaned gates twice;
this is the same loss one step earlier, a gate that was never committed.
It asserts, against the SHIPPED tree through the production-parity server: the element
mounts and exposes its state handle (a stale-SRI leaf silently refuses to execute, which
looks identical to a mount failure); every pin in the source is RENDERED, not merely
loaded; a tap opens a group with a NAMED language; the table deep-link carries that
group's own ISO code; and the gap filter leaves only tier 0.
★ IT TOOK THREE TRIES TO MAKE IT WORTH TRUSTING, and each failure is the point.
FIRST it was FLAKY — 1 run in 3. Clause 4 waited a fixed 900ms after clicking the filter,
but setFilter is applied asynchronously, so it queried mid-transition and still saw tier 1
and 2. It now waits for the map's own idle event. 5 of 5 runs clean. A gate that fails a
third of the time on correct code is a gate that gets switched off.
SECOND its doctrine check had a SAMPLE SIZE OF 1. It validated the two URLs of the one
group it happened to open — 1 of 2,685 codes — so a jw.org link planted anywhere else
passed cleanly. MEASURED: the injection did not fail the gate until the scan covered the
whole index. It now checks all 3,550 links, and fails if the index carries none at all,
because a scan over nothing passes vacuously.
THIRD, adversarially tested end to end: with jw.org injected on code `tel` the gate exits
1 naming the publisher; restored, it exits 0; the file's md5 is unchanged either side.
Registered in package.json and in verify-browser-all's GATES array — check:no-orphan-gates
confirms it, and check:quoted-scripts passes. Without a server it SKIPS loudly with the
command to start one, rather than passing quietly.
70 story sets were typed as Scripture for seven ticks because NOTHING compared a row's
label to where it points. Clause H, added last tick, catches that exact mislabel. It would
not have caught the same mistake made anywhere else.
Clause I asserts the general shape: Film only on jesusfilm.org or arc.gt, Bible Stories
only on git.door43.org and only under that name, Scripture never on a film host. Audited
across all 3,550 rows first — 0 violations, plus 0 duplicate (language, url) pairs — so
this ships as a guard rather than a fix. The 8 languages carrying more than one Scripture
URL were checked and are correct: Cebuano really does have an eBible ULB alongside Door43's
ULB and UDB, which is three translations, not three copies.
THE PASS LINE NOW NAMES EVERY CLAUSE. It listed four of nine, which reads as a narrower
check than it is, and the next reader calibrates their trust on that line rather than on
the source. Nine clauses, nine names, and --poison still fails 9/9 on demand.
The table also states its scope breakdown where a reader meets it — 855 New Testament, 254
Portions of both Testaments, 136 Full Bible, 14 Old Testament, 13 Portions — with the
reason it is counted from each publication's own book list rather than its subject label.
"How much Scripture exists" is the question under every other number in that table and it
was previously visible only by sorting a column.
Verified: gate passes, self-test 9/9, the table renders its new Scope column, and pins,
scope and deep-link probes all pass.
Door43 entries carry their own book list. Each ingredient is categorised bible-ot or
bible-nt, so a Door43 Scripture entry can say how much Scripture it is, exactly as an
eBible one does — and it is already in the response we fetch, so this costs no extra
requests. 35 entries scoped: 15 New Testament, 13 Portions, 4 Full Bible, 3 Portions of
both Testaments.
THE SUBJECT LABEL IS NOT THE SCOPE, which is why it is counted from the data. An entry
filed under "Bible" can be 27 NT books and nothing else. Calling that a Bible because of
its folder name is the same error as calling Open Bible Stories Scripture.
★ AND THAT ERROR WAS ALREADY SHIPPING, 70 ROWS OF IT, BY MY OWN HAND. Tick 15 added owner
disambiguation so two same-named entries could be told apart — "Open Bible Stories
(OBS-TLF)". The type test was `d.s === 'Open Bible Stories'`, an exact match, so every
disambiguated label fell through to Scripture. 70 story sets have been typed as Scripture
for seven ticks: Bhojpuri, Maithili and 68 more told a reader they had a translation when
they have 50 illustrated narratives. Found only because the type counts moved when this
tick changed the test to a prefix.
An exact match against a label that can grow a suffix is the whole defect, and the fix is
not enough on its own — so clause H now asserts that nothing named "Open Bible Stories" is
typed as Scripture, poisoned with the rest. 8/8 clauses fail on demand.
The Door43 chip in the sheet had the same exact-match and now reads "Bible Stories
(OBS-TLF) · Door43 · <scope>". The one `===` left in the fetcher is correct and was
checked rather than blanket-replaced: it compares the RAW subject from the API, which
never carries an owner suffix.
Every Scripture row on the map now has a scope. The 2,278 blanks reconcile exactly to
2,087 film plus 191 Bible Stories — none of which is a portion of the canon.
Verified: gate passes, its self-test fails 8/8 on demand, and the Door43, pins, table,
scope and deep-link probes all pass.
Last tick left 547 Scripture links with no scope and 24 with no name. Both had a cause
worth finding rather than papering over.
★ THE 547 WERE A PATCH THAT SILENTLY DID NOTHING. Two code paths create an eBible entry.
The edit that added `ss` matched a string containing httpsify(ee.u); the second path reads
`s: ee.u` without it, so the replacement found no match, reported success, and changed
nothing. 523 entries kept a title and a full-Bible flag while losing their scope — a
half-applied change is harder to see than a failed one, because every field you happen to
check is present. That branch now sets every field the other branch sets.
Scope coverage 690 -> 1,213.
THE 24 POINT AT AN OLDER EDITION than the catalogue's current pick — tel2010 where the
catalogue says tel2017, ben2006 where it says benobcv. BOTH RESOLVE, checked 8 of 8 at
200, so the curated choice is a choice and fill-never-overwrite keeps it. What was missing
was only the description, and the language index cannot supply it: it answers "the best
translation for this code", not "what is THIS link". The catalogue is now also indexed BY
URL, 1,545 entries, so a link is described by the edition it actually points to. Telugu
keeps ebible.org/tel2010/ and is now named "Telugu Easy Reading Version — Full Bible".
RESULT: 1,237 of 1,237 Scripture links carry a real translation name and a scope. Zero
rows still read "Scripture in this language". 840 New Testament, 251 Portions of both
Testaments, 132 Full Bible, 14 Old Testament.
The 2,311 blank scopes in the table reconcile exactly — 2,087 film, 121 Bible Stories and
103 Door43 Scripture entries, which are not eBible publications and have no book counts to
scope. Blank there is the honest answer, not a gap.
Verified: the scope line renders on a real group and is ABSENT on a group with no
Scripture, so it still discriminates; coverage gate passes; pins, table and deep-link
probes pass.
Every Scripture row on this map said "Scripture". The catalogue knows the translation's
actual name for 1,213 of the 1,237 languages that have one, and the difference it hides is
the one a mobiliser most needs: "Ahirani Matthew and Mark" is two Gospels, "Bhadrawahi
Bible" is a Bible. The table said "Scripture in this language" on all 1,237 rows and the
sheet showed a bare chip.
The sheet now names the translation and its scope — "German ELBBK Bible — Full Bible" —
and the table carries the real name in its Resource column plus a new Scope column: 101
Full Bible, 461 New Testament, 122 Portions of both Testaments, 6 Old Testament. Scope is
its own column rather than folded into Type, so Type stays a clean three-value filter.
SCOPE DESCRIBES THE TRANSLATION WE ACTUALLY LINK TO. A curated scripture_url pointing at
the same eBible page inherits it; one pointing elsewhere does NOT, because the catalogue's
book counts would then be describing a different publication. That distinction recovered
96 entries and correctly leaves 547 blank rather than guessing.
EBIBLE LINKS WERE THE TICK'S ACTUAL QUESTION and they came back clean: ebible.org/cmn2006/
renders the Mandarin Bible with its full book list in-script, png.bible/aai/ renders
Minaifia NT from Matthew to Revelation. They land where a person can read, which is what
the film links did not do. The scope work came out of reading those pages.
★ THE DEEP-LINK PROBE FAILED ON THIS COMMIT AND THE PRODUCT WAS FINE. It read the ISO code
from cell index 4; inserting the Scope column moved it to 5, so it reported a filter
failure while the filter was returning exactly the right 2 rows. It now finds the column
by its HEADER. A column index is a position, a header is a contract — the same mistake the
tooltip probe made two ticks ago by asserting wording instead of the rule.
Verified: the scope line renders "German ELBBK Bible — Full Bible" on a real group and is
ABSENT on a group with no scope, so it discriminates. Coverage gate passes, its self-test
still fails 7/7 on demand, and pins, table, deep-link, tooltip and sign probes all pass.
Two ticks ago this repo recorded that Scripture Earth was rejected because its JESUS Film
links are dead, on the evidence that the /watch/jesus.html/<slug>.html scheme 404s —
english.html included, so not merely rare languages. That was wrong, and it was published
where the next agent would inherit it.
It 404s TO A SERVER-SIDE FETCH ONLY. Loaded in a browser, jesus.html/english.html and the
Ghotuo link both render "FEATURE FILM JESUS · 128 min FHD", and a bogus slug renders
"404 PAGE NOT FOUND". The scheme is alive. The lesson was already in this file for
?languageId= and I applied it inconsistently: no jesusfilm.org URL can be graded by
fetching, because the site is client-routed — a fetch 404s pages that work and returns a
shell for pages that do not.
THE REJECTION STANDS, for the reason that actually holds. MEASURED on a random sample of
20 of the 730 tier-0 languages with a Scripture Earth directory: 19 are EMPTY — no video
files, mostly no subdirectories at all. A code directory is a roster row, not a resource.
Perhaps ~5% hold something real, recoverable only by crawling all 730, which is now
recorded as a small-return future option rather than a dead end.
This is the difference between rejecting a source and rejecting it for a reason that is
true. The first would have been re-litigated the moment someone opened one of those links
and watched it play.
ALSO VERIFIED, since the tick started there: all 33 arc.gt links we ship resolve to a real
JESUS Film page — every one, not a sample. Arclight returns those shortlinks as the
shareUrl for some languages, notably American, Russian and Iranian Sign Language, which
matters because sign languages are the emptiest part of this map. A bogus keyword answers
with JSON, {"error":"Keyword not found or invalid"}, NOT a 404 page — so the probe's
control had been grading the bogus case as alive and failing for the wrong reason. Fixed,
and the string recorded so the next check knows what a dead arc.gt looks like.
1,237 of the URLs we ship were plain http — all of eBible.org, png.bible and alkitab.pw,
with the host spelled `eBible.org` on six of them. Every one of those hosts serves https
directly (sampled 12/12 at 200) and redirects http there anyway, so the plain link bought
nothing but a redirect hop and a downgraded scheme in a field worker's browser, on a page
that may itself be embedded over https.
NORMALISED WHERE A URL ENTERS THE INDEX, not per fetcher. Doing it in the eBible fetcher
first left 120 links behind — the curated scripture_url values, which fill-never-overwrite
preserves and which therefore never pass through a fetcher at all. One httpsify at every
emit point takes it to 3,548 https and 0 http.
Scheme and HOST only. The path is left exactly as published, because a path is
case-sensitive and "tidying" it would break the link rather than improve it.
★ THE GATE CAUGHT MY OWN DRIFT, ten seconds after I added the clause. Clause G failed —
but as clause E, "1237 table URL(s) exist in no pin record": I had rebuilt the pins and
not the table, so the two surfaces disagreed about every eBible link in the corpus. That
is precisely the class this gate was written for last tick, and it found it on its first
real use rather than three ticks later by hand.
Clause G is poisoned in the self-test alongside the rest: 7/7 clauses now fail on demand.
Verified: 0 plain-http URLs remain, six upgraded links sampled live all answer 200 over
https, the coverage gate passes, and pins, table, deep-link, tooltip and list probes all
still pass.
Last tick established that ?languageId= is ignored by the site — a real id and a bogus id
render the same generic library — so 2,087 groups had a film link that did not take them
to the film. Arclight publishes the missing piece: media-components/1_jf-0-0/languages/<id>
returns a shareUrl, and that IS a deep link — jesusfilm.org/watch/jesus/<language-slug>.
2,082 of 2,087 languages now carry one; 304 existing links were upgraded in place and the
rest were written as deep links from the start. The 5 with no shareUrl keep the old URL
and their tooltip says so, rather than every group getting the same hedge.
FETCHED, NOT DERIVED, and that was the judgement call. The slug looks derivable — "Pashto,
Southern" -> pashto-southern, and 8 of 8 sampled names transformed correctly. Eight is not
2,087, and a wrong slug is not a broken link but a link to SOMEONE ELSE'S language, which
is the worst failure available here. So the API was asked 2,087 times, rate-limited at
250ms, cached and resumable so it is asked once. 5 missing, 0 wrong.
★ AND THIS CHECK CAN FAIL, which none of the previous jesusfilm checks could. A real slug
returns a page carrying the media component id `1_jf-0-0`; a bogus slug returns 0 of them.
Sampled 8 deep links: 8 real, 0 bad, and the bogus control returns 0 hits. In a browser
the Bhilali link renders "FEATURE FILM JESUS · Watch now · 128 min FHD" while the bogus
slug renders "404 PAGE NOT FOUND". That is the first time a jesusfilm URL has been
verified rather than assumed in either direction.
THE TOOLTIP PROBE FAILED ON THIS COMMIT, correctly: it asserted the old caveat wording, so
fixing the links broke the test that described the defect. It now asserts the CONTRACT —
a deep link must NOT carry the caveat and a legacy link MUST — which survives the next
change to the words.
SOURCES-CHECKED-AND-REJECTED.md records the shareUrl endpoint and the `1_jf-0-0`
discriminator, so the next agent inherits the answer instead of the dead end.
Verified: coverage gate, pins, table and deep-link probes all pass; the film chip on
German renders the real deep link with the accurate tooltip.
A tick spent on Scripture Earth ended by turning the check on our own links, and they do
not do what the chip implies.
MEASURED IN A BROWSER: https://www.jesusfilm.org/watch/?languageId=<id> renders the same
generic library page for id 529, for id 1304, and for id 999999999. languageId is a query
parameter on a client-rendered page and the current site ignores it. The film is real —
the JESUS Film Project's own API confirms a feature film in that language — but the URL
does not carry you to it, and the tooltip said nothing about that. A field worker follows
the link and has to find the language themselves. The chip now says so.
★ THE URL CANNOT BE VERIFIED BY FETCHING, IN EITHER DIRECTION, and both wrong answers are
available. The server returns a byte-identical 867,227-byte shell for every id: grading by
STATUS reports ALIVE for everything, including a bogus id; grading by CONTENT reports DEAD
for everything, because "WatchNotFound" lives in an i18n bundle present on every page. I
ran the content check first and it returned 10 of 10 of our own links DEAD — Fon and
Southern Pashto among them, which is not believable, and that implausibility is the only
thing that caught it. Reported as-is it would have ripped out 2,087 correct links.
No constructible scheme works either: the legacy /watch/jesus.html/<slug>.html form is
retired (english.html 404s, not just rare languages) and /watch/<slug>.html/videos — a
shape the live page itself renders — also 404s to a fetch, resolving client-side. The
Arclight API is the only thing that discriminates, and it stays the basis for the claim.
SCRIPTURE EARTH IS REJECTED, with the reasoning kept next to the code so the next agent
does not re-walk it. Its /data/ index looks like the largest win available — 3,477 ISO
639-3 directories, 730 of them languages we currently show as "nothing found" — and it is
not coverage: aab/video and aac/video are EMPTY, its JESUS Film links use the retired
scheme, and it files Ghotuo under `aaa` where the publisher files it under `ikh`. Shipping
from it would have added ~730 dead links to the groups that most need real ones.
SOURCES-CHECKED-AND-REJECTED.md records that, plus what is credential-blocked and why,
plus that sign.bible is a parked domain answering 200. It sits beside the bundle rather
than in _qa-cycle, which is gitignored — a note the next agent cannot read is not a note.
Verified: the film chip's title renders the honest text on a real group (German), and the
pins, country and table probes still pass.
Three defects this flight were the same defect, and none of them threw. Every page
rendered; only comparing two surfaces caught them:
the country sheet listed 36 groups for Indonesia while the map drew 669 pins, because
the sheet read a curated subset and the map read the pins;
the resource table silently dropped 506 real resources across 377 languages, because
its generator skipped any code no pin speaks — in a table titled "every link";
resources attached to `und` told 14 people groups there was Scripture in a language
the record explicitly does not identify.
A fourth is a matter of time, so the comparison becomes a gate rather than a habit.
SIX CLAUSES, all static, 60ms, no browser and no server: no ISO reserved code carries a
resource; every resourced code has a language name; the table's reach columns match an
independent recount off the pins; every resourced code appears in the table; no table URL
exists that the pin index does not hold; and each pin's tier agrees with its code's URLs.
Each one is a defect that was actually shipped, not a hypothetical.
★ IT REFUSES TO PASS VACUOUSLY. Five of six clauses assert a NEGATIVE, which is exactly
the shape that reads green against empty or mis-keyed input, so an empty corpus is a FAIL
rather than a clean run, and a missing input SKIPS loudly with the command to fix it.
★ AND IT SELF-TESTS. `--poison` injects one defect per clause in memory and requires all
six to fail. Clause D is included deliberately: it is the one that would have caught the
506 dropped resources, and the first version of this self-test left it unproven — the
most valuable clause was the one clause never shown to fail. 6/6 now.
Registered in package.json and in build:unlocked, because a gate nothing runs is not a
gate — this repo has carded that twice. check:no-orphan-gates went from FAIL to PASS on
registration, which is the check confirming itself. The CLI doc quotes the build chain
verbatim, so it was updated to match: package.json is what runs, the doc is the copy.
No product file changed, so nothing is rebuilt. check:quoted-scripts, check:doc-scripts,
check:no-orphan-gates and check:mjs-parse all pass.
Reading the list profile's own screenshot turned up a row for "Undetermined (und)" —
14 people groups — offering two Open Bible Stories links. ISO 639-3 reserves und, mul,
mis, zxx and qaa-qtz for exactly the case where the language is NOT known, so a resource
attached to one is attached to nothing. Telling 14 groups there is Scripture in their
language when the record says the language is undetermined is the single worst thing this
map can do, and it took looking at the page to see it. Door43 publishes 4 entries under
und; 16 pins sit on a special code. All are now excluded at the index.
COVERAGE GOES DOWN, 8,935 -> 8,921 pins with a real URL. That is the right direction: the
14 were false.
The same screenshot showed Dogri rendering "Open Bible Stories Open Bible Stories" —
two links a reader cannot tell apart. 40 languages carry more than one entry under the
same subject, because a language can have more than one independent translation effort.
The owner now disambiguates, and ONLY where it is needed: Dogri reads "Open Bible Stories
(translationCore-Create-BCS)" and "(OBS-TLF)", while a language with one entry is
unchanged.
The list profile also gained the pool it predated. It bundles its own resources.json at
build time, so Door43 never reached it: 49 languages, 63 links. Checked before writing —
120 of its 862 languages already carry a scripture link and those are exactly the 120 the
enriched index has, so nothing there needed correcting, and its curated 862-language scope
is this profile's subject rather than staleness. The enrichment is idempotent: it drops
what a previous run added before re-adding, or a stale title would survive the index
learning to disambiguate.
NOT DONE, DELIBERATELY: the 506 zero-reach rows still never match a COUNTRY filter.
Arclight carries a primaryCountryId that could attribute them, but the only alpha-2 to
alpha-3 mapping in this repo disagrees with itself on 18 countries and cannot resolve 51
of the 168 codes. A wrong attribution would point a real link at the wrong field, so the
behaviour is documented in the table meta instead of guessed at.
Verified: und/mul/mis/zxx absent from the index, the list renders 49 Door43 anchors where
it rendered none, three sampled new links answer 200, and pins, table, deep-link, country
and sign-language probes all still pass.
The table is titled "every link" and was silently dropping 506 real resources across 377
languages, because the generator skipped any code with no people group on this map. They
are not edge cases: Ahirani has Scripture, a film and Open Bible Stories; Pahari Mahasui
has Scripture, a film and five Door43 resources. Someone searching for that language
still needs to find it, and the reach columns reading 0 is the true answer to "how many
groups on THIS map speak it" rather than a reason to hide the resource.
3,043 -> 3,549 rows, 2,307 -> 2,684 languages. The meta says what a zero-reach row means
so the column is not read as "this resource reaches nobody".
THE INCLUSION EXPOSED A BLANK. Those codes are named nowhere in the people-group dataset
— it only names languages some group speaks — so their rows rendered a bare ISO code with
an empty language column, which tells a reader looking for a language precisely nothing.
The eBible index now carries languageNameInEnglish alongside the translation title (two
different things), and a final pass names any remaining code from whichever catalogue
knows it. Codes carrying a resource with no language name: 377 -> 0.
An audit of the reach columns against an independent recount off the pins found 0
disagreements on people_groups and 0 on speakers, so the table and the map agree about
who speaks what.
Verified: a seeded sample of 12 newly-exposed rows — 9 resolved 200, 3 skipped as
unverifiable, because jesusfilm.org/watch answers 200 for any id and a status check there
proves nothing. Three Door43 links first returned 000, which is curl failing to CONNECT
rather than an HTTP status; retried with spacing they all answer 200, so the failure was
my own request rate and not a dead link. Table, deep-link, pins, gap-list and country
probes all still pass, and the country sheet still never fetches the retired 1.4MB file.
The country sheet was built from people-group-resources.json, a curated 2,106-record
subset, while the map draws 12,379 pins. The two described different universes and the
sheet silently undercounted. MEASURED before this change: Indonesia listed 36 groups with
669 pins under your finger, Nigeria 38 against 433, India 899 against 2,146. A map that
contradicts itself on tap is worse than one that says less.
Matching was also done by PARSING a comma-separated country-name string against a
longest-first vocabulary — a second way to lose rows, since a name that does not match
the vocabulary exactly drops out with no error. Pins carry ISO3, so the index is now an
exact key rather than a text search.
ONE SHAPE, BUILT IN ONE PLACE. openPin used to assemble its own group object while the
country list built another, so a field added to one path silently did not exist on the
other — which is how is_sign and the Door43 list would have gone missing from a group
opened out of a country. groupAt(i) is now the only constructor.
THE HEADER HAD TO FOLLOW, and reading the screenshot is what caught it. Moving the list
to the pins left the stat block still reading the curated table, so the card contradicted
itself inside one view: "People groups 36" sitting directly above "Gospel resources found
(282)". The stats are now derived from the same groupsForCountry the list renders.
Growing-and-unreached and deaths/day are NOT derivable from pins — they come from the
curated analysis — so they are marked and footnoted with how many groups that analysis
actually covers, rather than sitting unlabelled among numbers with a different basis.
RETIRES A 1.4MB FETCH. people-group-resources.json is no longer requested at all: the
pins are already in memory and carry richer resource data than that file ever did. Only
the 136KB link-verification fetch remains, and it is still allowed to fail.
Verified on the served tree: for IDN, NGA, IND, NPL and TCD the sheet's group count now
equals the layer's pin count exactly (669/669, 433/433, 2146/2146, 171/171, 150/150), and
with + without partitions the total in every case. The network log confirms
people-group-resources.json is never fetched. Indonesia reads 669 groups, 387 with
nothing, 282 with a resource — and 669 - 387 = 282. All seven browser probes still pass.
MEASURED: has_audio is 'unknown' for all 2,106 source records and therefore for all
12,379 pins. Not one group on this map has had its audio checked, because GRN — the main
audio-gospel pool — is named as unchecked on every record. The map was nonetheless
showing 3,444 groups as "nothing found", covering 347,125,659 people, and for an oral
culture audio is not one resource among several, it is the one that matters.
So the claim was overstated in the place it is least affordable. Three changes, all copy,
no data:
The audio chip said "unknown", which did no work — it is unknown for EVERY group, so it
read as a property of that group rather than of our search. It now says "not searched
(GRN)" and names the pool in its tooltip. A shrug becomes something a reader can act on.
The gap list now leads with it: 3,444 groups, 347,125,659 people, and "Audio has never
been searched for any of them" before the ranked rows rather than after.
The legend caveat names the pool and what its absence costs, instead of the passing
"GRN audio is unchecked".
NOT ADDED, DELIBERATELY: Arclight publishes an audioPreview for 2,074 of these codes and
it is a real, resolving URL. It is also ~24.4KB of AAC — MEASURED at a uniform 11.8
seconds — a language-identification sample, not Scripture. Shipping it under "Audio ·
found" would be the same error as calling Open Bible Stories a Bible, so it is left out.
Real audio still needs GRN or FCBH credentials.
Verified on the served tree: the legend carries the warning, a group sheet reads "Audio ·
not searched (GRN)" with no bare "unknown" anywhere in it, the gap panel carries the
sentence, and the people-count renders 347,125,659 — the same number the build measures.
Pins, filter, gap-list and sign-language probes all still pass.
A sign language cannot be served by a text translation at all. eBible is a text pool, so
its silence for a Deaf group describes OUR SEARCH, not their need — and the sheet was
reporting it as "Scripture · none found" exactly as it does for a spoken language. That
is the map telling a true-sounding thing that misleads.
Sign languages are now flagged in the pin build and the sheet says so: what counts for
them is Scripture FILMED in that sign language, and the text pool was never the right
place to look. Counts are computed, not typed — 150 sign languages on the map covering
84,159,050 people, and the copy reads "none yet has both" only while that is true, since
it is generated from the same pins the layer draws.
THE SCALE: 234 pins on 150 sign languages, 183 of them with nothing found, 0 with both a
film and a text Scripture. 13 have a JESUS Film through Arclight and 1 has Open Bible
Stories through Door43; everything else is empty.
★ A NOTE LEFT IN THE BUILD FOR WHOEVER FILLS THIS GAP. The largest producer of
sign-language Bible content by a wide margin is the Watchtower/JW organisation, which is
excluded by standing rule — added canon. Anyone researching this will meet jw.org first
and it will look like the obvious answer. The legitimate partners are the Deaf Bible
Society and DOOR International, and both need credentials this build does not have:
deafbible.com is a key-gated app, doorinternational.org answers 403. sign.bible is NOT a
source — it is a parked domain listed for sale, which a status-code check would have
happily accepted as live.
No sign-language resource is added here, because none could be verified. What changed is
that the map stops implying the absence was measured against the right pool.
Verified on the served tree with a negative control: the note renders for Deaf Nicaraguan
(Nicaraguan Sign Language, ncs) and does NOT render for German, so it discriminates
rather than always firing. The rendered counts match the build's own tally exactly. Pins,
deep-link, filter, gap-list and language-naming probes all still pass.
The filter shows WHERE the gap is; it could not say which part of it is biggest. The
3,444 groups with nothing were reachable only by tapping dots until a large one turned
up, which is not how anyone chooses a field.
"See the 40 largest" now opens a ranked list in the sheet — the slot the country and
group views already use, so no new geometry and no new collision with the control rail.
Sorted by population, because choosing where to go is choosing how many people are
behind the decision. Tapping a row flies there and opens that group. Fly first, THEN
open: opening sets `selected`, which swaps the sheet away from the list, so the other
order loses the map movement behind a re-render.
THE LIST EXPOSED A REAL DEFECT. The largest gaps are exactly the groups with no entry
in any pool, so they had no record to carry a language name and the sheet rendered
"Language: (blank) cjy" for a 60-million-speaker group. Every language is now named
from the people-group dataset, creating the entry where no pool has one: 2,251 codes
are named-only — the language is known, nothing was found for it anywhere.
That makes "has a code entry" ~100% by construction, so it is relabelled in the build
output as naming and NOT coverage. Coverage is the line under it and still reads 8,935
of 12,379, 72.2%. A metric that reaches 100% because its meaning changed is worse than
no metric.
Verified on the served tree: 40 rows, populations strictly descending 60,310,000 ->
974,000 so "largest" is not a claim taken on trust; tapping row 1 moves zoom 1.3 -> 4.2
and opens Han Chinese Jinyu, whose scripture_url and film_url are empty and whose
Door43 list is empty — so the list is not mislabelling groups that have something. 200
sampled zero-resource groups all name their language, where the screenshot before this
change shows that field blank. Pins, table, deep-link and filter probes all still pass,
and the full a11y sweep passes 810 of 810 buttons across 21 leaf pages.
The map could say what one group has, on tap. It could not answer the question it
exists for — show me only the ones with nothing — so the 3,444 groups that still have
no resource were spread through 12,379 dots and could not be seen as a pattern.
THE KEY IS THE FILTER. A reader who has just worked out what a colour means is exactly
the reader who wants to see only that colour, so the legend entries became the controls
rather than adding a second row beneath them. Each carries its live count: 4,711 with
Scripture and film, 4,224 with some resource, 3,444 with nothing — summing to 12,379,
which is the check that the three buckets partition the set rather than overlap it.
FILTERED ON THE LAYER, NOT THE SOURCE. setFilter is a GL-side predicate, so all 12,379
features stay on the GPU and nothing is re-parsed or re-uploaded on a toggle. Rebuilding
the FeatureCollection per click would re-upload a megabyte to redraw a subset it already
holds.
Clicking an active filter clears it, and the state line names what is hidden with a
"Show all 12,379" out — a filtered map that does not say it is filtered is how a reader
concludes the data is missing.
Verified on the served tree: rendered features 12,379 -> 3,444 on the "nothing found"
filter, getFilter returns ["==",["get","tier"],0], and the only tier visible afterwards
is 0. All three buttons expose an accessible name and aria-pressed. The filtered view
shows the remaining gap concentrated in the Sahel, the Horn, north India and Nepal,
Myanmar, Indonesia and the Philippines.
Same shape as the eBible finding, same cause. Arclight was ALREADY a checked pool and
only 306 language codes carried a film link, while the catalogue lists 2,330 media
languages with 2,087 carrying a feature film. Being inside a pool is not the same as
having been read.
COVERAGE: pins with a real URL 6,985 -> 8,935, 56.4% -> 72.2%. Language codes 2,068 ->
3,196. 1,950 pins lift off "nothing found" and 1,214 move to Scripture AND film. The
resource table grows 1,497 -> 3,043 rows across 2,307 languages.
★ THE VERIFICATION HAD TO BE REDONE, and that is the part worth keeping. The obvious
check is to sample watch URLs and confirm 200. Ten of ten passed. The check was
worthless: https://www.jesusfilm.org/watch/?languageId=<id> is a single-page app and
answers 200 for EVERY id — measured, `0` and `abcdef` both return 200. A check that
cannot fail proves nothing, and that one would have certified 1,781 links on a status
code that is always 200.
The API discriminates where the page does not: media-languages/<id> returns a real
counts.featureFilm for a genuine language and 404 for a bogus one. So existence is
established from the API and the watch URL is the deep link for a language already
confirmed. Re-verified that way: 10/10 sampled languages carry featureFilm >= 1, and
the negative control — a bogus id — returns featureFilm 0, so the check can fail and
does, on the case that should fail.
featureFilm >= 1 IS THE COVERAGE TEST, not roster membership: 21 of the 2,330 listed
media languages have no feature film and are dropped. Only featureFilm is taken;
Arclight also carries short films and other media that were not screened.
FILL, NEVER OVERWRITE, as with eBible — a curated film_url stands, and the catalogue
only supplies a link where there was none. 1,695 of the codes had no row in the
resources table at all.
Verified: all browser probes pass — pins, table, deep link — 12,379 pins rendered, and
the map now reads green across Papua New Guinea, Indonesia, Brazil and Central Africa
where it was red, leaving the remaining red concentrated in the Sahel, the Horn, north
India and Central Asia. The pin table is 1.1MB but 281KB gzipped; the four repeated
pool strings compress 4:1, so interning them would buy nothing on the wire.
eBible was ALREADY one of the two pools this repo checked, and that is what made the
gap invisible: 120 language codes carried an eBible link while the catalogue lists
1,550 translations across 1,239 codes with canonical books. The pool had been read at
roughly a tenth of its content, and ~1,600 people groups were being told "nothing
found" about a published translation in their own language.
COVERAGE: pins carrying a real URL 5,349 -> 6,985, 43.2% -> 56.4%. Language codes
978 -> 2,068. The resource table grows 581 -> 1,497 rows across 1,314 languages. 1,090
of the new codes had no row in the resources table at all, which is why filling gaps
in the existing 862 would have missed most of it.
FILL, NEVER OVERWRITE. An existing scripture_url was curated and verified by an earlier
pass; the catalogue is broad but not hand-checked, so it only supplies a link where
there was none. Where the two disagree, curation wins.
CANON TEST: OTbooks + NTbooks > 0. A deuterocanonical-only publication is not the
66-book canon and is dropped; DC books ALONGSIDE OT/NT are not a reason to drop, since
the 66 are present either way. Measured on this snapshot: 3 rows carry no books at all.
DOMAINS ARE ALLOW-LISTED AFTER A SCREEN, because publicationURL does not always point
at ebible.org. Four domains appear and each was fetched and read: ebible.org (1,242),
png.bible (302, "Papua New Guinea Scriptures"), alkitab.pw (3, an eBible mirror), and
inscript.org (1) — EXCLUDED, because its page establishes no publisher or doctrinal
provenance and an unclear source is left out. A domain not on the list is dropped, so a
future catalogue update cannot introduce a publisher nobody screened.
TWO BROKEN LINKS CAUGHT STRUCTURALLY: nko and nlx publish 'http:///nkoNT/' — a
malformed URL with an EMPTY host, broken in eBible's own data. Requiring a non-empty
host rejects them; a looser check for the 'http://' prefix passes them happily, which
is how a "real" link that resolves nowhere gets shipped. badUrl and badDomain are
counted separately for the same reason — folded together, this hid.
Verified: the CSV parser was diffed against a reference parser across all 1,550 rows,
0 mismatches, so no URL is attached to the wrong language. A seeded random sample of 20
catalogue URLs resolved 20/20 at 200. All five browser probes still pass — pins, table,
deep link, Door43 lift, and 12,379 pins rendered — and the map now shows Papua New
Guinea, Indonesia and South America carrying resource colour where they were solid red.
Every table in the product was shipping Tabulator's DEFAULT theme — #333 header,
#666 rows, #444 filter boxes — against a house style that is Material LIGHT and has
no dark mode. Measured identically in both served consumers before the change:
row rgb(102,102,102), header rgb(51,51,51).
OVERRIDDEN BY SPECIFICITY, NOT BY ORDER, and that is the load-bearing part. The vendor
sheet is fetched and appended AFTER these rules, so any tie goes to the vendor. Each
override is written one class deeper than the rule it replaces: four for the column
header, five for the filter inputs, four for the paginator. Re-ordering the injection
would have been the fragile fix — it breaks the first time injectCss is made sync.
Getting that wrong is visible in stages, which is why it took three passes: at three
classes the columns stayed dark while the header went light; at four the filter inputs
were still #444 and the "Page Size" label was rendering white on a now-light footer,
invisible. The computed-style probe reported the header and row fixed and said nothing
about either — both were caught by looking at the screenshot.
Dark mode is left alone. .dt.is-dark is three classes and still beats these, so callers
using it keep it; this repo ships light only, but silently removing another consumer's
dark mode is not this change's business.
Blast radius named and checked: three consumers import DataTable — gospel-resources,
cities-internet and key-cities. The first two are the ones with a served table page and
both were re-checked, by computed style (row #fff, header #f3f3f1 in both) and by
reading both screenshots. key-cities ships no data-tables page, so it could not be
exercised live. The gospel-resources link and deep-link probes both still pass, so the
restyle did not disturb the anchors the table exists for.
The table listed every link but had no idea what you had just tapped, so answering
"what exists for THIS group" meant reading a language name off the map and typing it
into a filter box. The map and the table are separate PAGES, so the selection travels
as a URL: ?tab=links&iso=<code> from a people group, &country=<ISO3> from a country.
FILTERED IN THE PROFILE, NOT IN THE SHARED COMPONENT. DataTable has other consumers
and none of them need a filter prop; teaching it one would put a change with repo-wide
blast radius behind a feature only this bundle uses. The rows are filtered before they
are handed over, which is invisible to every other caller.
COUNTRY FILTERING WITHOUT A SECOND FETCH. Rows carry country_codes, the ISO3 set the
language is spoken in, so a country filter is a membership test on data already loaded
rather than pulling the 679KB pin table just to resolve which languages a country has.
+23KB for the column, against 679KB avoided.
THE EMPTY CASE SAYS WHY. A selection with no match renders "nothing found for this
selection in the pools checked, which is not proof that nothing exists" rather than an
empty grid, which would read as a broken filter or, worse, as proof of absence.
Switching to a tab that has no language key says so too instead of showing zero rows.
Verified end to end on the served tree: clicked a real pin, followed the link THE SHEET
RENDERED rather than one built in the test, and landed on 2 rows both carrying cmn with
"Showing 2 of 581 resources for Chinese, Mandarin". Country path checked the same way —
Nepal 51, Chad 22, unfiltered 581 with no banner, and an unmatched code showing the
honest empty state.
Every table in this bundle is keyed by PEOPLE GROUP and answers "who has nothing".
None of them answered the question a mobiliser asks first: what exists, what is it
called, and where do I open it. Answering it from a group-grained table means reading
the same JESUS Film link off forty rows.
581 rows, one per language x resource, across 413 languages, together reaching 5,349
people groups — the same 5,349 the pin build counts as carrying a real URL, so the two
tables cannot drift without one of them being wrong.
Reach is MEASURED, not assumed: people_groups, speakers and countries are aggregated
across the pins that actually speak that language, so a row says how many people that
one link serves. Sorted by reach, because the link serving the most people is the one
to open first.
The column is named resource_url because DataTable keys on /_url$/ to render a real
anchor instead of printed text. That is a contract with the shared component, not a
naming preference — rename it and every link silently becomes a string.
TYPES STAY HONEST. 146 Scripture, 306 Film, 129 Bible Stories. Open Bible Stories is
typed as Bible Stories and never as Scripture, and the meta says why. The pools caveat
and the doctrine boundary both render under the table rather than living in a file
nobody opens: only 66-book-canon publishers are included, and the excluded ones are
named so their absence reads as a rule rather than an oversight.
Verified at 1280x900 on the served tree: the tab loads first, renders all ten columns
and 50 rows a page, and 50 rows carry real anchors to ebible.org, jesusfilm.org and
door43 — clicked through from the page, not read out of the JSON.
Two pools had ever been checked — eBible and JESUS Film — and the map said "nothing
found" for everyone outside them. For 240 people groups that claim was simply untrue:
unfoldingWord publishes a released resource in their language and we were not looking.
WHAT WAS ADDED. A dated snapshot of the Door43 catalog (stage=prod only) keyed by ISO
639-3, 165 codes across Open Bible Stories, Bible and Aligned Bible. Cached rather than
fetched live so the pin table is reproducible offline and does not depend on someone
else's uptime; the source URLs travel in the file.
stage=prod IS THE WHOLE CARE. Door43 LISTS more languages than it HOSTS, and this repo
already recorded that trap — "roster membership is not coverage". Released entries only,
and the result reconciles cleanly against what was already known: of 38 languages
previously flagged as having Open Bible Stories, 38 are confirmed and 0 contradicted.
It also found 11 flagged false that do have a published resource.
THE BIGGER HALF WAS INVISIBLE. 116 of the 165 codes have no row in
people-group-resources.json at all, so there was no record to hang a link on and their
pins stayed "nothing found" no matter what Door43 published. Those codes are now created
from the catalog, which is where 213 of the 240 lifted pins come from.
COVERAGE: pins carrying a real URL 5,109 -> 5,349 (41.3% -> 43.2%); codes 862 -> 978.
Tier 1 now means SOMETHING was found rather than "one of scripture/film", because that
is what the colour has to mean once a third pool exists. Tier 2 still means Scripture
AND film — a story set does not get promoted into a Bible.
OBS IS LABELLED AS STORIES. The chip reads "Bible Stories · Door43", never Scripture:
Open Bible Stories is 50 illustrated narratives drawn from the canon, and telling a
reader they have a translation when they have a story set is the one lie this map
cannot afford. 2-letter and region-suffixed tags are DROPPED rather than guessed into
639-3 — a wrong language match ships a real link to the wrong people.
Verified on the served tree: the Kir people group (Mandeali, mjl) previously showed
nothing and now renders a real anchor to git.door43.org/OBS-TLF/mjl_obs, which answers
200. The existing pin probe still passes 12,379 rendered with both Han Chinese links
at 200, so the new pool added coverage without disturbing the old.
The pins landed with no key, so the map shipped two colour systems using the SAME
four hexes for two different claims and nothing telling them apart. A country is an
AVERAGE across its groups; a dot is one group's own language. Red-on-green is the
most interesting case on the map — a group with nothing found inside a well-supplied
country — and with no key it reads as a rendering fault instead of a finding.
The key says so in those words, and the SHAPE now carries the level: squares for the
country average, circles for a single group. Shape is the honest separator here,
because the hexes are deliberately shared — a dot and its country agreeing on what
"nothing found" looks like is the property worth keeping.
Counts are computed from the layer rather than written down: 12,379 dots, 5,109 with
a link. A number typed into a legend rots the first time the data moves.
Verified at 1280x800 on the served tree: the legend renders both key blocks, quotes
12,379/5,109 matching the generator's own tally, and the pin probe still passes
12,379 rendered with both Han Chinese links answering 200.
doxa-maps-88655c70