0022-weaving-pass-workflow

ADR-0022: Weaving-pass workflow

Status: Accepted Date: 2026-05-22

Context

ADR-0021 established the foundation-pass with three append-only parking files (_meta/parking/{threads,questions,web-search}.md) as the index the weaving pass would later consume. Foundation-pass for DP is now complete through Ch 2-7 — Part II close — yielding ~94 thread candidates, ~50 question candidates, and ~50 web-search items, all DP-sourced.

ADR-0021 names “weaving pass” as the consumer but does not specify its shape. Open questions: how to batch (per chapter? per cluster?), how to verify counter-arg citations (autonomous? user-mediated?), when to promote parked questions, what to do with the 7 threads already drafted during foundation pass, and how to honor the CONTEXT.md quality gate that no thread ships without a real cited counter-argument.

The weaving workflow is novel enough — and hard enough to reverse once threads land in /threads/ with attached questions — that it warrants explicit documentation before any cluster work begins.

Decision

A two-stage workflow opted into per cluster, governed by a one-time meta-batch that produces the cluster map.

Scope and batching

• Scope: weaving runs over one closed corpus at a time. First scope: DP (Part I + Part II, complete). CSG and WS atomics may enrich DP threads as supporting evidence but are not primary triggers in this pass.
• Batching: cross-cutting clusters, not chapter-by-chapter. Threads are inherently cross-chapter (christology pulls from 1-4 + 1-5 + 1-7 + 2-3b); chapter batching forces synthesis within a chapter’s atomics only and recreates foundation-pass shape.

Stage 0 — Meta-batch (one-time per corpus)

Produces the cluster map.

