TOURWB-MOD-001 · Architecture ratified 2026-04-13 · Build target Q2 2026

HR & People

The employee master record. Where every other module's people-data starts.

Your people, your way, ported anywhere. Every employee record is a PortableRecord — exportable as a Ledger card, owned by the customer, readable by every WorkBench module that ships.

Section 2

The Record: Dim_Employee

The primary dimension for HR & People. Identity fields anchor the record. Operational fields drive day-to-day. Derived fields are computed from the fact layer — not independently writable. Change a pay rate through Fact_CompensationChange, not by editing the column.

PS
Priya Shankar
ACTIVE — FULL TIME
Senior Engineer · Engineering
Dim_Employee
EMP-003
Identity
employeeId
EMP-003
firstName
Priya
lastName
Shankar
preferredName
email
priya@workbench-demo.com
Operational
title
Senior Engineer
department
Engineering
managerId
EMP-001
employmentType
FT
startDate
2022-09-12
employeeTimeZone
America/Chicago
certifications
AWS Solutions Architect
externalMetadata
{ source: 'manual', importedFrom: null }
Derived (from fact layer)
active
true
Fact_StatusChange
payRate
$148,000
Fact_CompensationChange
payType
salary
Fact_CompensationChange
payCycle
biweekly
Fact_CompensationChange
tenure
3.6 years
startDate
updatedAt
2025-07-01T14:22Z
latest fact event
archivedAt
null (REQ-13 soft-delete)
New in CR-WB-HRPEOPLE-002
employeeTimeZone is a required Dim_Employee field, IANA-formatted, pre-filled at hire from Dim_Company.companyTimeZone. Used for time clock day boundaries and pay period displays. No nullable, no silent default — every employee gets one the moment they land on the roster.
Deferred fields
pii (privacy review pending) · photo (card-experience vision emerges or customer credibility requires) · bio (customer demand for richer profiles)
Section 3

Status & Categories

When someone changes employment state — gets hired, goes on parental leave, gets terminated, comes back as a contractor — a dozen things have to happen correctly. Do they still count toward headcount? Are they still on payroll? Are they still accruing PTO? Should they still appear on their manager's roster?

The status name doesn't tell you. The conditions do.

WorkBench separates the status name (what HR calls the situation) from the business logic (what every other system needs to know about it). Four parent statuses, ~32 children, seven conditions each. Change someone's status once; everything downstream stays consistent automatically.

What each condition controls

ConditionWhat it drives
Rehire eligibleWhether this person can be re-offered employment in the future
Counts as headcountWhether they appear in headcount totals on reports
Accrues PTOWhether time off keeps accumulating during this state
On payrollWhether they get paid this period
Can clock timeWhether they can punch in/out against the time clock (drives day boundaries and pay period displays)
Benefits eligibleWhether they keep their health/dental/etc. coverage
Active for manager rosterWhether they show up on their manager's team list

Some conditions depend on your company's policy, not WorkBench's defaults. For example: does an employee on partial-pay leave keep accruing PTO? That's your call. WorkBench stores the value as customer_policy and reads from your company's policy lookup at runtime. Change the policy, every employee on that status updates automatically.

Active
Currently employed and working
7 children
ChildRehireHeadcountPTOPayrollTime ClockBenefitsRoster
Active — Full Time
Active — Part Timepolicypolicy
Active — Contractor
Active — Temporarypolicy
Active — Seasonalpolicy
Active — Probationarypolicypolicy
Active — Intern
yes nopolicy depends on your company's policy not applicableChild conditions override parent conditions when they differ.

Universal token vocabulary

Eight universal tokens score observed work behavior on a 1–5 integer scale. The core seven converged unanimously across council review. USTR-08 is Growth by default, with Initiative/Passivity flagged as an alternative pending operator ruling. Role-specific tokens (audit, engineering, etc.) are deferred to their own council reviews.

Communication
USTR-01
Clarity, timing, and audience awareness. Keeps people informed without making them chase context.
Execution
USTR-02
Turns commitments into completed work. Moves work from intention to done.
Judgment
USTR-03
Sound decisions in ambiguity. Knows when to act, when to ask, what tradeoffs matter.
Ownership
USTR-04
Treats outcomes as theirs to carry until resolved. Accountability with follow-through.
Adaptability
USTR-05
Absorbs new facts without getting stuck in the previous plan. Flexibility without loss of direction.
Collaboration
USTR-06
Works constructively across functions and perspectives. Coordination that improves the result.
Reliability
USTR-07
Dependable in ways others can plan around. Predictability under ordinary operating conditions.
Growth
USTR-08
Proactively develops new skills, seeks feedback, applies learning to improve performance over time.
OPERATOR RULING PENDING

