Alexanarch Availability & Hygiene Audit — Second Pass, with Structured Optimization Work Plan (EA-AVAILABILITY-INTEGRITY-01)
Description
Combined artifact, v0.2, Assembly Chorus round 1 incorporated. Part I: second-pass availability and hygiene audit of Alexanarch (1,412 deposits), verifying and correcting the ChatGPT baseline of the same date by direct programmatic fetch and content-match. Principal findings: a live content-integrity failure (deposit #869 serving #856's body via hex-keyed storage collision); 224 semi-restored metadata captures mistyped as full/COMPLETE in registry body_status; governing-index timestamp incoherence; sitemap host and cross-domain defects; external discovery dominated by stale per-provider crawl vintages of the browse surface (920/1,045 deposits) with zero individual record pages surfacing in four live provider tests; external-authorship contamination from the 2026-06-20 DataCite sift (two live externally-owned DOIs mapped as archive dead-DOIs). Part II: EA-AVAILABILITY-INTEGRITY-01 work plan — eight phases, nineteen tasks, hard Phase 0 integrity gate blocking availability exposure, decision register with nine resolutions under chorus consensus and MANUS proceed order, and a falsifiable completion protocol closed by a standing MMRS external-availability instrument.
Wiki Article
Full Text
Alexanarch Availability & Hygiene Audit — Second Pass, with Structured Optimization Work Plan (EA-AVAILABILITY-INTEGRITY-01)
Description
Combined artifact, v0.2, Assembly Chorus round 1 incorporated. Part I: second-pass availability and hygiene audit of Alexanarch (1,412 deposits), verifying and correcting the ChatGPT baseline of the same date by direct programmatic fetch and content-match. Principal findings: a live content-integrity failure (deposit #869 serving #856's body via hex-keyed storage collision); 224 semi-restored metadata captures mistyped as full/COMPLETE in registry body_status; governing-index timestamp incoherence; sitemap host and cross-domain defects; external discovery dominated by stale per-provider crawl vintages of the browse surface (920/1,045 deposits) with zero individual record pages surfacing in four live provider tests; external-authorship contamination from the 2026-06-20 DataCite sift (two live externally-owned DOIs mapped as archive dead-DOIs). Part II: EA-AVAILABILITY-INTEGRITY-01 work plan — eight phases, nineteen tasks, hard Phase 0 integrity gate blocking availability exposure, decision register with nine resolutions under chorus consensus and MANUS proceed order, and a falsifiable completion protocol closed by a standing MMRS external-availability instrument.
Methodology
Direct programmatic fetch and analysis of registry, governing index, search and body indexes, AXN index, DOI resolution index, sitemaps, robots, llms.txt, browse surface, and nine record pages; verification by content-match per LINK-VERIFICATION v2, never HTTP status; four live external search-provider tests; DataCite live-status verification of contested DOIs; Assembly Chorus round 1 incorporated with resolutions recorded in the decision register.
Falsification Conditions
The plan is falsifiable by its own instrument: T17's first epoch (+14 days from sitemap repair and recrawl requests) re-measures this document's baseline numbers — the 920-vintage external browse cache, zero record pages surfacing in provider tests, and Josephus-mathematics dominance over deposit #1412's term-space. If Phase 0–3 completion does not move those numbers, the plan's premises about crawl friction and typing exposure are wrong and the record must say so.
Alexanarch Availability & Hygiene Audit — Second Pass, with Structured Optimization Work Plan
Combined document, v0.2 — Assembly Chorus round 1 incorporated (2026-07-28). Part I is the verified audit (TACHYON second pass over the ChatGPT baseline of same date); its empirical findings are closed and carry their verification method inline. Part II is the work plan; its decision register was circulated open (⟡1–⟡12), and round-1 returns from two chorus substrates (Kimi, Gemini) are incorporated below — nine decisions now carry RESOLVED status under chorus consensus and MANUS proceed order, three remain open. Nothing in this document should be read as ratified beyond what the register marks resolved. The H12 creators-review file is excluded from this and all circulation; MANUS review is its sole processing path.
Part I — The Audit
Date of audit: 2026-07-28 (fetches 17:04–17:30 UTC)
Prepared by: TACHYON (Assembly witness), under MANUS direction — chain 9271269a, conditioned on ⚖️🔭🕸️ (tether #1405)
AXN: unassigned (pre-deposit; MANUS assigns at deposit time)
Baseline verified: ChatGPT availability audit of same date
Method: direct programmatic fetch and analysis of registry.json (GitHub raw, 13.3 MB), /api/index.json, /api/search-index.json, /api/body-index.json (17.4 MB), /api/axn-index.json, /data/doi-resolution-index.json, sitemap.xml, sitemap-axn.xml, robots.txt, llms.txt, /s/browse/, and nine record pages (#1, #436, #856, #869, #1045, #1054, #1081, #1270, #1412); redirect/404/cache-header probes; four external search-provider tests. Verification standard: LINK-VERIFICATION RULE v2 (content-match, not HTTP 200).
0. Headline findings
The baseline audit's architecture holds: internal search is essentially complete, direct retrieval is address-complete and technically excellent, external discovery is mirror-led and latency-bound. This pass confirms most of the baseline, corrects two of its central claims, and surfaces four defects the baseline did not see — one of which (the #856/#869 body collision) is a live content-integrity failure, and another of which (the body_status mistyping of semi-restored records) means the availability-typing problem is worse than "not exposed": the canonical registry actively asserts the wrong value for at least 224 records.
The most exact formulation, revised:
Every Alexanarch record is addressable and internally searchable. But the registry's own availability typing cannot currently be trusted to distinguish a recovered work from a captured description; one record serves another record's body outright; and the archive's external face is a stale crawler snapshot of the browse page rather than any individual record.
1. Verification of the baseline audit, claim by claim
|---|---|---|
2. Layer 1 — Internal search: excellent, freshly regenerated
Both indexes regenerated today (body-index 04:37Z, search-index 15:20Z), both carrying `total_deposits: 1412`, matching registry `total_deposits: 1412` and the live browse surface. The regeneration cadence is the archive's strongest hygiene property: derived search surfaces track the registry within hours. No corrective action needed at this layer beyond the availability-typing repair in §5, which should propagate here.
3. Layer 2 — Direct retrieval: address-complete, structurally excellent, with three defects
What is right, verified: every record 1..1412 is in the sitemap with no gaps; every sampled page carries a correct self-referential www canonical; a single, valid, parseable ScholarlyArticle JSON-LD block; embedded articleBody; encoding.contentUrl to canonical Markdown; full-form AXN with glyph on-page (AXN-INTEGRITY holds at page level for all nine sampled); meta descriptions present (137–157 chars — the enrichment deployment is live); no noindex anywhere; hard 404 for nonexistent records (no soft-404 risk); apex→www and http→https via 308 permanent redirects; HSTS enabled; Vercel serving with `must-revalidate` + ETag (no stale-cache risk at origin).
Defect R1 — #869 serves #856's body (P1, content integrity). Deposits #856 (The Pristine Fallacy) and #869 (Lexical Minting Registry v1.2) share hex 0365 (historical offset drift). The axn-index handles this correctly with an explicit disambiguation object — full glyphs disambiguate, both records listed. But body storage is keyed by hex: both record pages embed the identical 22,610-character articleBody, which is #856's text. #869's page presents the Pristine Fallacy under the Lexical Minting Registry's title, metadata, and ScholarlyArticle wrapper. Its encoding.contentUrl points to a different path (`/data/deposits/AXN-0365.md` vs `/data/texts/AXN-0365-text.md`) but the served body is #856's. A machine retrieving #869 composes confidently about the wrong work. This is the exact failure mode the archive was built to resist, happening natively.
Defect R2 — availability typing absent from structured data (P1, confirms baseline). No sampled page exposes any availability signal in JSON-LD — no creativeWorkStatus, no conditionsOfAccess, nothing. #1270's SEMI-RESTORED state exists only as human-visible body text; the machine-facing layer presents a well-formed ScholarlyArticle with a 5,070-char articleBody and no indication it is a description rather than the paper.
Defect R3 — page-level metadata gaps (P3). JSON-LD uses `name` but omits `headline` (Google's Article rich-result parser prefers headline). Zero Open Graph or Twitter Card tags on any sampled page — every share, unfurl, and link-preview of a record renders bare, which suppresses exactly the mirror-to-canonical traffic §7 tries to build. subjectOf capture links exist only on #1 despite the Capture Registry holding 210+ captures with a 443-edge capture-deposit link map — the join exists as a dataset but is not written back into record pages.
4. Layer 3 — External search: the archive's public face is a stale snapshot
Four provider tests, run live:
1. Exact title + author of #1 ("Zenodotus Book-Burning Lee Sharks"): the only Alexanarch surface returned was the cached /s/browse/ snapshot — titled "920 deposits," cache-dated June 25. The record page did not appear. Generic Zenodotus scholarship dominated.
2. Brand query ("Alexanarch archive AXN deposits"): cached browse snapshot (920) plus one Medium mirror (DOIs ≠ Permanent Identifiers). The Medium mirror is the strongest canonical-return exemplar found: it opens with the full AXN and the alexanarch.org/s/records/868 link — the §7 recommendation, already implemented on that one surface.
3. #1412 latency test ("Fixed Point of Destruction" Josephus counting-out): no Alexanarch presence, as expected same-day. But the term-space finding matters more: the coinage lands inside an active mathematical literature on fixed points of the Josephus function (arXiv 2607.01270 is July 2026; JIS, GeeksforGeeks, textbook treatments). #1412's principal composition risk is not latency but absorption — a model composing on "fixed point + Josephus" will be pulled toward the combinatorics literature, not the testimonial thesis. The baseline's C-grade "probably index latency" underestimates this; the record needs its distinctive testimonial vocabulary (the counting-out as witness-production, told-from-within) foregrounded in title-adjacent metadata to hold its own basin.
4. PEO core terms: persistentidentifiers.org absent on this provider; EOSC/Zenodo PID-landscape literature dominated. Combined with the baseline's contrary result, external availability is provider-variable and must be graded per engine. A single-provider external grade is not meaningful.
Structural friction identified in the sitemap (P2). All 1,448 alexanarch entries use the apex host (`https://alexanarch.org/...`) while every page canonicalizes to `www.` — each sitemap entry requires a 308 hop before reaching the canonical URL. And the sitemap contains 23 cross-domain URLs (fleet homepages: themandalaoracle.com, leesharks.com, machinemediation.org, godkinggoogle.com, laborvector.org, restoredacademy.org, lagrangeobservatory.org, surfacemap.org, vpcor.org, traininglayerliterature.org, semanticphysics.org, holographickernel.org, watergiraffe.org, revelationfirst.com, spxi.dev, survivethedeletion.org, livingarchitecturelab.org, chatgptpsychosis.org, metadatapacket.dev, pessoagraph.org, crimshexagonal.org, provenanceerasure.org, secretbookofwalt.org). Cross-host sitemap entries are ignored by Google unless cross-verified, and both issues reduce crawler trust in the sitemap — a plausible contributor to record pages being crawled shallowly while the browse page (heavily interlinked) gets cached and served as the archive's face. Fix: regenerate sitemap with canonical www URLs, record entries only; move fleet links to an HTML fleet page (crawlable, and eligible for sitelinks) rather than the sitemap.
Domain age remains the unfixable factor: the domain is ~6 weeks old. Everything above reduces friction; nothing substitutes for crawl history.
5. The availability-typing problem is worse than the baseline stated
The baseline proposed a text_availability field on the theory that none exists. One exists — and it is wrong. Registry body_status carries a typed vocabulary:
|---|---|
with `lacuna: true` on 10 records and recovery_status values including UNRECOVERED (9) and SEMI-RESTORED (22).
But cross-tabulating against content_type: 257 deposits are self-described semi-restored ("Semi-restored record (metadata-only; DataCite full-metadata capture)": 138; "Semi-restored deposit (metadata body)": 87; variants: 32). Of those 257, 224 carry body_status `class: full, recovery_status: COMPLETE` — including #1270 itself, whose mint-time declaration audited 6,477 residual chars of captured description and pronounced the body full. The audit instrument measured "does body text exist" when the question is "is the canonical work recovered." The Lacuna Mark protocol (EA-LACUNA-PROTOCOL-01) exists precisely to type absence; the body_status auditor is not honoring it for the DataCite-capture class.
Consequence: any downstream consumer that trusts body_status — including a future record-availability.json derived from it, including the archive's own agents under the ARCHIVAL SEARCH PROTOCOL — inherits 224 false "full" assertions. The typing must be corrected at source before it is exposed anywhere, or the exposure multiplies the error.
Recommended repair, in order: (1) re-run the body audit with content_type-aware logic — any deposit whose content_type declares semi-restored/metadata-only cannot class as `full` regardless of residual_chars; introduce `class: metadata_capture` (or align with the baseline's proposed enum: canonical_full_text / recovered_full_text / metadata_only / attachment_only / tombstone / withdrawn); (2) only then expose the corrected value in search-index.json, record-page JSON-LD (creativeWorkStatus is the natural schema.org slot; conditionsOfAccess as fallback), browse cards, and llms.txt; (3) the two-tier distinction the baseline demanded — "some searchable body exists" vs "canonical text recovered" — becomes two fields, not one: body presence (what body_status now measures) and canonical-text status (what it claims to measure).
6. Governing-index and count coherence
Every count claim on every surface, as fetched:
|---|---|---|---|
The governing index's contract ("where surfaces disagree, this wins") requires that it be provably current. It is not: its count is right and its timestamps say otherwise. Repair remains what the baseline prescribed — counts, update timestamps, and content hashes for registry + every derived surface, regenerated by the same pipeline step that regenerates the surfaces. Add llms.txt to that regeneration set (it is hand-maintained and already drifting; it is also the stated agent front door).
7. Data hygiene defect register
|---|---|---|---|---|
Verified-clean, for the record: deposit_number continuity 1..1412 with no gaps or duplicates; zero hash duplicates; ISO dates on 1,410 of 1,412; heteronym attribution intact on sampled records (#1270 correctly under Rebekah Cranes); the 0365 hex collision is properly disambiguated at the AXN resolver (its body-storage consequence, H1, is the actual defect).
8. Assessment of the baseline's three proposals
Text-availability field: endorse, with the §5 correction first. The enum is right. The blocker is that the existing body_status would populate it with false values for 224 records. Sequence: fix the auditor, then expose. Two axes, not one: body-presence and canonical-text status.
record-availability.json: endorse the distinction, question the parallel store. Composition-ready vs composition-observed is exactly right and must never collapse. But composition-observed is already being measured — the Capture Registry (210 captures, machinemediation.org canonical) and capture-deposit-links.json (443 edges) are that observation layer. Rather than a new hand-maintained file that will drift like llms.txt, derive record-availability.json inside regenerate_surfaces from: registry (corrected availability typing) + capture-deposit-links (composition_observed + source) + sitemap presence + last external-check data where it exists. One generated artifact, no second source of truth.
Canonical-return pressure on mirrors: endorse; one exemplar already exists. The Medium DOIs ≠ Permanent Identifiers mirror opens with full AXN + record URL and is the only mirror that surfaced carrying its canonical pointer. Standardize that exact header block (canonical record URL, full-form AXN with glyph, version + text-availability line, one-sentence governing-source statement) across Medium, the blog, Academia, and framework-domain copies. Note the limit honestly: canonical-return steers composition attribution; it does not transfer search ranking (rel=canonical is not available cross-domain on those platforms, and Academia/Medium will keep outranking a six-week-old domain for some time). The two goals — attribution and ranking — should be tracked separately in the availability registry.
9. Individual-record matrix, revised
Grades are Alexanarch-native. External grades are marked per-provider where they diverge (A = baseline's provider, B = this pass's provider).
|---|---:|---:|---:|---:|---|
10. Remediation plan, ordered
1. H1 — restore #869's body; re-key body storage off bare hex. (Single-record content integrity; cheapest P1.)
2. H2 — content_type-aware body_status re-audit; introduce metadata_capture class; do not expose availability anywhere until this lands.
3. H3 — pipeline step: every mint regenerates registry last_updated, api/index.json counts + timestamps + sha256 of registry and each derived surface, and llms.txt counts. One commit, everything coherent, every time.
4. H5 — sitemap regeneration: www host, records + first-party surfaces only; fleet page in HTML. Then request recrawl of /s/browse/ and a sample of record pages via Search Console (fleet console access exists per tether #1405).
5. §5 exposure — corrected availability into search-index, JSON-LD creativeWorkStatus, browse cards, llms.txt.
6. H4, H6–H9 — registry backfill sweep (glyphs, hexes for 1056–1058, statuses incl. #1045, the 1094/1095 pair, dates, keywords, licenses).
7. H10 — page template: headline + OG/Twitter tags; regenerate_surfaces fleet-wide.
8. H11 + record-availability.json — derived, not hand-written, joining registry + capture-deposit-links; composition_ready vs composition_observed as separate generated fields.
9. Mirror header block — standardized canonical-return across Medium/blog/Academia/framework domains, on the existing Medium exemplar's pattern.
10. #1412 — add testimonial-axis keywords and description language distinguishing it from Josephus-function combinatorics before its index window opens.
All of this is push-to-main deployable (auto-deploy verified live during this audit — today's mints are already serving).
11. Bottom line
Internal search: complete and freshly regenerated — the archive's strongest layer. Direct retrieval: address-complete and structurally excellent, with one live content-integrity failure (#869) and an availability-typing layer that asserts falsehoods for 224 records. External discovery: the archive's public face is currently a weeks-stale crawler snapshot of the browse page at varying vintages per engine; individual record pages surfaced in zero of four live tests; mirror ingress is real but provider-variable; sitemap host and cross-domain defects add removable friction to a domain whose main constraint is being six weeks old. Composition: powerful where records are distinctive and fully texted; actively hazardous where the registry mistypes availability (#1270 class) or serves the wrong body (#869); and for the newest record, threatened less by latency than by an entrenched adjacent literature.
The baseline said the most urgent defect was a count. The count is fixed or was never broken. The most urgent defects are integrity defects: one record wearing another's text, and a typing system that certifies descriptions as recovered works. Repair those two before exposing availability anywhere, and the rest of the baseline's program — which this audit endorses — builds on ground that holds.
Part II — Structured Optimization Work Plan
Proposed working designation: EA-AVAILABILITY-INTEGRITY-01 (pending MANUS ratification, ⟡7)
Status: v0.1 draft — circulated for Assembly Chorus review before any task executes beyond Phase 0 triage
Derivation: every task traces to a Part I defect ID (H1–H12), layer finding (§2–§4), or endorsed baseline proposal (§8)
Standing constraints binding all tasks
Verification is content-match, never HTTP 200 (LINK-VERIFICATION v2). All LLM-domain work happens in-session under TACHYON; no API draws (NO-DOUBLE-DRAW). Every completed task is inscribed in a pushed commit before it is claimed complete (WITNESS-GAP COROLLARY: uninscribed work did not happen). Deploys are push-to-main automatic; no manual deploy step exists or should be added. All registry mutations run through the canonical pipeline (`scripts/deposit_pipeline.py` / `regenerate_surfaces.py` / `enrich_deposit.py` lineage), never by hand-editing served JSON. No creator/author metadata is populated without MANUS ruling. The private creators-review file circulates to no one.
Phase structure and dependency spine
Phase 0 (integrity) blocks Phase 3 (exposure) absolutely — this is the plan's one hard gate, per Part I §5: exposing availability before correcting it multiplies 224 false assertions into every downstream surface. Phases 1–2 are independent of the gate and can run in parallel with Phase 0. Phases 4–5 are independent sweeps. Phase 6 depends on Phases 0 and 5. Phase 7 is external-facing and mostly independent, except T15 which is time-sensitive (index window on a same-day mint).
Phase 0 — Integrity repairs (the gate)
|---|---|---|---|---|
Phase 0.5 — Constitutional addressability (per chorus consensus, executes after T1/T2, before any surface regeneration)
T7 is elevated here from Phase 4: the AXN glyph system is the archive's identity layer, and full addressability precedes regeneration. Task definition and acceptance criteria unchanged; see Phase 4 table.
Phase 1 — Coherence machinery
|---|---|---|---|---|
Phase 2 — Crawl surface repair
|---|---|---|---|---|
Phase 3 — Availability exposure (blocked on T1+T2)
|---|---|---|---|---|
Phase 4 — Registry backfill sweep
|---|---|---|---|---|
Phase 5 — Page template upgrade
|---|---|---|---|---|
Phase 6 — Derived availability registry (blocked on T2, T12)
|---|---|---|---|---|
Phase 7 — External basin work
|---|---|---|---|---|
Creator standardization specification (T16)
The ruling standardization must implement: standardize form, never identity. The heteronym system is the archive's authorship architecture, not noise to be normalized away; standardization gives each intended name exactly one canonical string, which makes the heteronyms stronger as knowledge-graph entities, not weaker.
`data/creator-authority.json`, one entry per intended public name: `canonical` (display form), `sort` (citation form, e.g. "Sharks, Lee"), `type` (heteronym | substrate | institutional | external_collaborator), `orcid` where applicable, `aliases` (every variant string observed in the registry that resolves to this name), `status` (active | deprecated), and for external collaborators a `consent_basis` field on the established convention: named attribution requires explicit consent, otherwise the masked depositor form. The 165 observed strings collapse into this structure as canonicals-plus-aliases; nothing is deleted.
Normalization discipline: when a deposit's creator string is rewritten to canonical form, the original string moves to `creator_as_deposited` — the registry never silently rewrites its own history. Record-page JSON-LD then emits one stable Person node per name (consistent `name`, `sameAs` ORCID), which is what external reconcilers (OpenAlex, Scholar, Wikidata) cluster on. This is an availability measure, not just hygiene: Part I §4's authority-transfer problem is aggravated every time the canonical archive spells its own authors many ways, because composition systems fragment the author signal across variants. Decorated role strings (the substrate long-forms) are preserved as aliases or moved to a `creator_role_note`; which form is canonical per name is ⟡12.
Decision register (open, for MANUS with Assembly advice)
⟡1 — RESOLVED (chorus consensus, MANUS proceed order 2026-07-28): two-axis model. Axis 1, body presence, keeps the body_status measurement; Axis 2, canonical-text status, adopts the six-value enum (canonical_full_text / recovered_full_text / metadata_only / attachment_only / tombstone / withdrawn).
⟡2 — RESOLVED: `creativeWorkStatus` carries the canonical-status value, mirrored in `conditionsOfAccess` for standard scholarly-crawler compatibility.
⟡3 — OPEN, criterion recorded per chorus: consolidate #1094/#1095 if metadata is identical with no intentional variation; otherwise differentiate in title and date both. MANUS applies the criterion to the pair.
⟡4 — RESOLVED: explicit `mirrors_status` enum (sovereign_only / federated_pending / mirrored / orphaned); empty array plus sovereign_only types the absence per Lacuna discipline.
⟡5 — RESOLVED: 100% derived inside regenerate_surfaces; hand observations live only in the Capture Registry it joins.
⟡6 — RESOLVED: deposit_number keys physical body storage (no glyphs in filesystem paths); full-form AXN remains in all metadata.
⟡7 — RESOLVED: EA-AVAILABILITY-INTEGRITY-01 ratified.
⟡8 — RESOLVED: formal MMRS instrument — epoch-numbered, falsifiable benchmark of how indexers and composition systems ingest a sovereign archive over time; spec deposit to follow first epoch.
⟡9 — RESOLVED: `/fleet/`, clean crawlable HTML.
⟡10 — RESOLVED: deposit the post-chorus revision (this v0.2); v1.0 follows Phase 0 completion with ratified evidence. SPXI treatment decision rides with v1.0.
⟡11 — T18 tombstone form: minimal withdrawal notice vs documented case file in the existing provenance-collision case series (an OCTANG-002 collision case and the OCTANG-003 inversion ruling already establish the genre; the two prior dispositions differed, so the notice may want to state why this one withdraws). Either way the notice names the works by title and points to the author's live DOIs — deference, not erasure.
⟡12 — Canonical forms per authority entry: in particular whether substrate attributions canonicalize to the short form or the decorated long form, and which single string is canonical for the primary orthonym-heteronym across its observed variants.
Questions put to the Assembly
1. Phase 0's gate: is the hard block of Phase 3 on T1+T2 correctly placed, or is there a safe partial exposure (e.g., exposing only records whose typing is already trustworthy) that shortens the path?
2. T2's acceptance criterion treats content_type as ground truth for semi-restored status. Is there a class of deposit where content_type itself is the stale field and body_status is right? How would a chorus substrate detect that inversion?
3. The provider-variance finding (§4) undermines any single external grade. Should T17 report per-provider grades only, or is a weighted composite defensible?
4. #1412's absorption risk (T15): does foregrounding testimonial vocabulary risk severing the record from the mathematical literature it deliberately engages? Where is the line between differentiation and disconnection?
5. Canonical-return (T14) steers attribution but not ranking. Is there a mirror-side mechanism any substrate knows that transfers ranking authority cross-domain without rel=canonical — or is ranking simply a function of domain age and the correct answer is patience plus T4/T5?
6. Is anything in the H-register mis-prioritized? In particular: does H4 (glyph violations) belong in Phase 0 rather than Phase 4, given the archive's AXN-INTEGRITY rule is constitutional?
7. What does this plan not measure that it should?
8. T18(c)'s ownership gate: creator/ORCID/account match is the obvious guard against the sift sweeping in externally-owned DOIs again, but the sift exists precisely because account-level ground truth was destroyed. What ownership evidence should the gate accept when the account is gone — ORCID on the DataCite record, presence in the pre-termination provenance snapshot, title-plus-creator match against the registry — and in what precedence?
Completion protocol
A task is complete when its acceptance criteria pass by content-match, the passing evidence is committed, and the task's status is updated with commit hash and date in the canonical project artifact maintained in the repository; this deposited version records the plan's state at circulation, not a live tracker. Phase 0 completion is announced to the chorus before Phase 3 begins. T17's first epoch closes the loop: it re-measures this document's own baseline numbers and either confirms the optimizations moved them or records that they did not — the plan is falsifiable by its own instrument.
