Content Type

Content Type

Definition

Closed enumeration of the editorial shape a source_documents row can take: article, blog post, PDF, note, research document, generic document, or other. Re-homed off content_items.content_type onto source_documents.content_type at ID-131 M3 (20260628191700_id131_sd_classification_cols); content_items itself was DROPPED at ID-131 M6 (S450 GO) — the table no longer exists on any env. The source_documents.content_type column is character varying(50), nullable (DROP NOT NULL at 20260628191704_id131_sd_content_type_nullable — content_type is a classification OUTPUT, unknown at ingest, so the column cannot be NOT NULL). Closed for v1 per Q-OQR1-12 ratification — adding new content types is research-deferred to v2 per §6.2 of the WP-ONTO-R1 doc.

BI-3 three-way split (ID-133), now applied to this register: the pre-ID-131 15-value enum split three ways —

• Record classifications stay here as the 7 values below.
• q_a_pair migrated out — DONE. See §Synonyms/Acronyms.
• L-concept type discriminators moved to concept_type (37-concept-type.md, ID-133 BI-6). See §Notes for the mapping.

Synonyms / Acronyms

• q_a_pair — migration-out DONE. q_a_pairs is a peer Layer-5 class (32-q-a-pair.md) with no content_type column; it never re-entered source_documents.content_type post-M3. The historic content_items.content_type='q_a_pair' rows died with the content_items table at M6.
• policy / compliance / methodology / capability / case_study / certification / product_description are no longer content_type values — they left this register at BI-3 and now live as concept_type discriminators (37-concept-type.md). The Ratified-S237 policy (prescriptive statement) vs compliance (evidence of adherence) boundary and the capability-retirement decision are historical content_type context, preserved for provenance in §Notes; both currently collapse to concept_type=topic / concept_type=product per the mapping below.

Baseline values

key	label	provenance
article	Article	core
blog	Blog	core
pdf	PDF	core
note	Note	core
research	Research	core
other	Other	core
document	Document	core

Relationships

• source_documents.content_type — nullable character varying(50) (ID-131 M3 20260628191700, nullable at 20260628191704). No DB CHECK constrains the column directly; the closed 7-value set is HARD-rejected at the pipeline layer — see §Consumers.
• The pre-M3 content_items.content_type CHECK constraint content_items_valid_content_type (15 values) is GONE — content_items was DROPPED at ID-131 M6.
• Neither q_a_pairs nor feed_articles carries a content_type column (feed_articles constrains extraction_method via CHECK instead).
• L-concept type (the six migrated-out discriminators, collapsed to a 5-value set) now lives in 37-concept-type.md’s concept_type register — a SIBLING closed vocabulary, not a subset of this one. See §Notes.
• Layer 2 (descriptive metadata): content_type is the primary “what is this?” descriptor on every source_documents row.
• Layer 5: consumed by classifiers (lib/quality/, scripts/cocoindex_pipeline/extraction.py) at extraction time.

Consumers

• lib/validation/schemas.ts — VALID_CONTENT_TYPES canonical Zod constant tuple (export const VALID_CONTENT_TYPES = CONTENT_TYPE_VALUES;); ItemCreateBodySchema.content_type = z.enum(VALID_CONTENT_TYPES).
• lib/validation/ingest-schemas.ts — IngestUrlBodySchema.content_type.
• lib/taxonomy/taxonomy.ts — re-export shim (CONTENT_TYPES = VALID_CONTENT_TYPES).
• lib/ontology/content-type-registry.ts → lib/ontology/content-type-values.generated.ts — build-time-generated CONTENT_TYPE_VALUES tuple (public-repo mirror of this register’s baseline_values, per the ID-133 BI-7 Decision-A authority chain — see README.md).
• scripts/cocoindex_pipeline/extraction.py:470-481 — _validate_content_type field validator; the HARD-reject gate (see §Definition). Reads _VALID_CONTENT_TYPES off scripts/tests/fixtures/taxonomy_snapshot.json:content_types[].
• scripts/kb_pipeline/classifier.py — ML classification target (one of the 7 values, post-BI-3 trim).
• app/item/[id]/new/page.tsx, components/create-content/upload-tab-content.tsx — content_type form select.
• lib/mcp/tools/content.ts, lib/mcp/tools/search.ts — MCP search/filter input.
• Markdown parity test (__tests__/lib/ontology/markdown-parity.test.ts) — asserts the frozen content_type baseline validates against OntologyCVSchema and (where the taxonomy_snapshot.json fixture is present) matches the live DB CHECK. The fixture itself still carries the pre-BI-3 15-value set — the trim to 7 is subtask {133.13}‘s FREEZE, gated on bun run sync:taxonomy; this register authors the decision in parallel (ID-133 BI-3 note above).

Notes

• BI-3 split is JOINT-RATIFY (owner escalation, non-blocking for authoring). The resulting source_documents.content_type value set MUST equal ID-131 M3’s content_type column semantics, and the L-concept type set MUST equal ID-132’s concept type discriminators — this is a joint ratification across ID-131 §3 / ID-133 BI-3 / ID-132, flagged for the owner before the taxonomy_snapshot.json fixture + content-type-values.generated.ts are frozen at {133.13}. Drive from the id-71 strawman + the client’s hand-built topic index.

• RECOMMENDED content_type → concept_type mapping (from the {133.1}/{133.4} journal; mirrored at 37-concept-type.md, the mapping’s canonical home):

  raw content_type (pre-BI-3)	maps to concept_type
  case_study	case_study
  certification	certification
  policy	topic
  compliance	topic
  methodology	topic
  capability (already ratified-S237 to retire)	product
  product_description	product

  ID-132 BI-4 concept set = {topic, product, company, certification, case_study} (company has no raw content_type predecessor — sourced from the client’s company-overview corpus).

• policy vs compliance — Ratified-S237 author-vs-evidence rule (historical; now informs the mapping above). Liam ratified S237: policy = the organisation’s prescriptive statement (“we do X”); compliance = evidence of adherence to an external regime (“audit of X”). Industry-aligned with ISO management-system framing. Both collapse to concept_type=topic post-BI-3, so the distinction is preserved as provenance context, not an open content_type decision.

• methodology vs capability — Ratified-S237 retire capability (historical). Liam ratified S237: capability retires (0 prod rows); methodology absorbs the remaining concept space. Both now migrate to concept_type (methodology→topic, capability→product) rather than remaining content_type values.

• INV-2 source. No authoritative spec defined the pre-S237 boundaries; see docs/specs/wp6-ontology-harness/investigations/INV-2-content-type-semantics.md for the archaeology. Superseded by the BI-3 migration above — the values these investigations concerned are no longer content_type members.

• Prod-data evidence (verified 14/05/2026, pre-ID-131; historic content_items counts — table now dropped): policy 19 rows, compliance 17 rows, methodology 7 rows, capability 0 rows, q_a_pair 395 of 629 rows (~63%, dominant pre-migration content_type). Not re-verified against source_documents post-M3 — the classification/reclassification run over the migrated corpus is separate work.

• Closed enum for v1; client-extensible content types are research-deferred to v2 per §6.2.

• The full pre-BI-3 list mirrored phase-b-prerequisite-1-onthology-pipeline.md §2.1 row 4 verbatim; that document is now stale against this trimmed register (BI-9 prose-sweep scope, not this subtask).