Radar: one employee

Universal tokens · 1–5 scale
Priya Shankar · EMP-003
Strengths: 6Gaps: 0
CommsExecJudgeOwnAdaptCollabReliaGrowth
Strengths ≥ 4 · Proficient = 3 · Gaps ≤ 2 · Quarterly re-scoring cadence

Scoring scale: 1=Needs Improvement · 2=Developing · 3=Proficient · 4=Strong · 5=Exceptional. Strength/gap designation is derived, not stored.

Section 4

The Substrate

Every change to an employee is recorded as an immutable event. The employee record you see is a derived view. Pay rates, status, and role are all computed from the fact history. This means HR & People never loses history — and when Payroll ships as Module 5, it reads the same substrate. Both modules see the same truth.

10 fact tables · category-scoped
Fact_StatusChange
Employee status transitions (Active → On Leave, etc.)
Fact_RoleChange
Title, department, manager changes
Fact_CompensationChange
Source of truth for payRate / payType / payCycle
Fact_PayEntry
Pay period entries — embedded compensation capability
Fact_TokenScoreChange
Token scoring events, quarterly cadence default
Fact_NoteAdded
Operator / manager notes on employees
Fact_DocumentAttached
Attached files, policies, forms
Fact_PermissionChange
Access control changes
Fact_RelationshipChange
Manager-report relationship changes
Fact_EventLog
Module-scoped master log; rolls up to WorkBench master later
Fact_PayEntry does NOT mutate Fact_CompensationChange. Compensation structure updates remain in Fact_CompensationChange. Pay period entries sit in Fact_PayEntry.
Fact timeline · newest first
Priya Shankar · EMP-003
Fact_CompensationChange2025-07-01
Merit increase · $140K → $148K
$140,000 $148,000
Q2 2025 merit cycle
Fact_TokenScoreChange2025-01-15
Q1 2025 quarterly re-scoring · 8 tokens updated
Quarterly cadence
Fact_RoleChange2023-06-01
Promoted Engineer → Senior Engineer
Engineer Senior Engineer
Performance + tenure
Fact_CompensationChange2023-06-01
Promotion comp adjustment · $125K → $140K
$125,000 $140,000
Linked to role change
Fact_StatusChange2022-09-12
Status set to Active — Full Time on start date
Pending — Offer Accepted Active — Full Time
All events preserved forever. The employee record is a derived view; pay rate, status, and role are computed from the fact history.
Section 5

Starter Dashboards

Every WorkBench module ships with three Starter Dashboards. The measures behind them are defined once in the measure layer — same definition everywhere, no drift between modules. HR & People ships Workforce, Composition, and Capability. (Compensation is flagged for V1.1 once pay data has accumulated.)

Workforce
Headcount, tenure, distribution, turnover
Theme 1 of 3
Total Headcount
11
employees
+2 vs last quarter
By Department
6
depts
Leadership
1
Product
1
Engineering
3
Audit
4
Creative
1
Operations
2
Avg Tenure (Active)
2.7
years
Turnover Trend
6.2%
annualized
trending lower
Employment Type
Full Time8
Contractor3
Pending1
On Leave
1
parental · returns Jun
Measures defined once in the measure layer. Same definition everywhere.
Composition
Role distribution, token coverage, strength/gap profile
Theme 2 of 3
Token Coverage
58%
+15% vs last quarter
Top Strengths (Org)
Reliabilityavg 4.6
Executionavg 4.4
Communicationavg 4.3
Top Gaps (Org)
Adaptabilityavg 3.7
Growthavg 3.6
Judgmentavg 3.9
Roles
IC
7
Manager
2
Contractor
2
Pending
1
Strength/Gap Mix
Strengths (≥4)32
Proficient (3)18
Gaps (≤2)4
Unscored24
Scoring Freshness
Q1 2026
Next: Q2 quarterly prompt
Token coverage derived from Fact_TokenScoreChange. Strength/gap designation is derived.
Capability
Certifications, training trends, growth trajectory
Theme 3 of 3
Certifications
6
+2 this year
Training Hours / Month
42
hours
Growth Trajectory
3.9 / 5
+0.3 vs last quarter
CPA Coverage · Audit Dept
3 / 3
100% covered
Capability Gaps
Cloud certs · Eng1 / 2
Security trainingpending
Manager coachingQ3 plan
Internal Moves
2
12mo
Capability coverage gaps are triangulated from certifications + token strengths + role demand.

