Administration for public retirement funds
A benefit estimate has to survive a member’s question, a reviewer’s sample, and the board minutes. PensionOS computes each one from posted pay periods in integer cents, then prints the salary window it chose, the formula version it used, and the arithmetic beside the result.
The platform
A fund answers to the public, to its members, to the administrators who keep the record, and to retirees who are almost never at a desk. Each one gets a surface built for them. All four read the same posted contribution ledger, so the phone, the portal, and the public estimator cannot quietly disagree with each other.
Statutory postings carry a named owner and a cadence. Plan figures cite where they came from. The benefit estimator needs no login. The fund meets its posting obligations by default instead of by memory.
Every posted paycheck, with the contribution on each row recomputed against the plan’s configured rates. Benefit estimates that print the whole calculation. Survivor options side by side. A report worth handing to a spouse.
Each pay period arrives as one contrib_v1 file and faces fifteen control checks before a single row reaches a member. Clean batches post. Anything else is quarantined with a hashed exception report and a named override.
The member’s retirement picture on a phone, with the pension figure coming from the same ledger and the same formula version the portal uses. Internal builds only today, and the section below says exactly what that means.
Every number shows its work
No one types the benefit in. It is computed through four steps, and the estimate prints all four, so a member, a reviewer, or a trustee can follow it from the last paycheck to the monthly amount without asking anyone to be trusted.
The record starts from the paychecks a member actually earned, period by period, not from a salary figure someone keyed in.
source: contribution ledgerFinal average salary is the highest run of consecutive periods the plan allows. Code picks it, and the estimate prints which window it picked and the dates on both ends. The sample fund below is configured at 60 months, which is 130 bi-weekly pay periods.
rule: highest consecutive window, per plan configA single versioned formula with one multiplier source drives all five benefit types: normal, disability, vested termination, retro DROP, and death or survivor. Change the plan config, not the code.
formula: FAS × multiplier × serviceEvery figure is carried in integer cents from the paycheck to the monthly amount, beside a visible calculation waterfall, so the same inputs reconcile the same way every time it is run.
precision: integer centsEvery line below is the arithmetic that produced the figure above it, in integer cents, in order. These are the actual rows the benefit engine emits for this member, transcribed from the running demo.
SYNTHETIC DATA Sample Municipal Employees Retirement System (SMERS) Member Jordan Avery, DEMO-2201 No real member data
formula pensionos-db-multi-benefit-2.1.0 · integer cents · 5 steps · ledger-derived FAS window
| Operator | Step | Operand | Result (USD) |
|---|---|---|---|
| Highest 130 consecutive pay periods2021-07-09 to 2026-06-19 | 2021-07-09 to 2026-06-19 | $502,450.00 | |
| Annualized average salaryx 26 / 130 pay periods per year | x 26 / 130 pay periods per year | $100,490.00 | |
| Average monthly salary/ 12 months | / 12 months | $8,374.17 | |
| Benefit percentagex 14.00 years x 1.80% = 25.20% | x 14.00 years x 1.80% = 25.20% | ||
| Total monthly benefitEstimated monthly benefit | Estimated monthly benefit | $2,110.29 |
Wide table. Scroll sideways inside it to see the operand and result columns.
Estimate only, formula version pensionos-db-multi-benefit-2.1.0, multiplier 1.80%. This calculator never issues a benefit determination; final amounts remain with the fund administrator and actuary. Every figure belongs to a fictional fund and a synthetic member.
The statement
An estimate is worth very little if the member cannot see how it was reached. PensionOS puts the salary window, the formula version, the service credit, and the arithmetic on the same page as the result, so the number can be checked at a kitchen table without a phone call to the fund office.
SYNTHETIC DATA Sample Municipal Employees Retirement System (SMERS) Member Jordan Avery, DEMO-2201 No real member data
The payroll gate
Each pay period arrives as one file and faces fifteen control checks before a single row reaches a member’s record. The two verdicts below are the reconciliation engine’s actual output on two fictional SMERS batches, transcribed from the running demo. One clears. One carries a zero-earnings contribution and an inflated withholding, so the gate quarantines it.
SYNTHETIC DATA Sample Municipal Employees Retirement System (SMERS) Two fictional payroll batches No real member data
Verdict, computed by the reconciliation gate
Batch 2026-06-19-biweekly-demo
Posting allowed. Batch is eligible for member-ledger import.
Batch 2026-07-03-biweekly-demo
Posting blocked. A named admin override and immutable audit event are required.
Blocked means blocked. There is no path in this demo that posts these rows. The exception report is hashed either way, so the record of a refusal is as durable as the record of a clean import.
Schema, signature, money footings, configured contribution rates, roster binding, headcount, and the bank remittance must all reconcile before a row can reach a member.
| Control check | Result |
|---|---|
| Schema version | ✓ passed |
| Source hash format | ✓ passed Checks the shape of the declared digest, not the file bytes. Recomputing the hash server-side is on the production list below. |
| Detached signature status | ✓ passed Reads the status the sender declares. Cryptographic verification arrives with the production payroll transport. |
| Row count footing | ✓ passed |
| Earnings footing | ≠ blocking Header pensionable earnings must equal row total. |
| Employee contribution footing | ≠ blocking Header employee contributions must equal row total. |
| Employer contribution footing | ✓ passed |
| Duplicate employee row | ✓ passed |
| Member match | ✓ passed |
| Member identifier match | ✓ passed |
| Zero earnings with contribution | ≠ blocking Contribution row cannot be rate-validated because pensionable earnings are zero. |
| Employee contribution rate | ≠ blocking Employee contribution does not match pensionable earnings times plan rate. |
| Employer contribution rate | ✓ passed |
| Headcount tie-out | ✓ passed |
| Bank remittance tie-out | ≠ blocking ACH must tie to employee plus employer contributions. |
Wide table. Scroll sideways inside it to see the result column.
Every exception carries the expected and the actual amount in integer cents, and the full report gets a SHA-256 hash. A negative delta means the file reported more than its rows contain.
| Exception | Expected (USD) | Actual (USD) | Delta (USD) |
|---|---|---|---|
| Earnings footing | $7,915.00 | $3,820.00 | negative ($4,095.00) |
| Employee contribution footing | $554.05 | $599.05 | $45.00 |
| Zero earnings with contribution | n/a | n/a | n/a |
| Employee contribution rate | $267.40 | $312.40 | $45.00 |
| Bank remittance tie-out | $1,707.15 | $1,712.15 | $5.00 |
| Blocking exceptions | 5 |
Wide table. Scroll sideways inside it to see the expected, actual, and delta columns.
A payroll adapter reshapes the city’s export into one contrib_v1 batch per pay period, carrying schema version pensionos-payroll-v1. A named, versioned file contract means the city payroll office signs up to one shape, and a change to that shape is a version number instead of an email. A pay-period id imports once; corrections are reversal and replacement under a new id, never a silent overwrite. This demo proves the contract and the gate. It does not claim a production file transport exists.
The mobile app
The phone app reads the same ledger of posted paychecks as the member portal and runs the same versioned formula, so a member checking their benefit on a phone sees the number their statement will show. It opens on the retirement picture, shows the pay periods the estimate came from, and prints the formula version next to the figure.
The pension screen. The benefit, the 130 pay periods it came from, and the formula version, all on one screen. Each check mark is the app recomputing that row against the plan rate, not a stored status. Synthetic member, Sample Municipal Employees Retirement System.
The home screen. Balances the member typed in themselves, and one pension figure the fund can prove. The account-linking card is switched off and says so rather than pretending. Synthetic demonstration data only, no linked accounts.
The retirement journey. A ledger-driven pension figure beside Social Security and savings amounts the member entered. Deterministic arithmetic against obligations the member stated. It is an estimate, and it is never advice.
PensionOS installs as a web app on any modern phone. On iOS it also runs as a native shell around that same web app, signed by Simpli-FI OS LLC under the bundle com.simplifios.pensionos. One codebase, one reviewed build behind both.
As verified in App Store Connect on 2026-07-10, two builds, 0.1 (1) and 0.1 (2), were valid and in beta testing with a private internal group, and build 2 was uploaded on 2026-07-07. There was no public link, no external beta, and no store release, and App Store version 1.0 was unsubmitted. We re-check that record before repeating it, rather than carrying a status forward on trust. Internal device acceptance testing and the store privacy disclosures are still open.
The app runs on synthetic data. No real member data has been loaded into any environment. What you can do today is open the no-sign-in demonstration of that app surface and press every control on it. It is the same component the iOS shell wraps, running on the same contribution ledger.
Every one of these is a place where the easy version of this product was available and was not taken. That is the same instinct a board wants in whoever administers its plan.
The member owns every input. The fund owns only the pension number, which it can prove. An imported balance is a balance the fund becomes responsible for.
The connector is built, server side, value only, and it is switched off. It turns on after a vendor security review, a data-processing agreement, and a working revocation path, not before.
The app will never ask a member for a Social Security password. Not in v1, not later. It takes the member’s own statement figure as a manual input instead.
We do not accept a document we cannot yet promise to protect for its whole life, from encryption at rest through a written destruction schedule.
Deterministic before intelligent. The member can see the arithmetic, and so can an examiner. A member who asks why their number changed deserves a formula, not a paraphrase.
Nothing leaves the phone by default. A cloud save requires a signed-in member at the higher authentication level, and the saved record carries its formula version, its inputs, its timestamp, and the actor who sent it.
A member can check their pension on a phone in a parking lot and see the same figure, the same window, and the same formula version their fund would print on a statement. The phone shows the benefit to the dollar and the portal shows it to the cent, $2,110.29 a month, from one calculation. That is the whole point of building the phone on top of one ledger instead of beside it.
Why a fund can trust it
Public retirement administration touches the most sensitive data a person has and the most important number of their later life. The four tenets below are what is actually built today on synthetic data, and what is still ahead. The labels are not decoration. Read the fourth one.
The benefit engine is versioned and covered by tests, carries integer cents end to end, and prints the window and formula version behind every figure.
Payroll imports face fifteen control checks with quarantine and named-administrator overrides. A pay period imports once; corrections are reversal and replacement under a new id, never a silent overwrite.
Multi-factor sign-in, step-up on sensitive actions, field-level encryption masked to the last four, and an append-only trail of every change.
Live payroll transport, cutover from synthetic to real member data, and SOC 2 Type II readiness in progress. These are gates held behind counsel and a controls review, and none of them is claimed as finished.
Who it is for
A pension system has four constituencies who rarely agree on anything except that the number should be right. PensionOS is built so the same ledger answers all four.
The fastest way to judge this is to watch a payroll batch get rejected, then follow one member’s monthly benefit back to the paychecks it came from. That takes about ten minutes. Bring your plan document and your hardest question.
Book a ten-minute walkthroughNo account, no form, nothing installed. The walkthrough runs on the Sample Municipal Employees Retirement System, a fictional fund with a synthetic member.