Reference
The pages in this section are the truth the handbook leans against. Several are generated from code at build time and cannot drift.
Generated from code
| Page | Source | Watched paths |
|---|---|---|
| RBAC matrix | packages/auth/src/rbac.ts | rbac.ts |
| Validation rules | packages/domain/src/payroll/rules/validation-rules.ts | validation-rules.ts |
| Notifications catalog | packages/notifications/src/templates/ (curated metadata) | templates/*.ts |
If the underlying code changes, these pages refresh on the next build. CI watches these paths and rebuilds automatically.
Status machines
| Domain | Diagram |
|---|---|
| Payroll cycle | 16 states, PLANNED → ARCHIVED |
| Journal batch | 5 states, DRAFT → CLOSED |
| Journal entry | 5 states, DRAFT → APPROVED/REJECTED/ESCALATED |
| Reconciliation run | 6 states, PENDING → COMPLETE |
| FS engagement | 7 states, DRAFT → ARCHIVED |
| XBRL filing | 8 states, DRAFT → ARCHIVED, with validation/mapping recovery loop |
SOPs (upstream authority)
These are the source of truth for what the platform should do. The handbook is the source of truth for how to do it in the app.
Architecture
- Why one repo for two products — design rationale for shipping Payroll and Bookkeeping on a shared codebase.
- XBRL Filing & Financial Statements integration — how the
xbrl-saasandfinstatementsource repos were folded in as two product modules. - Correspondence module — the mail-intake pipeline and where its pieces live.