Most Microsoft Fabric architecture diagrams are too polite.
They show data arriving, becoming cleaner, and eventually appearing in a report. What they usually leave out is the argument that determines whether the platform remains understandable after the third development team, the tenth source system, and the fiftieth downstream consumer: where does source reality end, where does product construction happen, and where does the enterprise make a promise?
When those boundaries are unclear, every table is treated as equally public. Analysts connect to whichever object is easiest to find, engineers preserve internal tables because somebody may be using them, and source-facing objects begin to look like product interfaces. The platform may still run, but the architecture has stopped communicating intent.
This article proposes a deliberately simple alternative for a schema-enabled Fabric Lakehouse:
- Every ingestion method lands data in, or exposes it through,
ingest.*. - Materialized Lake Views (MLVs) and notebooks move data into
transform.*. - MLVs publish stable, consumption-ready tables into
surface.*. - Consumers connect to the product through governed interfaces built on
surface.*, not through the internal construction layers.
Here, ingest.* is shorthand for every table in the ingest schema. The same applies to transform.* and surface.*; the asterisk is architectural notation, not part of the schema name.
The result is not another three-color diagram. It is a practical way to separate source capture, internal implementation, and the published contract of a data product.
The Problem is Not That Fabric Has Too Many Ingestion Tools
Fabric gives architects several ways to bring data into the platform: Data Factory, Mirroring, OneLake Shortcuts, Shortcut Transformations, Eventstream, notebooks, and APIs. Microsoft’s current data movement guidance treats them as choices for different sources, latency needs, and control requirements—not as a single preferred method. Microsoft Learn: data ingestion options and data movement decision guide.
That breadth is useful. The architectural mistake is allowing the ingestion mechanism to determine the long-term shape of the data product.
A mirrored table should not become a public interface simply because it arrives quickly. A shortcut should not become the business contract merely because it is already queryable. A Data Factory landing table should not be renamed “gold” because a pipeline finished successfully. Those are acquisition choices. They say how data became available, not what the organization promises the data means.
The ingest.* schema gives every acquisition pattern the same destination boundary. Some sources are physically landed there. Others appear there as shortcut-backed tables. A mirrored source may be referenced into the product through a schema or table shortcut. The implementation differs, but the architectural meaning remains consistent:
This is source-facing data. It is available to the product, traceable to its origin, and not yet the interface consumers should depend on.
Three Schemas, Three Responsibilities
Fabric Lakehouse schemas now allow tables to be grouped into named collections for discovery, access control, and cross-workspace querying. Schema-enabled lakehouses also support schema shortcuts, which can expose multiple external or cross-lakehouse Delta tables as a schema without duplicating them. Microsoft Learn: Lakehouse schemas.
That capability becomes much more valuable when schemas express responsibility rather than merely department names.
ingest.* is the source-capture boundary. It preserves what arrived—or what is being referenced—as close to source shape and meaning as practical.
transform.* is the internal construction boundary. It contains the standardized, reconciled, enriched, and modeled data used to build the product.
surface.* is the publication boundary. It contains the stable tables that downstream teams, semantic models, applications, agents, and other data products are allowed to depend on.
This is not an argument against Bronze, Silver, and Gold. Medallion describes progressive refinement. Ingest–Transform–Surface answers a different question: who is allowed to depend on what?
Bronze, Silver, and Gold describe maturity. ingest.*, transform.*, and surface.* describe architectural responsibility.
Everything Arrives Through ingest.*
The ingest schema should be intentionally boring. It is not where the enterprise tries to make every source look alike. It is where the product establishes a controlled, governed relationship with each source.
A core platform may use scheduled Data Factory extracts or a lower-latency mirror. Marketing data may arrive through a connector or API. Contact-center events may use Eventstream, while historic files use a pipeline. Existing domain data may enter through a OneLake Shortcut, and vendor files may be referenced directly or converted by a Shortcut Transformation.
OneLake Shortcuts are the clearest true no-copy pattern in this architecture. They behave as references to data held elsewhere, allowing Fabric engines to work through a unified namespace without moving the authoritative files or tables. Schema shortcuts can expose a set of Delta tables under a Lakehouse schema, which makes them especially useful when one foundational data product needs to consume the published surface of another. Microsoft Learn: OneLake Shortcuts and shortcuts in a Lakehouse.
Shortcut Transformations are different. They copy and convert supported structured files into managed Delta tables and keep those outputs synchronized with the source. That is not literal zero-copy, but it does remove the need for a hand-built staging pipeline and keeps the resulting representation inside Fabric’s managed environment. Microsoft Learn: Shortcut Transformations.
The point is not to force every source through the same tool. The point is to prevent the tool from becoming the product boundary.
transform.* is the Workshop, but it Should not Become a Public Hallway
Once source-facing data is available in ingest.*, the product team needs a place to reconcile it. This is where identifiers are aligned, codes are standardized, dates are normalized, duplicate records are resolved, business relationships are constructed, and quality rules begin to mean something beyond “the file loaded.”
Materialized Lake Views should be the default mechanism for relational, declarative transformation in this layer. Fabric MLVs persist their results as Lakehouse tables, refresh automatically, and can be defined in Spark SQL or PySpark. Fabric builds a dependency graph across MLVs, runs them in dependency order, and exposes lineage and run history. Current MLV capabilities also support declarative data-quality constraints and an optimal refresh process that can select no refresh, incremental refresh, or full refresh based on the source and configuration. Microsoft Learn: MLV overview, MLV lineage, and MLV data quality.
That makes MLVs a natural fit for filtering, joining, deduplicating, conforming, calculating stable attributes, and building progressive intermediate models.
Notebooks remain essential, but they should be used for the work that is genuinely procedural or computationally complex. Entity resolution, fuzzy matching, specialized Python libraries, machine-learning scoring, complex file handling, and unusual API interactions are reasonable notebook responsibilities. Their outputs should return to transform.*, where MLVs can continue the dependency chain.
This creates a useful operating rule:
Use MLVs when the transformation can be expressed as a durable relationship between tables. Use notebooks when the work genuinely requires code.
The rule matters because notebooks are easy to turn into invisible pipelines. When one notebook reads several sources, embeds business joins, handles exceptions, and writes public tables, it has become an orchestration system without admitting it.
Most importantly, transform.* remains internal. The product team can replace an MLV, split a notebook, change a conformance approach, or redesign an intermediate table without turning an implementation change into an enterprise outage.
surface.* is the Data Product Contract
A data product needs somewhere to make a promise. That is the purpose of surface.*.
The surface schema should contain only the tables the product team intends to support. Those tables should have a clear business grain, stable keys, understandable names, documented definitions, known refresh expectations, enforceable access rules, and quality measures that mean something to a consumer.
MLVs are a strong publication mechanism because they make the relationship between the internal model and the published output explicit. An MLV can read from one or more transform.* tables or upstream MLVs, materialize the result into surface.*, and participate in the same dependency-aware refresh graph. Fabric treats the resulting MLV like a standard Lakehouse table for storage, access, and security. Microsoft Learn: creating MLVs.
From there, Fabric provides several consumption interfaces. A Lakehouse automatically includes a SQL analytics endpoint for T-SQL access. Direct Lake semantic models can load columns from Delta tables in OneLake without creating the normal imported dataset copy. Surface tables can also be exposed through shortcuts to downstream data products, wrapped behind APIs, or used by operational applications and agents. Microsoft Learn: Lakehouse overview and Direct Lake overview.
The interface can change by consumer, but the contract remains the surface. A product may expose Delta tables, SQL, a semantic model, or an API, but each interface should be intentionally built on the same published boundary.
Zero Unmanaged Copy Does Not Mean Zero Physical Copy
“Zero-copy” is often used as though every physical representation is an architectural failure. That is not a useful standard for a production data platform.
A banking data product may need a managed replica to protect operational performance, a Delta conversion for reliable SQL and Spark access, or materialized tables and aggregates to meet service levels.
The better principle is zero unmanaged copy.
A true no-copy reference, such as a OneLake Shortcut, fits the principle. Direct Lake also fits because the semantic model reads from OneLake rather than maintaining the familiar imported Power BI copy. But Mirroring, Shortcut Transformations, Data Factory landings, and MLV outputs can also fit the principle even though they create physical representations.
The test is whether the representation is deliberate and governed. It should have an owner, a purpose, a retention policy, a security posture, a refresh expectation, and lineage back to its source. It should live inside the data product boundary rather than in a personal workspace, desktop extract, shadow lake, or copied table whose only justification is that somebody was afraid to touch the original.
A Banking Example: The Customer Relationship Data Product
Consider a foundational customer relationship data product for a retail or commercial bank.
The core banking platform provides customers, accounts, balances, and product relationships. The marketing platform provides campaigns, responses, consent, and digital engagement. The contact-center or servicing platform provides cases, interactions, outcomes, and service history. Card or payment systems may contribute transaction behavior and merchant activity.
Those sources will not arrive through one mechanism. Core tables may be mirrored or copied on a controlled schedule. Marketing data may come through Data Factory connectors or APIs. Contact-center events may arrive continuously while historic records arrive in batches. Existing card-domain tables may be consumed through shortcuts from another product’s surface.* schema.
All of them appear in the customer product’s ingest.* schema as a fan of source-facing tables. The product has not yet declared that two customer identifiers refer to the same person, that an account relationship is active, or that a campaign response represents meaningful engagement. It has only established governed access to the evidence.
In transform.*, MLVs standardize source values, align account relationships, normalize interaction types, calculate stable balances and activity windows, and build conformed relationship structures. A notebook may perform probabilistic identity resolution across customer number, household, email, telephone, and address when deterministic joins are insufficient. Its results return to the transform layer, where the rest of the product remains declarative.
MLVs then publish a small, stable set of surface.* tables: customer profile, account relationship, service summary, engagement summary, and other product-specific contracts. Those tables can support a Customer 360 semantic model, a relationship-and-wallet-share derived product, a financial-health or cross-sell product, and the context supplied to a servicing agent.
The derived products should consume the foundational product’s surface. They should never reach backward into its ingest or transform schemas. That is what makes product composition sustainable: each team can improve its internal implementation without forcing every downstream team to relearn the source systems.
Governance Follows the Whole Flow, but Discovery Begins at the Surface
Microsoft Purview should govern the entire chain, not merely the final report.
Unified Catalog provides the business-facing location for data products, ownership, descriptions, glossary terms, and access workflows. Data Map captures technical metadata and lineage across supported sources and Fabric items. Classification, sensitivity, data quality, and access controls should travel with the product rather than being documented in a separate spreadsheet. Microsoft’s current Fabric and Purview integration supports scanning Fabric tenant metadata and item-level lineage into Purview; Lakehouse table and file sub-item metadata scanning is available in preview, while sub-item lineage still has limitations. Microsoft Learn: Fabric lineage in Purview, Unified Catalog, and Purview with Fabric.
The architecture should not assume that every table-level dependency will automatically appear in one enterprise lineage view. MLV lineage provides the internal dependency graph, while Purview provides the broader catalog and governance context.
The catalog entry presented to consumers should point to the product’s supported surface and interfaces. Ingest and transform assets remain governed and discoverable for the teams that operate the product, but they are not the front door.
The Architecture Survives Because the Boundaries are Allowed to Change at Different Speeds
Source systems change whenever their owners need them to. Internal transformations change whenever the product team learns something or improves the implementation. Consumer contracts should change only when the product team deliberately releases a new version.
The ingest–transform–surface pattern gives each of those rates of change a place.
ingest.* absorbs source reality without pretending it is ready for broad use.
transform.* gives engineers room to build, test, reconcile, and replace implementation details.
surface.* turns a set of tables into an interface that can be documented, secured, measured, and supported.
Fabric’s ingestion choices, schema-enabled Lakehouses, OneLake Shortcuts, MLVs, notebooks, SQL endpoint, Direct Lake, and Purview integration all fit naturally into that separation. The products are not valuable because every workload uses the same tool. They are valuable because every tool participates in a clear contract.
Do Not Publish the Workshop
Fabric’s broad ingestion palette is a strength, but only when the architecture prevents it from becoming six unrelated landing patterns.
The pattern is straightforward: every source lands in or appears through ingest.*; MLVs and notebooks construct the product in transform.*; MLVs publish supported contracts into surface.*; and consumers connect through intentional interfaces built on that surface. True no-copy patterns are used where they make sense. Physical representations are created when they provide value. Unmanaged duplicates are treated as defects.
Take one existing Lakehouse and classify every table. Is it source capture, internal construction, or a published contract? If a table cannot be placed confidently, it is probably carrying an accidental responsibility—or supporting an accidental dependency.
Move that ambiguity before building the next pipeline.
