Ontology

Every fact in your KlyHub knowledge base lives in exactly one of five layers. The layers exist for three reasons:

1. Retrieval stays fast. An AI client querying for "current competitors" doesn't have to search your operational notes.
2. Answers stay explainable. Citations point to a layer + entry, so the AI can say "according to your Market layer, your top competitor is Acme."
3. Updates stay surgical. When something changes in your Operations, you don't accidentally rewrite your Core identity.

The 5 layers are: Core, Market, Motion, Operations, Memory.

Core

What lives here: the unchanging identity of the company.

• Legal name, DBAs, registered entity type, founding year, founders.
• One-sentence elevator pitch.
• Mission, values, primary customer segment(s).
• Headquarters, primary operating geographies.

Cardinality: exactly one Core record per tenant.

Update frequency: rare — typically only on legal restructurings or major pivots.

Market

What lives here: how the company sits in its market.

• Industry, sub-industry, category labels.
• Top competitors, with differentiation notes per competitor.
• Buyer personas, ICP (ideal customer profile), market segments.
• Pricing posture (where the company sits relative to category pricing).
• Trends + signals you're tracking.

Cardinality: one Market record per tenant; arbitrarily many child entries (competitors, personas, segments).

Update frequency: quarterly to monthly — Market evolves as the company learns.

Motion

What lives here: how the company goes to market and grows revenue.

A Motion is a distinct revenue-generation pattern. A company with PLG self-serve and an enterprise sales team has two Motions, captured separately so the AI can answer questions like "which motion has the best 12-month payback?" without conflating them.

Each Motion entry captures:

• Motion type — PLG, sales-led, channel/partner-led, marketplace, hybrid.
• Acquisition channels with cost-per-acquisition and conversion-rate notes.
• Activation criteria — what "activated" means for this motion.
• Retention + expansion levers.
• Funnel-stage metrics if you're tracking them.

Cardinality: one or more Motion records per tenant (the Motion[] array is the only list-typed top-level layer).

Update frequency: monthly — motions change as you experiment.

Operations

What lives here: the operating reality of the company.

• Team structure, headcount by function, key hires planned.
• Tech stack (with attention to anything an AI client should know — e.g. "we are migrating off Stripe to a competitor").
• Customer onboarding flow, key SLAs.
• Vendors, sub-processors (mirrors /legal/subprocessors if you publish one).
• Compliance posture — SOC 2, GDPR DPO, etc.

Cardinality: one Operations record per tenant; many child entries.

Update frequency: monthly — Operations changes as the company grows.

Memory

What lives here: what changed, when, and why.

Memory is the only append-only, timestamped layer. Every Optimization update from the intake appends a Memory entry. Examples:

• 2026-04-15 — Closed Series A; new investor: Acme Ventures.
• 2026-05-01 — Hired Director of CS; backfilling old support inbox.
• 2026-05-10 — Decided to sunset the channel-partner motion; reallocating to PLG.

Memory entries cross-reference the other four layers, so when an AI client asks "what changed in our Motion picture last month?", it gets the deltas with the relevant Motion entries linked.

Cardinality: unbounded (you'll have many Memory entries over time).

Update frequency: continuous — anything from a few entries a month to a few a day.

How the layers interact

A typical AI client query touches multiple layers:

"What's our differentiation against Acme in the enterprise segment, and what motion are we using to win against them?"

This resolves to:

1. Market — competitors entry for Acme, with notes scoped to segment=enterprise.
2. Motion — the enterprise-sales motion record, with the play we run when Acme is in the deal.
3. Memory — the last 3 wins/losses against Acme to ground the answer in recent reality.

KlyHub does this resolution automatically — your AI client just calls klyhub.query with the prose question, and the server fans out to the right layers.

For programmatic access to the layers, see the API reference.