Inputs: _meta/parking/{threads,questions,web-search}.md, existing threads/*.md, CONTEXT.md.

Output: staging/weave-0-cluster-map/

• REVIEW.md — proposed cluster list, each entry: cluster slug + one-line claim + rationale + parked candidates pulled in (threads / questions / web-search) + existing-thread relationship (anchor / sub-claim / supersedes / orthogonal) + shape-representativeness flag (small / typical / large) + proposed sequence position
• cluster-map.md — the durable artifact

User review: approve, merge, split, reject clusters; set sequence.

Finalize: copy REVIEW to _meta/batch-reviews/weave-0-cluster-map.md; move cluster-map.md to _meta/cluster-map.md; delete staging; commit.

Stage 1 — Research batch (per cluster)

Verifies counter-argument citations. Mechanical: find quote, cite, mark provenance.

Input: cluster’s web-search items from _meta/cluster-map.md.

Output: staging/weave-{cluster-slug}-research/

• REVIEW.md — citation provenance summary + flagged items
• research-notes.md — per critic/work, sourced quotes with citations

Each citation gets one of four markers:

• [verified] — quote from accessible source, page/section noted
• [flagged-paywall] — book exists, AI couldn’t access full text, user-supply needed
• [flagged-unverifiable] — work might be misnamed/misattributed, user to confirm
• [secondary] — only encyclopedia-summary available, marked as not load-bearing

Hard rule: no fabricated page numbers or invented quotes. Flag and stop.

Hybrid execution per source type: AI runs WebSearch / WebFetch autonomously for patristic and canonical sources (Augustine, Aquinas, Calvin, Anselm — well-indexed at CCEL, New Advent, archive.org). For modern academic books (Wright 2003, Hart 2019, Levenson 1993), AI fetches but [flagged-paywall] when access is blocked.

Finalize: copy REVIEW to _meta/batch-reviews/weave-{cluster-slug}-research.md; move research-notes.md to _meta/research/{cluster-slug}.md; mark verified entries in _meta/parking/web-search.md as [verified — see _meta/research/{cluster-slug}.md]; delete staging; commit.

Stage 2 — Weaving batch (per cluster)

Synthesizes threads from atomics + research notes. Judgment-heavy.

Input: cluster atomics (existing in /reference/, /experience/), _meta/research/{cluster-slug}.md, parked questions for the cluster, existing /threads/ notes in the cluster.

Output: staging/weave-{cluster-slug}-threads/

• REVIEW.md — Variant-1 Thorough shape per ADR-0009:
  • For each new thread: claim, atomics used, counter-arg with citation, response (real or “[still wrestling — specific point]”)
  • For each existing thread in scope: keep-as-is / upgrade / subsume / split decision with rationale
  • Proposed question promotions with backlink to engaging thread
  • Parking-entry updates (mark [woven into thread-X] or [promoted as q-X])
• Proposed thread files: thread-{slug}.md each (Claim / Reasoning / Counter-argument / Response, per ADR-0006)
• Proposed question files: q-{slug}.md each (per ADR-0014 question-note schema)

Quality gate (hard): every new thread ships with ≥1 counter-argument citing a named critic. “Still wrestling” responses are allowed and encouraged when honest; placeholder counter-arguments fail the batch.

Quality gate — load-bearing vs supplementary refinement (per cluster-1 shakedown, 2026-05-22):

• Each thread has exactly one load-bearing counter-argument (the one the ## Response section directly engages). Per CONTEXT.md L82-83 “prefer one counter; multiple allowed only if all are independently strong” — multi-counter threads must mark which is load-bearing.
• Load-bearing counter-arg must be [verified] — accessible primary source + quote/page reference. This is the hard gate.
• Supplementary counter-args may be [secondary] (citation pipeline marker) — fine to ship if the load-bearing one is verified.
• If a load-bearing counter-arg is [flagged-paywall] or [flagged-unverifiable] after stage 1, the thread may ship in stage 2 with the CONTEXT.md L82-83 “source not located — provisional” disclaimer in the ## Counter-argument section, AND the stage 2 REVIEW.md surfaces the thread on a backlog list for user upgrade. This avoids stage-1↔stage-2 ping-pong while preserving the audit trail.
• The “still wrestling” mark in ## Response is for response uncertainty, not citation uncertainty — do not conflate.

Finalize: standard ADR-0009 finalize — REVIEW to _meta/batch-reviews/, threads to /threads/, promoted questions to /questions/, parking entries updated, staging deleted, commit.

Sequencing

After meta-batch produces the cluster map:

1. Smallest cluster — workflow shakedown (cheap rollback)
2. Best-verifiable cluster — citation-pipeline shakedown (mostly patristic / canonical sources)
3. Load-bearing clusters — christology / chronology / eschatology / Korea-SA, once workflow + pipeline are trusted
4. Remaining clusters — any order

Question promotion

Parked questions promote to /questions/ only when an engaging thread woven in the same cluster references them. ADR-0014’s default-promote rule (re-inverted from ADR-0021’s default-park) holds only inside weaving batches and only for questions a thread engages. User retains the override-promote knob per batch.

Existing threads

The 7 threads drafted during foundation-pass are treated as proto-clusters. Each is either an anchor or sub-claim within a proposed cluster. The meta-batch maps the relationship; stage-2 weaving decides per thread to keep / upgrade / subsume / split. Upgrade-pass on existing threads runs as a follow-up after each cluster’s new threads ship.

Alternatives considered

• A. Chapter-by-chapter weaving (mirror foundation-pass). Rejected — threads are inherently cross-chapter; chapter batching produces narrow threads that miss the cross-references parking entries already point at.
• B. Single-stage (search + weave in one batch). Rejected — citation errors and synthesis errors have different failure modes; separating them lets the user catch each independently. Research notes also become reusable across clusters (Augustine cited once for christology cluster, re-cited for trinity cluster).
• C. Priority-tier burndown (all [critical] first, ignore cluster structure). Rejected — critical-tier questions span clusters; weaving them without cluster scaffolding produces orphan threads that the cluster pass would have to re-do.
• D. Bulk-promote all DP parked questions to /questions/ at weaving start. Rejected — orphan Question notes pollute the index; the answering-thread rule keeps /questions/ meaningful.
• E. Re-weave all 7 existing threads from scratch. Rejected — discards the user’s foundation-pass judgement about what claims are load-bearing. Proto-cluster treatment preserves that signal.

Consequences

• (+) Two-stage shape isolates failure modes (citation accuracy vs synthesis quality), making each user-reviewable independently.
• (+) Cluster batching honors the cross-chapter shape parking entries already encode.
• (+) Research notes (_meta/research/) accumulate as durable, reusable knowledge regardless of any single thread outcome.
• (+) Hard quality gate (cited counter-argument) operationalizes CONTEXT.md’s thread schema requirement — no thread ships as wishful synthesis.
• (+) Parking files reduce to working inventory: weaving consumes entries and marks them, leaving only un-woven candidates for the next pass.
• (−) Doubles batch count per cluster (~10 clusters × 2 stages = ~20 batches). Mitigated by stage-1 being mechanical (low cognitive load) and stage-2 being the only judgment-heavy work.
• (−) New directory _meta/research/ to track. Acceptable — additive, mirrors _meta/batch-reviews/ shape.
• (−) Some web-search items will land [flagged-paywall] and stall pending user supply. Acceptable — better than fabricated citations; supply-on-demand fits the user’s chat-first iterative pattern.
• (−) Cluster sequencing pre-commits to validating the smallest cluster first, which may not be shape-representative. Mitigated by meta-batch flagging shape-representativeness per cluster so the user can override sequencing.