The problem this solves

Revenue-ranked reporting tells a flattering story that profit-ranked reporting often contradicts. A store can post strong revenue and still be a net drag on the business once it carries its fair share of corporate overhead — and the reverse is just as common: a modest-revenue, thinly-staffed digital channel can be quietly one of the most profitable things in the portfolio. The "whale curve" — profit ranked and plotted as cumulative % — is the standard way profitability analysts surface this: it shows, in one chart, how concentrated real profit actually is, and how much of it a long tail of thin or loss-making entities is eroding.

This is the payoff use case for the whole PCMCS module — it takes the exact overhead allocation UC13 computes for one entity at a time and runs it for all 42 at once, then asks the question none of the other use cases ask directly: given everyone's fair share of overhead, who's actually making the company money?

Audience

Finance leadership and portfolio strategy teams deciding where to invest, close, or renegotiate. FP&A teams building the board's profitability narrative. Store and channel controllers who want to see where their entity sits in the full ranking, not just its own number in isolation.

Every entity, the same fully-loaded calculation

There is no separate profitability data model — this use case is entirely a ranking and presentation layer over the other two modules' existing calculations.

A ranked curve and the full entity ledger behind it

• KPI row: entities ranked, count profitable, total company fully-loaded profit, peak cumulative %
• Whale curve chart: cumulative % of total profit against entity rank, with a 100% reference line — the peak-then-decline-to-100% shape is the headline visual
• Detail table: every entity's revenue, pre-allocation NI, allocated overhead, and fully-loaded NI, ranked and colored by sign

The last step in the PCMCS sequence

Allocation Waterfall (UC13) answers "how much overhead does one entity carry." Reciprocal Cost Allocation (UC14) handles the harder circular-cost case. Profitability Curve takes UC13's output, runs it across the entire portfolio, and turns it into a decision-support ranking — which is the point the other two use cases build toward but don't answer directly.

Recommended integration points

• Portfolio review / store rationalization: the bottom of the curve is exactly the entity list a rationalization exercise starts from — but always paired with the "why" from UC13's trace, not the ranking alone
• Investment prioritization: entities near the top of the curve are candidates for expansion capital; the curve makes "where does the next dollar of growth investment earn the most" a visual answer, not a spreadsheet sort
• Board / investor profitability narrative: "our top 16 entities generate 116% of company profit" is a much sharper story than an average margin percentage

The numbers

The honest checklist

• ✓You already allocate overhead down to entities (or products, customers, channels) and want to see the profitability picture that emerges after that allocation, not before it
• ✓Leadership makes portfolio decisions (expand, hold, close, renegotiate) and needs a profit-concentration view, not just a revenue ranking
• ✓You want the allocation methodology (UC13/UC14) and its downstream profitability consequence (this) visibly connected, not computed in separate disconnected tools
• ✗You haven't yet built a defensible overhead allocation — start with UC13; a profitability ranking is only as trustworthy as the allocation feeding it
• ✗You need product- or customer-level profitability rather than entity-level — this demo ranks the 42 entities in the shared cube; the same technique applies to any cost object with a revenue and an allocated-cost figure

Try it now

The live demo ranks all 42 entities and redraws the curve in real time.

Things to try

• Type "Which stores are unprofitable after allocation?" and scroll the detail table to the bottom rows — compare their revenue to their allocated overhead
• Switch scenario to Actual and watch both the curve shape and the peak cumulative % shift as every entity's underlying P&L recomputes
• Cross-reference a top-of-curve entity here against its Allocation Waterfall trace (UC13) — the two numbers should tie out exactly

A ranking is only as honest as its inputs

It would be easy to build a "profitability curve" that ranks entities by raw, pre-allocation net income — that's just a revenue-adjacent sort and tells you nothing a simple P&L report doesn't already show. The entire value of this use case is that it ranks by fully-loaded profit, meaning every entity has already absorbed its real, traceable, auditable share of corporate overhead before the ranking happens. That's why this use case has no data model of its own — building one would risk the ranking disagreeing with the allocation the rest of the module already computes.

