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.
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.
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.
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 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.
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.
Scope & Align — Step 2. Review scope, align with business capabilities, classify each CDO as External Standard, Canonical, or Bespoke. See Scope.
Map to Processes — Step 3. Map CDOs to the business processes that create, read, update, and retire them; assign ownership. See Processes.
Requirements & Resilience — Step 4. Capture functional and non-functional requirements for each CDO, including resilience targets (RPO, RTO, availability). See Resilience.
Application Selection — Step 5. Cluster CDOs and select applications that embed industry best practice for those clusters. See Applications.
Governance & Maturity — Step 6. Establish ownership, review cadence, and a promotion path for CDOs. See Governance.