nx_artifactdrift.nx

nx_artifactdrift.nx -- IS THE BINARY WE ARE SERVING THE ONE THE LAST BUILD PRODUCED? ⚠THIS ORGAN WAS NAMED WRONG TWICE, AND BOTH GUARDS WERE RIGHT. It shipped as `nx_promotestale` and nx_job_run's launch guard refused it: that guard splits the name on '_' and denies any SEGMENT STARTING WITH a control-plane stem, so "promotestale" reads as promote. Renamed to `nx_servedrift`, /api/promote then refused it as a DAEMON and nx_job_run refused it again -- "servedrift" starts with "serve", and that guard's header states it chose stem-prefix DELIBERATELY so `nx_server` could never escape, calling an escaped server "the brick". -- BOTH REFUSALS WERE CORRECT. A launch guard must be wrong in the direction of REFUSING, and a name that starts with `serve` genuinely looks like a server. The tempting fix -- patch an allow-path into a never-brick guard so it consults organ_kind.conf -- would trade a real safety property for a bad name. -- SO THE NAME MOVED, NOT THE GUARD: this measures DRIFT BETWEEN THE BUILT AND SERVED ARTIFACT, which `artifactdrift` says exactly and claims to be no kind of server. ★★AN ORGAN'S NAME IS PART OF ITS INTERFACE, BECAUSE THE ESTATE'S OWN SAFETY RULES READ IT -- and when a guard and a name disagree, the guard is the thing with a proof behind it. WHY IT EXISTS, MEASURED 2026-08-14: two organs were found SERVING STALE CODE purely because a human happened to notice nx_catalog's BUILT and PROMOTED columns disagree -- nx_vizsla_digest (47,402 served vs 47,596 built) and nx_vizsla_plan (176,882 served vs 217,561 built: ~40 KB, a FIFTH of the organ, missing from the running binary). Both were invisible to every health check the estate runs. -- A RUNNING BINARY THAT IS NOT WHAT ITS SOURCE BUILT IS A SILENT CORRECTNESS AND SECURITY DEFECT: every fix, every audit and every gate verdict then describes code that is not the code being executed. -- SPOTTING IT BY EYE DOES NOT SCALE. nx_catalog answers this one NAME at a time; this sweeps. nx_artifactdrift [judge] [registry] [buildroot] [srcroot_primary] [srcroot_secondary] [declare_conf] [trend_log] THE OWNER-SIGNAL AXIS (DM5 ps_owner_scan, 2026-08-20). Every BEHIND row carries an OWNER SIGNAL, so a promote list built from this census can never omit the check. BEHIND alone is NECESSARY BUT NOT SUFFICIENT for "promote me": a BEHIND row can be ANOTHER SEAT'S WORK IN FLIGHT -- measured live 2026-08-15 on nx_oo_extract_gate, where the only thing that stopped the promote was a human looking. STATES, a partition over the BEHIND rows and NOTHING ELSE: DECLARED a row in the declaration conf claims the target -- a STATEMENT, so it outranks the inferences below and is the mechanism for the standing "declare any build you do not promote" law IN-FLIGHT-SUSPECT scratch siblings <target>.nx.* beside the source, or a same-day source touch SRC-UNRESOLVED no source under either root -- the axis ABSTAINS; it does not acquit UNDECLARED no claim and no signal: the ONLY class eligible to be CONSIDERED, never an order ⚠IT IS A SEPARATE AXIS, exactly like the INERT exec-bit axis and for the same reason -- folding owner states into the IDENTICAL/STALE/NO-BUILD/NO-SERVED/STAGED-POINTER partition would break the reconciliation that makes that partition worth trusting. It reconciles against BEHIND on its own, and