DR-130: Subject taxonomy is display-level metadata — the driving axes are scope, semantics, and concept membership

DR-130 — Subject taxonomy is display-level metadata; the driving axes are scope, semantics, and concept membership

Context

The S528 census, DR-125’s expiry ruling and the S529–S534 deletion waves dismantled the IMS-inherited subject-classification machinery piecewise, but no ratified source stated what subject taxonomy IS in the target model — platform-direction.md and entity-glossary.md never mention it, and four negative rulings (DR-125, DR-126, s529-a1 §4.1, the bundle’s ontology.json composition) circled the answer without landing it. The vacuum is why the concept kept regenerating: sessions found the columns, the snapshot, the seed rows and the filters, and inferred relevance from existence. S535’s grounding pass (reports/s535-taxonomy-grounding.md) measured the residual surface: the snapshot’s domains/subtopics feed a write-only telemetry counter, its form_types gate validates a value the walk discards (ID-136), platforms/ requirement_type have no consumers, and content_types — the one real gate — is hardcoded in the generator script, never DB-derived.

Decision

“Aboutness” is derived, display-level metadata; nothing in the platform is DRIVEN by a platform-global subject vocabulary. The driving axes are:

1. Scope (scope_tag) — the only filter-shaped mechanism retrieval needs (DR-125, id-422);
2. Semantics — embeddings + keywords + entity extraction; aboutness at query time is ranking, never an exclusion predicate;
3. Concept membership — bundle topics (scope-keyed since S531) and guides as curated clusters (DR-126); subject browsing is a curation-loop product, not an ingest stamp.

Consequently: the per-document LLM subject-classification stage and its driving consumers (hybrid_search filter_domain/filter_subtopic, the MCP find domain axis, review.ts filter_domains) retire; the platform-global taxonomy_domains/ taxonomy_subtopics vocabulary retires as a platform-core concept; and taxonomy_snapshot.json retires entirely — superseding DR-121’s relocation, which is now moot: there is no runtime asset to move once the pipeline’s readers are retired or inlined. If a client ever needs a subject vocabulary (badges, guide-membership display), it returns as an R6 client-overlay CV in the client bundle repo — curated, display-only, never NOT NULL, never minting identity, never a pipeline gate. hybrid_search’s filter_kind (document/answer/reference) is confirmed correct and unaffected.

Alternatives considered

• Execute DR-121’s move and keep the snapshot as pipeline runtime data. Rejected: it re-blesses the conflated file in the same month the grain expired, and the only array with a true production requirement is a generator-script constant.
• Keep domain filtering for users who know the subject. Rejected: three requirement-side sources plus measured behaviour show subject narrowing over an open vocabulary is recall-hostile by construction (lane 1 §1.2/§1.6); no client item, gap-tracker item or workflow names it.
• Keep the vocabulary platform-global “for the connectors”. Rejected: s529-a1 §4.1 — more heterogeneous inlets make a fixed vocabulary worse; the three ratified axes are inlet-agnostic.

Consequences

• id-416’s precondition inverts: instead of moving the snapshot before narrowing the build context, the pipeline’s snapshot readers are retired/inlined first (interim: the content-type gate’s set inlines as a documented transitional constant pending the 04-content-type rework — id-417 OQ5). Until that lands, the Dockerfile must still carry the file or the image cannot import.
• DR-121’s entity_aliases_snapshot.json rider (zero-caller generator — wire into deploy or delete, as its own decision) is unaffected and carries forward unresolved.
• The retirement execution — snapshot + generator + parity tests + validators + miss-counter telemetry + sync:taxonomy shrink + column cleanup on source_documents/reference_items — is next-session scope under id-417’s charter; tasks/id-71.md (S535 entry) carries the binding consequences for the MCP/tool rebuild; tasks/id-421.md carries the form_types CRUD half.
• A positive one-paragraph statement of this shape belongs in reference/entity-glossary.md / platform-direction.md with the cleanup, so the vacuum that let the concept regenerate is closed at the source. (Landed S537.)

Amendment (owner, S537)

sd.ai_keywords drops with the classification stage rather than surviving as a semantics-axis input: measurement at execution showed its only writer was the retired TS classify stage (flow.py declared the column and clobbered it on upsert but no caller ever passed a value), so the keywords leg of axis 2 is retired — the semantics axis is embeddings + entity extraction. get_popular_keywords and the keyword-suggestions surface retired with it. Executed in 20260805190000_id417_dr130_sd_ri_taxonomy_retirement.sql.