Effective-Dated, Bitemporal Model
One schema for enrollment, payroll, carrier, compliance and communication records on SAP HANA or PostgreSQL, with business time and system time on every row.
Analytics Strategy: Decisions First, Charts as Evidence
One effective-dated model of enrollment, payroll, carrier and compliance records. One Analytics Context that every KPI, chart and question runs against. AI that interprets what the engine computed — and never computes on its own.
Benefits Reimagined treats analytics as part of the record, not a report exported from it: the workspaces that replace legacy SAP benefits reports, the spotlights that rank what needs attention and the explanation behind every number all read the same as-of-dated data. It works the same whether a record arrived from SAP SuccessFactors in real time or from Workday, UKG, ADP or Dayforce through HRIS Sync.
Decision-firstOne Analytics ContextAs-of dated · bitemporalThe LLM interprets · Python calculatesAny HRIS record
Decision-First Analytics on One Effective-Dated Model
Most benefits analytics starts with a chart and hopes a decision follows. We start with the decision — the waive rate that needs a campaign, the offer threshold that needs a check, the invoice that needs a match — and put the evidence one click behind it. To make that honest, every figure is as-of a date, pending is never counted as enrolled, employee and employer cost are never blended, and a correction never overwrites what was true before. Then AI does one job: it explains what the engine computed.
ModelOne effective-dated schema, two clocksAskOne context every tile subscribes toComputePython calculates; the database aggregatesExplainThree models, separated on purposeAny HRISSame model for SAP and every other source
1Analytics Context per workspace — every KPI card, chart, table and Athena question subscribes to it
3intelligence models kept apart on purpose: AI Query plans, the ML Engine ranks and forecasts, AI Insight explains
2clocks on every record — business time and system time — so a retro correction adds a version and keeps the original
5minimum cohort size (configurable) before any breakdown is shown, applied inside the orchestrator
Working Flow — From a Benefits Question to the First Table
The strategy is only as real as the catalog underneath it. Benefits Reimagined publishes a complete analytics catalog of its data model — every entity, its grain, its keys, its as-of rule, its measures and the module that writes it. This is how an analyst uses it, question by question; the last column is the rule that stops the wrong answer.
| # | The question · start here | How the catalog answers it | The rule that stops the wrong answer |
|---|---|---|---|
| 1 | “Who is in which Access Control or program?” Benefits eligibility record (infotype 0171) | Start from the eligibility record, join the employee master and the Access Control | As of a date — the eligibility record keeps history, so a report date picks one slice per person |
| 2 | “How many people have medical right now?” Health plan elections (0167) | Join the eligibility record, the plan's general data and the dependent coverage rows | One row per person and plan where the report date sits inside the validity dates; a pending (locked) row is a decision — enrolled or not — made once and applied everywhere |
| 3 | “Employee vs employer cost?” Elected cost on the election row | Compare with the configured cost-rule variants for the rate that could apply | Configured and elected are two layers; the cost-variant code on an election is a code, never money |
| 4 | “401(k) deferral vs what payroll took?” Savings plan election vs payroll cumulative amount | Join on the plan's wage type | Three layers of money — configured rule, elected amount, payroll actual — reconciled in that order |
| 5 | “How is open enrollment moving?” Offers → cart → elections → signed attestation | Each stage is a different table; the drop-off is the gap between them | The cart is a draft; the election rows are the receipt — a cart is never counted as an enrollment |
| 6 | “Life events this month?” Adjustment-reason record (0378) | Join the adjustment reasons and the workflow instances | A qualifying life event writes its own record; it is not an enrollment |
| 7 | “Evidence of insurability overdue?” Insurance plan elections | EOI required, provided and group flags, joined to the EOI submissions | Overdue is a date comparison on the election, not a status guess |
| 8 | “Ticket queue and conversion?” Service tickets | Join cases, priorities and SLA configuration | Ticket, document, note and case statuses are different enumerations — one global “open” bucket is wrong |
| 9 | “Documents outstanding? Direct-bill receivables? Invoice vs expected?” Uploaded documents · direct-billing items · vendor invoice facts | Dependents and verification cases; billing cases and payments; ReVerge and Integration Center reconciliation | Soft-deleted rows — cancelled tickets, deleted documents, deleted dependents — are always filtered |
| 10 | “Who was offered a plan but did not take it?” Benefit program + eligibility + offers, minus elections | The offer output carries the eligibility messages | Offered is configured; taken is elected — the join key is what keeps the two honest |
One Question, Five Layers
Follow “what is driving our coverage gap?” from the record it is computed on to the explanation Athena gives — and see why the same question gets the same answer for an SAP entity and a Workday entity.
One effective-dated model is the strategy.
Enrollment, eligibility, deductions, carrier confirmations, invoices, compliance facts and communications live in one schema on SAP HANA or PostgreSQL, keyed by business time and system time. That is what makes a benefits number defensible: an eligible-enrolled rate is computed as of a date, a pending election is its own state, a cost-rule variant is never mistaken for money, and a cart is a draft until the record is the receipt. Analytics reads the tables the modules write — no nightly extract, no second copy.
What the model guarantees
- As-of dating on every point-in-time figure
- Pending is its own state — never counted as enrolled
- Employee and employer cost kept apart, never blended into one figure
- A retro correction adds a version; the original record stays
- Small-cohort suppression before any breakdown leaves the engine
Why it matters
A figure you can date, source and reproduce is a figure you can put in front of an auditor or a CFO.
Elasticsearch and Kibana index the same records for operational dashboards, search and audit — the model is one; the surfaces are many.
One Analytics Context — every click updates one state.
A workspace holds one context: which analytic, which date range, which filters, which selection. Every KPI card, chart, table and Athena question subscribes to it. Clicking a row in a table does not navigate anywhere — it writes one dimension into the context, and everything downstream re-runs through the same query endpoint. Add a metric, a dimension or a model behind the orchestrator and the React screens keep rendering the same result shape.
What lives in the context
- The analytic, the date range, the filters (department, location, plan type…) and the current selection
- One request to one analytics query endpoint — not a route per cut of the data
- Every component subscribes; none filters on its own
- Ask Athena carries the same context into its question
Why it matters
Cross-filtering without per-chart logic means a new question is configuration, not a front-end release.
The metadata-driven renderer — Python publishing the dimensions, metrics and components a workspace exposes, React rendering whatever arrives — is the target state for every dashboard.
Python calculates; the database aggregates at source.
The Analytics Orchestrator turns a context into work: a KPI engine, statistics, forecasts, anomaly detection, segmentation and risk scores. It never pulls a raw table — SAP HANA or PostgreSQL filters and aggregates at source and returns what the components asked for, scoped to the calling user's role-based permissions. Cohorts below the configured minimum are suppressed before anything leaves the orchestrator.
What the orchestrator runs
- KPI engine and statistics with one definition per metric, shared by every workspace
- ML Engine — forecast, anomaly, segmentation, prediction; Python models, not a language model
- Permission scoping and cohort suppression on every call
- Execution logged with the context that produced it
Why it matters
Numbers are computed once, the same way, for every screen — so a KPI on the dashboard equals the same KPI in a report.
The ML boundary is explicit: a model may predict a full-time transition or a threshold breach; it never sets a legal status or a filing figure — those stay deterministic in the engines that own them.
Three models, separated on purpose — ask, rank, explain.
AI Query turns a question into a structured analytics plan — never raw SQL, never a direct answer — that the orchestrator executes. The ML Engine ranks, matches, forecasts and detects. AI Insight explains a metric the engine has already computed, naming the records behind it. Kept apart, the one that answers cannot score, the one that scores cannot explain, and none of them can write. That separation is what lets BR Spotlight, BR Insights and Athena share one architecture without sharing one failure mode.
How the models divide the work
- AI Query → an analytics plan; powers Athena and IntelliSearch
- ML Engine → rank, forecast, detect; powers BR Spotlight, IntelliSuggest and IntelliMap
- AI Insight → an explanation with sources; powers BR Insights and every “why this match”
- Every call logged with model, version and prompt template
Why it matters
The LLM interprets. Python calculates. The database supplies the data.
Prompts, models and providers are configuration — inventoried and evaluated in the compliance engine under the NIST AI Risk Management Framework.
The same model for SuccessFactors and every other HRIS.
The canonical data model is HRIS-neutral. SAP SuccessFactors records arrive in real time through OData and Intelligent Services Center; Workday, UKG, ADP, Dayforce and Paycom records arrive through the same HRIS Sync control plane, mapped to the same fields with the same provenance. A participation rate, an ACA employee-month or a coverage gap is computed identically for an SAP entity and a Workday entity — and a multi-entity organization sees them side by side in one workspace.
How sources meet the model
- SAP SuccessFactors: 140+ mapped fields, real time, embedded sign-in
- Other HRIS: the same fields through HRIS Sync, with the mapping ledger as evidence
- One workspace across entities that run different HRIS platforms
- Role-based permissions resolved from each HRIS identity through SSO
Why it matters
You choose the HRIS; the analytics do not change.
Legacy SAP benefits reports are replaced by governed workspaces that serve non-SAP entities too — see Essential Insights.
Rules of the Model — What the Catalog Enforces
Eight design rules, written into the catalog and followed by every analytics surface on the platform — the workspaces, Essential Insights, Athena's allow-listed reads and Ad-Hoc Reporting alike.
| Rule | How it works | Why it is there |
|---|---|---|
| Every people metric starts on the spine | Employee master + the benefits eligibility record, as of the report date on both — then the Access Control and program groupings, then whether the plan was even offered | Two reports that start on the spine agree; two that do not, will not |
| As-of dating, always | Most HR and benefit tables keep history; a person can have three rows for one plan in a year. Point-in-time means one row per person and plan where the report date sits inside the validity dates; activity means rows whose start date falls in the period | Counting without an as-of date inflates enrollment — the number-one analytics bug |
| Pending is a decision, not an accident | A locked row means pending, often awaiting evidence of insurability; whether pending counts as enrolled is decided once, per metric, and applied everywhere | The tile, the export and the Athena answer cannot disagree about pending |
| Configured is not elected | Configuration tables say what could happen; election rows say what did. They join on a key or they do not mix | Analytics that blend the two without a join key lie |
| Cart is not enrollment | The cart is a draft; the election rows are the receipt; the signed attestation is the proof. The drop-off is the gap between them | The open-enrollment funnel is real stages, not one status field |
| Money has three layers | The configured rule, the elected amount and the payroll actual — reconciled in that order by BR ReVerge and the Integration Center; the cost-variant code is never money | A premium on a chart came from a money field, or it is not on the chart |
| A person-month bridge for anything monthly | Employee × calendar × the eligibility record as of month-end; coverage, cost and ACA facts hang off it | Two Access Controls are never mixed in one month |
| Status enumerations are per module | Tickets, documents, notes and cases each have their own status set; soft deletes — cancelled, deleted flags — are always filtered; similarity vectors are never summed or grouped | One “open” bucket across modules would count the wrong things |
Core Capabilities of the BR Analytics Architecture
Built for benefits numbers — as-of rates, pending states, split costs, employee-months — not a generic BI layer pointed at an export.
One Analytics Context & Endpoint
Every KPI, chart, table and Athena question subscribes to one state and one query endpoint; a row click re-runs everything downstream.
Analytics Orchestrator
A Python KPI engine, statistics and ML models computing on aggregates the database returns — one definition per metric, shared by every surface.
Three Separated Intelligence Models
AI Query plans, the ML Engine ranks and forecasts, AI Insight explains; the one that answers cannot score, and none of them can write.
Governance Inside the Engine
Role scoping and small-cohort suppression on every call, every query logged with its context, prompts and models inventoried under NIST AI RMF.
Operational Dashboards & Search
Elasticsearch and Kibana over the same records for operations, compliance and audit, with cross-event reporting across OE, life events, hires and terminations.
The Analytics Catalog — Every Table, Its Grain, Its Rule
The strategy is documented at the table level. The catalog is generated from the platform's own schema and cross-checked against the backend code that reads each table, so it says which module writes a table, which read it, and how to date it — for benefits analysts, BI engineers and module developers at once.
880entities in the data model — 860 tables and 20 projections — every one a catalog article: identity, purpose, grain, lifecycle, analytics use, joins, pitfalls, field dictionary, module usage
662entities confirmed in use by backend modules; the remaining 218 are marked schema-only and checked with a row count before any warehouse drops them
28domains, from enrollment and elections through ACA, COBRA, billing, payroll, Communication Hub, workflow, intelligence and compliance
1join spine — employee master plus the benefits eligibility record, as of the report date — that every people dashboard starts on
- 24Enrollment & elections
- 25Employee & HR master
- 25Benefits configuration — foundation
- 80Benefits configuration — plans
- 32Flexible administration & programs
- 3Life events
- 55ACA
- 13COBRA
- 25BR Resolve / ISD
- 18Documents
- 12Direct billing
- 16Carrier billing & GL
- 41Payroll / BR ReVerge
- 32Integration Center & reconcile
- 48Communication Hub
- 23Workflow & business rules
- 26Security / RBP
- 55Intelligence / Athena
- 10Dependent verification
- 6QMCSO
- 33Compliance
- 8Content & org updates
- 41Purge / audit / transport / sync
- 13Ad-hoc / metadata / reports
- 13User prefs / admin apps
- 28Benefits configuration — other
- 44Other / shared
- 131Schema-only (kept for confirmation)
The analytics surfaces already built on the catalog — and the two that read it directly:
- Costs & contributionsBR Reports
- Resolve dashboard tilesBR Resolve
- Direct billing KPIsBR Direct Billing
- Employee document analyticsDocument Center
- Essential Insightsper-module chart actions
- Athena allow-listed readsa curated set of 28 tables
- Ad-Hoc Reportingthe published table catalog
Counts are from the September 2026 generation of the catalog; the catalog is regenerated whenever the schema changes, and a screen label never outranks the table name.
Report Exports vs. the BR Analytics Strategy
Most benefits analytics is an export, a pivot and a BI tool bolted on afterwards. Here is what changes when the analytics are part of the record.
| Moment | Exports and BI bolt-ons | Benefits Reimagined |
|---|---|---|
| “How enrolled are we?” | A daily count grid, exported and reconciled by hand. | As-of rate computed on the record, with pending shown separately. |
| Filter by location | Each chart carries its own filter logic; tiles drift apart. | One context — every tile re-runs against the same state. |
| “Why did it move?” | Someone builds a pivot and a theory. | AI Insight explains the computed figure and names the records behind it. |
| A retro correction lands | Last month's report now disagrees with itself. | Bitemporal — the original and the correction both survive. |
| A cohort of three | Shown, and a privacy problem. | Suppressed below the configured minimum, inside the engine. |
| Add a metric | A BI ticket and a release. | Configuration behind the orchestrator; screens unchanged. |
| A non-SAP entity | A second report pack from a second system. | Same workspace, same model, through HRIS Sync. |
Athena on every workspace
Ask Any Dashboard What, Where, Why and How
Every BR analytics workspace carries Athena in place, scoped to the context the screen is showing. AI Query plans the read, the orchestrator runs it, AI Insight narrates the result — and Athena hands the next step to the module that owns it.
- “What is our eligible-enrolled rate as of July 1?” — the as-of figure, with pending shown apart
- “Where is the coverage gap concentrated?” — a breakdown that honours cohort suppression
- “Why did the HDHP share rise?” — the AI Insight explanation with its sources
- “How do I act on it?” — a Communication HUB campaign or a BR Resolve case drafted, never sent
- “Show me the same for our Workday entity” — the same question, the same model, a different source
What's driving the 4.8% coverage gap — is it a data problem or a real one?
Athena · from the workspace contextAs of 09/01 the gap is 1,214 eligible employees with no active medical election. 862 (71%) are Plant 2 hourly and have waived in each of the last three months. 267 (22%) joined in the last 60 days and are still inside their new-hire window — not a gap yet. 85 sit in the sync exception queue with a missing hire date from the HRIS, which is a data problem. Cohorts under five are not shown.
Sources: Benefits Participation · as of 09/01 · HRIS Sync · exception queue · Enrollment Intelligence · new-hire window
Open exception queueShow Plant 2 trend
Draft a campaign for the 862 and flag the 85 to the sync team.
AthenaDrafted, nothing sent: a plan-comparison campaign in Communication HUB targeted at Plant 2 hourly waivers, and a BR Resolve case to the integration team listing the 85 records with their exception codes. Both wait for your approval.
Review campaignOpen case draft
Ask about any metric on this workspace…
Why Benefits and Finance Leaders Choose the BR Analytics Approach
Decisions Before Charts
Workspaces open on what needs deciding; the evidence sits one click behind it.
Numbers You Can Date
Every rate is as-of a date, every correction keeps the original, every cohort is large enough to show.
One Context, No Drift
A KPI on the dashboard equals the KPI in the report, because both came from one definition and one state.
The LLM Never Calculates
AI Query plans, the ML Engine scores, AI Insight explains — and none of them can write to the record.
Governed by Design
Role scoping, cohort suppression, query logs and a NIST AI RMF inventory are inside the engine, not a policy beside it.
Same Answers on Any HRIS
SuccessFactors in real time, every other HRIS through HRIS Sync — one model, one workspace, one set of definitions.
Where the Strategy Shows Up — Workspaces, Spotlights, Explanations
The strategy is not a slide; it is the reason the rest of the Analytics family behaves the way it does. Essential Insights are the governed workspaces built on the model. BR Spotlight is the ML Engine and the rules ranking what needs attention. BR Insights is the AI Insight model explaining a number. Chatbot Analytics reads the interaction log Athena writes. Each is one surface over the same context.
- Essential Insights — Enrollment Intelligence, Benefits Participation, Demographics and ACA Intelligence, replacing legacy SAP benefits reports for SAP and non-SAP entities alike
- BR Spotlight — what needs attention today, ranked by the ML Engine and rules, with an owner and an action in the owning module
- BR Insights — the explanation behind any computed metric, with the records that produced it
- Chatbot Analytics — what employees ask Athena, what was resolved in chat, and where the content gaps are
- Operational dashboards — Elasticsearch and Kibana over the same records for operations, compliance and audit
Bring One Number You Don't Trust. We'll Show You Where It Comes From.
Pick a figure your team argues about — the enrolled rate, the employer cost per head, the waive rate in one plant. We'll compute it as of a date on your own records, filter it from one context, let Athena explain it and show the log behind the answer.
As-of dated · bitemporalOne Analytics ContextCohort suppressionNIST AI RMF
Analytics Strategy FAQs
The set of decisions about where benefits numbers come from, how they are computed and who may see them. In Benefits Reimagined it means one effective-dated data model shared by every module, one Analytics Context that every screen subscribes to, a Python orchestrator that computes each metric once, and AI that explains computed results rather than producing its own.
A workspace opens on the decisions the data implies — a rising waive rate, an offer threshold at risk, an invoice that does not match — with the KPI tiles and charts as the evidence behind each one. Charts are still there; they are the second click, not the first.
Because a benefits fact is only true for a period. An eligible-enrolled rate must be computed as of a date, a pending election is not an enrollment, and a retroactive correction must not rewrite last month's report. BR stores business time and system time on every record so a figure can be reproduced exactly as it was on any date.
One state object per workspace — the analytic, the date range, the filters and the current selection. Every KPI card, chart, table and Athena question subscribes to it, and a click on a row updates it so everything downstream re-runs through one query endpoint. It removes per-chart filter logic and the drift that comes with it.
No. The AI Query model turns a question into an analytics plan; the ML Engine — Python models, not a language model — ranks, forecasts and detects anomalies; the AI Insight model explains a metric the engine has already computed. The language model interprets, Python calculates, and SAP HANA or PostgreSQL supplies the data.
Role-based permissions scope every call, cohorts under a configurable minimum are suppressed inside the orchestrator, every query is logged with the context that produced it, and every prompt, model and provider is inventoried and evaluated in the compliance engine under the NIST AI Risk Management Framework.
No. The data model is HRIS-neutral. SuccessFactors records arrive in real time and are embedded in the SuccessFactors sign-in; Workday, UKG, ADP, Dayforce and Paycom records arrive through HRIS Sync with the same fields and provenance. Metrics are computed identically for every entity, and a multi-HRIS organization sees them in one workspace.
They are replaced by governed, effective-dated workspaces — Enrollment Intelligence for Enrollment Statistics, Demographics for Employee Demographics, and Benefits Participation and ACA Intelligence alongside them. Familiar grids survive as tabs inside the new workspaces, so nothing you rely on today disappears.
Yes, at the table level. The Schema Analytics Catalog covers all 880 entities in the platform's data model — 860 tables and 20 projections across 28 domains — and each article states the table's purpose, grain, lifecycle (who writes it, who reads it, how rows end), first metrics, joins, pitfalls, a full field dictionary and the backend modules that reference it. It is generated from the schema and cross-checked against the code, and regenerated whenever the schema changes.
The two tables every people dashboard starts on: the employee master and the benefits eligibility record, both read as of the report date, which yield the Access Control and the program groupings. From there the benefit program says whether a plan was even offered, and the plan's general data supplies name, carrier and wage types. Reports that start on the spine agree with each other.
Because most HR and benefit tables keep history: one person can have three rows for the same plan across a year, and counting rows without an as-of date inflates enrollment. Point-in-time means one row per person and plan where the report date sits inside the validity dates; activity means rows whose start date falls in the period — “elections started”, not “people covered”. The same rule is why the platform keeps configured, elected and payroll-actual money apart and never charts a cost-variant code as a premium.
Decide First. Then Look at the Chart.
One effective-dated model, one context, three separated models and a person on every commit — for your SAP SuccessFactors workforce and every entity on another HRIS.