nx_gateadjudicate.nx

nx_gateadjudicate.nx -- THE GATE ADJUDICATION CENSUS: every gate source in the compile corpus, its adoption ladder (file facts), the execution surfaces that name it, and the ONE remedy bucket it falls in. Built for campaign lane B (2026-08-18): "2,287 uninvoked gate sources wire-or-retire, 105 deployed-dark, 2,182 undeployed" -- numbers measured once on 2026-08-07 over ONE source directory (2,317 gates) and later shown to understate the population by ~880 (nx_gatesubj on the whole corpus: 3,194). A campaign that works a stale list re-investigates what is already fixed, so step 0 of the lane is this instrument, re-runnable, full population, partition summed. WHAT ALREADY EXISTED (asked first -- nx_spendgate/nx_capsearch, 2026-08-18): nx_gatesubj every gate's SUBJECT from its own source (the population enumerator; composed here through the same gk_corpus_scan so the denominator cannot disagree) nx_catalog PER-NAME adoption ladder (SOURCE.BUILT.STAGED.PROMOTED.REGISTERED.AUTHORISED.INVOKED) -- its INVOKED axis is the MCP actlog only, and gates are mostly run by beats, so a gate reads DARK there while a clock row runs it nightly nx_wirecensus registered-but-never-called over the MCP surface (S4) nx_gate_rollup reads knowledge/gatereg.conf rows -> knowledge/status/<gate>.log verdicts nx_gatebuilt_gate authored-vs-compiled census (prints a bounded list, no partition) None joins the GATE population to the surfaces that CAUSE EXECUTION. That join is this organ. THE EDGE DEFINITION IS THE QUESTION (measured 08-07: four definitions gave 75 / 0 / 2,043 / 30). A gate counts as INVOKED only through a surface that runs it or collects its verdict: CLOCK its own .elf is the organ of a clock row, OR its name appears in that row's ARGUMENTS (clocksched- live, clockjobs- desired; measured: rows like `nx_sov_build_run.elf <gate>` and `nx_law_warden.elf scan` carry args, so the organ column is split at its first space) ROSTER its name is MENTIONED inside the source of an organ that IS on the clock (2-hop, e.g. nx_estate_census_run -> nx_gatesubj.elf; nx_gfx_gates_beat -> "nx_gltf_load_gate"+".elf", so the match is the identifier, not the .elf literal), or inside an organ listed in knowledge/gateadjudicate_rosters.conf (off-host rosters such as the laptop's nx_memplane_run, declared as DATA -- never a name baked in here) GATES a knowledge/compare/*.gates row (the executed-evidence map nx_swcompare_evidence runs) GATEREG a knowledge/gatereg.conf row (nx_gate_rollup collects its verdict) GROSTER a knowledge/gateroster.conf row -- the data-driven roster nx_gate_roster_run runs on the clock; counted as a surface ONLY while nx_gate_roster_run itself is a roster organ (on the clock or in the rosters conf), otherwise the conf is a list nothing executes and is NOT credited (printed as groster_inert=1 so the reader sees the missing clock row) ACTLOG an MCP invocation on record in knowledge/status/actlog.jrnl (tail window, declared) A mere MENTION of <gate>.elf in some other source is recorded as REF (something wants it) but is NOT invocation -- report generators name their findings, and that class contaminated three measurements in one hour on 08-07. ★ AN UNSTAMPED REPORT IS INDISTINGUISHABLE FROM A REGISTRY. TRIAL the LATEST row for the gate in knowledge/status/gateroster.jrnl (nx_gate_roster_run's journal: