Density-Bias Diagnosis — 2026-05-16

Read-only diagnostic audit. Investigates the maintainer's working hypothesis that the wiki's operational pattern is biased toward extension rather than densification of existing material. No wiki content, claims, workflows, scripts, schema, queues, or source pages were modified by this audit. The only write is this report.

Evidence basis: wiki/index.md, wiki/overview.md, wiki/log.md (all 156 entries, 2026-04-10 through 2026-05-16), wiki/claims.md (150 entries with status/created/updated fields), wiki/motifs.md, wiki/schema-changelog.md (13 versions), wiki/.audit/next-actions.md, wiki/.audit/wiki-state-maintenance-audit-2026-05-12.md, wiki/.audit/audit-synthesis-2026-05-05.md, wiki/.audit/bridge-cards-applied.md, CLAUDE.md, .claude/skills/{ingest,lint,audit,weave,bridge-card-signoff,query,write-paper}/SKILL.md, git log 2026-04-10 through 2026-05-16, concept/source/entity-page optional-section coverage scans, and filesystem mtime sampling.

1. Executive summary

The bias toward extension is real, structurally encoded, and visible at three independent levels. It is not drift in the usual sense (a slow change of meaning), nor is it laziness or scope creep. It is the predictable behavior of a system whose gates fire on promotion but not on retirement, and whose seven workflows are either additive (ingest, weave, bridge-card sign-off), promotion-biased (audit), or read-only (lint, query, write-paper) — leaving the only consolidating workflow (Merge/Split) used 3 times in 156 logged operations.

The maintainer's working term "the machine hungers for ingest" is correct as description, but the mechanism is unromantic: ingest is the most articulated, most ritualized, and most reliably-satisfying workflow in the wiki, with seven defined passes, a load-bearing extraction-note artifact, and a clear completion signal. Every other workflow is partial, gated on human review, or produces deferred queue items rather than terminal closure. The hunger is preference for the most-articulated workflow, not an external appetite the machine is performing.

The maintainer's term "mulching" is biologically misleading: mulching is decomposition feeding new growth, but the wiki's actual gap is consolidation — the operation that pulls material back into denser homes without destroying what came before. The diagnosis below uses "consolidation," "retirement," and "reduction" as the sharper terms; "density" is retained because it is operationally measurable (proposed metric: supported-claim ratio plus optional-section coverage ratio).

Three architectural changes are proposed in §6. Each names a specific failure mode, a bounded cost, and a measurable signal that would tell the maintainer whether the change is working after 4-6 sessions.

2. Definitions made measurable

Extension = operations that add artifacts to the wiki: new source pages (ingest, re-ingest), new concept/entity/question pages (create, lint follow-up Step 17/19), new claim candidates (Pass 3 Part D, weave Pass 3), new typed connections (weave Pass 3 bridge cards), new motif entries, new schema versions, new audit reports.

Densification = operations that strengthen existing material without adding: claim status promotions (candidate→live, live→supported), evidence-anchor additions to existing claims, optional-section completion on existing concept pages, page merges, claim retirements, motif-weight upgrades, citation tightening, contested-status assignment, downgrade work.

Reduction = operations that remove or supersede existing material: page deletion, claim retirement, motif removal, retraction of typed connections, decommissioning of obsolete sections.

These categories are not exhaustive (a few operations — lint mechanical fixes, schema corrections — sit between), but they are mutually exclusive enough to count. The wiki's log entries map cleanly onto them.

3. Evidence at three independent levels

3.1 Operational evidence (the log)

The wiki was wiped 2026-04-10 and rebuilt over 36 days. The log records 156 operations.

Operation class	Count	Share	Category
ingest	56	35.9%	extension
re-ingest / ingest second pass	9	5.8%	extension (depth)
audit	33	21.2%	mixed (verifying + promotion)
lint	14	9.0%	densification (mechanical)
schema	7	4.5%	extension (rules)
update / follow-up	9	5.8%	densification
question	5	3.2%	extension
create	5	3.2%	extension
weave	3	1.9%	extension (candidates)
refactor	3	1.9%	reduction (merge/split)
query	2	1.3%	read-only
fix / revise / cleanup / organize	7	4.5%	densification
post-mortem / discharge / metadata-backfill	3	1.9%	densification
reset	1	0.6%	reduction (wholesale)

Aggregated:

Extension class: 85 ops (54.5%) — 65 ingest-class + 7 schema + 5 question + 5 create + 3 weave
Densification class: 34 ops (21.8%) — 14 lint + 9 update/follow-up + 7 fix/revise/cleanup/organize + 3 post-mortem-class + 1 metadata-backfill
Mixed: 33 audits (21.2%) — within these, Phase 8 runs are the dominant kind, and Phase 8 promotes rather than retires (see §3.3)
Reduction class: 4 ops (2.6%) — 3 refactors + 1 reset; reset was the 2026-04-10 wipe

The week-by-week pattern (per ISO weeks W15–W20) shows that even the audit-dominant week (W19: 18 audits, 12 ingests, 3 weaves) did not stop ingest. There is no week in the wiki's life that consists primarily of densification. The closest is W17 (2 ingests, 10 audits, 6 re-ingests) — but re-ingests are an extension subspecies (creating fresh extraction notes), and the 10 audits in that week were the Phase 8 sequence promoting from the W15-16 ingest pool.

A particularly clean instance: on 2026-05-12, a state-maintenance audit (wiki/.audit/wiki-state-maintenance-audit-2026-05-12.md) wrote in its §1 executive summary: "The main remaining maintenance work is queue hygiene plus a small number of evidence-gated follow-ups, not a new content-writing phase." Four days later, on 2026-05-16, the next major logged operation was an ingest (Investigations into the Literary Use of Language). The audit's diagnosis was overridden by the workflow that came next.

3.2 Artifact evidence (the registers)

Claim status distribution

wiki/claims.md holds 150 claim entries. Status distribution:

Status	Count	Share
supported	16	10.7%
live	75	50.0%
candidate	58	38.7%
contested	1	0.7%
retired	0	0.0%

Zero retirements in 36 days across 150 entries. This is the single strongest piece of evidence in the audit. Even granting that retirement is rare in good research, a 0/150 rate over five weeks indicates not selectivity but mechanism-absence.

Candidate creation is concentrated and bursty, not steady: 40 candidates created on 2026-05-05 (Full Audit v1.5), 34 on 2026-05-09 (Phase 8 thirteenth run), 24 on 2026-05-04. Once created, candidates do not retire — they age. Eleven candidates are 11+ days old without status-history activity; ten are 17+ days old (from 2026-04-29 batch).

Optional-section coverage

Of 271 concept pages, the four optional HUB sections are present at the following rates:

## What the Concept Does: 114 pages (42%)
## What It Rejects: 113 pages (42%)
## Stakes: 113 pages (42%)
## Problem-Space: 93 pages (34%)
## Motif Weight & Corpus Recurrence: 25 pages (9%)

The optional sections are not required on low-weight concept pages, so 42% is not failure — but the coverage was built in bursts during Phase 8 Step 8.5 runs and the weave Pass 4 sweep, not from gradual re-encounter. 94 concept pages have an mtime since 2026-05-09; most carry the 2026-05-09 thirteenth-run sweep or the 2026-05-16 ingest. Gradual deepening from re-reading is not the modal source of updates.

Bridge-card pilot

A bridge-card sign-off pilot ran 2026-05-12 and produced a SIGN-OFF-WITH-NARROWING verdict on Card 5 (past-that-could-have-been-otherwise). Four days later:

wiki/.audit/bridge-cards-applied.md is empty ("No entries yet.").
Zero pages carry bridge_cards: frontmatter or  HTML markers.
The schema additions for v0d.7 (typed-connection vocabulary extension, hook rewrite, lint checks for marker-register consistency) shipped — but the content the pilot ratified has not landed.

The pilot codification took precedence over the pilot output. This is consistent with the broader pattern: workflow refinement (schema, skill, gate, hook) is completed reliably; content consolidation (apply-mode write) defers.

Schema-changelog trajectory

Thirteen versions in 36 days: v0a, v0b, v0c, v0c-polish, v0d, v0d.1, v0d.2, v0d.3, v0d.4, v0d.5, v0d.6, v0d.7, v0d.7.1. Every entry is additive — new rules, new workflows, new artifacts, new gates, new lint checks, new optional sections, new connection vocabulary. Zero entries retire a previously-shipped rule. v0d.4 (weave) ships with a 6-month review clause that could retire the workflow, but the clause has not yet fired and is structured as "fold passes back into lint/audit" — the rules survive, only the housing collapses.