Reuse, sort, accumulate

App UI — Component breakdown

One subtraction, correctly sourced

fullyLoadedNI = genIS(entityId, year, scenario).FY._NI
              - computeAllocationWaterfall(entityId, year, scenario).totalAllocated

The calculation itself is a single subtraction — the engineering value is entirely in calling the same waterfall function UC13 exposes to users, rather than re-deriving a parallel allocation inline. If UC13's allocation methodology ever changes (a new pool, a different driver, a resized pool), this use case's ranking updates automatically and stays consistent with it — there's no second copy of the allocation logic that could silently drift out of sync.

A property of the math, not a coincidence

cumulativePct is defined as runningSum / totalProfit × 100. By the time every entity has been included in the running sum, runningSum === totalProfit by construction — so the curve's final point is always exactly 100%, regardless of how profit is distributed across entities. What varies is everything before that final point: how high the curve peaks (concentration among top performers) and how far it dips before recovering (how much of a drag the bottom performers are). This was verified directly: a unit test asserts the last point's cumulativePct equals 100 to within 0.01, for any year/scenario combination.

Getting a real whale shape, not a cliff

The first pass at sizing UC13's allocation pools (7.5% of revenue combined) produced a company-wide fully-loaded loss — only 6 of 42 entities stayed profitable, and the "curve" was really a near-monotonic climb with no meaningful peak, because almost the entire portfolio had gone negative together rather than showing genuine dispersion. A second pass at 3% combined over-corrected the other way: 40 of 42 entities profitable, peak cumulative % of only 100.1% — barely a whale shape at all, since almost nothing in the tail was actually eroding the total. The pools were re-tuned to 4.7% combined (1.9% G&A + 1.3% IT + 1.5% Marketing), which produces 16 of 42 entities profitable and a peak of 116% — a shape with a real long tail, verified by rerunning the same Node unit-test harness after each adjustment rather than eyeballing the chart.

The smallest schema, matching Ownership's pattern

Profitability's NLQ schema — {intent, year, scenario, confidence} — is deliberately the same shape as Ownership's (UC9): no entity or method to resolve, because the output is always the full ranking of all 42 entities at once. The few-shot examples cover the phrasing variety users would naturally reach for — "whale curve," "profitability curve," "which stores are unprofitable," "fully loaded profit," "cumulative profit contribution" — rather than any lookup logic, since year/scenario extraction is the only real parsing work this use case's NLQ layer has to do.

Cost model — At-scale projections

LLM cost is flat per query at roughly $0.0002 — year/scenario only, the same minimal footprint as Ownership. The ranking calculation is O(n log n) in entity count (dominated by the sort), and each entity's profitability calculation is itself O(regions) via the shared waterfall — so a company with 500 entities instead of 42 would still rank the full portfolio in well under a second of client-side compute.

Key files

Why this use case has no data model of its own

Every number this page shows already exists somewhere else in the codebase — revenue and pre-allocation NI in epm-data.js, allocated overhead in this same file's computeAllocationWaterfall(). This use case's entire contribution is the sort-and-accumulate step that turns 42 independent entity calculations into one ranked, cumulative story — a deliberately thin layer, by design.

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents a misleading curve

• Zero-division guard on cumulativePct: if totalProfit is ever exactly zero, the calculation falls back to 0 rather than dividing by zero and propagating NaN or Infinity into the chart
• Sort order is asserted, not assumed: unit-tested that every entity's fullyLoadedNI is greater than or equal to the next entity's — a sort-comparator regression would fail the test before ever reaching the UI
• Universe matches UC13's exactly: both use the same allocationUniverse() function (non-corporate entities only), so the entity count shown here always reconciles with the entity count UC13's dropdown offers

Who is asking, and what are they allowed to see?

