The geometry of profit
11 dimensions. Every one of them Stored. That is not a coincidence — it is a design decision with consequences that reach into every rule you will ever write. This hall explains why ASO dimension design is different, what Stored vs Dynamic actually means in production, and how NovaPrism's 11 dimensions were chosen and justified.
Why dimensions are the foundation of everything
Every rule you write in Hall 4, every model you define in Hall 3, every number that appears in PCM_REP — all of it flows from the dimension design you lock in here.
A dimension is an axis of analysis. It answers one question: from what perspective do we want to see cost? NovaPrism needs to ask: by division (Entity), by GL account (Account), by shared service function (Function), by client engagement (Customer), by time period (Period), and more. Each unique question becomes a dimension.
The reason dimension design is Hall 2 and not Hall 8 is simple: you cannot add a dimension to a live EPCM application without rebuilding it. Every downstream decision — rule design, data load format, reporting layout — assumes a fixed dimension set. Get this wrong and you rebuild from scratch. Get it right and every subsequent hall clicks into place.
ASO dimension rules — what changes vs BSO
EPCM uses ASO (Aggregate Storage). Planning uses BSO (Block Storage). They look similar in the UI. They behave very differently. The storage type of each dimension has direct consequences for aggregation, calculation, and rule reliability.
In BSO, dimension members can be Tagged with Dense or Sparse storage. In ASO there are no Dense/Sparse tags — instead, each member has a Data Storage property: Stored or Dynamic (or Never Share, Label Only for structural members). This is a more powerful distinction than it sounds.
NovaPrism's 11 dimensions — the design rationale
Each dimension answers a distinct business question. The design principle: if two questions can be answered from the same axis, they share a dimension. If they cannot, they get their own.
| Dimension | Storage | Business question it answers | NovaPrism design notes |
|---|
PCM_Balance — the system dimension you don't design
PCM_Balance is the only dimension in EPCM that you cannot rename, restructure, or change. It is prebuilt by the system and its six members define the entire flow of money through the model.
Every other dimension tells EPCM what kind of thing you are measuring (which account, which entity, which period). PCM_Balance tells EPCM what stage in the allocation pipeline the value is at. You can think of it as the allocation lifecycle dimension — every cell in the model has a PCM_Balance coordinate that tells you whether the value is raw input, in-transit allocation, or final output.
| PCM_Balance Member | What it holds | Written by | NovaPrism example |
|---|---|---|---|
PCM_Input | Raw costs loaded from source system | Data load (Hall 8) | ES division's $52M IT pool cost, loaded from GL extract |
PCM_Allocated_In | Cost received from another cost object | Allocation rules | DS receives $14.19M from the IT pool — this is its PCM_Allocated_In |
PCM_Allocated_Out | Cost sent to another cost object | Allocation rules | ES sends its full $134M out — PCM_Allocated_Out = $134M |
PCM_Adjustment_In | Manual adjustment credits | Manual data entry or adjustment rules | Q1 restatement: +$0.3M correction to DS IT allocation |
PCM_Adjustment_Out | Manual adjustment debits | Manual data entry or adjustment rules | Corresponding $0.3M debit from IS |
PCM_Output | Final fully-loaded cost for this object | Calculated: Input + Allocated_In − Allocated_Out + Adjustments | DS: $580M direct + $40.26M allocated in = $620.26M output |
Alternate hierarchies — Period and View without Dynamic
NovaPrism needs Periodic, YTD, and QTD views. The wrong approach is to make View a Dynamic dimension using formula members. The right approach is alternate hierarchies in Stored dimensions.
In ASO, a dimension can have multiple hierarchies — a primary hierarchy for base aggregation, and one or more alternate hierarchies for different rollup paths. NovaPrism's Period dimension has a primary hierarchy (Q1, Q2, Q3, Q4 rolling up to FY24) and an alternate hierarchy (Jan, Feb, Mar rolling up to Q1_YTD).
This means YTD values are aggregations, not formulas. When the reporting user selects Q1_YTD, ASO aggregates Jan + Feb + Mar from stored cells. No formula member, no Dynamic dependency. The value is always consistent with the underlying data and can be written to by rules if needed.
| Design choice | Approach | Can rules write to it? | Performance | Verdict |
|---|---|---|---|---|
| View as Dynamic dim | YTD member uses Dynamic formula summing Period members | No | Calculated at query time | Avoid |
| Period alt hierarchy | YTD node in alternate hierarchy aggregates stored Period members | Yes | Aggregated from stored cells | Correct |
The Customer dimension — 60 engagements + rollup
The Customer dimension is what makes NovaPrism's model worth building. Without it, you can see divisional profitability. With it, you can see which of the 60 engagements is destroying value.
NovaPrism has 60 active client engagements coded as ENG_001 through ENG_060. These are leaf members in the Customer dimension, rolling up to a parent All_Customers. The Engagement Contribution ruleset (seq:50 in Hall 4) pushes fully-loaded costs from the Entity dimension intersection down to the Customer dimension intersection — creating a fully-loaded P&L at the engagement level.
This is the dimension that delivers the key insight: 17 of 60 engagements are loss-making on a fully-loaded basis, but none appear loss-making on direct costs alone. The Customer dimension is what makes that visible. Without it, you would never know.
All_Customers rollup parent must be Stored (not Dynamic) because rules write to the engagement-level leaf members and the system aggregates to All_Customers. If All_Customers were Dynamic, the aggregation would recalculate but never match the sum of engagement-level PCM_Output values exactly — because Dynamic members in ASO recalculate from stored children, but intermediate stored values at the parent level are not guaranteed to match when the rule writes happen at different times. Stored is safer and gives a directly auditable group total.Venturi Dimension Visualiser
Click any dimension node to inspect its storage type, member design, exam traps, and NovaPrism-specific justification. This is NovaPrism's live dimension map.
Dimension design decision tree
Answer five questions about a dimension you are designing. The tree tells you Stored or Dynamic — and why.
Design NovaPrism's dimension set from scratch
You are the EPCM implementation lead. The application is empty. You must propose and justify the complete dimension set before the build can begin.
All_Customers rollup parent, and a No_Customer member for costs not yet attributable to an engagement. Explain why this third member is necessary and what happens to allocation calculations if it is missing.No_Customer member is critical. When the Facilities pool is allocated to DS, IS, and CL by square footage, the allocation targets Entity members. The Engagement Contribution ruleset (seq:50) then maps Entity-level costs to Customer-level engagements. But not every cost has a clear engagement mapping at the time of allocation. No_Customer captures the unattributed portion — without it, the Customer dimension total will not reconcile with the Entity dimension total, and Rule Balancing will fail.What Dimensions Gallery covers on the exam
Hall 2 maps to the second syllabus topic: Designing Dimensions. Expect 5–7 questions in this area across the 50-question exam. It is the second-highest weighted topic after Rule Sets & Rules.
1. Describe dimension types and storage properties in EPCM Standard (ASO) — Stored vs Dynamic, Label Only, Never Share.
2. Explain the PCM_Balance system dimension and its six members.
3. Design alternate hierarchies for Period/View without Dynamic formula members.
4. Explain the consequences of setting operational dimension members to Dynamic.
5. Identify which dimensions are prebuilt (PCM_Balance) vs user-defined.
FALSE for any dimension whose members are targets of allocation rule writes. Dynamic members in ASO do not persist values — rules that write to them will fail silently. Stored + alternate hierarchy is the correct Period design.
Distractor 2: "You can rename PCM_Balance to match your company's naming convention."
FALSE. PCM_Balance is a System dimension. Its name, its six prebuilt members, and their definitions are fixed. You can add members to user-defined dimensions freely — you cannot modify PCM_Balance.
Distractor 3: "EPCM Standard supports up to 20 dimensions."
The exam tests the actual limit. EPCM Standard supports up to 20 user-defined dimensions plus the mandatory system dimensions. NovaPrism uses 10 user-defined + PCM_Balance (system) = 11 total, well within limits. The number 20 is the ceiling for user dimensions, not total dimensions.
| Concept | Exam answer | Implementation reality |
|---|---|---|
| Default storage type for operational dims | Stored | Every dimension that participates in rule logic must be Stored — this is the first thing you verify on any implementation |
| PCM_Balance member count | 6 (Input, Allocated_In, Allocated_Out, Adjustment_In, Adjustment_Out, Output) | You reference these names in every rule you write — memorise them in Hall 4 |
| Dynamic member use case | Pure reporting members with no rule write target — calculated subtotals only | In practice most implementations use zero Dynamic members in the operational model |
| YTD/QTD design pattern | Alternate hierarchies in Period dimension, Stored members | Same — this is the only correct pattern for EPCM allocation models |
| Max user dimensions (Standard) | 20 | NovaPrism uses 10 user-defined. Most implementations use 8–14. |