Nishi atlas · organ card

nx_mmbench — media + companion capability ruler

The instrument that measures how far the sovereign media manager and companion AI stand from the products people actually use, and derives the build order from that measurement.

A correction, kept in public. An earlier revision of this page claimed the atlas card corpus — 33,243 generated organ cards — was “100% unreachable, HTTP 404”, and a matching severity-7 debt was filed against the edge. That was false, and it has been retracted.

The atlas is healthy. Atlas home, the family tree and every organ card serve correctly — each card carrying its parents, children, gates, partners, sibling counts and its import-hop distance from the graph root.

The 404s were an artefact of the measuring instrument: our verification tool applies a connect-override so that requests for our own domain deterministically reach the sovereign edge rather than the unrelated server co-squatting port 443 — and that override does not always fire. When it silently fails, the tool grades the wrong machine and reports a confident RED. Re-probed with the override held explicitly, the same URLs return 200. Filed as seq990; the retracted claim was seq984. The lesson is the durable part: when an instrument reports RED, confirm it was pointed at the right target before believing it — and never file a debt off a single unconfirmed RED.

Family

OrganRoleLive bytes
nx_mmbenchthe ruler: 56 capabilities × 12 reference products, emits report / json / gapq41,286
nx_mmbench_libtestable core: aud (evidence audit), wired/wired_ref (wiring), bin_ref (serving-binary probe), usablesource 6,113
nx_mmbench_gatethe proof: 24 teeth incl. negative controls and monotonicity22,632
nx_media_probepage → media extraction, live over sovereign TLS (nx_yt_probe + mx_extract)552,195
nx_feedfetchRSS/Atom acquisition: fetch, discover the feed link in a page shell, parse items to indexable text541,988
nx_staledir_gateproves a source/deployment disagreement can never prescribe a destructive rebuild15,627

Lineage

nx_syscallsnx_mmbench_lib → { nx_mmbench, nx_mmbench_gate }. The gate additionally inherits nx_gate_verdict, the shared verdict base class, satisfying the D001 DRY law rather than hand-rolling a counter and a PASS/FAIL printer. The lib exists so the gate exercises the code that ships, not a copy of it.

The strong wiring test is adopted from nx_reader_liveness, not invented here — that organ was written after mobi/azw decoders shipped built, gated and green while the serving path never routed to them.

Gate — 24/24 GREEN

A ruler that has never been seen to say NO is not a ruler. Each tooth below has been observed firing.

TeethWhat it forbids
T1–T9Evidence audit: a HAVE naming an absent artifact is destroyed, not footnoted; a HAVE naming nothing is capped; evidence may only demote; verb matching is exact.
T10A liar-kill must lower the computed headline (1000‰ → 666‰ on a planted set).
T11–T16Wiring: a fully-built HAVE with no deployment collapses to GAP; a real deployment passes through.
T17No invention. A deployment can never promote something we never built.
T18Darkness lowers coverage below built.
T19–T21Serving-binary probe is truthful in three directions: referenced, scanned-and-absent, and unknown (an oversized or unreadable binary must never masquerade as dark).
T22Deployed but unreferenced is still DARK. Deployment alone stops being sufficient.
T23–T24Referenced is wired; unknown falls back to the weaker test, never to a false dark.

MCP + API surface

All four organs are registered tools, callable over our own TLS with least-authority capability tokens. Registration, promotion and cap minting all went through the sovereign mgmt API (/api/build/api/promote/api/tools/register/api/cap/mint) — no shell in the loop.

Current reading

MetricValueMeaning
coverage_permil566what the product can actually reach — the headline
built_permil622code that exists and survives its evidence probe
dark_caps1built and proven but unreachable from the product
liar_killed / ungrounded0 / 0a measured zero: T2 proves the kill fires
open gaps26demand-ranked; the queue is the build order

Full detail, per-capability evidence paths and the gap queue: the ruler page.

Ownership

Measurement and honesty: R engineer-media / referee, A pm, C adversary, I all. Deploying dark capability: R engineer-media, A pm, C supervisor. Ongoing built-vs-live liveness maps to the ecosystem monitor activity, A supervisor. Adult-content boundaries on the private planes: A operator.

The instrument that lied, and what was behind it

Chasing the false-RED above to its root turned up something worse than a flaky tool. The verifier’s auto-override is data-driven from a registry of our own domains, and that registry names the verifier as its consumer. But no source file in the entire build tree implements it — the only mentions anywhere are two archived session notes, one of which is the note written by the session that built the feature. The capability was built, deployed, and documented; its source is not in the tree.

The consequence is sharp. The normal, encouraged loop — build the target, promote it — would silently delete the auto-override and turn every verification of our own domains back into a coin flip against the unrelated server co-squatting port 443. That is the mechanism that produced the false claim on this page. I opened that source intending to harden it and would have rebuilt it; the check that stopped me was noticing the live binary printed a string its own source could not produce.

Filed seq1008 at severity 8 with a do-not-rebuild note — and then fixed. The lost capability has been reimplemented from the contract documented in the registry header, so the binary is reproducible from source again. Proven behaviourally, not asserted: the exact URL that returned 404 RED before the fix now returns 200 GREEN, with the recovered override line and a new vantage=PINNED stamp; an external domain still reports vantage=DNS and passes, so the fail-safe path is intact; and the verifier’s own gate still passes 10/10 GREEN, so nothing regressed. seq1008 is closed.

