In short: A planning data warehouse earns its keep in the semantic layer, where raw source records become planning objects with agreed meanings. Conformance is a short list of decisions made once, covering which date a shipment belongs to, whether returns net off, and whether inter-company transfers count. Hierarchies have to be versioned or last year's numbers cannot be reproduced after a reorganisation, and that is the correction most expensive to make late. The test that settles whether the layer works is to pick a number published six months ago and recompute it from the warehouse today.
Two people bring numbers for last month's shipments to the same meeting. One says 412,000 cases, the other 398,000. Both pulled from the same warehouse. It takes twenty minutes to establish that one used ship date and the other used the requested delivery date, that returns are netted in one and not the other, and that one includes inter-company transfers. Nobody was wrong. There were simply three definitional choices that had never been made in one place, so each report made them independently.
A planning data warehouse exists to make those choices once. The storage and the pipelines are the easy part. The value sits in the layer where raw source records become planning objects with agreed meanings, and the reason projects underdeliver is almost always that this layer was treated as plumbing rather than as the deliverable.
The layers and what each one promises
A workable structure has four layers and each makes a different promise.
Landing. An immutable copy of what the source sent, with the time it arrived. It promises nothing about meaning. Its job is that you can always go back to what was actually received, which is what makes replay possible.
Conformed. Source records mapped onto shared dimensions and cleaned of source-specific encoding. It promises that an item code means the same thing regardless of which system it came from, and that a location in one feed can be joined to a location in another.
Semantic. Planning objects with agreed definitions: demand, shipments, on-hand, lead time, forecast. It promises that a measure named the same thing in two places is the same number.
Planning store. Whatever the planning application holds internally, versioned for planning purposes.
The layer people skip is the third. Skipping it means the definitional choices get made in each report, each extract and each model, which is exactly the situation in the opening paragraph. Feed latency per layer is a related design decision and T4 covers it; the transport between layers is AA6's.
Conformance is a small number of decisions, made once
The conformed layer needs a short list of decisions and each one has a right answer for your business rather than in general.
The grain of each dimension. Is a location a site, a building or a storage area. Is a customer a legal entity, a ship-to, or a banner. Getting the grain wrong forces every downstream consumer to either aggregate or split, and the two consumers who choose differently produce the two numbers in the meeting.
The key. Source systems change their identifiers, merge records and reuse codes. A surrogate key with a mapping table insulates everything downstream from that, and the mapping table becomes a permanent asset. T3 covers resolving the same entity appearing several times across sources.
The unit of measure. Every quantity needs a stated unit and a conversion to a base measure, held once. Where a case pack changes over time, the conversion is effective-dated, and a historical quantity converts at the rate in force then rather than now.
Currency, where value is held at all. Rate type and rate date have to be specified per measure, and a plan comparison across periods needs a stated policy on whether to use current or historical rates.
None of these is difficult. All of them are contentious, because each has an established answer somewhere in the business already, and the warehouse's job is to pick one and record why.
The calendar deserves separate mention because it is the one that quietly breaks reconciliation. A business with a 4-4-5 fiscal calendar, an ISO week, a manufacturing week starting on a different day and a retail calendar borrowed from a customer has four definitions of a period in play, and every one of them has a legitimate owner. Hold all of them as attributes of a single date dimension rather than picking a winner, so that a fact can be reported on any of them and any two reports can be reconciled by naming which calendar each used. Y9 covers the version of this problem that appears when several markets each define a week their own way.
Hierarchies have to be versioned or your history is unreproducible
This is the decision most often got wrong, and it is expensive to correct later.
Product and customer hierarchies change. A category is reorganised, a customer moves between regions, a brand is split. If the warehouse holds only the current hierarchy, then any historical number reported by hierarchy changes retrospectively every time the structure changes, and a forecast produced last quarter cannot be reproduced.
The standard treatment is a slowly changing dimension holding each version with its valid-from and valid-to dates, so that a fact can be reported against the hierarchy as it was at the time or as it is now, deliberately, with the choice recorded.
Both views are needed and they answer different questions. Comparing this year against last year for the current category structure needs the current hierarchy applied to both. Explaining why last year's plan said what it said needs the hierarchy that was in force when it was written.
Quantify what the omission costs before deciding whether to build it. If a category reorganisation moves 6 percent of items between categories, then every category-level year-on-year comparison after the change is wrong by up to 6 percent of the affected categories' volume, in an unpredictable direction, for the twelve months it takes the change to work through the comparison window. Somebody will spend several days each month explaining variances that are entirely artefacts.
Measures need definitions written in sentences
The semantic layer's real output is a set of measures with definitions precise enough that two people implementing them independently get the same number.
Take demand. It sounds atomic. It requires at least five decisions: which date it is recognised on, whether cancelled lines count, whether inter-company movements count, how returns are treated, and whether unfulfilled demand is included. Z7 covers the difference between a sales forecast and a demand forecast, and D1 covers what happens when the history is censored by what you could not supply.
The date choice alone moves the number materially and is worth an illustration. Suppose the last three working days of a month carry 18 percent of the month's shipment volume, which is common where a sales incentive lands at month end. A measure recognised on ship date puts all of that in the closing month. A measure recognised on the requested delivery date puts a portion of it in the following month, because some of those shipments were requested for early next month and pulled forward. If a third of that 18 percent has a requested date in the next month, then 6 percent of monthly volume moves between periods depending on which date the measure uses. On a 400,000 case month that is 24,000 cases, which is larger than most forecast errors anyone is worrying about.
Write the definition as a sentence, store it with the measure, and make it visible in the tools that consume it. A measure whose definition lives only in a transformation script has no definition as far as the business is concerned.
Why conformance belongs here rather than in the planning system
Two reasons, and the second is the one that decides it.
The first is that more than one consumer needs the same definitions. Planning, finance reporting, commercial analytics and the sales incentive calculation all want a shipments number, and if each derives its own the organisation spends its meetings reconciling.
The second is that a planning system's internal model is versioned for planning. It holds scenarios, overlays and provisional values, which is exactly right for its job and wrong as a reporting source. Pulling a reporting number out of a planning system requires knowing which version you are in, and version semantics differ by product. Keeping the reporting definitions in the warehouse means the reporting layer never has to reason about planning versions.
There is a corollary. The planning system should consume from the semantic layer rather than from raw sources, so that the numbers a planner sees reconcile by construction to the numbers a finance director sees. Where a planning deployment integrates directly from the ERP for speed of delivery, this reconciliation problem is being deferred rather than avoided.
The test that tells you whether it works
One test settles it. Pick a number that was published six months ago, in a plan or a report that somebody acted on, and recompute it from the warehouse today.
If it comes back identical, you have immutable landing data, versioned hierarchies and stable measure definitions. If it comes back different, the differences will tell you exactly which of the three you are missing, and each one is a specific piece of work rather than a general complaint about data quality.
Run this quarterly on a rotating sample of a handful of published numbers. It takes a couple of hours and it is the only routine check that exercises the whole structure at once.
Set a tolerance before you run it, because a small difference is often legitimate. Late-arriving transactions genuinely change a historical figure, and a warehouse that reproduced the old number exactly would be hiding a real correction. What you are testing for is whether every difference has an explanation. A shipments figure that has moved by 0.3 percent because 40 late invoices arrived is healthy. The same figure moving by 4 percent with no identifiable cause means something restated underneath you and nobody recorded it.
Where this stops
A warehouse cannot make a source correct. If lead times in the ERP are wrong, conformance makes them consistently wrong across every consumer, which is an improvement in traceability and no improvement in the plan. The data quality work sits at the source, and P6 covers who owns which field.
Versioned hierarchies also cost something real. They complicate every query, they confuse analysts who expect a simple join, and they need a default so that a casual user gets a sensible answer without knowing about effective dates. Set the default to the current hierarchy, make the as-was view explicitly requestable, and accept that most consumers will never use it.
And there is a scale below which this is over-engineering. A single business unit with one ERP, one set of hierarchies and four reports does not need four layers. The structure earns its cost when there is more than one source system, more than one consuming function, or a hierarchy that changes. Where none of those is true, a conformed layer and a documented measure list will do.
Start by writing definitions for your five most-argued measures, in sentences of no more than three lines each, and circulating them to the people who currently produce different numbers for each. The disagreements that surface in that review are the actual scope of the semantic layer, and you will have found them in a week rather than in month eight of a build.