Workforce Platform Expansion (Payroll & Rostering)
No code, proto, schema, or service for payroll or rostering exists anywhere in the codebase today. This page names a product direction confirmed on 2026-09-28: the custodian portal grows into a full end-to-end workforce & compliance management platform, not just credential compliance. It is not a spec, has no phases, and should not be treated as a commitment or a timeline. Course delivery is the one piece of this direction that is scoped — see Course Delivery & Retakes — and can proceed independently of everything on this page.
The direction
Custodian Workforce Compliance today is read-only gap tracking against an existing credential register: it never rosters people onto shifts and never touches wages. The confirmed direction removes that boundary — payroll (wages, tax withholding/remittance, banking) and rostering (shift/labor scheduling) become part of the custodian platform, alongside compliance and course delivery.
Why this isn’t scoped further here
This is a different kind of change than adding a service to an existing domain — it’s a new regulated product line, on top of a platform whose entire design center has been credential verification:
- Payroll is licensed activity in most jurisdictions. Processing wages, withholding tax, and remitting to tax authorities typically requires jurisdiction-specific registration/licensing — not a design decision Attest can make unilaterally.
- New data classification. Banking details and tax identifiers are a materially more sensitive data class than anything Data Models & Crypto covers today — this needs its own security review, not an extension of existing key-custody guardrails.
- Jurisdiction-specific by nature. Wage law, tax brackets, statutory leave, and payslip requirements vary per country/state; almost none of this generalizes the way W3C VC issuance does.
- Build vs. integrate is unresolved. Nearly no platform builds payroll tax calculation from scratch — most integrate an embedded payroll-as-a-service provider per jurisdiction. Which approach, and which provider(s), is undecided.
Open decisions requiring explicit owner approval
- Native payroll engine vs. embedded payroll-as-a-service integration, per jurisdiction.
- Launch jurisdiction(s) — this single decision determines almost all remaining payroll scope.
- Data residency, encryption, and access-control model for banking/tax data.
- Whether rostering is compliance-gated only (block rostering a worker onto a shift if their required credential has lapsed) or a full labor-scheduling system (shift swaps, overtime rules, timesheets).
- Licensing/registration path per jurisdiction before any payroll processing goes live.
- Legal/compliance sign-off — payroll sits under a different regulatory regime than credentialing, and needs its own review, not a rider on the platform’s existing launch-blocking list in CLAUDE.md’s Roadmap Context.
Where this would slot in, if built
New services, not extensions of existing ones — consistent with the platform’s own single-responsibility principle:
- A Payroll Service, isolated from every credential-domain service, holding its own jurisdiction-scoped schema.
- A Rostering Service, which would read compliance state from Custodian Workforce Compliance (a gap blocks a roster assignment) without that service taking on rostering’s own responsibilities.
- Custodian Registry and Core Engine’s roles stay exactly as documented — DID/key custody and orchestration respectively, neither becomes a payroll or scheduling system of record.
Next step
This needs an ADR and a jurisdiction-by-jurisdiction legal/compliance review before any real scoping begins. Do not implement from this placeholder alone.