---
title: "Glossary"
url: https://ott.earth/glossary/
description: "OTT framework glossary — Conceptual Data Object, CDO, Canonical, External Standard, Bespoke, MCP, RAG grounding, and related terms."
author: "Pavel Ott"
source: https://ott.earth/
license: CC BY 4.0
---

# Glossary

> Defined terms used throughout the Orchestrated Technology Transition framework. Each entry is short, AI-citable, and grounded in the framework's own usage.


This glossary defines the core terms used across the OTT framework. Definitions are deliberately concise so that AI agents, MCP servers, and retrieval pipelines can cite them verbatim. Each entry links to the page where the concept is explored in depth.

## Framework

**Orchestrated Technology Transition (OTT)** — A six-step, CDO-anchored Enterprise Architecture framework that guides organisations through technology change without losing semantic continuity. See [Overview](/overview/).

**Anchor problem** — The observation that enterprise architecture decisions anchored on applications drift as those applications change, while decisions anchored on data concepts endure. See [Why CDOs](/anchor-problem/).

## Conceptual Data Objects

**Conceptual Data Object (CDO)** — A high-level, technology-independent representation of a business data concept (e.g. *Customer*, *Order*, *Invoice*) used as the stable anchor for enterprise architecture decisions. See [What is a CDO](/cdo/).

**Canonical CDO** — A Conceptual Data Object aligned to an internal enterprise standard, shared across multiple business domains.

**External Standard CDO** — A Conceptual Data Object aligned to an industry or regulatory standard (e.g. ISO 20022 *Party*, HL7 FHIR *Patient*).

**Bespoke CDO** — A Conceptual Data Object unique to a single business context, not yet standardised internally or externally. Bespoke CDOs are candidates for promotion to Canonical or External Standard status. See [Rationale & Classification](/cdo/rationale-classification/).

**CDO attribute** — A property of a CDO definition: name, business meaning, type, relationships, mandatory attributes, validation rules, interoperability, authoritative source, and AI-native attributes. See [Attributes for CDOs](/cdo/minimal-attributes/).

**Promotion path** — The governed process by which a Bespoke CDO is elevated to Canonical, or a Canonical CDO is aligned with an External Standard, as adoption broadens.

## AI-native attributes

**MCP exposure** — Whether and how a CDO is exposed through Model Context Protocol servers, tool schemas, or agent APIs. Defines the AI-callable contract: read, write, search, subscribe — and the auth model that applies.

**Semantic representation** — The recommended embedding model, chunking strategy, and synonyms or aliases used for retrieval against a CDO. Ensures consistent semantic search behaviour across every AI application referencing the same concept.

**AI usage policy** — The permitted AI uses of a CDO: retrieval, summarisation, inference, training, fine-tuning, third-party LLM exposure. Prevents sensitive or contractually-restricted data from leaking into model training.

**Grounding status** — Whether a CDO is approved as a source-of-truth anchor for RAG (retrieval-augmented generation) and agentic workflows. Distinguishes ground-truth concepts from informational ones.

**Provenance signal** — A required signal returned alongside CDO data (source system, freshness, confidence score, last-validated timestamp) so AI agents can weight evidence and disclose uncertainty.

**Human-in-the-loop trigger** — A condition under which AI actions on a CDO require human approval (e.g. create, delete, value above a threshold). Defines blast-radius limits for autonomous agents.

## Framework steps

**Catalogue** — Step 1. Identify and catalogue Conceptual Data Objects across the enterprise. See [Catalogue](/list-cdos/).

**Scope & Align** — Step 2. Review scope, align with business capabilities, classify each CDO as External Standard, Canonical, or Bespoke. See [Scope](/review-scope/).

**Map to Processes** — Step 3. Map CDOs to the business processes that create, read, update, and retire them; assign ownership. See [Processes](/map-processes/).

**Requirements & Resilience** — Step 4. Capture functional and non-functional requirements for each CDO, including resilience targets (RPO, RTO, availability). See [Resilience](/business-requirements/).

**Application Selection** — Step 5. Cluster CDOs and select applications that embed industry best practice for those clusters. See [Applications](/application-selection/).

**Governance & Maturity** — Step 6. Establish ownership, review cadence, and a promotion path for CDOs. See [Governance](/governance/).