The hardening rides the same rebuild: the vantage is now printed on every single run. There is no longer a silent path — a reader can always see which server was graded, and an our-domain that somehow failed to pin says so loudly instead of returning a confident RED.

The general class then turned out not to need a new detector. nx_stale_check already rebuilt each organ from source and byte-compared it to the deployment — but it called every disagreement STALE, and the STALE remedy text says “rebuild+restage”. For a binary that is ahead of its source, that remedy is precisely what destroys the shipped feature. The detector that should have caught this would instead have prescribed the damage. Its one existing guard only fires for tiny stub sources, so a 2 KB gap on a 575 KB binary sailed straight through.

So the fix was a direction guard, not a new organ: when a fresh build is smaller than what is deployed, the deployment carries code the source does not emit, and the tool now reports DEPLOYED-AHEAD and withholds the destructive remedy instead of prescribing it. It states its own floor plainly — size direction is a heuristic, a legitimate shrinking refactor lands in the same bucket — so it declines to act rather than claiming a diagnosis. Proven by nx_staledir_gate, 7/7 GREEN, including a regression tooth pinned to the real byte magnitudes and an anti-vacuity tooth proving genuinely-stale targets still reach STALE.

On its first real sweep it found a second one. nx_media_inventory — the sovereign media census — deploys at 155,398 B while its source rebuilds to 123,351 B: a 32 KB gap, roughly fifteen times the one that started this. It is flagged do-not-rebuild pending investigation (seq1050). It is also the organ whose output grounds the corpus figures published on the ruler page, so a silent rebuild would have moved published numbers too. In the same sweep nx_torrent_seed came back STALE — the opposite direction, correctly called — which is live evidence the guard discriminates rather than flagging everything.

Delivered: RSS/Atom acquisition is live

The ruler moved for the right reason — a capability got built, not a number got adjusted. Usable coverage 547 → 566‰, media plane 554 → 581, dark capabilities 2 → 1, open gaps 27 → 26.

nx_feed_extract — a real RSS 2.0 and Atom parser — had been in the tree since early July and had never once been called. It is a library with no entry point, so no amount of deploying could make it reachable. An earlier revision of this page said these organs were “deploy work, not build work”. That was wrong, and I only found out by checking whether they had a main() before trying to deploy them. They did not.

So the missing piece was written: nx_feedfetch, a thin consumer that fetches a URL over our own TLS and hands the bytes to the parser. Both paths proven on live sites, not fixtures: a direct feed (reddit.com/r/selfhosted/.rss → 200, 60,476 B → 25 items parsed into indexable text) and the harder discovery path (lwn.net returns a page shell → found /headlines/rss in its markup → fetched it → 15 items). The verifier gate stayed 24/24 GREEN across the change.

One capability remains dark: site-scraper-adapters, whose organ (nx_archive_capture) is a library too — a single function with no entry point — so it needs the same treatment rather than a deploy.

Fleet reproducibility: 175‰

The direction guard made a fleet sweep worth running. Forty of the 435 registered deployed organs, sampled systematically (every eleventh, so no hand-picking), each rebuilt from its own source and compared byte-for-byte against what is actually deployed:

VerdictCountMeaning
CURRENT7175rebuilds byte-identical — genuinely reproducible
BUILDFAIL (disputed)20500build did not produce a binary — but see the correction below: this conflates a real compiler error with load
STALE10250differs; source side is ahead (deltas of 12–289 B)
NOELF250no deployed binary found to compare
DEPLOYED-AHEAD125deployment carries code the source does not emit

Correction, same day. An earlier revision of this page read the second row as “half the fleet’s source no longer compiles” and called it the headline. That reading is not safe, and it is withdrawn.

On re-test, an organ the sweep called BUILDFAIL (nx_box) builds perfectly well when built on its own. The likely mechanism is the sweep itself: forty rebuilds back-to-back on a shared machine, each forking a compiler. BUILDFAIL conflates “this source cannot compile” with “the machine was too busy to compile it” — and only the first is a defect.

What still stands: one organ, nx_heal, failed with a real and reproducible compiler error — a module constant used before its declaration, which would silently read zero. The compiler gained a correct safety check that blocks some existing source. So the class is real; its size is unknown. Full re-verification was cut short because the re-test itself degraded the transport. The reproducible figure from this sweep is the one at the top: 7 of 40 organs verified byte-reproducible. Everything below that line needs a quieter machine and a second pass.

A hypothesis of mine, tested and rejected. Before the sweep I expected the new guard to flood with false positives: a better compiler emits smaller code, so any organ not rebuilt recently should look “deployed-ahead”. It fired once in forty. The ten STALE rows run the other way — fresh builds are larger, by 12 to 289 bytes — so current drift inflates rather than shrinks, which makes a rebuild that comes out smaller more anomalous, not less. The guard discriminates. Worth stating plainly because the flattering reading would have been to skip the test.

A third unreproducible binary surfaced in the same pass: nx_verify, an 11 KB gap, flagged do-not-rebuild pending investigation. Sample coverage is 40 of 435 — 92‰, not a census. The true fleet numbers are unmeasured; these are the numbers from the sample actually taken.

Filed from this lane