Data Model

The analytics data model exists only in the heads of the two engineers who built the original tracking implementation. When a new analyst asks 'what tables should I join to calculate monthly active users?' the answer is 'ask Derek, he built it.' There is no schema documentation, no entity-relationship diagram, and no written definition of what each table or metric represents. Derek is on vacation for two weeks, so the analyst waits.

None — AI cannot generate queries or analysis against the analytics data model because no schema documentation, entity definitions, or relationship descriptions exist in any accessible form.

The analytics data model has scattered documentation — a README in the dbt repository describes some core tables, a Confluence page from last year lists event taxonomy categories, and inline SQL comments explain a few complex joins. A new analyst finds the README but it was last updated eight months ago and references tables that have been renamed. The Confluence page covers acquisition events but not product usage events. Piecing together the full data model requires reading documentation in three places and cross-referencing with the actual database schema.

AI could parse existing documentation fragments to understand parts of the analytics data model, but cannot build a complete picture because the scattered documents are inconsistent, outdated, and cover different subsets of the schema.

The analytics data model is documented in a dedicated schema catalog — dbt model descriptions cover every table, field descriptions explain each column, and a wiki page defines the core metrics (MAU, activation rate, churn). The analytics team updates the catalog when they add new models. But the documentation describes the technical schema without explaining the business semantics — the catalog says 'user_activated_at: timestamp' but doesn't define what 'activated' means in business terms or which product actions qualify.

AI can generate SQL queries against the documented analytics data model and explain what each table contains. Cannot yet translate business questions into accurate queries because the documentation lacks business-context definitions for key metrics and derived entities.

The analytics data model documentation is comprehensive, current, and business-contextualized. Every entity has a technical schema definition paired with a business description. Metrics include calculation methodology, known edge cases, and refresh cadence. An analyst can ask 'how is net revenue retention calculated, and which accounts are excluded?' and find the authoritative answer in the data model catalog without asking a person. The documentation stays current because it's embedded in the dbt project and updated alongside code changes.

AI can translate natural-language business questions into accurate SQL queries, explain metric definitions with full business context, and flag when a requested analysis involves known edge cases. Cannot yet validate that query results are semantically correct — only syntactically valid.

The analytics data model is a formal semantic layer — entities, relationships, and metric definitions are encoded as machine-readable configuration. A BI tool or AI agent doesn't need to know SQL to answer business questions — it queries the semantic layer, which translates business concepts to the appropriate joins and calculations. The semantic layer validates query logic against defined relationships, preventing common mistakes like double-counting revenue across overlapping product lines. Business users ask questions in plain language and get semantically correct answers.

AI can autonomously translate business questions into semantically correct analyses, validate query logic against the formal data model, and explain results with full business context. Can detect and prevent analytical errors that would be invisible in raw SQL.

The analytics data model is self-documenting. Schema changes, new metrics, and evolving relationships are automatically reflected in the semantic layer as they occur. When an engineer adds a new event type to the tracking SDK, the data model catalog updates itself with the inferred entity definition, suggests business-context descriptions based on naming conventions and usage patterns, and validates the new entity's relationships to existing tables. The data model documentation is never stale because it is generated from the living system.

Can autonomously maintain, document, and evolve the analytics data model. AI detects schema changes, generates documentation, validates relationships, infers business semantics, and keeps the semantic layer synchronized with the live database — all without manual documentation effort.

Ceiling of the CMC framework for this dimension.