Architecture

Overview

Omora Labs inverts the traditional analytics stack: business meaning is defined first in a semantic layer, and all downstream transformations and reports consume those definitions.

1. Semantic Layers

Business meaning → Contract definitions

The semantic layer defines the core business concepts of the organization before any data is ingested. Semantic Layers such as Periods, GL Accounts, Business Units, Revenue Types, Revenue Changes, and Value Types encode financial meaning, hierarchies, and classification rules once, in code.

These definitions are authoritative. They act as a contract: all incoming data, downstream transformations, and reports must conform to them. The semantic layer determines what concepts exist, how they relate, and how business logic is interpreted, independent of any specific dataset. These contracts are expressed in SQL.

Example: Defining a fiscal calendar, a chart of accounts hierarchy, and valid revenue classifications before any transactions are uploaded.

Stack: DuckDB

2. Facts

Business meaning → Contract definitions

Facts store what actually happened, expressed using the semantic contracts. They record measurable values (amounts, quantities, prices, volumes) classified by the semantic layers.

Facts do not define meaning or logic. They are structured observations that conform to predefined semantic layers and are typically produced by workers or transformations.

Example: Revenue changes per period, split into price and volume, classified by revenue type and value type.

Stack: DuckDB

3. Workers

Manual work → Version-controlled automation

Workers are background processes that automate data ingestion, enrichment, and maintenance tasks. They run on schedules or events and always write data through the semantic layer contract, ensuring all generated or fetched data conforms to existing dimensions.

Examples: Fetching FX rates.

Stack: Polars | Dagster

4. Transformations

Dimensions → Analytical models

This layer builds analytical models and derived datasets by consuming dimension-aligned data from ingestion. All business meaning is already defined and enforced; transformations here focus on derivation, not interpretation.

Typical outputs include fact tables, aggregates, and reusable analytical models (e.g. monthly revenue, budget vs actuals inputs, cash flow building blocks). No dimension logic is redefined: transformations strictly rely on the semantic layer.

Example: Building a monthly Budget vs Actuals model by aggregating transactions along Periods, GL Accounts, and Value Types, without redefining fiscal calendars or account groupings.

Stack: dbt

5. Reporting & BI

Analytical models → Dashboards and outputs

This layer is responsible for consumption and presentation only. All business logic has already been applied upstream, so reports and dashboards simply query precomputed analytical views and render results for automated and repeatable decision-making. No business logic or classification exists at this stage.

Example: A Budget vs Actuals dashboard visualizes precomputed monthly figures by Period and GL Account, inheriting all definitions from upstream layers.

Stack: Hex | Looker

Why This Architecture?

Without a semantic layer:

• Budgeting and reporting logic lives in fragile spreadsheets and BI tools
• Automations break when files, filters, or dashboards change
• Business definitions are reimplemented per tool, per report
• Data and logic become coupled to vendors, ERPs, or BI platforms

With Omora Labs:

• Financial logic is automated once and reused everywhere
• Budgets, forecasts, and reference data can be generated and maintained by code
• Business definitions live in your repository, not inside spreadsheets or BI tools
• Your data remains proprietary and portable, independent of any vendor

Next Steps

Explore Semantic Layers to see contract components, check automation with workers, review transformations in action, or browse templates that showcase the workflow end-to-end.