Network palette fails two computed checks, and dark mode reuses the light steps (#199)

[realmarcin]

Ran the dataviz rubric's palette validator against the shipped per-community network palette — the one check the rubric says never to eyeball. Two findings, both computed rather than judged.

1. The normal-vision floor fails, and secondary encoding does not excuse it

[FAIL] Normal-vision floor  #56bbe6↔#57c7ab ΔE 10.3 (normal) — below 15
[FAIL] Lightness band       outside band: #edab12 at L 0.783
[WARN] Contrast vs surface  #57c7ab 2.01, #56bbe6 2.12, #edab12 1.96

#56bbe6 (Mutualism) and #57c7ab (Cross-feeding) are the two commonest interaction types, and at ΔE 10.3 a full-colour reader struggles to tell them apart.

The template already knows this number. Its comment says shape "is not a courtesy to CVD readers, it is what makes two of the commonest types separable at all." That reasoning is right about CVD and wrong about this check: the rubric is explicit that a normal-vision floor below 15 is a hard fail and that secondary encoding does not excuse it — shape rescues the CVD case, not the full-colour one.

Re-stepping two colours clears it: #56bbe6 → #2a7fd4 and #edab12 → #b8860b.

[PASS] Lightness band       all 9 inside L 0.43–0.77
[PASS] Chroma floor         all 9 >= 0.1
[WARN] CVD separation       #7f30cf↔#2a7fd4 ΔE 7.8 (deutan) · tritan 11.4
[PASS] Normal-vision floor  #913079↔#cf30b7 ΔE 15.1 (normal)
→ ALL CHECKS PASS

The remaining CVD warning sits in the 6–8 band, which the rubric permits only with secondary encoding — satisfied by the per-type d3 symbols added in #270. The contrast warning obligates visible labels or a table view, and the page has both a labelled legend and a <details> data table.

2. Dark mode reuses the light palette

Both modes are handed the same nine hex values. The rubric asks for dark to be selected — "its own steps from the same ramps, validated against the dark surface, not an automatic flip."

Measured against the dark surface, today's palette fails the lightness band on six of nine. The re-stepping above improves that to four, because it was chosen for the light surface, so it is an improvement rather than a fix:

[FAIL] Lightness band  #57c7ab 0.757, #a91919 0.473, #1212ed 0.438, #913079 0.477

That wants a second set of steps plus template plumbing to select between them, which is more than a colour swap. Not attempted alongside finding 1 — filed here so the light-mode fix is not mistaken for having addressed dark.

Also checked, and fine

The two remaining open items on #199 are done or deliberate. The brand hero gradient is now on both community_umap.html and community.html — that item can be ticked. Filters below the plot is recorded as a deliberate layout choice.

[realmarcin]

Attempted the re-stepping proposed above; it does not work, and the reason is worth recording so the next attempt does not repeat it.

#56bbe6 → #2a7fd4 does clear the rubric's normal-vision floor. It then fails this repo's own gate:

tests/test_network_palette.py: MUTUALISM (#2a7fd4) and SYNTROPHY (#7f30cf)
are only ΔE 5.5 apart under deutan vision, below the 15.0 floor

And #edab12 → #b8860b clears the lightness band, then collides with Commensalism:

COMMENSALISM (#cf7830) and COLONIZATION_FACILITATION (#b8860b)
are only ΔE 1.5 apart under deutan vision

The two checks disagree, and that is the real finding

• scripts/validate_palette.js (dataviz skill): OKLab ΔE×100, adjacent pairs in list order.
• tests/test_network_palette.py (this repo): CIELAB ΔE76, all pairs, including the taxon and unmapped greys.

Different metric and different pair set. A swap that satisfies one routinely breaks the other, and the adjacent-pairs restriction means the validator never compared #b8860b with #cf7830 at all — they are not neighbours in the list. The repo's all-pairs test caught it immediately.

Neither is wrong. But only satisfying both is meaningful, and optimising against either alone produces a change that looks verified and is not.

Searched, rather than guessed

• 775 candidates for the colonization slot clearing the repo's 15.0 all-pairs floor → every one that also passed the OKLab checks was a cyan, which re-introduces the blue-blue adjacency the change was meant to remove.
• ~207k saturated warm pairs for the Commensalism + Colonization slots clearing all-pairs → none passed the OKLab checks; the best failed the normal-vision floor against #a91919.
• Relaxing chroma finds solutions, but the validator rejects them as reading grey.

Nine mutually separable, saturated hues is at or past what the space allows once CVD simulation and two metrics are both binding. That is precisely what the rubric means when it says a 9th series folds into "Other", small multiples, or composite encoding — the fix is structural, not a better hex.

What shipped instead

No colour changes. The template comment cited the ΔE 10.3 figure as an argument for shape; that reasoning is wrong and is now corrected in place, along with the constraint above so the next attempt starts from the measurements. The defect stays open here.