Skip to content
Canonical

Entity Type

Entity Type

Section titled “Entity Type”

Definition

Section titled “Definition”

An entity_type is the controlled vocabulary of entity classes the extraction pipeline may assign to a Knowledge-Graph entity mention — the kind of real-world thing a span of source text refers to (an organisation, a certification, a person, and so on). It is the Layer-5 (Ontology) class vocabulary the AI uses when it lifts entities out of a document body into the Knowledge Graph, and it is the allowed_types half of the owner’s allowed_types / allowed_relations register (ID-133 Decision B).

The vocabulary is closed at v1: the 12 baseline values below are the complete set, and the extraction gate HARD-rejects any entity type outside it. Enforcement is the Pydantic entity_type Literal on EntityMentionExtraction (scripts/cocoindex_pipeline/extraction.py:378–391) — a value not in the Literal raises a ValidationError (mapped to invalid_enum), exactly mirroring the closed-enum content_type HARD-reject. ID-133 does not edit that gate; it documents it. The register values are sourced verbatim from that Literal so the markdown register equals the runtime Literal at authoring time.

Synonyms / Acronyms

Section titled “Synonyms / Acronyms”
  • allowed_types — the owner’s name for this register; entity_type IS the allowed_types vocabulary (ID-133 Decision B, the allowed_types / allowed_relations pair).
  • entity class / entity kind — informal names for an entity_type value.

Baseline values

Section titled “Baseline values”

The 12 closed entity classes, in Literal order. Each value is core and immutable at v1; the CV-level client_extensible: true is the forward bridge (see Notes), not a v1 capability.

keylabelprovenanceprovenance_modelclient_extensibleeditable_via
organisationOrganisationcorecorefalsedatabase_migration
certificationCertificationcorecorefalsedatabase_migration
regulationRegulationcorecorefalsedatabase_migration
frameworkFrameworkcorecorefalsedatabase_migration
capabilityCapabilitycorecorefalsedatabase_migration
personPersoncorecorefalsedatabase_migration
technologyTechnologycorecorefalsedatabase_migration
projectProjectcorecorefalsedatabase_migration
sectorSectorcorecorefalsedatabase_migration
productProductcorecorefalsedatabase_migration
standardStandardcorecorefalsedatabase_migration
methodologyMethodologycorecorefalsedatabase_migration

Relationships

Section titled “Relationships”
  • KG write-site — entity_mentions (DB table). Each entity-mention row carries an entity_type column drawn from this vocabulary; the value is set at extraction time and stays in the Canonical DB (it is never lifted out into a markdown record).
  • Sibling — 35-relationship.md (relationship, Layer 6). Entity mentions are the nodes; relationship predicates are the edges between them — related_layers: [6] records the pairing. A (source, relationship, target) triple connects two entities, each of an entity_type.
  • Provenance chain. Every entity mention is stamped back to the source it was extracted from. Post-ID-131 the stamp’s parent FK is source_document_id (see Notes / 33-reference-item.md for the source-document chain).

Consumers

Section titled “Consumers”
  • Cocoindex extraction pipeline — sole writer. extract_entity_mentions (scripts/cocoindex_pipeline/extraction.py) emits EntityMentionExtraction rows; the Pydantic entity_type Literal (378–391) is the HARD-reject gate. The Literal mirrors the TS VALID_ENTITY_TYPES const in lib/validation/schemas.ts.
  • Parity guard — the lockstep mechanism. TestEntityTypeParity (scripts/tests/test_cocoindex_extraction.py) binds the triple Python Literal == TS const == register fixture. The public CI-visible fixture mirror is __tests__/fixtures/ontology/ontology-cv-baselines.json (expanded with entity_type per ID-133 Decision A); the docs-site “parity-guard twin” keeps that fixture in lockstep with this markdown register. Drift in any of the three fails CI.
  • Knowledge Graph read surface. entity_mentions is the typed read surface over extracted entities; consumers filter and join on entity_type.

Notes

Section titled “Notes”
  • Extraction stamp parent + entities stay in the DB (BI-8). Post-ID-131 the extraction stamp’s parent FK is source_document_id (NOT content_items_id) — see ID-131 M2 / _ExtractionStamp at scripts/cocoindex_pipeline/extraction.py:261–264 for the lockstep re-parent. ID-133 does NOT edit that code (it is ID-131’s; this register only reflects it). The entity write-site stays in the Canonical DB: entity mentions (and the relationships in 35-relationship.md) do not leave the DB into a markdown record (OKF v3 §7.1 / id-131 BI-14).
  • Closed at v1; forward bridge (Decision B). All 12 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: client-extensible entity types are research-deferred to v2, mirroring content_type’s “closed for v1” posture. If the product later makes them client-extensible, the per-value provenance_model / client_extensible / editable_via keys are exactly the columns a future DB-backed provenance table would carry — promotion goes to the taxonomy_domains-style DB register, NOT to a new markdown reader (Decision A drift-avoidance).