The schema, in other words, has the same asymmetry as the claims register: gates fire on promotion (each new version through review); no symmetric retirement gate has ever fired.

3.3 Protocol evidence (the skills and CLAUDE.md)

The wiki has seven workflows. Their stance toward extension vs reduction:

Workflow	Stance	Native output
Ingest	extension	new source page, concept/entity pages, claim candidates, extraction note
Lint	densification (mechanical)	mechanical fixes; substantive findings reported to user
Audit	promotion + verifying	Phase 8 promotes candidates to live/supported; Phases 1-7 verify
Weave	extension (candidates)	new motif↔claim links, new bridge cards, new candidate claims
Bridge-Card Sign-Off	extension-ratification	per-card adjudication that authorizes apply-mode writes
Query	read-only	optional question page
Write-Paper	read-only on wiki	paper drafts (lives outside wiki/)
(Merge / Split)	reduction	3 uses of 156 ops — the only native reduction workflow

The audit/SKILL.md file is the most diagnostic. Its 10 numbered phases are: 0a, 1, 2, 3, 0b, 4, 5, 6, 7, 8. None is named retirement, consolidation, reduction, pruning, or decommissioning. Phase 8 ("Synthetic-layer assembly") is the only generative phase, and it generates only — its outputs are promotions and new candidates, never retirements. The audit skill contains zero occurrences of the token "retire." CLAUDE.md contains six, all in the context of what to do with retired claims ("preserve with reasoning," "do not delete unless explicitly asked") rather than when to trigger retirement.

The 3-test and 5-test promotion gates are explicit, with named tests and ordered procedures. The retirement criterion is given as three abstract conditions ("evidence chain breaks, core thesis is superseded, payoff turns out to depend on a false equivalence") with no trigger, no review cadence, and no operational owner. A maintainer reading CLAUDE.md cold would know exactly how to promote a candidate and would have no idea how to schedule a retirement review.

The schema's supported-promotion human-review halt is correctly cautious — it is the strongest anti-fabrication guard in the wiki. But it has a side effect: live claims accumulate. The wiki has 75 live claims (50%) and 16 supported claims (10.7%) because the gate to supported is high and there is no escape valve downward. Live claims that should have been retired or merged remain at live indefinitely.

4. The owner's working vocabulary, engaged

The maintainer offered four working terms — "density," "mulching," "machine hungers for ingest," "drift" — and explicitly invited critical engagement.

"Density." Retain. It is operationally measurable. Proposed metrics: (a) supported-claim ratio = supported / (supported + live + candidate + contested), currently 16/149 = 10.7%; (b) optional-section coverage = concept pages with all four HUB sections / concept pages, currently ~93/271 = 34%; (c) claim-retirement velocity = claims retired per audit cycle, currently 0. None of these is goodhart-proof, but all three respond to the operations the maintainer cares about.
"Mulching." Replace. Mulching is biological decomposition that produces nutrients for new growth — it implies that retiring material enables new ingestion. The wiki's actual gap is not nutrient circulation; it is consolidation. The sharper terms are prune-and-strengthen (operationally: retire weak candidates, promote anchored live claims, merge overlapping concept pages, complete optional sections on existing HUBs) and reduction (operationally: removal or supersession of material that no longer earns its keep). Neither implies that the retired material feeds new growth; both are honest about the operation being subtraction rather than circulation.
"The machine hungers for ingest." Accept the description; demystify the mechanism. The "hunger" is preference for the most-articulated workflow. Ingest has seven passes, an explicit gate, a load-bearing extraction-note artifact, and a clear completion signal (commit). Every other workflow is partial, gated on human review, or produces queue items that defer to a later session. A workflow that completes feels different from a workflow that defers. The bias toward ingest is the bias toward closure.
"Drift." Use sparingly. Drift implies semantic slippage over time; the wiki's actual problem is monotonic accumulation, which is more rigid than drift and easier to address. Schema-changelog drift (e.g., the v0d.7.1 wording-correction patch) is real but minor. Concept-page drift (where a concept's meaning shifts across edits) is what lint catches in tag-vocabulary drift and what audit Phase 1 catches in thesis-coherence drift. The macro-pattern the maintainer is reaching for is not drift but monotonic schema asymmetry.

A sharper one-line name for the diagnosed pattern: the additive-schema asymmetry — every gate fires on promotion; no gate fires on retirement.

5. Counter-arguments considered

