Backend authorization is authoritative
Frontend filtering, navigation, and tenant-scoped query keys improve UX, they do not replace backend checks. Server-side ownership validation is the boundary that matters.
Mud Cake is built for multi-tenant SaaS from the ground up. Customer and tenant context are part of the operating model, and backend authorization is the authoritative security boundary.
Six pillars
Frontend filtering, navigation, and tenant-scoped query keys improve UX, they do not replace backend checks. Server-side ownership validation is the boundary that matters.
Transformation SQL is built by trusted backend code from structured operations, trusted storage bindings, validated identifiers, and server-injected tenant and customer predicates. Users never author SQL.
Dataset selection, lookups, transformation dependencies, schedule execution, folder access, clone operations, and output updates are all tenant-scoped. Cross-tenant operations are prohibited.
Dataset-to-dataset lineage is recorded on every publish and run, referencing the producing transform and version. Lineage is data provenance, distinct from execution orchestration.
Ownership carried in a DTO or cached object is never sufficient authority for a destructive act. Every physical operation re-reads its binding and re-asserts ownership before acting; ambiguous state fails closed.
Every run records trigger type, version used, output schema, row-count diagnostics, and a safe failure or skip reason. Manual, Scheduled, and Dependency origin are all distinguishable in history.
The ownership model
Mud Cake supports multiple tenants per customer with a flexible architecture that separates the SaaS ownership boundary from the workspace data-isolation boundary, and keeps platform administration separate from customer identity. Map tenants to divisions, regions, or business units; each one is independently governed and fully isolated.
Customer, the SaaS ownership boundary
A customer can own multiple tenants, each with its own users, datasets, folders, data destinations, and audit logs. The flexible customer-tenant architecture maps to how real organizations actually work.
Tenant, the workspace & data-isolation boundary
Tenant-scoped business data stays within one customer and one tenant. Membership roles: CustomerAdmin, TenantAdmin, Contributor, Reviewer.
Platform admin, separate control plane
Platform administration is separate from customer users and skips tenant context, requiring platform-admin authorization.
Physical storage
A dataset's physical location is resolved through a single storage-binding resolver that operates in customer/tenant context, verifies ownership and binding state, and fails closed with a typed error rather than falling back to a derived name. Ownership is explicit, MudCake-managed or External-customer-managed, never inferred from a name.
Single binding authority
Every read and every physical operation resolves through one binding resolver, no reconstructing a name from anything else.
Explicit ownership
Each binding carries explicit ownership and a claim on the physical object, from provisioning until genuine release.
Generation-safe schema change
Non-additive schema changes create a new physical generation and re-point the dataset, identity, lineage, and history are unaffected.
We'll walk through the authorization model, tenant isolation, and lineage with your reviewers.