Documents Library
Upload, search, view and retire the employer's configuration documents — PDF, Word, Excel, CSV, text — extracted together and read whole on every proposal; shared with Athena for Admins.
AI-Powered Configuration — From the Client's Documents to Committed Rows
Athena IQ reads the employer's documents and proposes the configuration, node by node. A consultant approves and commits.
Upload the benefit guide, the rate sheet and the blueprint questionnaire. Open a node — access controls, providers, plan types, salary groups, health plans, cost rules. Athena IQ proposes the rows that node should contain, each with a rationale that cites the document and a confidence, after checking what already exists and what the parent nodes allow. You select, approve and commit through the same create action the screen uses. Nothing is written until you do.
Rationale + citation + confidence per row
Parents before children
Nothing written until commit
Insert-only audit
Reimagining Benefits Configuration
"Implementation used to mean a consultant reading a sixty-page benefits guide and typing it into forty screens in the right order. AI-Powered Configuration reads the guide instead — and the rate sheet, the memo, the questionnaire — then proposes each node's rows with the sentence in the document that justifies them. The consultant still decides every row, still approves, still commits. What changes is what they spend their day on: judgement, not transcription."
Upload Documents
The library Athena IQ reads
Open a Node
Page guide, parents, existing rows
Athena IQ Proposes
Rows, rationale, citation, confidence
Approve & Commit
The screen's own create action
Audit & Download
Every status change, the approved blueprint
1
document library, read whole on every proposal — not just the file you have open — so a rule in the memo is not missed because you were reading the guide
0
rows written by a proposal or an approval — the live table changes only when you commit, through the node's normal create action
3
filters after the model answers: code length and format, parent membership, already exists — anything failing them is dropped before you see it
7
audit actions, insert-only — created, approved, rejected, committed, commit failed, reset, updated — each with who and when
Working flow
Who Clicks What, in Order
The consultant workflow as it runs today on the blueprint — who does what, in order, and the rule the platform enforces at each step.
| # | Who | What they do | What the platform enforces |
|---|---|---|---|
| 1 | Consultant | Uploads the employer's configuration documents — guides, rate sheets, memos, the questionnaire — to the Documents library; searches, views, retires them. | Only readable documents in the accepted types count; retired documents leave the library; extracted text is cached about thirty minutes. |
| 2 | Consultant | Opens the blueprint, picks the Access Control and the date range in the header. | Most child nodes require an Access Control first; the Access Control node itself proposes the codes and needs none; the plan year on approvals comes from the start date. |
| 3 | Consultant | Opens a node from the table of contents; the page guide appears. | The page guide is written from the approved field help for that form and cached per node; a refresh replaces it; no documents are needed for it. |
| 4 | Consultant | Clicks Athena IQ. | The platform extracts every readable document, loads the field definitions, the rows already in the live table, and the parent codes — from the latest pending or approved proposal for the parent first, otherwise the live table. |
| 5 | Model | Proposes rows in business language with a rationale that cites the document, a reference and a confidence; may say it cannot extract, or that everything documented already exists. | Invalid output is an error, not a guessed table; the server then drops rows that break code length, reference an unknown parent, or already exist. |
| 6 | Consultant | Reviews each row — values, rationale, reference, confidence — selects the ones to keep, or retries with a note that overrides the instruction. | Rationale, reference and confidence stay on the row as review fields; they are not written to the configuration. |
| 7 | Consultant | Approves the selected rows. | A stored proposal for this node and Access Control, status approved; an uncommitted proposal is overwritten with a warning; a committed one is never overwritten — a new proposal is created. |
| 8 | Consultant | Commits. | The node's create action runs once per selected row; a duplicate or overlapping date is skipped; any other error stops the loop, shows the message and marks the approval failed; success marks it committed. |
| 9 | Reviewer | Reviews the audit screen — approve, reject or reset a proposal; see counts. | Approve and reject only from pending; reset only after a rejection or a failed commit; a committed proposal cannot be deleted; every change is an insert-only audit row. |
| 10 | Consultant | Downloads the approved blueprint. | HTML documentation built from the latest approved or committed payload per node, optionally filtered to one Access Control — a document, never a write. |
One Node, Five Stages
Follow a consultant building a client's medical plans — from the document library to committed rows and the downloadable blueprint.
The library Athena IQ reads — all of it, every time
The consultant uploads what the client sent: the 2027 Benefits Guide, the medical rate sheet, an eligibility memo, the blueprint questionnaire. PDF, Word, Excel, CSV and text are extracted; unreadable files and empty extracts are skipped. When Athena IQ later runs on any node, it reads the whole library — not just the file the consultant has open — so the waiting-period rule in the memo is not missed while building plans from the guide. The same library is the employer-document source for Athena for Admins.
What the stage does
- Upload, search by file name or uploader, view, retire — newest first
- Statuses saved, active, uploaded, approved all count as readable; retired documents leave the library
- Extracted text is combined and cached for about thirty minutes; a change reaches Athena IQ after that
- Large libraries are capped in total text so a proposal stays focused
Why it matters
One upload serves every node — and the admin assistant too.
Upload the rate sheet before running cost rules; the proposal can only cite what is in the library.
Open a node — the page guide, the parents, the rows already there
The blueprint is the configuration narrative: a table of contents of nodes in dependency order — basic settings, groupings, plan attributes, employee criteria, then the plans. The consultant picks the Access Control and the plan-year dates in the header and opens node 5.1, Health plan general data. A page guide appears, written from the approved field help for that form — what it is, what to create, what it affects, when to update it — and cached until someone refreshes it. Behind the scenes the platform already knows what this node needs: plan types, plan statuses and providers as parents, and the two health plans that already exist in the live table.
What the stage does
- Nodes in order: access controls → currencies, providers, line codes, reason codes → groupings → plan types and statuses → parameter, salary, age, seniority groups → health, insurance, savings plans
- Page guide from approved field help, per node, cached; refresh replaces it
- Reference nodes — country groups, currency groups, plan categories, calculation methods — are explained, not proposed
- Parents come from the latest pending or approved proposal first, then the live table — so a child node can be built on an approved parent before it is committed
Why it matters
Order and dependencies are enforced by the blueprint, not remembered by the consultant.
Most nodes need an Access Control chosen first; the Access Control node is where the codes themselves are proposed.
Athena IQ proposes — and the server throws away what doesn't fit
The consultant clicks Athena IQ. The platform extracts the whole library, loads the eleven field definitions for this form, the two plans already in the live table (so the model is told not to repeat them), and the parent codes — plan types and statuses from their approved-but-uncommitted proposals, providers from the live table. The model returns rows in business language: a plan code, names, type, provider, COBRA relevance, pre-tax, plus a rationale that cites the document, a reference and a confidence. Then the server filters: codes too long, parents not in the list, rows that already exist are dropped. If nothing survives and the model gave no reason, the server writes one — everything documented is already configured, or the documents did not support a new row.
What the stage does
- Rationale in business language with the document and page; confidence as a review field, never a configuration value
- Retry with a note: the consultant's instruction is placed above the documents and overrides them
- Access controls: as few as the documents support, short codes, twenty-character descriptions, low-confidence proposals withheld
- Invalid model output is an error the consultant sees — never a guessed table
Why it matters
The consultant reviews three justified rows, not a sixty-page guide.
Names filled from reference tables — a country name from the country group, not from the model.
Approve, then commit — through the screen's own create action
The consultant ticks HDHP Plus and PPO Standard, leaves HMO Select for the client to confirm, and approves. That stores a proposal for this node and Access Control — one record holding the approved rows, status approved, plan year from the header. If an uncommitted proposal already existed for the node it is overwritten, after a warning; a committed one is never overwritten. Then Commit: the node's create action runs once per selected row, exactly as if the consultant had typed the row on the screen. A duplicate or an overlapping date is skipped and the loop continues; any other error stops it, shows the message, and marks the approval failed. Success marks it committed.
What the stage does
- Approve stores the selected rows as a proposal; nothing is written to the configuration yet
- Commit uses the same create action and validation the screen uses — codes normalised where the screen requires it
- Duplicates and date overlaps are skipped; a hard error stops the loop and leaves earlier rows in place
- A child node may use an approved parent before it is committed — the blueprint keeps the order
Why it matters
The live table is written by the same code as manual entry — nothing the screen would refuse gets in.
One approval is one status for the whole node; the audit shows which rows were created before a failure.
Audit and download — the review log and the approved blueprint
The audit screen is the review log of AI proposals: every status change is an insert-only row — created, approved, rejected, committed, commit failed, reset, updated — with who and when, plus counts. A reviewer can approve or reject a proposal that is still pending, reset one that was rejected or whose commit failed so it can be tried again, and cannot delete anything that has been committed. It is not a second copy of the live benefit tables; it is the record of what the AI proposed and what people decided. When the client wants documentation, Download approved blueprint builds an HTML document from the latest approved or committed payload per node — filtered to one Access Control if wanted — and returns it. It creates nothing.
What the stage does
- Insert-only audit: seven actions, each with actor and timestamp; counts for the review dashboard
- Approve and reject only from pending; reset only after rejection or a failed commit
- A committed proposal cannot be deleted; approval notes are kept with the record
- Download: the newest approved or committed payload per node, injected into the blueprint documentation template
Why it matters
"Who approved this plan, from which document, and when?" has an answer.
The blueprint document is generated from the same payloads the audit tracks — no separate write-up to keep in sync.
Ground rules
Rules of the Blueprint
What a consultant can rely on and what an auditor can check — from the blueprint as it runs, not from a slide.
| Rule | How it behaves | Why it matters |
|---|---|---|
| Nothing written until commit | A proposal is text; approval stores it; only Commit calls the node's create action. | The live table changes exactly when a person says so. |
| The screen's own create action | Commit runs the same action and validation as typing the row by hand, once per row. | Nothing the screen would refuse gets in through the AI. |
| Parents before children | Each node loads the parent codes it may reference — from the latest pending or approved proposal first, then the live table — and the server drops rows that reference anything else. | A child never points at a parent that does not exist or is not on its way. |
| Never repeat what exists | Rows already in the live table are shown to the model as off-limits, then filtered again after it answers. | No duplicate plans, groups or codes. |
| Codes fit the screen | Code length and format are enforced per node — access-control codes at most three characters, plan codes up to four, descriptions trimmed to their field length; names filled from reference tables, not the model. | A proposal is always something the screen can hold. |
| Rationale, reference, confidence are for review | They stay on the proposed row for the consultant and the auditor; they are not written to the configuration. | Explainable without polluting the tables. |
| Whole library, thirty-minute cache | Athena IQ reads every readable document in the library, not the file you have open; a change is visible after the cache expires. | A rule in the memo counts while you build from the guide. |
| Commit is honest about failure | Duplicates and overlapping dates are skipped; any other error stops the loop, keeps earlier rows, and marks the approval failed for a reviewer to reset. | No silent half-writes. |
| Reference nodes are explained, not proposed | Country groups, currency groups, plan categories and calculation methods get a page guide and an explanation; the modal says no approval or commit is needed. | The AI describes reference data; it does not invent it. |
| Insert-only audit | Every status change is a new audit row with actor and time; committed proposals cannot be deleted. | Who approved which row from which document, forever. |
Core Capabilities of AI-Powered Configuration
Six pieces on the blueprint — documents, guide, proposals, approval, audit and download — with the node catalog behind them.
Page Guide per Node
A short administrator guide for each node — what it is, what to create, its impact, when to update — written from the approved field help and cached until refreshed; no documents required.
Athena IQ Proposals
Rows for the node from the documents, field definitions, existing rows and parent codes — each with a rationale that cites the document, a reference and a confidence; server-filtered for code length, parents and duplicates.
Approve & Commit
Select rows, approve into a stored proposal per node and Access Control, commit through the node's own create action with skip and stop rules — and let child nodes build on approved parents.
Insert-Only Audit
Created, approved, rejected, committed, commit failed, reset, updated — each with actor and time; reviewers approve, reject or reset; committed proposals can never be deleted.
Approved Blueprint Download
HTML documentation generated from the latest approved or committed payload per node, optionally for one Access Control — the client's configuration narrative, produced from the same records the audit tracks.
Workbook Configuration vs. AI-Powered Configuration
Most implementations still move a client's documents into a workbook and the workbook into forty screens by hand. Here is what changes — and what deliberately does not.
| Step | Workbook and manual entry | AI-Powered Configuration |
|---|---|---|
| Reading the client's documents | A consultant reads sixty pages and fills a workbook. | Uploaded once; read whole on every node's proposal. |
| Knowing the order | Tribal knowledge — which table before which. | The blueprint — nodes in dependency order, parents loaded before each proposal. |
| Drafting the rows | Typed from the workbook. | Proposed with a rationale, a document reference and a confidence; duplicates and bad references filtered out first. |
| Deciding | Implicit — whoever typed it decided it. | Explicit — select, approve, commit, each recorded with who and when. |
| Writing the table | Screen by screen, row by row. | The same create action, run per approved row, with the screen's validation. |
| When it goes wrong | Found in testing, weeks later. | Skipped or stopped at commit, marked failed, reset by a reviewer. |
| The documentation | A separate write-up, soon out of date. | Downloaded from the approved payloads — always the configuration that was actually approved. |
| Who decides | The consultant. | Still the consultant. The AI proposes; nothing is written until a person commits. |
The node catalog
Node by Node, Parent Before Child
The blueprint proposes rows for every configuration node that has one, in the order the platform needs them. Reference nodes are explained instead. Insurance and savings plans follow the same assist, guide, approve and commit shape as health plans.
- Basic settings — access controls (the codes themselves, as few as the documents support), currencies per access control, providers, insurance line codes, maintenance reason codes
- Groupings — cost, credit, coverage, employee-contribution and employer-contribution groupings, each a code and a description under the access control
- Plan attributes and employee criteria — plan types and statuses; parameter groups, then salary, age and seniority groups that reference them
- Health plans — general data, options, dependent coverage, limits by dependent type, cost rule variants, cost rules with the plan-year dates, and the electable plan assignments
- Explained, not proposed — country groups, currency groups, plan categories, calculation methods (Athena IQ says which proration method fits; it does not insert one)
Why did you recommend a salary-and-age variant for HDHP Plus?
Athena IQ · from the documentsThe medical rate sheet's "HDHP Plus" tab lists employee contributions in a grid of three salary bands by four age bands, and the Benefits Guide (page 13) says contributions "vary by salary band and age". A variant with salary and age dimensions is the smallest one that can hold that grid. It references parameter group 0001 and the salary groups you approved on node 4.2 — those are approved but not yet committed, which the blueprint allows.
Sources: Medical rate sheet 2027 — tab HDHP Plus · 2027 Benefits Guide p.13 · Node 4.2 salary groups — approved
Open the proposalShow the rate grid
Good — commit it.
Athena IQCommitting is yours to do: select the rows, Approve, then Commit on the node — the platform runs the cost-rule-variant create action once per row and records who committed it. I only propose.
Go to node 5.5
Ask about this proposal…
Why Implementation Teams Choose AI-Powered Configuration
Judgement, Not Transcription
The consultant reviews justified rows instead of retyping a guide — the day goes to deciding, confirming with the client, and committing.
Every Row Cites Its Source
Rationale, document reference and confidence on each proposal, kept for review and audit — the client's own words behind the client's configuration.
Order Enforced by the Blueprint
Parents before children, existing rows never repeated, codes that fit the screen — the dependencies live in the tool, not in a consultant's memory.
Written by the Screen's Own Code
Commit is the same create action as manual entry, with the same validation — the AI cannot put anything into a table that the screen would refuse.
An Audit Trail from Day One
Who proposed, approved, committed, rejected or reset — insert-only, with the approved blueprint downloadable as documentation at any point.
Configuration for Any HRIS
The rows it helps commit serve employees arriving from SAP SuccessFactors or any other HRIS Benefits Reimagined syncs with — one configuration model underneath.
Where It Lives in the Configuration Console
AI-Powered Configuration is the Athena Admin menu of the configuration console: the Documents library, the Blueprint, and the Audit screen. The blueprint's node registry decides which nodes offer Athena IQ, which are informational, and which columns the review table shows; a node not in the registry says so rather than guessing. The overview page is a go-live checklist for reference.
- Documents — the employer configuration library; the source for proposals and for Athena for Admins' document answers
- Blueprint — table of contents, node documentation, page guide, Athena IQ, approve, commit, status badges, download
- Audit — the insert-only review log with reviewer approve, reject and reset, and counts by status
- Overview — a go-live checklist and callouts, kept as reference material
- Every configuration screen — Athena for Admins answers questions about the field while the blueprint proposes its rows
Four Stories, End to End
Four moments from one implementation, each traced through the flow above.
The access controls the documents support
On node 1.1 the model proposes one US access control — the questionnaire describes one administration, one payroll, one set of plans — and withholds a second, low-confidence proposal for a regional entity. The server keeps the code (three characters or fewer, not already present, a valid country group), trims the description, and the consultant approves and commits.
Building on an approved parent
Plan statuses are approved but not yet committed when the consultant opens Health plan general data. Athena IQ still proposes the plans, referencing those statuses, because parents come from the latest approved proposal first. The consultant commits the parent later; the blueprint kept the order either way.
The half-failed commit
On cost rules, the third row overlaps an effective date and is skipped; the fifth hits a hard error. The loop stops, the message is shown, the approval is marked failed, and the four created rows stay. The reviewer resets the approval, the consultant fixes the row, and the next commit skips the four that already exist.
The blueprint the client can read
Before go-live the consultant downloads the approved blueprint filtered to Access Control US: twenty-four nodes of approved and committed payloads, rendered as documentation. Nothing was created by the download — it is the same record the audit screen tracks, in a form the client's benefits manager can read.
Bring One Client's Documents and Watch a Node Get Built
A benefits guide, a rate sheet and a memo — de-identified is fine. We'll upload them, open the health-plan node, run Athena IQ, show you what the server filtered out and why, approve two rows, commit, and download the blueprint.
Nothing written until commit
Citation on every row
Screen's own create action
Insert-only audit
AI-Powered Configuration FAQs
A consultant workflow in the configuration console. You upload the employer's configuration documents — benefit guides, rate sheets, memos, the blueprint questionnaire — open a node of the configuration blueprint, and ask Athena IQ for the rows that node should contain. It reads the documents, the field definitions, the rows already configured and the parent nodes, and proposes rows with a rationale that cites the document. You select, approve and commit; nothing is written until commit.
No. A recommendation becomes a stored proposal when you approve it, and the live table changes only when you commit — and commit calls the same create action the screen uses when you type the row by hand. Athena IQ never inserts into a configuration table.
Basic settings (access controls, currencies, providers, insurance line codes, maintenance reason codes), groupings (cost, credit, coverage, employee and employer contribution), plan attributes (plan types, plan statuses), employee criteria (parameter, salary, age and seniority groups) and health plans (general data, options, dependent coverage, limits by dependent type, cost rule variants, cost rules, plan assignments). Insurance and savings nodes follow the same shape. Reference data — country groups, currency groups, plan categories, calculation methods — is explained, not proposed.
Before the model is asked, the rows already in the live table are loaded so it is told not to repeat them, and the parent codes it may reference are loaded — from the latest pending or approved proposal for that parent first, otherwise from the live table. After the model answers, the server drops any row whose code is too long, whose parent is unknown or that already exists. Invalid output is an error, never a guessed table.
The proposed values, a rationale in business language, the document reference and a confidence. Rationale, reference and confidence are review fields; they are not written to the configuration at commit. Where the model cannot extract anything, or everything documented already exists, the response says so and why.
Commit runs the create action once per selected row. A duplicate or an overlapping date is skipped and the loop continues; any other error stops the loop, shows the message, and marks that node's approval as failed. Rows created before the failure stay created — the approval is one status for the node, not a per-row ledger — and a reviewer can reset the approval and try again.
Yes, and it is insert-only: created, approved, rejected, committed, commit failed, reset, updated — each with who and when — on the audit screen, which also lets a reviewer approve, reject or reset a proposal. The approved blueprint can be downloaded as HTML documentation built from the latest approved or committed payload per node.
No. It reads the platform's own configuration model and your uploaded documents. The configuration it commits serves employees arriving from SAP SuccessFactors or any other HRIS Benefits Reimagined syncs with.
The Documents Propose. The Consultant Commits.
Configuration built from the client's own words, in the order the platform needs, written by the screen's own code, with an audit trail from the first proposal to the downloaded blueprint.