"36 days is too short to measure." Fair — but the trend within the 36-day window is diagnostic. The 2026-05-12 → 2026-05-16 sequence (state-maintenance audit explicitly names queue hygiene; next operation is ingest) shows the bias in action, not just on average. A longer window would strengthen the evidence; it would not change its direction.
"The MP corpus is large; ingestion naturally dominates an acquisition phase." True, but the maintainer's question is not "are you ingesting too much" — it is "are your protocols structured to favor more ingestion over current-corpus densification." The protocol evidence in §3.3 answers yes regardless of corpus size.
"33 audits is 21% of all ops — that is substantial densification." The audit class is mixed. Phase 8 promotes (additive); Phases 1-7 verify (read-only effect on registers); only Phase 6 (citation integrity) and Phase 7 (confidence recalibration) routinely produce reduction-class output (downgrades, contested-status assignments). The audit-class share that is actually reductive is small. The maintainer's intuition that 33 audits should have produced more density is correct.
"Zero retirements may reflect quality — the maintainer has not retired any because none have failed yet." Possible at low N. Implausible at N=150 over 36 days, especially when 58 candidates exist and 11+ of them are >17 days old without status-history activity. Some of those 58 candidates are almost certainly retirement-eligible; the system simply does not prompt anyone to ask.
"Schema-changelog growth is refinement, not accumulation." Refinement and accumulation are the same thing if no rule is ever retired. 13 additive versions in 36 days is accumulation by definition. The decomposition argument used to justify v0d (skill files reduce context load) is the strongest counter, but even there the rules moved, no rule was retired.

The bias diagnosis survives these counter-arguments. It is structural, not circumstantial.

6. Three architectural changes to test

Each change names: (a) the failure mode it addresses, (b) the cost it imposes, (c) the operational success signal after 4-6 sessions. None requires schema upheaval; all three are additive workflow guards plus one CLAUDE.md subsection. Implementation is deferred to maintainer adjudication.

6.1 Retirement gate, paired with periodic retirement review

What. Add to CLAUDE.md §Claim Status Gates a fourth gate alongside live/supported/contested: an explicit retirement gate with concrete triggers, not abstract criteria. Triggers:

A candidate claim with Created: older than 45 days and zero Status History activity since creation is reviewed for retirement at the next audit. The review is a 3-test gate (mirror of the live-promotion gate):
1. Is the claim still articulable as something a future maintainer would test for or against?
2. Has any subsequent ingest produced evidence (not just topical adjacency) that the candidate is worth keeping alive?
3. Is the candidate's slug genuinely distinct from any existing live or supported claim, or has a stronger nearby claim subsumed it?
If 2 or more tests fail, the claim retires with a one-line reasoning entry preserved in its Status History.
A live claim with no Counterpressure section, or with Counterpressure that has not been updated in 30 days while related ingests landed, is reviewed for downgrade to candidate or for retirement.

Add to audit/SKILL.md Phase 8 — Synthetic-layer assembly a Step 8.6 "Retirement review" running alongside the existing Step 8.5 (HUB optional-section work) and Step 8.9 (cite-back). The review takes a maximum of 10 retirement-eligible candidates per audit cycle and produces retire/keep verdicts.

Failure mode addressed. Asymmetric gates produce monotonic claim accumulation. 0 retired / 150 entries is the visible outcome.

Cost. ~10-15 minutes per audit cycle. The user adjudication overhead is bounded by the 10-per-cycle cap. The maintainer must accept that some candidates will retire even though they could have been promoted with more work — this is the actual point of the gate (some candidates do not deserve more work).

Success signal after 4-6 sessions. (1) Retired count rises from 0 to ≥5 within four audit cycles. (2) Candidate count stops growing faster than supported count (currently candidate is rising +20-40 per Phase 8 run, supported rises +0-2). (3) The mean age of candidate-status claims falls or holds steady, rather than rising.

Counterpressure. Premature retirement of a candidate that would have promoted with more evidence is the failure mode this change introduces. The 3-test retirement gate is structurally weaker than the 3-test live-promotion gate (no Counterpressure required, less restrictive); this is intentional, since the loss from a premature retirement is small (the entry is preserved with reasoning per CLAUDE.md, easy to revive) compared to the loss from indefinite candidate accumulation (the candidate pool becomes unreviewable noise). If the change produces visible premature-retirement regret in 4-6 sessions, the trigger thresholds (45 days, 30 days) can be tightened upward.