The demo answers neither question — it has a cookie gate and no notion of a user. In production these are the two questions everything else rests on, and they have different answers: authentication is who you are, authorization is what you may see. Corporate SSO settles the first. Only Oracle EPM Cloud can settle the second, and the single most important rule in this section is that this application must never become the place where that decision is made.

9.1 · The identity chain, end to end

9.2 · Federating the corporate identity provider

Oracle EPM Cloud does not replace your directory — it trusts it. The EPM Cloud identity domain is federated with the corporate IdP so authentication happens where it already happens, under policies security has already written.

For the browser application itself, use OIDC Authorization Code flow with PKCE. Not the implicit flow, which is deprecated and leaks tokens through the URL, and never a resource-owner password grant — a finance tool should not be capable of handling a password at all.

9.3 · From group membership to EPM roles

Roles are granted to groups, never to individuals, and the groups come from the directory. That one discipline is what makes joiner/mover/leaver work without anyone having to remember this application exists.

Entra ID group                    →  EPM role / entitlement
──────────────────────────────────────────────────────────────────
FIN-EPM-Analysts                  →  Planning User
FIN-EPM-Controllers-EMEA          →  Power User + EMEA data scope
FIN-EPM-Admins                    →  Service Administrator
──────────────────────────────────────────────────────────────────
Provisioned by SCIM. Remove the user from the group and the
entitlement disappears on the next sync — including here.

For this use case the relevant native entitlement is: PCMCS User, with the ranked portfolio view typically limited to leadership and FP&A.

9.4 · The architectural decision: who enforces?

This is the choice that determines whether the deployment is defensible. Both patterns appear in the diagram above; the difference is where the security boundary actually sits.

The shortcut to refuse. Pattern B built with a Service Administrator account and no filtering at all is the most common way this gets delivered, because it works perfectly in UAT — testers are usually over-entitled, so nobody notices that everyone can see everything. It fails at the first access review, and by then it is in production with real users depending on it.

9.5 · Data-level security is the part that matters

Role membership decides whether a user can open the application. It does not decide which rows they get back, and confusing the two is the most expensive mistake available here.

• For this use case: PCMCS POV access; the ranking is portfolio-wide and should not be assembled from a partial entitlement.
• Apply it before aggregation, not after. Filtering a total that has already been computed across entities the user cannot see still leaks the total.
• The NLQ layer needs its own check. Layer 4 already validates that the resolved point of view uses approved members; production adds a second test — that the resolved POV sits inside this user’s scope — and it runs before the data call, not after. A natural-language interface is very good at asking for things politely; the authorization check must not care how the question was phrased.
• Fail closed. If entitlements cannot be resolved, return nothing and say so. An empty result is a support ticket; a permissive default is an incident.

9.6 · Provisioning, sessions and the leaver problem

• SCIM provisioning from Entra or Okta into the EPM Cloud identity domain (OCI IAM, formerly IDCS), covering joiner, mover and leaver. The mover is the case people forget — somebody changing region should lose the old scope, not accumulate both.
• No local user store. If this application keeps its own copy of who may do what, a leaver keeps access until somebody remembers to update it. Nobody ever does.
• Short-lived access tokens with refresh-token rotation; align session timeout with the data classification rather than with convenience.
• MFA and Conditional Access at the IdP — not reimplemented here. Device compliance and location policy come free with federation.
• Quarterly recertification of both the groups that grant access and the service account’s own entitlements, evidenced and signed.
• Break-glass access is a named, monitored, time-boxed account — never a shared credential in a password manager.

9.7 · What this means for Profitability Curve

9.8 · Security configuration checklist

• ✓Oracle EPM Cloud federated with the corporate IdP over SAML 2.0 or OIDC; the cookie gate removed entirely
• ✓Browser app uses OIDC Authorization Code + PKCE — no implicit flow, no password grant
• ✓MFA and Conditional Access enforced at the IdP, not reimplemented in the application
• ✓Roles granted to directory groups, never to individuals; SCIM covers joiner, mover and leaver
• ✓Enforcement pattern chosen deliberately — Pattern A where the API supports it, or Pattern B with filtering centralised and tested
• ✓Data-level security applied before aggregation, and the resolved POV checked against the user’s scope before the data call
• ✓No local user table and no local role table anywhere in the application
• ✓Every query logged against the real end user, even when a service account makes the call
• ✓Authorization failures fail closed and are logged as security events rather than swallowed
• ✓Quarterly recertification of access groups and of the service account’s own entitlements

