This interim Finance Intelligence Hub brings the current transition-governance snapshot, architecture and certified-layer guidance, data-ecosystem reference, and the first detailed Finance workflows into one static experience.
Content standing: governance snapshot dated Nov. 6, 2026 · certified-layer operating guide dated Oct. 21, 2026 · Membership, Revenue FP&A and ecosystem views remain draft / validation artifacts.
The hub is organized by the task a Finance leader or team member is trying to complete, not by the file the information originally came from.
Portfolio readiness, team movement, blockers, milestones and the operating rhythm.
Readiness percentage, stage standing, 20 proof gates, evidence and the next unlock for each team.
Shared source access → team working schemas → Certified Outputs, with the production database context underneath.
Certification criteria, documentation, checks, publication sequence, version handling and implementation controls.
Executive workflow stories plus the source, control and validation detail needed to trust them.
Movement statements are carried directly from the Nov. 6 working governance snapshot.
Progress is measured by proven future-state capability, not activity completed. The portfolio uses five stages and 20 binary readiness gates per team.
Working governance snapshot: Nov. 6, 2026 · sourced from the calibration workbook and maintained through the governance cadence.
Where are we overall, what moved, and what needs attention?
The weekly executive pulse reports change, not activity.
Each target is expressed as a capability that must be proven, not simply work completed.
Each team has the same 20 proof gates. Select a team to see the evidence, open questions and next unlock behind its readiness percentage.
Snapshot: Nov. 6, 2026 · 11 process groups.
| Team / process group | Lead | POC | Readiness | Movement this cycle | Attention |
|---|
A working roll-up of foundational source families emerging from Process & Source Discovery—what is mapped, what has a Snowflake target, and where validation remains.
Standing: initial reference, not yet an authoritative source inventory.
“Available in Snowflake” reflects what is captured in the working register; it does not by itself establish M&R access, authoritative status or workflow validation.
| Domain | Standing | Reach | Mapped relationships | Targets identified | Working status | Next focus |
|---|
The source profile exposes upstream enablement, M&R dependency, requested objects and what must be proven before Stage 2 is met.
CMS Data Warehouse remains the current intake while the enterprise path is being migrated through MAGNUS / Databricks toward a Snowflake product / subscription path for M&R.
Requested scope: M&R member subset using HICN / MBI identifiers and applicable date filters such as PaymentDateYM or RunDate.
CmsTRRHICChanges · CmsTRR · CmsMORTypeD · CmsMORTypeM · CmsMORPartD · CmsMORTypeB · CmsMORPartDPDPOnly · CmsMMR · CmsMMRPDPOnly
Required CMS source family and example objects are known.
MAGNUS / Snowflake direction established; final product / object mapping still to confirm.
Subscription availability varies by object; M&R reconciliation / workflow validation is not yet complete.
| Process group | Process / use | Working source objects | Current path | Future path |
|---|---|---|---|---|
| Revenue Analytics | Rev Actuary / RAF Revenue forecast workflow | CMS_MMR · MASTERHICCHANGES · CMSTRR · CMSTRRPDPONLY | SAS connection to CMS DW | Shared Source Access · final Snowflake mapping to validate |
| Part D | MOR / Part D actual inputs | CMSMORPartD · CMSMORPartDPOnly | SAS connection to CMS DW · team attribution to validate | Shared Source Access · final mapping to validate |
| Part C / Bid | Part C Bid Code actual inputs | CMSMORTypeM · CMSMORTypeD | SAS connection to CMS DW · team attribution incomplete | Shared Source Access · final mapping to validate |
| Other portfolio teams | To be established through process/source discovery | — | Current path to validate | Shared Source Access once dependency is confirmed |
Build a more connected M&R Finance organization where trusted facts, repeatable forecasts and decision-ready intelligence move across teams with less friction.
Operating principle: standardize the handoff, not the work. Teams keep the expertise, judgment and ownership of how their work is performed.
Clearer governed handoffs replace fragmented file exchanges. Trusted outputs become reusable and dependencies are easier to understand.
Less time moving files, reconciling versions and rebuilding logic; more time analyzing, challenging assumptions and influencing decisions.
Connected inputs and repeatable processes create a stronger foundation for scenario thinking, forecasting and guided intelligence grounded in governed facts and human judgment.
The future state removes friction around the work without removing the expertise that makes the work valuable.
AI is not the source of truth and does not replace team judgment. Guided intelligence becomes useful because the facts, definitions, assumptions and outputs underneath it are governed and traceable.
Trusted definitions, source, lineage, refresh and reusable certified outputs.
Controlled assumptions, versioned forecasts, surfaced exceptions and explicit validation.
Decision-oriented questions and scenario exploration grounded in governed facts with human review where judgment is required.
The transition governance model separates visible movement from proven readiness. Every process group advances through the same five stages and 20 gates while keeping its own workflow expertise and implementation choices.
Reference standing: working governance model carried from the Nov. 6, 2026 calibration snapshot.
The handoff standard is common; the way teams do their work is not forced into one implementation pattern.
| Stage | Gate 1 | Gate 2 | Gate 3 | Gate 4 |
|---|---|---|---|---|
| 1 · Mobilized & Enabled | Team ownership established | Scope established | Working environment ready | Transition working plan established |
| 2 · Authoritative Sources Connected | Required sources identified | Authoritative status established | Sources accessible | Source validation passed |
| 3 · Team Forecast Workflow Operational | Core forecast workflow executable | Inputs and assumptions controlled | Required deliverables reproducible | Workflow validation passed |
| 4 · Certified Team Data Outputs | Output contract established | Lineage and refresh established | Quality checks passed | Certified for downstream consumption |
| 5 · Integrated FP&A Workflow | Certified output connected | Consolidation & applicable SOX controls operational | Cross-team dependencies resolved | End-to-end cycle validated |
The objective is a predictable mechanism for advancing each team and escalating only what requires broader action.
Advance the next gate: movement, constraint, next unlock and ownership.
Consolidate the portfolio, connect dependencies and prepare escalation.
What moved, what did not, the most important blocker and whether a decision is needed.
The calibration plan uses real Finance work to expose friction, ownership gaps and control points before the pattern is generalized.
Document the use cases, map current handoffs, identify performers and consumers, and align on what the future-state simulation needs to prove.
Work through both use cases end to end using the proposed Stage 1–5 pattern; capture friction, exceptions, ownership gaps and control points.
Refine gates and handoffs based on what worked and what did not before broader application.
Pressure-test a cross-functional path from source inputs and assumptions through the Revenue YoY Bridge and final Finance output.
Question: does the future-state model make assumptions, transformations, unresolved variance, ownership and the final handoff easier to trace and resolve?
Pressure-test whether forecasting can operate at HPlan level while preserving the controls, assumptions and reconciliation needed for broader FP&A consumption.
Question: can the future-state pattern support HPlan-level forecasting without making the process harder to control or reconcile?
Enable the transition, connect teams, make dependencies visible and protect the certification standard.
Workflow expertise, forecast judgment, team-specific analytical logic, interpretation and ownership of the outputs it publishes.
The long-term operating model keeps teams flexible inside controlled working schemas while standardizing the governed interface used for downstream reuse.
Important distinction: PROD is the environment. Team data schemas are working areas inside PROD. Certified schemas are the read-only handoff for shared Finance information.
Enterprise and shared data made available to Finance teams.
These are the production source / data-share names carried by the Certified Layer guide.
Where teams build, transform, test, adjust assumptions, reconcile and iterate.
MMLRISK_ANALYTICSMEDICAL_TFMMEMBERSHIPREVENUEMEDICAL_NON_LAGMR_INDPHARMACYSGNABCASIMEDSUPPPHARMACY_ACTUARYPHARMACY_DATA_TMMEDSUPP_FPNAGROUP_MACONSOLIDATIONS_TMRead-only for consumers. Documented and registered outputs are published for downstream use.
CERT_MMLCERT_RISK_ANALYTICSCERT_MEDICAL_TFMCERT_MEMBERSHIPCERT_REVENUECERT_MEDICAL_NON_LAGCERT_MR_INDCERT_PHARMACYCERT_SGNACERT_BCASICERT_MEDSUPPCERT_PHARMACY_ACTUARYCERT_PHARMACY_DATA_TMCERT_MEDSUPP_FPNACERT_GROUP_MACERT_CONSOLIDATIONS_TMThe operating model is schema-led; these names provide the physical production context currently documented.
| Purpose | Production database |
|---|---|
| MML tenant | UTXZB_PRD_UHC_MR_MML_TENANT_DATA_DB |
| Main M&R Finance database | UTXZB_PRD_UHC_MR_FIN_DATA_DB |
| Risk Analytics | UTXZB_PRD_RISK_ANALYTICS_DATA_DB |
The governance architecture describes a PROD-only long-term model and carries a prior DEV transition target of Early November. That target remains source text, not a statement that the transition is complete.
Existing development activity transitions out as the future-state PROD model is established.
Teams retain flexible working space for build, transform, test, reconcile and iterate.
Ownership, definition, rules, lineage, refresh, QA, assumptions/version and change history travel with reusable outputs.
Certification gives a consumer a stable, read-only handoff plus the context required to understand what the output is, who owns it, what it passed, which version is current, and where it goes next.
Source guide: M&R Finance · Snowflake production operating guide · 21 October 2026.
A Certified Output is a documented table or view published in a team’s CERT_* schema. It is not the same thing as an enterprise Data Product.
CERT_* through the established publishing path.Downstream users should not have to rediscover meaning, ownership or lineage every cycle.
| Documentation area | What a consumer should understand |
|---|---|
| Purpose and ownership | Business purpose, producing team, business owner, technical contact and support path. |
| Structure and grain | Certified location, what one row represents, important keys, fields, units and null meanings. |
| Definitions and calculations | How important measures are defined and calculated, including aggregation or filtering rules. |
| Time, scenario and version | Period, forecast cycle, scenario, revision, cutoff and as-of context. |
| Assumptions | Material assumptions, scope and effective period, plus what changed in a new version. |
| Sources and transformation | Origin and important transformations or dependencies between source and output. |
| Checks and reconciliation | What must pass before publication and what the output reconciles to. |
| Publication and history | Who can submit/review, how active version selection works and how prior versions are referenced. |
| Downstream consumers | Who uses it next, what for, frequency and whether publication notification is useful. |
The output must be documented and registered before it appears in the application.
Teams keep running existing workflows while priority outputs are identified, documented, registered and progressively moved into the certified publishing process.
Progress is not how many workflows are blocked. It is how much important Finance information flow becomes documented, discoverable and ready to publish.
Working: revisions can change without affecting consumers.
Approved / Active: the certified consumer interface points to the approved revision for the selected context.
Locked / historical: prior official versions remain identifiable for reproduction and traceability.
| Control | Implementation expectation |
|---|---|
| Certified Output registry | Stores certified schema, owner, documentation, checks and downstream-consumer information. |
| Submission identity | Each candidate receives a durable request / revision identity tied to the exact payload and documentation version. |
| Validation | A failing required check stops publication; results remain tied to the tested revision. |
| Review separation | Working/review revisions are restricted; ordinary consumers see only the approved certified interface. |
| Approved selection | Approval changes the consumer selection atomically so partial change cannot expose an inconsistent state. |
| History and traceability | Publication records preserve output, cycle/version, sources/assumptions, checks and human decisions needed to reproduce the handoff. |
| Consumer notification | Notification remains separate from the publication transaction so a messaging failure does not undo publication. |
External links preserved from the source guide; they are references, not runtime dependencies.
The goal is not to move every source into M&R. The goal is to establish an authoritative, governed path into M&R—and an equally governed path for M&R outputs to be reused downstream.
Standing: draft for validation · source location, ownership, account relationship and access mechanism still require source-by-source confirmation.
First establish whether the authoritative source is already in the enterprise Snowflake ecosystem; then establish the governed M&R access mechanism.
Authoritative data exists in Snowflake outside the M&R consumption boundary. Sharing / subscription / applicable governed access is still required.
Cross-account access depends on the actual account and tenancy relationship.
Identify the authoritative owner and the upstream ingestion / transformation / publication work before M&R can consume it.
Account, resource group and tenancy are different boundaries.
The source location and account / tenancy relationship determine the technical mechanism; every path converges on governed M&R source access, team-owned work and certified publication.
Source → UHGSDRP producer → Data Share / applicable mechanism → M&R Shared Source Access → Team Data Schema.
Source → other SDRP-managed account → approved cross-account access → M&R Shared Source Access → Team Data Schema.
Required source → authoritative owner → Snowflake enablement → ingestion / transformation / publication → approved M&R access.
Team A Data Schema → validate / certify → Certified Data Schema → Team B / FP&A consumption.
The working mental model retained from the ecosystem artifact.
| Snowflake Account | Top-level Snowflake boundary where platform resources and data are hosted; account relationship helps determine access. |
| Tenancy | Logical construct grouping environments and Snowflake objects under customer ownership; the current M&R working reference is UTXZB and tenancy type remains to be confirmed. |
| Resource Group | Administrative container for tenancy resources and deployment / administration visibility. |
| Data Share | Snowflake mechanism for sharing selected objects read-only across accounts without recreating the source. |
| Data Catalog / Subscription | Enterprise discovery and subscription path for published data products; related to but not synonymous with a Snowflake data share. |
| Gateway Role | Working SDRP mechanism described for governed read-only schema access across supported tenancies within the same resource group; applicability depends on the actual relationship. |
| Shared Source Access | Business-friendly name for the incoming M&R consumption boundary where approved enterprise sources become available to teams. |
| Certified Data | M&R output published for downstream reuse with ownership, definition, rules, lineage, refresh, QA/reconciliation and version context. |
The workflow is a two-process chain: first build controlled monthly forecast detail, then enrich and publish it in a form downstream Finance users can consume.
Working view · owner validation required. Source-supported synthesis from the Membership workflow deck and discovery register.
Actual membership + approved assumptions + plan structure are allocated and rolled forward, then enriched with business / accounting tags and published as detailed forecast data plus tie-out / reporting materials.
Monthly Adds, Terms, Switches and Ending Membership at detailed reporting dimensions.
Detailed distributions and tie-out views for Adds, Terms, Ending, Switches, Net Growth, checks and prior-year ending context.
Completeness still requires owner validation.
| Source family | Examples consumed | Process use | Current evidence | Target / validation focus |
|---|---|---|---|---|
| Business assumptions + switches | New Mbr Forecast SAS Template_2026_8+4_Individual.xlsx · Adds A15:AR · Terms A15:AR · Switch_Forecast A1:F | Process 1 | Documented · incomplete | Confirm separate C&S DSNP / Group template, Switch_Forecast owner, storage and version control. |
| Actual membership base | FICHFIN.MBR_WALK_SMRY_RPTD | Process 1 + 2 | Documented · consistent | MEMBERSHIP_SANDBOX.MBR_WALK_SMRY_RPTD · confirm owner, refresh and history depth. |
| Structure + mapping | 2027 Structure Grid Output.xlsx · Membership Mapping Tables.xlsx · New Plans SCC | Process 1 + 2 | Documented · owner conflicts | Confirm Structure Grid owner, workbook sheets, risk-tagging use and cycle refresh. |
| Product allocation factors | Adds_Terms Breakout by Product_Entity.xlsx · Ind_Type2 | Process 1 | Documented · consistent | Confirm whether a Group version exists and governance by forecast cycle. |
| Market + product tags | IFICHMML.FIN_MARKET_TAGS · IFICHMML.FIN_PRODUCT_TAGS | Process 2 | Documented · consistent | MMLTARG.FIN_MARKET_TAGS · MMLTARG.FIN_PRODUCT_TAGS · resolve FY/CY versions and ownership. |
| Accounting + organizational tags | %PS9_GAAPMLR · Legal Entity Novations · Bid_Group_Number_Mapping · risk / customer / group attributes | Process 2 | Partially documented | Identify PS9 GL object; confirm LE Novations and bid-group mapping files / owners. |
| History + fallback sources | MBR_FORECAST_2011_2019_ARCHIVE · MBR_FORECAST_31JAN23 · historical fallback | Process 2? | Needs validation | Confirm whether both tables are used and their roles. |
| Code-held parameters + rules | SAS macro variables · embedded 99999 / closure / HPBP-SCC overrides · inc_gaap_mlr_mapping.sas | Process 1 + 2 | Missing from original register | Locate, assign owner, document versioning and decide which rules become governed reference data. |
Evidence standing: source-supported synthesis. Process naming, ownership conflicts, consumer completeness and several file/table details remain open for Membership-team validation. Snowflake locations shown are only those already captured in the discovery register.
The Current Year model completes risk scores against actuals; the Future Year model projects them forward using bid trends. Most of the input spine is produced outside Revenue FP&A.
Working view · owner validation required. Discovery status remains “In Discovery”; source authority, refresh/as-of, history depth, access and migration standing are not established in the supplied material.
General Ledger actuals + the Membership forecast + member cohort buckets + mapping / tagging reference data + team assumptions are staged in SAS/FIN360, modeled at HPBP / Grp_nbr / SCC grain, tied out to the RAF accrual and ledger, and published as two forecast tables.
Revenue forecast at HPBP / Grp_nbr / SCC, tied to RAF accrual and ledger.
Future-year revenue built from projected risk scores and tied to bid projection trend.
The source evidence points to governed access and handoffs as the main transition work—not blind reconstruction of every current implementation.
Twelve of the fourteen named current-year inputs are owned outside Revenue FP&A. The gating work is governed source access plus ownership—not recreating every upstream logic path.
Four inputs come from Membership. A governed Membership output is a natural first consumer handoff into Revenue rather than a file copy.
REVENUE_SANDBOX and MMLTARG names document development staging in the source material; they are not treated here as approved production or certified locations.
The register already notes FP&A development to remove two Excel dependencies: prospective manual adjustment and ESRD/Hospice override.
Neither source is silently preferred. The difference stays visible as validation work.
| Item | Flowchart says | Discovery register says | Why it matters |
|---|---|---|---|
| Ledger ownership | FICHGL — Accounting | FDM Team | The ledger tie-out is a release control; accountable ownership must be clear. |
| Future-year trend ownership | Bid Actuarial Team (Jamison T.) | Revenue FP&A | This input drives the future-year projection. |
| Membership forecast vintage | MBR_FORECAST_31JUL26(_CS) | 31JUL26 with note referencing 31MAY26 | The Membership artifact publishes 31AUG26; a single governed vintage is required. |
| Member premium ownership | URS Group FP&A Team | URS / Revenue | The PMPM override needs an accountable approver. |
| Four staged Excel inputs | Names REVENUE_SANDBOX objects | Snowflake target blank | Need to distinguish actual staging from planned staging. |
| Seven workbooks + two bucket summaries | Not shown | Recorded as source rows | The flowchart understates the manual surface. |
| RAF accrual input | 2026 EOL / Final RAF Accrual → REVENUE_SANDBOX.C03_RAF | No matching row; C03_RAF_Cap_Adjustment exists separately | The current-year tie-out target is missing from the controlled register. |
| Current-year forecast as FY input | REV_FCST_2026_5_7_2026_YOS | No row for the internal handoff | Vintage convention and internal handoff both need recording. |
| Process basis | Forecast only | Two rows carry Actual basis | There may be an actuals process not covered by the flowchart. |
| Future-year summary line | Closing line describes the output as Current Year Revenue Forecast | n/a | Appears to be drafting carry-over; confirm intended wording. |
Discovery standing: synthesis of the Revenue forecast flowchart and 28 Revenue FP&A rows in the Process & Source Discovery Register. No validated as-of date is recorded for this group; access and migration are “Not Assessed” and multiple governance fields are blank.
Reserved for the governed fact, forecast and decision experiences that will sit on top of the certified data foundation.
The intended direction is guided intelligence grounded in governed facts, repeatable forecasts, explicit assumptions and human judgment. This placeholder intentionally contains no invented KPI, forecast, decision feed or AI capability.
This section will point to the future support / ticketing system when that destination is available and approved.
No ticket URL, owner, SLA or routing logic was supplied, so this hub does not invent one. Add the approved destination here when it exists.