Seed roster: ~12 fictional employees across 6 departments, one management layer. All numbers here are representative — read the fact layer for real data.

Section 6

Ledger Export

Every employee record is a PortableRecord. The customer owns their data. Export exactly what belongs to the employee as a Ledger card — a snapshot at export, not a live feed. Tenure at export is what ships; old cards don't silently age.

Ledger Card · Employee
Priya Shankar
EMP-003
Snapshot at export
2026-04-13T10:04Z
by EMP-001 (Operator)
Included in export (10)
employeeId
EMP-003
firstName
Priya
lastName
Shankar
preferredName
title
Senior Engineer
department
Engineering
startDate
2022-09-12
tenure
3.6 years
as of 2026-04-13
certifications
AWS Solutions Architect
manager-scored tokens
8 tokens, Q1 2026 cadence
CONSENT
Excluded (5)
email
Privacy — excluded by default
payRate
Privacy — compensation not exported
payType / payCycle
Privacy — compensation not exported
managerId
Relational data — separate Ledger concept
pii / photo / bio
Deferred from V1 · not in scope
PortableRecord · customer-owned · snapshot does not auto-update
Drag-to-Ledger coming soon
Section 7

Connectivity

WorkBench meets your data where it already lives. HR & People can bring data in from the systems you already use — like BambooHR or Gusto — and take data out via Ledger export, CSV, or webhook. External metadata is preserved on every ingestion.

Bring data in from
B
BambooHR
HRIS sync
PLANNED
G
Gusto
Compensation context
PLANNED
CSV import
Operator-driven
PLANNED
S
SCIM 2.0
Post-V1 identity
EVALUATING
HR & People
Take data out to
Ledger export
Per record
PLANNED
CSV export
Operator request
PLANNED
Webhook out
Payroll subscribes at Module 5
PLANNED
External metadata is preserved on every ingestion. WorkBench does not strip source-system context.
Section 8

What's Not Yet In V1

We ship complete stages, not half-built products. Here's what the council ratified as planned-but-not-in-V1 — with trigger conditions for when each gets built. Honesty is the differentiator.

Self-service employee wing
DEFERRED
Reason: Module 1 is operator-facing first. Identity / auth / permissions must precede self-service. Schema supports it; UI does not surface it.
Trigger: Module 1.5 or Module 2 once operator-facing version is validated in DDL production (aspirational: 30 days post-Module-1 ship, pending operator ruling).
Operator-authored Role-Specific tokens (Audit)
DEFERRED
Reason: Establishing correct ratification path for role layers — council-reviewed, not operator-bypassed. Prevents precedent that operators can skip council review.
Trigger: Separate CR-WB-AUDITTOKENS-001 (or equivalent) per role layer.
PII fields beyond name / email
DEFERRED
Reason: Privacy review and customer demand needed before adding sensitive fields.
Trigger: First customer requirement + privacy framework completion.
Photo, bio fields
DEFERRED
Reason: V1 is operator-facing. Visual identification not yet needed on the operator surface.
Trigger: Card-experience vision emerges OR customer credibility requires human visual identification.
Configurable custom token permissions
DEFERRED
Reason: Admin-only in V1 prevents taxonomy drift. Delegation to scoped managers needs its own review.
Trigger: V1.1 — configurable per customer.
Integrated Payroll module features
DEFERRED
Reason: Payroll ships as Module 5 with its own CR. HR & People embeds compensation capability, not payroll.
Trigger: Module 5 build kickoff (includes migration plan commitment).
Compensation Starter Dashboard (4th theme)
DEFERRED
Reason: Three themes ship in V1. Compensation theme needs accumulated pay data before it's a meaningful dashboard.
Trigger: V1.1 once Fact_PayEntry has enough history to support the theme.
Next tour · WB-MOD-002
Live
Payroll & Comp
Same employees, read through a different lens. See how Payroll shares HR's substrate — no sync, no reconciliation, no parallel employee table.
Continue →