From demo to a governed enterprise deployment

Everything above runs on synthetic data, a public LLM API key, a cookie gate, and no audit trail — deliberately, so the mechanics are inspectable. Taking Profitability Curve to production is not a rewrite; the 4-layer pipeline and the data-layer contract survive intact. It is a controlled-change program across six workstreams: architecture, LLM platform, security, SOX/audit, environment promotion, and operations. This section is the checklist we run with clients.

10.1 · Production reference architecture

10.2 · Choosing the LLM platform

The demo’s DeepSeek call is a placeholder for a single adapter, callLLM(system, user), behind Layer 3. Swapping the provider changes one function and zero business logic. Pick the platform the organisation already governs — the security and procurement review is the long pole, not the integration.

Put a model gateway in front of whichever you choose (Azure API Management, OCI API Gateway, Kong AI Gateway, LiteLLM, or Portkey): it owns key custody, per-team spend caps, routing and fallback between models, prompt/response logging, and lets you retire a deprecated model without touching the application.

10.3 · Security controls

10.4 · SOX, audit, and model-risk controls

A read-only NLQ layer does not change a financial-reporting control, but it is an interface to a SOX-relevant system and lands squarely in ITGC scope. Treat prompts, schemas, and eval sets as code — that single decision satisfies most of what an auditor will ask for.

10.5 · Dev → Test → Prod promotion

• Promoted artifacts: application build, prompt templates (versioned), approved-member schema snapshot, eval set, infrastructure config (IaC) — all from the same Git tag.
• Pipeline: branch → PR review → CI (tests + evals) → deploy to Test → UAT sign-off → CAB → deploy to Prod → smoke test. Hosting can stay on Cloudflare Pages/Workers or move to OCI Functions + API Gateway or the org’s standard platform — the code does not care.
• Configuration: per-environment secrets and endpoints injected at deploy; the same build runs in every environment.
• Metadata sync: a scheduled job refreshes dimension metadata into Layer 2 grounding with change detection, so a new entity or account appears in the approved lists without a code release.
• Rollback: previous build and previous prompt version retained; rollback is a redeploy, and because prompts are versioned it also reverts a prompt regression.

10.6 · Operating it

• SLOs: p95 latency, availability of the read path (the deterministic fallback keeps it alive when the LLM is down — already built), fallback rate as a quality signal, eval pass rate per release.
• Cost governance: per-user and per-team token budgets at the gateway; alert on anomalies; the unit-cost model earlier in this kit is the baseline.
• Model lifecycle: providers retire models on a schedule — re-run the eval suite on the successor before switching, and record the switch as a change.
• Incident runbook: LLM outage → fallback parser; EPM API outage → cached metadata with a stale banner; guardrail spike → review logs for injection attempts.

10.7 · What changes for Profitability Curve

10.8 · Production readiness checklist

• ✓LLM platform selected from the governed list, DPA / zero-retention terms on file, gateway in front of it
• ✓SSO integrated; authorisation derived from EPM security groups; cookie gate removed
• ✓Read-only EPM service account per pod, credential in a vault, rotation scheduled
• ✓Prompts, schema, and eval set version-controlled and under change management
• ✓Append-only audit log wired to the SIEM with the agreed retention
• ✓Golden-query eval suite passing in CI; results archived as release evidence
• ✓Dev / Test / Prod pipeline with gates, IaC, and a rehearsed rollback
• ✓Model-risk register entry and owner named; first re-validation date set
• ✓Metadata refresh job scheduled with change detection
• ✓SLOs, cost caps, and the incident runbook agreed with platform operations