Engagement23 The engagement, end to end · 2 of 3

The decisions that are expensive to reverse

Most of what a warehouse team does is reversible in an afternoon. This list is not. Each of these gets written down, with the reasoning, in the first month.

Stand 29.07.2026

#The eight that need writing down

What

Decide once, in phase two, in writing

Decision	Cost of getting it wrong	Route
Environment topology — catalog per environment	Retrofit means moving every table, reissuing every grant, re-pointing every report. No partial rollout.	Architecture · Unity Catalog
Layer contract — what may enter and leave each layer	Without it, gold becomes silver with a prefix and the first cross-source question cannot be answered.	Architecture
Naming and identifier standard	Renaming after BI connects is a fortnight of coordination, not one statement.	Architecture
Modelling approach — Kimball, Vault, or wide	Changes the shape of every table and every load. Effectively a rebuild.	Data model
Key strategy — hash surrogate keys and their normalisation	A collision or an un-normalised input corrupts joins silently, and the fix is a full reload.	Data model
Historisation — which dimensions are SCD2	History not captured cannot be recovered later. The data is simply gone.	Data model
Semantic layer ownership — metric views, BI model, or both	'Both' means two definitions of revenue and a standing argument about which is right.	BI & semantics
Tag taxonomy for cost attribution	Tags cannot be backfilled — untagged spend is unattributable forever.	Storage & cost

Why

Every one of these is cheap in week three and expensive in month six, and none of them is technically hard. They get missed because they are not urgent — no ticket says "decide the historisation policy", so the first pipeline quietly decides it by accident.

Two of them are worse than merely expensive, because they destroy information rather than costing effort: history you did not capture cannot be reconstructed, and tags cannot be backfilled. Everything else on the list is money and time. Those two are permanent.

Doing it

Put all eight on one page with the decision, the date, and one paragraph of reasoningNot a slide deck — a file in the repository.
Decide the two irreversible ones first: historisation, and the tag taxonomy
Build one vertical slice against the decisions before writing them down as finalA decision no code has touched is a guess.
Record what you rejected and whyThe question comes back in month four, reliably.

Embedding it

Make the team present the eight decisions back to you, not the reverseThe gaps in their explanation are the gaps in the decision.
Timebox each oneThese are chronic sources of analysis paralysis, and a good decision made on Thursday beats a perfect one made in March.
When they want to revisit one later, make them cost the reversal firstUsually that ends the discussion honestly, in either direction.

Defaults

Eight decisions, one page, in the repository, with dates and reasoning
Irreversible-information decisions first: historisation and tagging
Prove each decision with one vertical slice before declaring it
Rejected options are recorded, not discarded

Gotchas

Deferring historisation until 'we know the requirements'Meanwhile the loads overwrite, and when the requirement arrives the history it needs was never written. There is no fix — only a restart of the clock.
Deciding the semantic layer lateBy then Power BI has its own model, the warehouse has metric views, the two disagree by a rounding rule, and every number in every meeting is now contestable.
Writing the decisions in a consultant's deck rather than the client's repositoryThey are not findable at the moment someone needs them, so they get re-decided differently.
Treating the eight as sequentialThey interact — the key strategy depends on the modelling approach, which depends on the layer contract. Do them in one workshop block, not one per sprint.