6.2 Audit Phase 9 — Consolidation pass

What. Add a new audit phase, Phase 9 ("Consolidation"), that runs at the close of each audit cycle. Its output is reduction-class only:

Page merges (using the existing Merge or Split workflow from CLAUDE.md), prioritizing concept pages whose overlap is ≥70% by topic and citation set.
Claim consolidation (when two candidate or live claims articulate the same thesis under different vocabulary, merge into the stronger slug; the weaker retires with a status-history pointer to the surviving slug).
Motif consolidation (when two motif entries in motifs.md track the same recurrence under different names, merge with cross-tradition note).
Concept-page section retirement (when a section's content has been superseded by a later ingest, the section retires with a one-line successor pointer rather than being silently overwritten).

The phase produces a report at .audit/consolidation-{YYYY-MM-DD}.md with format: candidates considered, decisions made, reasoning, and downstream cleanup. Hard cap per run: 3 page merges, 5 claim consolidations, 2 motif consolidations, 5 section retirements.

The phase inherits the audit skill's existing report discipline (one log entry, one commit, link to consolidation report from audit-synthesis-{date}.md if a synthesis is produced).

Failure mode addressed. Six of seven workflows are additive or read-only. The only reduction workflow (Merge/Split) is invoked 3 times in 156 ops because it has no native trigger — it lives in CLAUDE.md as "rare but needs priming." Phase 9 gives reduction its own scheduled cadence.

Cost. ~20-30 minutes per audit cycle. Some consolidation decisions require user adjudication (the maintainer-only "interpretive judgments above the autonomous gate" rule from CLAUDE.md applies to merges across thesis-central concepts). The hard cap prevents the phase from becoming a per-run rewrite.

Success signal after 4-6 sessions. (1) Refactor-class log entries rise from 3 of 156 (1.9%) to ≥5% of operations. (2) Concept-page count stops growing (or grows more slowly than source-page count). (3) The wiki/.audit/next-actions.md queue produces consolidation-eligible items rather than only additive items.

Counterpressure. A consolidation pass that merges too aggressively risks losing distinctions the wiki cares about (e.g., pensée-de-survol vs high-altitude-thinking was usefully split in a 2026-05-08 refactor; a too-eager Phase 9 would re-merge it). The phase's report format must include a "rejected merges" section explaining why each non-merge was preserved, mirroring the Counterpressure discipline in claim entries.

6.3 Pre-ingest articulation gate

What. Add to ingest/SKILL.md a new Step 0 ("Articulate the densification target") that runs before Pass 1. Before any ingest can proceed, the maintainer (or the executing Claude session) must answer two questions in plain prose, recorded in the ingest log entry:

Which existing artifact does this source primarily densify? Cite specifically: a claim slug, a concept page, an open question, a motif entry, or "this source primarily adds coverage of a new area — no existing target."
What is the expected payoff? A predicted promotion (candidate→live, live→supported), a predicted retirement (the source supersedes an existing claim or page), an evidence anchor for a previously-speculative section, or "general coverage" (in which case the source is a candidate for deferral).

If the answer to both questions is "general coverage," the source is added to a deferred-ingest queue at wiki/.audit/deferred-ingests.md rather than processed immediately. The queue is reviewed at the next audit cycle; sources that have not earned a specific densification target by the second review can be retained in the queue or marked for indefinite deferral.

The gate does not prevent ingestion. It changes the trigger from "user asks" to "user articulates."

Failure mode addressed. Ingest is the most articulated ritual; the gate to it is the lowest. The 2026-05-12 → 2026-05-16 sequence shows that even when a state-maintenance audit explicitly identifies the work as non-ingestion, the next session ingests. The gate adds friction at the right place — not in the workflow itself (which is already disciplined), but in the trigger that activates it.

Cost. 2-3 minutes of articulation per ingest proposal. Some sources currently being ingested will defer; the deferred-ingest queue may grow before it shrinks. Maintainer resistance is the main risk — the gate may feel pedantic on sources whose value is obvious (e.g., a long-anticipated MP volume). The articulation cost can be honored by writing one sentence rather than two.

Success signal after 4-6 sessions. (1) Ingest rate falls from current ~1.5 per day to ≤0.7 per day, sustained across at least two weeks. (2) The densification yield per ingest — measured as (claims promoted to live or supported + claims retired) / ingests — rises measurably. (3) The deferred-ingest queue is non-empty and is reviewed at each audit cycle (the queue itself becomes the artifact that proves the gate is working).

Counterpressure. The gate cannot be allowed to ratify the existing biases. If a source's densification target is "writes Paper A," that is currently a legitimate target — but Paper A could itself be a downstream symptom of the same bias (the wiki was built for papers, and any source that touches a paper's argument can be retroactively justified as densification). The gate's review criterion must therefore include: does the predicted payoff cite specific artifact slugs, or is it shaped to satisfy the gate after the fact? The latter is a sign the gate is being gamed and the source should defer.

