Build a real entity graph. Not a flat keyword list.
The Entity & Keyword workspace gives every project the full Koray hierarchy — source context, central entity, sub-entities, composite attributes with structural types, the scoring trio, typed values, metadata blocks, lexical relations and triples. The semantic-SEO backbone the rest of Holistic Rank reads from.
7
Koray layers covered
10
Structural-type flags
8
Lexical relation types
3
Score axes (kept separate)
Knowledge domain, source context, central entity, central search intent.
Every Koray-aligned semantic-SEO project starts with four framing fields. Knowledge domain pins the topic. Source context describes the site's purpose and monetisation. The central entity is the single thing that appears in every section. Central search intent unifies them.
- Four fields, one source of truth for the project
- Every downstream module reads the framing layer
- Editable from a single modal — no scattered config
- Powers content briefs, schema generators, topical maps
Project framing
Knowledge domain
SEO consulting · B2B SaaS
Source context
Mid-market SaaS clients — retainers + audit fees
Central entity
Technical SEO Audits
Central search intent
Source context + central entity unified
Central → sub-entities → related, self-referencing all the way down.
Entities form a tree. Set a central entity for the project, then nest sub-entities indefinitely — plane → wing → engine → blade. Each level inherits source context and can override it. Parent–child relationships drive the topical map and content planning.
- Self-referencing tree — unlimited depth
- Central, sub, related and outlier entity types
- Parent–child relationships preserved through updates
- One central entity per project, enforced at the DB level
Entity class, named/unnamed, synonyms.
Beyond a name, each entity carries a class (Service / Place / Thing / Concept…), a named-vs-unnamed flag, and an array of synonyms. The synonyms feed keyword expansion, the class powers schema-type inference, and the named flag distinguishes proper-noun entities from generic ones.
- Free-form entity class label per entity
- Named vs unnamed flag, used for schema inference
- Synonyms array — fuels keyword expansion downstream
- Inline editor — no extra clicks
Technical SEO Audits
Class · Service
Eight linguistic relations to close topical-map gaps.
Holonym, meronym, hypernym, hyponym, synonym, antonym, polyseme, homonym — the eight Koray-mapped relations. Link each entity to other in-project entities or to free-text terms. Used by the topical-gap analyser, the cannibalisation scanner, and the brief generator.
- All 8 relation types from the Koray framework
- Link to another entity OR a free-text term
- Powers topical-gap and cannibalisation analysis
- Per-entity inline panel — no separate page
Lexical relations · Technical SEO Audits
Size → height, width, depth. Real composite attributes.
Attributes carry the entity. A simple attribute (age) stores one value. A composite attribute (size) contains child attributes (height, width, depth). The parent–child link is first-class — every downstream module renders the composite tree correctly.
- Composite attributes via parent_attribute_id
- Unlimited nesting depth
- Same model handles simple and composite
- Tree picker in the editor — no manual ID juggling
Composite attribute
core_web_vitals
composite · direct · multivalued
Ten Koray structural flags. Pick any combination.
An attribute is rarely just one thing. The structural-types field is an array — pick simple OR composite, direct OR indirect, single-valued OR multivalued, derived OR stored, plus the key flag. The editor groups them by shape, ownership, cardinality, origin and role.
- 10 flags: simple/composite/complex · direct/indirect · single/multivalued · derived/stored · key
- Multi-select — every legal combination is supported
- Grouped editor — never guess which group a flag belongs to
- Stored as a Postgres array; query-friendly
Multi-flag picker
Shape
Ownership
Cardinality
Origin
Role
Core section (main) vs outer section (minor).
Every attribute is tagged main or minor — driving whether it densifies the core section of the topical map or supports it through the outer section. Trust and quality signals flow from outer to core; the source-context densification flows the other way.
- Core section = main attributes
- Outer section = minor attributes (trust/quality)
- One flag, downstream modules use it everywhere
- Visualised as a coloured badge throughout the UI
main
Core section
Densifies source context
minor
Outer section
Trust / quality propagation
page_speed_score main
consultant credentials
client testimonials
Root, rare, unique. Where the attribute sits on the topical map.
The SCN (Search Coverage Network) dimension positions each attribute on the topical map. Root attributes are shared across the map. Rare attributes are distinctive but findable elsewhere. Unique attributes belong only to this entity. Used by the topical-authority scorer to weight coverage.
- Root · Rare · Unique — three Koray-defined positions
- Drives topical-authority weighting
- Picker tiles with one-line explanations
- Optional — sensible defaults if not set
SCN dimension
root
Shared across the map
rare
Distinctive but findable
unique
Belongs only to this entity
Prominence, popularity, relevance. Three separate axes.
Most tools collapse 'how important is this attribute' into one number. Koray's framework keeps them apart. Prominence is how essential to the entity definition. Popularity is the search volume of the attribute name. Relevance is to the SOURCE CONTEXT, not the entity. The editor exposes them as three distinct inputs — never merged.
- Prominence (0–1) — essential to entity definition?
- Popularity (int) — search volume of the attribute name
- Relevance (0–1) — to SOURCE context, not entity
- Three columns in the database — semantics preserved
Three separate scores · attribute = page_speed_score
Essential to definition
Search volume
To source context
value_content + value_set + unit + data_type.
Each attribute holds one or more values. Each value is typed (string, number, boolean, date, enum, url, image, json), unit-aware (m, kg, EUR…) and constrained by a value_set (length, Celsius|Fahrenheit). Multivalued attributes hold multiple value rows; single-valued ones hold exactly one.
- 8 data types — string, number, boolean, date, enum, url, image, json
- Per-value unit and value_set
- Inline editor — add, edit, remove without leaving the drawer
- Single-valued or multivalued — same consistent model
lcp · multivalued · stored
1.8
2.4
1.6
Validation · Presentation · Grouping · Dependency · Computation.
Each attribute can carry typed metadata. Validation limits the value range. Presentation specifies formatting. Grouping clusters related attributes. Dependency links one attribute's range to another. Computation defines conversions (% / m→ft / EUR→USD). Payload is JSON — store whatever you need.
- 5 typed metadata kinds — validation, presentation, grouping, dependency, computation
- Each carries a JSON payload tailored to the kind
- Read by validators, formatters and converters across the platform
- Surfaced as code-block chips in the editor
Metadata blocks
validation
{"min":0,"max":10}presentation
{"format":"%.2fs"}dependency
{"dependsOn":"page_url"}complex_computation_validation
{"convert":{"s→ms":1000}}Subject → predicate → object. The graph edges.
Triples connect entities to each other or to literal values. Subject and object are both entities (or the object can be a literal). Together they form a queryable graph — the semantic-SEO backbone. Used by the entity-prominence snapshots, the topical-map renderer and the schema generator.
- Subject and predicate are required
- Object can be an entity OR a literal value
- Indexed for fast traversal
- Drop in any predicate vocabulary you prefer (Schema.org, custom)
Triples
Every module reads from one entity graph.
Wire the Koray hierarchy once. Topical maps, schema generators, content briefs, on-page audits, E-E-A-T scoring and outreach all read from the same source of truth.