WorkBench · Modular Business OS

Seventeen modules.
One substrate.
Same data layer.

Every WorkBench module reads from the same facts. No parallel employee tables. No nightly sync jobs. No reconciliation step. Pick a module and it already composes with the others — because there is nothing between them to bridge.

This page is the architectural explanation and the tour entry. 3 modules are live. 3 have ratified tours you can walk through today. 11 are on the roadmap. All 17 anchor to the same substrate. The Workforce Triangle — HR identity, Payroll compensation, Time hours — is complete.

See live tours →Browse the roadmap
Section 2

What is a WorkBench module?

Four load-bearing claims, one architecture. Not a suite. Not an integration layer. A substrate with lenses.

2a

The eight-section contract

Every WorkBench module tour walks the same eight sections: Overview, Sibling Mandate, Primary Events, Anatomy, Cross-Module Read, Variance & Measurement, Bitemporal, Receipts. Content adapts per module; structure does not. Once you know one tour, you know all of them. Ratified in CR-WB-MODULE-001.

01
Overview
02
Sibling Mandate
03
Primary Events
04
Anatomy
05
Cross-Module Read
06
Variance & Measurement
07
Bitemporal
08
Receipts
2b

The Sibling Mandate

Each module reads from the same Dim_Employee. No module maintains parallel identity. No module writes employee records that another module would have to reconcile against. When HR changes an employee's status, Payroll's next query sees the new status — not after a batch job, not on a schedule, not eventually. Immediately. This is the substrate's load-bearing guarantee, sharpened in CR-WB-PAYROLL-001.

WorkBench
One substrate. Two module lenses.
HR & PEOPLEEmployee status,tenure, tokens, rolesPAYROLL & COMPComp events,pay runs, withholdingsreadsreadsDIM_EMPLOYEE · FACT_STATUSCHANGE · FACT_COMPCHANGE · FACT_PAYROLLRUNThe substrate. One set of facts. No duplication.EMP-001MayaEMP-003PriyaEMP-007HanaEMP-009TheoEMP-012Noor
Payroll doesn't have an employees table. When Payroll needs to know who Priya is, it reads HR's Dim_Employee. When HR terminates someone, Payroll's queries see the new status immediately — not after a sync job runs at midnight.
What most platforms replace it with
HR DATABASEemployees_hr(owns employee_id)PAYROLL DATABASEemployees_payroll(its own employee_id)nightly syncreconciliation job
Two databases. Integration layer between them. Drift by 5 p.m. on any given Friday. This is what the substrate replaces.
Right now the substrate has two lenses. As more modules ship, more lenses read from the same facts — the substrate stays still, the lenses multiply.
2c

Same data layer in practice

EMP-003 is Priya Shankar. She appears in the HR & People tour as an employee record. She appears in the Payroll & Comp tour as a pay-run subject. Not a copy. Not a sync. The same record, read through a different module's lens. The employee_id in hr.dim_employee is the employee_id in payroll.fact_compchange. No mapping table exists because no mapping table is needed.

Same employee · two module lenses
HR & People lens
Senior Engineer · Active · Engineering · 8 token scores · tenure since 2022-09-12.
=
Payroll & Comp lens
$148,000 base · biweekly · FCC-003-03 raise effective 2026-03-01 · $421.65 retro.
Same employee_id. Different lenses. The substrate does the unifying work; no integration layer required.
2d

Why it compounds

The third module reads from the first two. The fourth reads from the first three. Integration cost does not scale with module count — it is structurally absent. Every module shipped reduces the surface area a business would otherwise have to maintain between systems. By module seventeen, the substrate has replaced the integration layer entirely. The argument gets stronger with every module that ships. The receipts get heavier.

Section 3

Three tours live right now

These aren't independent demos. They share the same 12 employees, the same Dim_Employee, the same substrate. Each tour reads from the prior tours' data. That's the architecture, visible.

Section 4

How modules stack

Three beats. Each one stronger than the last.

01

One module on a substrate

HR & People proves the substrate exists and works for one domain. Dim_Employee is the identity spine. Fact_StatusChange is the first event type. Status, tenure, categorization, roles — all derived from an immutable event log.

02

Two modules sharing a substrate

Payroll & Comp proves the substrate generalizes. No parallel identity. Fact_CompChange and Fact_PayrollRun read from Dim_Employee and cite HR's Fact_StatusChange events. The math compounds: Live Burn Rate reads both modules in a single query — one JOIN, no sync, no nightly job.

03

Three modules, then seventeen

Time & Attendance is Module 03 — now shipped. It closes the Workforce Triangle: HR owns identity, Payroll owns compensation, Time owns the hours. Each module shipped reduces the integration surface a business would otherwise have to maintain. By module seventeen, the substrate has replaced the integration layer entirely.

Module stack · growing
Today
SUBSTRATE
6 modules
Workforce Triangle complete + 3 utility modules
Next
SUBSTRATE
7 modules
Module 04 joins the substrate
Far future
SUBSTRATE
17 modules
Seventeen modules, one substrate
The substrate at the bottom does not grow. The modules above it do. That's the compounding — every module anchors to the same foundation, so adding the next one does not cost integration work.
Section 5

The module roadmap

All seventeen modules. Four live today. Two tours ratified. Eleven queued.

LIVE
Controls
106 controls across 9 process areas.
LIVE
Teams
47 auditors with verified skill tokens.
TOURWB-MOD-003
Time & Attendance
Closes the Workforce Triangle. Fact_TimePunch + Fact_TimeAllocation on the shared substrate.
Take the tour →
LIVE
Analytics
Live dashboards — budget vs actual, billable %, coverage.
TOURWB-MOD-001
HR & People
The employee master record. Eight council-reviewed sections.
Take the tour →
TOURWB-MOD-002
Payroll & Comp
Reads HR's Dim_Employee. The math is legible, start to finish.
Take the tour →
COMING SOON
Capacity Planning
Skill matching, utilization projection, revenue impact.
COMING SOON
Invoicing
Logged hours → client-ready invoices.
COMING SOON
Accounting
Chart of accounts, P&L, balance sheet.
COMING SOON
Expenses
Log, categorize, reconcile. Receipts in, reports out.
COMING SOON
Documents
Contracts, SOPs, policies. Version controlled.
COMING SOON
Scheduling
Who's working when. Reads capacity + time.
COMING SOON
CRM
Client records, contacts, engagement history.
COMING SOON
Reporting
Pull any metric across any module.
COMING SOON
Integrations
QuickBooks, Stripe, Gusto — data in, data out.
COMING SOON
Ledger Cards
Verified work history that travels with your team.
COMING SOON
Client Portal
Read-only window for clients and stakeholders.
3 of 17 modules live · 3 on tour · 11 coming soon · One substrate underneath them all.
Section 6

Module Charter receipts

Three council reviews define how every module gets built. Read them if you want the architecture proof, not the marketing.

Modules ratified. Tours shipped. The cathedral compounds.

Walk a tour. Read the receipts. Watch the compounding happen in real time — every module that ships makes the next one cheaper to build.

Tour HR & People →Tour Payroll & Comp →Tour Time & Attendance →
← Back to WorkBench landing