Concept Type

Definition

A concept_type is the controlled vocabulary of L-concept classes an OKF (Open Knowledge Framework) concept-bundle producer may assign to a distilled concept .md file — the kind of synthesised knowledge a concept represents (a topic, a product, the company itself, a certification, or a case study). It is the Layer-5 concept-frontmatter type discriminator that gates every L-concept write (ID-133 BI-6) — the L-concept analogue of the closed-enum HARD-reject pattern already used by content_type (04-content-type.md) and the KG-ontology pair entity_type / relationship (BI-5, 34-entity-type.md / 35-relationship.md).

Status: RATIFIED-DEFAULT, not yet FROZEN (JOINT-RATIFY). TECH §BI-6 prose lists the raw BI-3 discriminators being migrated out of content_type — case_study / policy / compliance / methodology / certification / product_description — plus any id-71-derived additions (specs/id-71-ai-tooling). The RECOMMENDED mapping (ID-132 BI-4, ratified into this register per the {133.1}/{133.4} journal) collapses those raw discriminators to the 5-value set below. The FINAL set is an owner joint-ratification outcome across ID-131 §3 / ID-133 BI-3 / ID-132 BI-4 — this register is authored against the recommended collapsed set as the S448 default and MUST be revisited (baseline_values + the mapping below) if joint ratification lands on a different set.

The raw-discriminator → collapsed-type mapping (from the {133.4} journal, driving the fixture/snapshot freeze in a later subtask):

raw BI-3 discriminator	collapses 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`
— (no raw discriminator; sourced from the client’s company-overview corpus)	`company`

Synonyms / Acronyms

L-concept type — the type discriminator on an L-concept (Layer 5 of the OKF three-layer storage model, 36-three-layer-model.md); not to be confused with 03-layer-vocabulary’s audience/depth axis.
BI-4 concept-type set — ID-132’s name for this same register ({topic, product, company, certification, case_study}).

Baseline values

The 5 ratified-default concept classes. Each value is core and immutable, edited only by database_migration; the CV-level client_extensible: true is the forward bridge (see Notes), not a v1 capability.

key	label	provenance	provenance_model	client_extensible	editable_via
topic	Topic	core	core	false	database_migration
product	Product	core	core	false	database_migration
company	Company	core	core	false	database_migration
certification	Certification	core	core	false	database_migration
case_study	Case Study	core	core	false	database_migration

Relationships

Sibling — 36-three-layer-model.md (Layer 1, l_concepts). This CV classifies the members of the l_concepts storage layer — every concept file in an OKF bundle carries exactly one concept_type value in its frontmatter. related_layers: [1] records the reciprocal pairing (36 already declares related_layers: [5] back at this Layer).
Migration-in from content_type (BI-3). The six raw discriminators listed in the mapping table above leave 04-content-type.md entirely and become this CV’s values — see 04-content-type.md’s Notes for the migration-out record.
resource: URI → L-records citation. Every concept’s resource: frontmatter key uses the canonical://<table>/<uuid> scheme (owned by ID-132) to cite the source_documents / q_a_pairs / Knowledge-Graph row it distils — the l_concepts → l_records pointer described in 36-three-layer-model.md’s Relationships section. concept_type never appears in the URI itself; it is a sibling frontmatter key.
KG semantic linter (ID-132 BI-13). The concept-frontmatter validator also lints concept bodies against the closed entity_type (12 values) / relationship (10 values) sets from BI-5, so concept_type sits alongside those two CVs as one of three closed vocabularies a single concept write may be checked against.

Consumers

ID-132 OKF concept producer — sole writer. The producer (a cocoindex flow in scripts/cocoindex_pipeline/, sibling to flow.py) writes concept .md files via localfs.declare_file; every write is gated on a concept-frontmatter validator (ID-132 BI-13) that checks type ∈ this baseline set before the file lands.
ConceptFrontmatterSchema — the code twin (ID-133.12, in parallel). A NEW Zod schema at lib/ontology/concept-schema.ts (sibling to lib/ontology/schemas.ts; direct import, no barrel) validates type against this exact 5-value enum, the required frontmatter keys, and the resource: URI shape. The enum in that module MUST mirror this register’s baseline_values keys.
Parity note (differs from BI-5’s three-way bind). entity_type / relationship are triple-bound (Python Pydantic Literal == TS const == fixture) because they gate the cocoindex extraction pipeline. concept_type has no Python Literal counterpart — L-concept production is a separate producer flow, not the entity/relationship extraction gate — so the lockstep here is two-way: this register markdown == ConceptFrontmatterSchema’s TS type enum.
ID-132’s Task-level SOFT dependency. ID-132 prefers to consume ID-133’s validator, but ships an in-Task minimal fallback validator (same required-key + type-set + resource:-scheme checks) if ID-133 has not yet landed, so the dependency never hard-blocks either Task.

Notes

Required concept frontmatter keys. Every L-concept .md file’s YAML frontmatter MUST carry: type (this CV’s key, e.g. topic), title (human-readable concept name), description (one-line summary), and timestamp (last-synthesised/last-edited ISO 8601 string). resource: and tags: (below) are additional required keys enforced by the validator but are not concept_type-specific.
The resource: URI scheme — canonical://<table>/<uuid>. Owned by ID-132 (not this CV). It is the single ingress point through which a Canonical DB row identity enters the client-owned OKF bundle — a pointer value, never the concept’s own identity key (the concept’s identity is its file path, per ID-132 BI-2). A table/query resource form (e.g. canonical://q_a_pairs?scope_tag=<tag>) is used instead of a row uuid when a concept references a queryable collection rather than one record (ID-132 BI-8).
The tags: convention. tags: string[] is a free-form label array on every concept, distinct from concept_type. Candidate concept classes considered during BI-4 ratification but rejected as separate concept_type values — metric, playbook — are carried as tags, not types (ID-132 PRODUCT.md, BI-4): a metric or dataset-flavoured concept is still typed topic/product/etc. and tagged metric/dataset for finer filtering.
Lift-vs-build call (BI-6). Google’s okf-skills validator was evaluated as a base for ConceptFrontmatterSchema rather than building from zero. Decision: build, not lift. The KH idiom is gray-matter (^4.0.3, already used at loader.ts:61) + Zod, mirroring the existing lib/ontology/schemas.ts pattern used by every other CV in this register — a thin KH-native schema keeps one validation idiom across the whole ontology surface. The okf-skills project is borrowed for its rule set only — the required-key list and the canonical://<table>/<uuid> URI shape — never its runtime.
Closed at v1; forward bridge (mirrors BI-5 Decision B). All 5 values are core and immutable, edited only by database_migration. The CV-level client_extensible: true is the forward-compat bridge, not a v1 capability: if concept types later become client-extensible, the per-value provenance_model / client_extensible / editable_via keys are exactly the columns a future DB-backed register would carry.