Product concepts

Nine words carry the whole product. Getting them straight is worth five minutes, because everything else — the interface, the API, the repository layout — is built on them.

Where the business layer stands today. Domain, Entity and Policy are part of the product model, and the repository already carries a context/ directory for them. They are not yet editable in Context Studio: what you create today are Cubes, Semantic Views and their Metrics. This page describes the vocabulary so it means the same thing everywhere; the screens follow.

Domain

A business subject that groups related Metrics.

Revenue, Profitability, Operations, Customer. Qontexta ships with none of them: Domains come from your business, not from a template.

A Domain holds Metrics, Entities and Policies, and is implemented by one or more Cubes. A Domain is not a Cube, and a Domain with a single Cube is a coincidence, not a rule.

Metric

A governed business calculation.

A Metric has meaning, an owner and a trust state, and one or more technical implementations. “Revenue” is one Metric even if three Cubes compute it at different grains.

Entity

A business axis for analysing Metrics.

Customer, Hotel, Product, Legal Entity. An Entity maps to one or more Dimensions, and the mapping is declared rather than assumed: the business name and the technical field are allowed to differ, and usually should.

Policy

A rule about trust, ownership, access or lifecycle.

Four types today: access, certification, ownership and lifecycle. It is deliberately not a general rule engine — it declares what governs what, leaning on the roles and validation states already in the product.

Cube

A technical implementation of part of a Domain.

Measures, Dimensions, SQL, joins, pre-aggregations. This is the engineering object, and it is a standard Cube definition: nothing here is proprietary.

Semantic View

A Cube view — a curated selection of fields exposed together. It is a technical object that lives inside the Engineering Perspective.

Semantic Views used to be called domains in earlier versions of the product, and still are internally in some API fields. They are not business Domains: a Semantic View is one file exposing fields from one or more Cubes, while a Domain is a business subject that may span several Cubes.

Perspective

Two heights, one definition.

Business Perspective asks what a number means, who answers for it and who consumes it. Engineering Perspective asks where it comes from, with which SQL and in which deployment. Same Metric, two questions — not two models, and not a filter.

Semantic Repository

The capability that versions your context: branches, review, approval, audit and pull requests. Today it runs on GitHub, and the repository is yours.

Semantic Engine

The capability that executes approved definitions and exposes them over SQL, REST, GraphQL and MCP. Today it runs on Cube.

Data Platform

Your warehouse — BigQuery, Snowflake, Databricks, Redshift, PostgreSQL. Qontexta reads it, never copies it: queries run where your data already lives.

The rule that holds it together: Domains organize business meaning, Cubes implement it, Perspective reveals both. AI proposes, humans approve, the repository records, the engine executes.

Introduction