Composite Fact Layer CFL
The Composite Fact Layer (CFL) is an architectural layer in a semantic engine that makes multi-fact, multi-grain analytical queries correct by construction. When a single query references measures drawn from two or more independent fact tables, naive SQL join generation silently multiplies rows. That is the classic fan trap (over-counting) and chasm trap (under-counting).
The CFL detects that a query spans multiple facts, then:
- decomposes the query into per-fact sub-queries at the correct grain;
- aggregates each fact independently;
- recomposes the results over their shared dimensions (e.g. via
UNION ALLor a full outer join on the conformed keys).
AI agents and BI tools receive correct numbers without having to reason about join cardinality themselves. The CFL is implemented in the OrionBelt Semantic Layer (OBSL).
In one sentence: the Composite Fact Layer turns an over-counting multi-fact join into several correct single-fact queries and recomposes them over shared dimensions, fan-trap-free by design.
Artefacts Composability Resolution ACR
Artefacts Composability Resolution (ACR) is a feature of the OrionBelt Semantic Layer (OBSL) engine that answers a single, practical question while you build a query: given what you have selected so far, which other artefacts can you still add and get a valid result?
A semantic model is a graph of data objects connected by joins, with dimensions, measures, and metrics defined on top. Not every combination is valid, since the wrong artefacts can multiply rows (fanout) or simply have no join path at all. Starting from your current selection (the anchor), ACR walks the model's join graph and resolves the exact set of artefacts that remain composable with it:
- Dimensions you can group by, reachable through fanout-safe joins.
- Measures and metrics you can aggregate, drawn from the facts your selection belongs to.
- Cross-fact measures still combinable through the Composite Fact Layer (CFL), OBSL's
UNION ALLplanner for independent fact tables. These are surfaced separately, so you know they join at a higher level.
The result is the composable set: a precise, deterministic list, not a guess. Because ACR is driven by the same join logic the compiler uses, anything it offers is guaranteed to compile.
For people, ACR powers a guided query builder: the dimension, measure, and metric pickers highlight what fits the current query, so you compose valid analyses without understanding the physical joins underneath. For AI agents and BI tools, ACR turns query construction into safe artefact composition, so the agent picks from named artefacts known to combine instead of reasoning about table relationships and risking invalid SQL.
In one sentence: you compose meaning by name, and ACR guarantees the engine can hold it together, because every offered artefact is known to compile.
→ Read the full explainer: Artefacts Composability Resolution (ACR)
Freshness Inheritance
Freshness Inheritance is a cache-invalidation model in which a cached query result inherits its freshness (and therefore its staleness) from the source tables in its lineage, rather than from a fixed time-to-live (TTL).
Each source table emits a freshness heartbeat. Any cached query whose lineage includes that table is invalidated automatically when the heartbeat advances. A single upstream change cascades to every dependent query, so:
- caches never serve stale results, because invalidation is driven by real data changes rather than a guessed expiry;
- caches are not needlessly evicted, since a query stays valid as long as none of its sources have changed.
Freshness Inheritance replaces the brittle "pick a TTL and hope" pattern with lineage-driven correctness. It is implemented in the OrionBelt Semantic Layer (OBSL) result cache.
In one sentence: a cached query is exactly as fresh as the freshest-required of its source tables, and one heartbeat invalidates every query that depends on it.
Executable Business Rule
An executable business rule is a rule declared in a semantic model as a condition over the model's own dimensions, measures and metrics, with no SQL, which the engine compiles to the query that reports the rule's findings. A rule over dimensions only is row-level and becomes a WHERE predicate; a rule that reads a measure or metric is aggregate, declares its grain, and becomes a HAVING condition at that grain, through the same planner as any other query.
classification and eligibility rules describe members: their findings are the rows the condition selects. validation and constraint rules state an invariant with a severity: their findings are its violations. Rules compose with all, any and not, may inline other rules of the same level and grain, and are exported into the model's RDF graph and offered to agents as tools. Implemented in the OrionBelt Semantic Layer (OBSL).
In one sentence: the rule is written once over business concepts, and the engine turns it into the query that says who qualifies or what is wrong.
→ Read the full explainer: Executable Business Rules and Ontology Links
External Concept Mapping
An external concept mapping is a qualified link from a semantic-model artefact (the model, a data object, dimension, measure, metric or rule) to a concept in an external ontology such as schema.org, FIBO or a corporate glossary. It carries a SKOS mapping relation (exact, close, broader, narrower, related, where broader means the external concept is the broader one) and provenance: justification, source, ontology version, confidence.
A mapping never changes the compiled SQL. It is projected into the model's RDF graph as a skos:*Match triple and is discoverable over SPARQL, REST and MCP, so "which artefacts mean this concept" is a query rather than a code search. Implemented in the OrionBelt Semantic Layer (OBSL).
→ Read the full explainer: Executable Business Rules and Ontology Links
Semantic Sidecar
A Semantic Sidecar is an architectural pattern in which a governed semantic layer runs alongside your existing data platforms, instead of embedded inside a single BI tool or imposed as a centralized rewrite, and exposes business concepts (dimensions, measures, metrics, business rules) through a unified API to AI agents, analytics workflows, and reporting.
The data stays where it is; the semantics live next to it, version-controlled and addressable by any consumer. One model, many consumers, no architecture change. The pattern is implemented as a reference design in the OrionBelt Semantic Layer (OBSL).
Ontology-Based Query Check OBQC
Ontology-Based Query Check (OBQC) is a deterministic, rule-based SQL validator that checks a generated query against a loaded RDF/OWL ontology before the query reaches the database. It parses the SQL with sqlglot and treats the ontology's oba: annotations (tables, columns, SQL types, primary and foreign keys, join conditions, and relationship direction) as its source of truth.
An LLM will happily produce SQL that reads perfectly and computes the wrong thing: hallucinated columns, joins that ignore the foreign keys, missing GROUP BY columns, and fan-traps that silently inflate totals. OBQC checks all of these structurally, with no LLM call and no probabilistic reasoning:
- Errors block execution. The query is never sent to the database, and the calling agent gets the issue and a suggested fix.
- Warnings allow execution. They are attached to the result, so the agent can self-correct or explain the caveat.
OBQC is implemented in OrionBelt® Analytics (OBA), where it validates every query issued through execute_sql_query.
In one sentence: OBQC is the deterministic check that stands between an LLM's plausible SQL and your database, so structurally wrong queries never run.