Saltar al contenido
Conceptos del producto

Conceptos del producto

Nueve palabras sostienen el producto entero. Merece la pena dedicarles cinco minutos, porque todo lo demás —la interfaz, la API, la estructura del repositorio— está construido encima.

En qué punto está la capa de negocio. Domain, Entity y Policy forman parte del modelo del producto, y el repositorio ya trae un directorio context/ para ellos. Todavía no se editan desde Context Studio: lo que se crea hoy son Cubes, Vistas Semánticas y sus Metrics. Esta página fija el vocabulario para que signifique lo mismo en todas partes; las pantallas llegan después.

Domain

Un sujeto de negocio que agrupa Metrics relacionadas.

Ingresos, Rentabilidad, Operaciones, Cliente. Qontexta no trae ninguno: los Domains salen de tu negocio, no de una plantilla.

Un Domain contiene Metrics, Entities y Policies, y lo implementan uno o varios Cubes. Un Domain no es un Cube, y que un Domain tenga un solo Cube es una coincidencia, no una regla.

Metric

Un cálculo de negocio gobernado.

Una Metric tiene significado, dueño y estado de confianza, y una o varias implementaciones técnicas. “Ingresos” es una sola Metric aunque tres Cubes la calculen a distinto grano.

Entity

El eje de negocio por el que se analizan las Metrics.

Cliente, Hotel, Producto, Sociedad. Una Entity se corresponde con una o varias Dimensions, y la correspondencia se declara, no se supone: el nombre de negocio y el campo técnico pueden diferir, y normalmente deben.

Policy

Una regla sobre confianza, propiedad, acceso o ciclo de vida.

Hoy cuatro tipos: access, certification, ownership y lifecycle. Deliberadamente no es un motor de reglas genérico — declara qué gobierna a qué, apoyándose en los roles y los estados de validación que ya existen.

Cube

La implementación técnica de una parte de un Domain.

Measures, Dimensions, SQL, joins, preagregaciones. Es el objeto de ingeniería, y es una definición estándar de Cube: aquí no hay nada propietario.

Semantic View

Una view de Cube: una selección curada de campos expuestos juntos. Es un objeto técnico y vive en la Perspectiva de Ingeniería.

Las Semantic Views se llamaban dominios en versiones anteriores del producto, y todavía se llaman así internamente en algunos campos de la API. No son Domains de negocio: una Semantic View es un fichero que expone campos de uno o varios Cubes; un Domain es un sujeto de negocio que puede abarcar varios Cubes.

Perspective

Dos alturas, una definición.

La Perspectiva de Negocio pregunta qué significa un número, quién responde de él y quién lo consume. La de Ingeniería pregunta de dónde sale, con qué SQL y en qué despliegue. La misma Metric, dos preguntas — ni dos modelos, ni un filtro.

Semantic Repository

La capacidad que versiona tu contexto: ramas, revisión, aprobación, auditoría y pull requests. Hoy funciona sobre GitHub, y el repositorio es tuyo.

Semantic Engine

La capacidad que ejecuta las definiciones aprobadas y las expone por SQL, REST, GraphQL y MCP. Hoy funciona sobre Cube.

Data Platform

Tu almacén: BigQuery, Snowflake, Databricks, Redshift, PostgreSQL. Qontexta lo lee, nunca lo copia: las consultas se ejecutan donde ya viven tus datos.


La regla que lo sostiene todo: los Domains organizan el significado, los Cubes lo implementan y la Perspectiva enseña ambos. La IA propone, las personas aprueban, el repositorio registra y el motor ejecuta.