Duodata/Documentation
    Contact Support

    Getting Started with Duodata

    How the app is organized

    Duodata intentionally starts simple: there are four concepts users need to define.

    1. Metrics: the numbers you measure
    2. Slices: the dimensions you measure "per"
    3. Reports: groupings of metrics and slices (data products)
    4. Sources: where the data originates (systems of record / taps)

    Stage-appropriate behavior: start by defining the four concepts. Everything else (governance, configuration, forward engineering) is layered on top.

    The conceptual model

    The four concepts and their relationships

    At the most basic level:

    • A Metric can be:
      • derived from Source data (a "source metric": may include transformations like COUNT DISTINCT, but does not reference other metrics)
      • derived from other Metrics (a "derived metric": has a formula referencing other metrics)
    • A Metric is sliceable by one or more Slices
    • A Report is a set of Metrics + Slices
    • A Source anchors metrics/slices into the company's data reality

    A compact mental model:

    Sources ──► (ground) ──► Metrics ◄──► Slices
                          │
                          └──► Reports (Metrics + Slices)
                                   │
                                   └──► Semantic Publishing (e.g., Snowflake Semantic Views)

    Lifecycle

    Duodata is designed for continuous iteration. A practical lifecycle is:

    1. Define (the ontology): Create sources, metrics, slices, reports
    2. Govern: Assign owners, status, value drivers; plan releases
    3. Implement: Map to platforms (schemas, tables, columns); link implementations (deep links)
    4. Publish: Generate semantic artifacts (e.g., Semantic Views); deploy via native app (Snowflake)
    5. Iterate + control drift: Update definitions as the business changes; reconcile drift between Duodata and the platform

    Quickstart: build your first ontology slice

    This is a minimal sequence that gets you to something publishable.

    Step 1: Define sources

    Define the systems that matter (order management, billing, HR, etc.). A source is the bridge from "textbook metric" to "company reality".

    Constraint: metrics/slices typically have one source (so sources are set from the metric/slice, not edited as an additive relationship from the source side).

    Step 2: Define your first metric (source metric)

    A source metric includes:

    • description
    • source
    • unit (semantic meaning, not data type)
    • time grain (how the metric exists over time)
    • slices (where relevant)

    Unit is semantic. "Percentage" / "USD" / "Count" tells the user what the number means; it is not "decimal vs integer".

    Step 3: Define a derived metric (formula + filters)

    A derived metric references other metrics in a formula. You can add conceptual filters by slice.

    Open the formula editor:

    Step 4: Add value drivers (optional but powerful)

    Value drivers describe what moves a metric and why. Over time, this creates a value driver tree.

    Step 5: Define slices and roll-ups

    Slices are "per what" you measure metrics. The roll-up relationship is a light-touch model of dimensional hierarchy.

    A slice can also include enumerated values when it's low-dimensional and stable:

    Roll-ups on a slice:

    Step 6: Create a report (metrics + slices)

    A report is conceptually simple: a set of metrics and slices, plus a reporting period.

    Git is the audit log and portability layer for definitions and generated artifacts. Connect it in your organization's settings.

    Step 8: Export YAML (backup)

    YAML export under your organization's settings makes the metric ontology portable and versionable. It provides a structured, machine-readable representation of your metric model.

    Step 9: Add a platform (and keep schema in sync)

    Platforms represent where metrics are implemented. For Snowflake, the platform is uniquely identified by organization + account.

    Schema options:

    • Manual upload (download from platform and upload here)
    • Native-app sync via Git (schema pulled into repo automatically)

    Step 10: Map implementations

    Implementation mapping can be lightweight and still valuable:

    • map a metric to a column/expression

    • map a slice to a table (dimension)

    • add a deep link (so people can jump to the implementation)

    Last updated March 5, 2026