How it works

From business data to calculated datasets, on a governed path.

A Mud Cake workflow can start with a spreadsheet, SQL data, another dataset, or extracted document data. Each step is durable, tenant-scoped, and recorded, so you can trace any calculated number back to its source.

The concept

Data in. Logic applied. Calculated dataset out.

Users are not simply storing datasets. They are building business processes in which datasets feed transformations, transformations produce new datasets, and those datasets feed additional transformations.

Spreadsheets

SQL data

Other datasets

Lookup + Calculate + Filter + Aggregate

Versioned, repeatable transformation steps

Calculated dataset

Materialized output with schema, storage binding, and lineage

Another workflow or downstream system

Output datasets can feed additional transformations or be consumed externally

The flow

Six steps, data to calculated dataset.

  1. 01

    Bring in your data

    Upload spreadsheet data, connect existing SQL tables, or extract structured information from supported business documents. Multiple ways to start, one governed platform.

  2. 02

    Organize as reusable datasets

    Give business data a governed, inspectable home rather than leaving important logic buried in individual files and scripts. Browse, preview, inspect schema, trace lineage, and organize into folders.

  3. 03

    Build your business logic

    Create transformations using operations such as selection, renaming, calculated columns, lookups, filters, and aggregations without writing arbitrary SQL. Lookups can join against other datasets or your existing SQL tables. The backend generates trusted SQL from validated identifiers and injects tenant predicates.

  4. 04

    Produce calculated datasets

    Materialize the results into datasets with schema, storage binding, and lineage. These datasets can themselves become inputs to additional workflows, so one calculation can feed the next.

  5. 05

    Automate the process

    Run workflows manually, on schedules from hourly to monthly, or from upstream data-refresh dependencies. A successful run durably queues downstream transforms automatically. Run history records Manual, Scheduled, or Dependency origin.

  6. 06

    Govern everything automatically

    Maintain lineage, versions, execution history, tenant boundaries, and traceability throughout the workflow. Backend authorization is the authoritative security boundary, not UI filtering. Cross-tenant access is prohibited, not merely discouraged.

Transformation lifecycle

Draft, Publish, Run, versioned at every step.

01 · Draft

Save Draft

Records metadata and a Draft version. No output dataset, no rows, no lineage.

02 · Validate

Validate & Preview

Checks the definition and runs a read-only preview, no durable output created.

03 · Publish

Publish

Creates or updates the output dataset, schema, storage, and lineage. Does not run rows.

04 · Run

Run

Materializes the published version into the output dataset and records run history.

Editing a published transformation starts a Draft revision; runs keep using the current Published version until you publish the revision. Clone copies a saved Draft or Published version into a new independent transformation.

Want to see it run on your data?

We'll walk a real workflow through the full path, data in to chained downstream dataset.