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 — 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, recomposed 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 — the wrong artefacts can multiply rows (fanout) or simply have no join path. 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 — 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 — the agent selects 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 — 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 — invalidation is driven by real data changes, not a guessed expiry;
- caches are not needlessly evicted — 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 — one heartbeat invalidates every query that depends on it.
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 — structurally wrong queries never run.
→ Read the full explainer: OBQC — Ontology-Based Query Check