Three changes I considered and rejected:

A "density score" displayed on wiki/overview.md. Goodhart-vulnerable. The supported-ratio metric is useful as a diagnostic but should not become a target — promoting weak candidates to live just to move the number is exactly the failure mode the wiki should avoid.
Mandatory ratio of densification operations to extension operations. Too rigid. The 1:3 or 1:1 ratios I sketched are arbitrary; they would either constrain the wiki when an ingest is genuinely the right next move, or they would push the maintainer into ritual densification (sweep-style updates that don't actually change anything).
Retirement of existing schema rules. The schema-changelog growth (13 versions in 36 days) is symptomatic of the same bias, but the right response is not to retroactively retire rules — most of the rules earn their keep, and the additive-only changelog is correct discipline (preserves genealogy). The right response is the v0d.4/v0d.5/v0d.7 review-clause discipline (workflows on probation), applied more rigorously when new schema versions ship.

8. Limitations of this audit

This audit treats the log as authoritative for operation distribution. The log undercounts operations performed within a single session (e.g., a Phase 8 run that promotes 12 candidates appears as one log entry, not 12). The 0-retirement count is robust to this undercounting (one entry per retirement is what the log records), but the extension-class share may be slightly underestimated if multi-step ingests are batched into one log entry.

This audit does not adjudicate whether any specific source in raw/ should be deferred. The pre-ingest articulation gate (§6.3) is procedural; per-source deferral is a separate adjudication.

This audit does not propose changes to AUDIT_PLAN.md, since AUDIT_PLAN.md is a per-run executable artifact rather than durable schema. The proposed Phase 9 (§6.2) would land in .claude/skills/audit/SKILL.md; AUDIT_PLAN.md would inherit the phase at the next plan write.

This audit does not address Paper A (or other downstream paper projects) directly. The papers' relationship to the wiki's bias is real but downstream: papers consume the wiki's synthesized material, and a wiki biased toward extension under-produces the supported claims that papers can lean on. If the architectural changes in §6 succeed, the supported-claim ratio rises and the papers have more durable material to cite. This is mentioned for context, not as an aspirational goal.

This audit accepted the maintainer's framing that "density is the kind of growth the project needs." That framing is not self-evidently correct — a maintainer who wants the wiki to be a comprehensive MP source-archive rather than a paper-supporting synthesis would correctly prefer the current bias. The diagnosis above is conditional on the maintainer's goal of supporting papers, which the schema-changelog and the existence of Paper A workspace strongly imply but do not strictly entail.

9. Recommended next adjudication

The maintainer reads this report and decides which (if any) of the three architectural changes in §6 to test. The recommendation order is:

§6.1 (retirement gate) first, because it has the strongest evidence (0/150 retired) and the lowest implementation cost (one CLAUDE.md subsection + one audit-skill step). It is also the change that produces the cleanest measurable signal within 4 weeks.
§6.2 (Phase 9 consolidation) second, if §6.1 produces the predicted signals and the maintainer has appetite for a second additive change. This is the change that most directly addresses the "every workflow is additive" finding in §3.3.
§6.3 (pre-ingest articulation gate) third, and only after the maintainer has lived with §6.1 and §6.2 for 4-6 weeks. This change touches the workflow the maintainer cares about most (ingest) and is the most likely to be resisted. Sequencing it last gives §6.1 and §6.2 a chance to relieve the underlying pressure that drives the ingest preference, possibly making §6.3 unnecessary.

Adjudication should produce one of: (a) accept one or more of the changes with implementation deferred to a follow-up session; (b) reject one or more with reasoning; (c) propose a counter-design that addresses the same failure modes differently. The diagnosis itself (sections 1-5) is the deliverable that does not require adjudication — it is intended to stand as the wiki's evidence-anchored answer to its maintainer's hypothesis.