Shortcuts-only bronze: stop copying what OneLake already holds

Medallion diagrams still tempt teams to land a physical bronze copy of everything upstream. When the upstream domain already publishes curated Delta in OneLake, that copy is not prudence. It is a second warehouse with a friendlier name.

Bronze can be a contract of shortcuts and thin clean views. Ownership stays with the publisher. Freshness follows the source. Your CI/CD list becomes the shortcut set, not a shadow catalog of cloned tables.

Figure 1. Bronze can be a pointer surface. Prefer OneLake shortcuts over copying bytes the platform already holds. Source: Microsoft Learn: OneLake shortcuts.

I learned this on estates where bronze looked busy and still lied about ownership. Pipelines copied silver and gold from sibling domains overnight. On-call owned the copy. Nobody owned the drift when the publisher changed a key.

The core idea

If OneLake already holds the curated Delta, bronze should reference it, not reinvent it.

Physical ingest still matters for raw files, CDC dumps, and systems outside OneLake. It does not matter for "we already trust this Delta table next door." Shortcuts plus thin clean views beat copy-then-clean for cost, freshness, and clarity about who fixes a broken grain. Orphan clean views with no shortcut behind them are fiction. Drop them or back them.

A model that stays explainable

1. Separate external raw from internal curated

Two bronze stories live in one word. External raw needs land-and-register: files, extracts, API dumps. Internal curated is another domain's published Delta. Treat them differently in docs and pipelines. The second story is shortcuts, not Spark writes that replay someone else's silver.

2. Shortcut set is the bronze contract

List every shortcut path, target workspace or lakehouse, and expected grain in the repo the same way you list API contracts. Promotion and review should ask whether the shortcut set changed, not whether a copy job ran green. When a publisher renames a table, the contract breaks in one place you can find.

3. Thin clean views, not a second transform layer

Clean views on shortcuts handle renames, type nudges, and column picks for downstream silver. They should not become a parallel medallion. If the view needs heavy business logic, you are sneaking silver into bronze. Push that conversation upstream or own a real silver transform with a reason.

4. Kill orphan cleans

A "clean" or "transformed" view with no shortcut (or no registered raw) is a table someone invented because a notebook was open. Either attach it to a real source or delete it. Orphans confuse join keys, docs, and newcomers who assume every bronze object is backed.

5. Keep join keys boring

Once bronze stops inventing parallel physical tables, keys stay the publisher's keys. Your silver joins on documented business keys instead of "our copy's surrogate that drifted last Tuesday." Naming stays simple when you are not maintaining alias tables for the same entity.

6. Document CI/CD around the shortcut map

Deployment notes should include shortcut recreate or validate steps. A lakehouse that promotes without shortcuts is an empty promise. Pair the map with ownership: which team owns the target Delta, which team owns the consumer views.

Failure modes I design against

Copy for comfort. "We might need it offline" becomes permanent dual maintenance. You pay storage and reconciliation forever.

Clean views that rewrite grain. Thin becomes thick. Suddenly bronze owns business rules the publisher never signed.

Silent republish of upstream gold as local bronze. Consumers think your workspace is the system of record. Support tickets bounce forever.

Shortcut sprawl without a list. Twenty shortcuts, no contract file, one broken path in prod. Same failure mode as undocumented APIs.

Assuming freshness equals pipeline success. Your copy job can succeed on yesterday while the publisher already fixed today. Shortcuts inherit truth; copies invent lag.

What "thin" means in review

A clean view that renames columns, casts types already decided upstream, and projects the columns silver needs is thin. A clean view that recalculates business status, invents surrogate keys, or filters to a preferred subset without documenting why is silver in costume. Reviewers should reject costume cleans or demand they move to a named silver transform with tests. Shortcuts-only bronze fails if every team sneaks logic into the clean layer because "it was right there."

Trade-offs

Shortcuts couple you to publisher availability and permissions. That is the point. If you need an air-gapped snapshot for a regulated extract, say so and land a deliberate copy with retention rules. Do not pretend every table needs that posture.

Cross-workspace shortcuts need identity and sharing hygiene. Teams that cannot share Delta should not fake integration with nightly clones either. Fix the sharing model or accept a formal interface table the publisher owns.

Thin views still need testing when types change upstream. You trade copy lag for contract monitoring. Put schema checks on the shortcut targets you care about.

What I would put on an ADR

1. Bronze is shortcuts plus thin cleans for OneLake-published Delta; physical land only for external or non-OneLake sources.
2. A versioned shortcut inventory is the bronze contract in Git.
3. No clean/transformed bronze object without a registered backing source.
4. Heavy logic belongs in silver or upstream, never as a silent bronze rewrite.
5. CI validates shortcuts and critical view schemas on promote.
6. Ownership of target Delta is named next to each shortcut entry.

Primary references: OneLake shortcuts, Lakehouse overview, and Lakehouse schemas.

Closing

Bronze should answer "where do we trust upstream curated data from?" not "how many times can we copy the same Delta."

If your bronze folder is a museum of clones, shrink it to a shortcut contract and thin views. Cost, freshness, and ownership get honest in the same move.