The ligature is the join, the marks say their names by elimination, and an offset walks down to one

[omars-lab]

packages/core/src/skins.ts has said since Loop 6a that sub-word highlighting is
impossible because the print's glyphs are "anonymous outlined <path>s". That is
true of assets/pages/**. It is false of the ligature corpus, and this branch
establishes how false with two numbers instead of a grep: which word a mark
belongs to (④), and now which mark it is (⑤).

④ — the join

A tajweed rule is a [start, end) over codepoints. Containment files a mark under
the right word; it says nothing about which letter. The corpus offers exactly
one join — <g id="md-ligature-…"> names the letters it draws in data-text and
nests the marks drawn on them — and ④ asks whether that join holds across all 604
pages.

of 91,451 entries the print calls words
draw no letters at all — pause marks, ۩, ۞	4,486	4.91%
of the remaining 86,965
join cleanly	86,962	100.00%
no assignment of ligatures to letters exists	0	0.00%
a ligature's mark count disagrees	3	0.00%

88.79% → 97.75% → 99.90% → 100.00%, and the number moved each time a markup dump
explained a family — never because a rule was added to move it. That order is the
whole point: a rule fitted to the data would make ④ agree with the corpus by
construction, which is exactly the property that would stop it being evidence.

Two of my own errors surfaced on the way:

• The left-to-right walk was wrong twice over. Ligature document order is not
  reading order («ٱلرَّحِيمِ» → [لر|حيم|ٱ]) and a letter can be drawn in two
  ligatures («فَلَا» → [فلا|ا]). A length check passed both and then misassigned
  every mark while the totals balanced. align now matches on content, which is
  strictly stronger — some words that used to pass now fail.
• The seated hamza always gets its path. I briefly made it conditional on the
  ligature's spelling. «أَنَّ» is drawn [أ|ن] and still carries hamza then
  fatha; the conditional cost 151 words.

The three that remain

Named in the docblock rather than absorbed, because a rule for either would be a
rule for one word:

• «أَيۡدِيهِمۡ» at 21:28 and 22:76 — the word occurs 26 times; 24 draw
  hamza, fatha, sukun, kasra, kasra, sukun and these 2 draw the same list without
  the hamza.
• «لِيَسُـُٔواْ» at 17:7 — the print draws a small waw and a maddah its own
  data-hafs writes no codepoint for. The only word in the corpus where a small waw path appears without a U+06E5.

Neither costs anything downstream. ② is what decides whether the geometry ships,
and ② is exact: 326,515 marks, 0 outside their own word, unchanged.

⑤ — which mark is which

④ counts. Counting says a ligature drawing three letters carries three marks; it
does not say which drawn path is the tanween and which is the sukun, and a tajweed
rule that wants to light the tanween needs exactly that.

The obvious answer — pair them off left to right — is not an answer at all: it
assumes the print draws marks in the order the text writes them, which is the
thing in question. So ⑤ never looks at position. Each agreeing ligature contributes
a bag of codepoint tokens beside a bag of drawn names, and the
correspondence is recovered by elimination across the whole corpus: if a run wants
{sukun, أ, fatha} and the print draws {hamza, sukun, fatha}, then once two are
pinned elsewhere the third follows.

The mechanism is arc consistency over bipartite matchings (supported), not
set intersection. Intersection presumes the relation is already a function and
drove U+0653 to an empty candidate set on the first run — which is how the
أ-carrier convention below was found. Arc consistency deletes a pairing only when
no perfect one-to-one assignment of a run's bag can use it, so it cannot
over-eliminate.

⑤ which mark is which — 152101 runs whose counts agree, 62931 held out
    for the test below, leaving 2869 distinct token-bag/name-bag shapes
    to propagate over; a fixpoint in 2 pass(es)
    34 of 34 tokens pinned to exactly one name; 0 still open
    [no dead shapes]

It is checked on data it was not shown. Every run carrying exactly one mark is
withheld from the propagation, because a one-mark run forces its own pairing and
scoring against it would report 100% by construction.

the held-out test — 62,931 single-mark runs, none of them propagated over
the dictionary predicts the drawn name	62,931	100.00%
predicts a different name	0	0.00%
a token that never appears beside another	0	0.00%

And only now, order

Measured afterwards, once pairing was settled without it — of 89,170 runs carrying
two marks or more:

drawn in the order the text writes them	87,957	98.64%
the same marks, drawn in another order	1,213	1.36%
with R1 — the seated hamza drawn last	88,780	99.56%

R1 was stated before it was scored. A second candidate — shadda drawn after its
vowel — was refuted at −40 runs and deliberately not implemented; the docblock
records it. The residual 390 runs (0.44%) are enumerated by family, led by 50
instances of «شَيۡـٔٗا».

The one contradiction, resolved into a convention

U+0653 (combining madda) on أ is drawn as a shortened fatha-shaped stroke the
corpus names fatha — 277 of 277, 0.89× the width of a same-line fatha — while
all nineteen other carriers get a path named maddah (4,682 of them, one constant
width corpus-wide). It gets its own token U+0653@hamza solely so the relation
stays a function. This is the only place in the dictionary where a codepoint's
drawn name depends on the letter under it.

§⑦ said this was impossible, and was wrong

The section previously argued — with the probe's own output — that the
codepoint → name gap could not be closed offline, citing 611 pairings of a
sukun with a hamza path. Those 611 were an artifact of the tally positionally
zipping want against got, which arc consistency never does. «بِٱلۡأٓخِرَةِ»
was the worked example and ⑤ pairs it correctly.

The refutation is retired in prose rather than deleted, because it is a clean
example of the failure mode this repo keeps finding: a check that shares a
mistake with the thing it checks will agree with it.

What survives §⑦ unchanged: identity is not placement. A print that named its paths
correctly and placed one of them a letter to the left would satisfy ①–⑤ exactly
as a correct one does. That half stays eye-only, and sub-word-marks.md §⑧ ① now
splits the question into the offline-measurable half and the two that are not.

mark-B — the offset walks down to a rectangle

④ and ⑤ leave the join sitting inside a probe. lib/mark-join.mjs extracts the
arithmetic so there is exactly one of it, and markPaths(word) is the entry point
a caller wants: [{ at, len, token, name, mark }], where at is a codepoint
index into that word's own data-hafs. That index is the bridge — tajweed offsets
count codepoints, so an annotation can now be walked all the way down to the
rectangle the print drew.

Extracted rather than left in place for the reason tajweed-fold.mjs gives about
itself: probe-encodings.mjs --marks draws these rectangles, and if the
inspector's join were a second implementation, a clean screen would stop being
evidence about the probe — the one failure a diagnostic tool must not have.

It refuses rather than approximates. null for a mark count that disagrees, a
name the tokens did not ask for, or letters no assignment of ligatures can cover.
A partial answer here would look exactly like an answer, which is the defect the
left-to-right walk already shipped once while every length balanced.
mark-join.test.mjs is 28 tests on words small enough to count by hand, and most
of them assert one of those refusals.

The walk, over all 60,057 annotations

where the rule's own letter is drawn
a named path — this is the rectangle to light	28,535	47.51%
a base letter with no named path	30,943	51.52%
the word was respelt, so the offset does not address data-hafs	497	0.83%
the oracle itself misses, so there is no position to resolve	82	0.14%
no host, no word, or a word the join refused	0	0.00%

The 51.52% is an answer, not a shortfall — and this is the part worth reading
twice, because it looks like a coverage number somebody should try to raise. Ten
of the eighteen rules name a consonant: qalqalah opens on ق, lam_shamsiyyah
on ل, ghunnah on ن or م. The print draws a consonant as a letter outline, not as
a named mark. There is nothing above them to light, and there never was.

The eight rules that do name a mark reach one almost always — hamzat_wasl →
wasla 98.11%, madd_2 → superscript alef/small waw/small yeh 98.58%,
iqlab → small meem or a … iqlab composite 99.82%.

So the finding is a split, not a rate: a mark-granular highlight is available
for the rules about marks and not for the rules about letters, and any UI built on
this has to say which it is doing. That is a design constraint mark-C inherits and
it was not visible before the walk.

Nothing is unreachable for a structural reason — no-host, no-word and
unjoined are all 0 — and the remainder is counted rather than guessed: 497
respelt words, whose offsets do not address data-hafs by construction, and 82
oracle misses.

On screen

The inspector draws each mark's own rectangle inside its word box, with the
selected annotation's mark lit. Verified in a browser rather than asserted:
selecting a hamzat_wasl annotation on 2:4 lights exactly one rect.mk inside
exactly one rect.box, titled wasla · ٱلَّذِينَ codepoint 0 · fold 2.

Hollow and hairline, because the ink rule holds a level finer and is under more
pressure there: a mark's box is small enough that filling it in would look
like the mark. §⑥ 4 of encoding-inspector.md says so in place.

--marks is opt-in for one reason and it is a size: 326,515 more rectangles takes
the report from 5.0 MB to 13.8 MB.

What this leaves open

sub-word-marks.md §⑧ ① keeps its open status. Its offline half is answered
above; what stays is what arithmetic cannot reach — whether the box the dictionary
names sits where a reader looks for that mark, and whether lighting it reads as
a truer rendering of the rule than washing the word. The blocker moves from "the
encoding inspector drawing the marks" to a hafiz looking at them.

Ships nothing

No bytes reach apps/web/public/assets. make ci green; gate:budget 117.9 KB gz
of 150 KB, +0.0 against the baseline. gate:issues 87 indexed across 13 registers,
30 open; gate:map 22 features / 158 pointers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EuhvbUKjGesE3uMhjCzBGt