Appearance
HR Capabilities: Packages, Access, and Administration
HR is a collection of related products, not one indivisible suite. A service may need reliable employee records and organization structure without payroll, recruiting, benefits, time tracking, or employee self-service. The capability model is intended to let each tenant select the functional packages that fit its service while preserving a shared workforce foundation.
This guide explains the HR capability catalogue, the distinction between a capability and a user permission, service defaults, seed-package boundaries, activation and suspension, and the implementation state observed in the checked-in source.
A catalogue entry is not proof that a feature is complete
The capability catalogue defines product boundaries and intended scope. It does not prove that every workflow listed below is complete, that every inactive feature is hidden in the UI, or that every API is currently guarded. See Current implementation and gaps.
What a capability means
A capability is a service-level switch for a coherent HR product area. It answers: is this product area available to this particular company service? For example, a tenant can use the employee and organization foundation while keeping payroll available in the service offering but inactive for that tenant.
A capability is not:
- A user permission. Capability activation makes the service package available; role and user permissions decide which people can view or act on it.
- A menu label or a replacement for the permission tree. Capabilities must complement authorization, not grant it.
- A setup record. Enabling Leave does not create leave types or accrual rules; enabling Benefits does not create plans; enabling Scheduling does not create shifts or rosters.
- A subscription invoice by itself. The registry records functional service configuration; commercial entitlement must not be inferred from a capability row alone.
- Proof of feature readiness. Screens, API routes, validations, audit history, seed dependencies, and downstream payroll/accounting handoffs still require implementation and verification.
Employee identity and organization structure form the foundation. Recruiting, payroll, attendance, leave, benefits, expenses, development, and employee self-service are distinct functional areas selected around it.
The platform model
HR reuses shared platform capability tables rather than maintaining a parallel HR-specific registry.
| Model part | Source | Responsibility |
|---|---|---|
| Capability catalogue | service_capability / service-capability.yaml | Stable code, name, scope, dependencies, and behavior requirements. |
| Service offering | service_default_capability / service-default-capability.yaml | Which capabilities a service can offer, and which are required or on by default. |
| Tenant selection | company_service_capability | Status selected for one company's instance of a service. |
| Seed boundary | service_capability_seed_pack, service-seed-packs.yaml | Seed package associated with a capability and data eligible to be loaded. |
| User authorization | Existing L1/L2/L3 tree and action permissions | Which users may enter an area or perform an operation. This is independent of capability activation. |
The tenant selection is scoped by company_service_id. Activating a package in Community Finance & HR does not activate it in a separate HR & Payroll service instance belonging to the same company.
HR capability catalogue
The following descriptions expand the backend catalogue into operational terms. They describe intended package boundaries, not a guarantee that every listed subfeature is complete in the current release.
Foundation
HR Workforce Core — HR_WORKFORCE_CORE
The required foundation for HR service delivery: employee records linked to Party identity, organization and manager relationships, jobs, grades, positions, contracts, effective-dated employment changes, employee identity/access links, and baseline HR security and audit foundations. It supports a useful employee register even where a tenant does not want the full HR suite.
Other HR capabilities declare Workforce Core as a required dependency. Both current HR service offerings mark it required and enabled by default. This is not itself a system-user permission: linking an employee to an account and assigning that account a role remain separate, permission-controlled actions.
Hiring and workforce operations
HR Talent Acquisition — HR_TALENT_ACQUISITION
Covers approved workforce requisitions, candidates, applications, interviews, offers, offer version history, recruitment approvals, and candidate-to-employee handoff. It is for organizations that want to manage hiring in HR rather than import or directly create every employee. The handoff should preserve a person's identity and recruitment history rather than create a duplicate Party.
HR Onboarding and Transitions — HR_ONBOARDING_AND_TRANSITIONS
Covers onboarding task plans, probation outcomes, transfers, promotions, salary-change events, suspensions, and other effective-dated employee transitions. The defining feature is a dated, traceable employment event and its downstream effects—not simply overwriting a current-status field. Changes may affect position occupancy, access, compensation, or payroll eligibility.
HR Time and Attendance — HR_TIME_ATTENDANCE
Covers recording work time and attendance, review and correction workflows, attendance rules, overtime requests/approvals, and preparation of approved time records for later use. Corrections should preserve who changed a record, why, and the approval outcome. When payroll consumes attendance or overtime, only approved eligible records should cross that boundary.
HR Leave and Absence — HR_LEAVE_AND_ABSENCE
Covers leave types, accrual rules, balances, paid/unpaid requests, approvals, absence records, and payroll-ready leave/absence inputs. A leave request describes authorized time away; an attendance record describes observed or reported time. An absence is not automatically approved leave. Payroll treatment depends on policy and approval state, not merely on a date appearing in a record.
HR Scheduling and Coverage — HR_SCHEDULING_AND_COVERAGE
Covers shift patterns, roster planning, employee availability, planned coverage, and exceptions when a team or work area has a gap. It complements, but does not replace, attendance: a planned shift is not proof of attendance, and attendance is not a roster. Leave and availability can affect planned coverage; actual attendance and overtime may later provide operational or payroll evidence.
HR Employee Relations — HR_EMPLOYEE_RELATIONS
Covers sensitive cases such as grievances, disciplinary matters, investigations, evidence, decisions, and resolution history. It calls for restricted access, an evidence chain, and suitable maker-checker controls. Ordinary employee-record visibility must not automatically grant access to confidential case material; permissions, audit, document handling, and retention are essential.
HR Contingent Workforce — HR_CONTINGENT_WORKFORCE
Covers contractors and other non-permanent workers whose engagement, end date, access, time capture, and payment route must be managed without treating them as ordinary permanent employees. Engagements need an accountable owner and clear end date; access and payment eligibility should follow the engagement. Payment may hand off to payroll or payables as appropriate.
Pay, benefits, and expenses
HR Payroll Operations — HR_PAYROLL
Covers controlled payroll periods, approved inputs, calculation, statutory outputs, payslip records, GL accrual, payment settlement, remittance, and the audit trail. Payroll consumes approved eligible employee and source data; it should not silently rewrite attendance, leave, loan, benefit, or compensation records. Calculation, validation, approval, posting, payment, and statutory filing are distinct checkpoints. A successful calculation alone does not prove GL posting, settlement, or filing acceptance.
Payroll depends on Workforce Core and shared accounting, payments, workflow, approval, document, and reporting services. Employee pay structures belong to HR Compensation; loan pricing belongs to Loans. These are separate products and pricing profiles.
HR Compensation — HR_COMPENSATION
Covers employee pay structures, salary bands, effective-dated salary revisions, allowances, rewards, and compensation-change approval. Compensation defines what terms apply and when; payroll determines what is payable for a period using those terms and eligible period inputs. Mid-period changes require an explicit effective date and an agreed proration method before payroll consumes them.
HR Benefits and Total Rewards — HR_BENEFITS
Covers benefit plans and eligibility rules, life-event re-evaluation, enrollment, waiver decisions/evidence, suspension and end dating, employee and employer contributions, provider invoices, and versioned total-reward statements. Enrollment, provider invoicing, contribution, payroll deduction, and payment reconciliation are distinct records. Approval to enroll is not proof that a provider was paid or that a payroll deduction settled.
HR Travel and Expenses — HR_TRAVEL_EXPENSES
Covers travel requests, per-diem policy, expense claims, approvals, receivable/payable recognition, settlement, and GL traceability. A per-diem policy is configuration; a travel request or claim is an operational transaction. Per diem can apply to qualifying travel or other approved assignments, so it is not itself a travel claim.
Claim recognition and payment must be separate accounting events: recognition generally debits the applicable expense and credits an employee payable; later settlement debits that payable and credits the actual cash or bank account. Approval alone is not settlement. This capability does not inherently mean claims must be processed through payroll.
Talent and employee experience
HR Performance and Goals — HR_PERFORMANCE_AND_GOALS
Covers performance cycles, employee goals, reviews, feedback, manager input, calibration, development plans, and approval history. A sound cycle defines who sets and approves goals, which reviewers contribute, when the cycle is open, how calibration is controlled, and how final outcomes are communicated. A performance outcome does not itself authorize a payroll change.
HR Learning and Development — HR_LEARNING_AND_DEVELOPMENT
Covers training programmes, employee enrolment, completion records/evidence, skills development, and learning reporting. Completion evidence should support the record; skills profiles should only change through an authorized, auditable update.
HR Career and Succession — HR_CAREER_AND_SUCCESSION
Covers career paths, talent pools, succession plans, readiness assessments, and internal mobility decisions. It supports future role coverage; a proposed successor does not automatically become the role incumbent. Succession data is sensitive and needs restricted visibility, defined review, and retention rules.
HR Employee Self-Service — HR_EMPLOYEE_SELF_SERVICE
Covers employee-scoped access to the employee's own profile, payslips, leave, attendance requests/corrections, documents, benefits, and request tracking, where the underlying functions are also enabled. The signed-in account must be linked to the right employee. Self-service is not broad HR access: approval and sensitive-field controls still apply, and employee scoping must be enforced server-side rather than only in the browser.
HR Manager Self-Service — HR_MANAGER_SELF_SERVICE
Covers manager views/actions for the manager's authorized reporting scope: direct reports, team leave, attendance, coverage exceptions, onboarding, performance, and team work queues. It should provide useful team workflows without exposing the whole HR register. The catalogue specifies direct reports as the default scope; delegated or expanded scopes need an explicit policy and audit trail.
Planning, insight, compliance, and connections
HR Workforce Planning — HR_WORKFORCE_PLANNING
Covers planned headcount, position requisitions, capacity scenarios, workforce plans, approved workforce budgets, and labor-cost planning. It connects a future staffing plan to approved positions and budgets rather than treating every proposed hire as an available seat. Position control can bridge planning and recruiting: define approved positions, forecast needs, then recruit against an approved requisition.
HR Analytics and Reporting — HR_ANALYTICS_AND_REPORTING
Covers the HR reporting catalogue, workforce metrics, payroll reconciliation, compliance reports, and controlled analytical outputs. Reports should identify their source, population, period, filters, and refresh time. Sensitive payroll, employee-relations, health, and identity data must not become visible just because a user can run a general report; report permissions and row/field controls still apply.
HR Documents and Compliance — HR_DOCUMENTS_AND_COMPLIANCE
Covers employee documents, statutory evidence, expiry tracking, acknowledgments, retention rules, and audit-ready files. This is controlled evidence management, not just attachment upload. Each owning workflow should define required evidence, who can view it, expiry and retention, and the consequence of missing or expired evidence.
HR External Integrations — HR_EXTERNAL_INTEGRATIONS
Covers controlled connections to payroll providers, banks, statutory authorities, communications, identity systems, time devices, and other HR sources. Every integration needs provider identification, data mapping and boundaries, credentials, retries/idempotency, audit logs, and verified acknowledgment for outbound writes. Activation does not connect a device or provider by itself. Biometric collection (fingerprint, voice, etc.) additionally requires explicit privacy, consent, retention, and legal review.
Service defaults
The current backend service blueprint defines these defaults:
| Service offering | Required / enabled by default | Available but not automatically enabled |
|---|---|---|
HR & Payroll (HR_PAYROLL) | HR_WORKFORCE_CORE, HR_PAYROLL | Talent acquisition; onboarding/transitions; time; leave; scheduling; compensation; benefits; travel; performance; learning; career/succession; employee relations; employee and manager self-service; workforce planning; analytics; documents/compliance; integrations; contingent workforce. |
Community Finance & HR (COMMUNITY_FINANCE_HR) | HR_WORKFORCE_CORE | All 20 optional capabilities, including HR_PAYROLL. |
“Available” means the service offering can activate the package; it does not mean it is active for every company-service instance. In particular, Community Finance & HR does not force every tenant to use payroll or the complete HR suite. These are service-blueprint defaults, not a readout of one live tenant. Existing explicit tenant selections take precedence; a changed default should not silently deactivate an existing active selection.
Status and dependency behavior
The service blueprint default and tenant override combine to produce effective status.
| Status | Meaning |
|---|---|
REQUIRED | Required by the service blueprint; part of the intended baseline. |
DEFAULT_ENABLED | Enabled by default for a new service instance unless overridden. |
ACTIVE | Explicitly activated for this company service. |
AVAILABLE | Still offered, but inactive for this company service. |
SUSPENDED | Explicitly paused; configured but should not be usable while suspended. |
RETIRED | Explicitly retired from this company service. This status change is not an instruction to delete historical records. |
An available service-blueprint row does not activate a package. With no tenant override, only a required/default-enabled capability is active. An explicit ACTIVE tenant row activates an optional package; explicit AVAILABLE, SUSPENDED, or RETIRED does not. In the backend route guard, an explicit tenant override is active only when its status is ACTIVE.
All optional HR capabilities declare Workforce Core as a required capability. Capability dependency configuration also records needed platform primitives and service profiles; for example, payroll/travel need accounting and payment foundations, while external integrations need integration and audit foundations. The service blueprint must offer the package before an administrator can activate it.
The current service-management update path rejects deactivation when other active capabilities depend on the selected capability and lists those dependents. Suspend/retire dependents first. Since Workforce Core is the required foundation, smaller HR deployments should keep it enabled and turn off unneeded add-ons—not remove the foundation. Historical employee, payroll, benefit, claim, or attendance records need retention and access controls even if a package is suspended.
Seed packs: what activation does and does not do
A capability-to-seed-pack mapping defines a controlled boundary for service-specific setup data. Current HR mappings are:
| Capability area | Seed pack | Seed files currently declared |
|---|---|---|
| Workforce Core | hr-workforce-core | No HR-specific files; inherits platform primitives. |
| Payroll | hr-payroll-core | HR tag binding and Uganda payroll pricing profile, item, and tier seeds; inherits accounting, project-fund-control, wallet, and workforce packs. |
| Talent acquisition, onboarding, performance, learning, succession | hr-talent-core | None currently declared in this pack. |
| Time, leave, scheduling/coverage | hr-time-attendance-core | None currently declared in this pack. |
| Compensation, benefits | hr-rewards-core | None currently declared in this pack. |
| Travel and expenses | hr-travel-expense-core | None currently declared in this pack. |
| Employee relations | hr-employee-relations-core | None currently declared in this pack. |
| Employee and manager self-service | hr-employee-experience-core | None currently declared in this pack. |
| Workforce planning and analytics | hr-planning-analytics-core | None currently declared in this pack. |
| Documents and compliance | hr-documents-compliance-core | None currently declared in this pack. |
| External integrations | hr-integrations-core | None currently declared in this pack. |
| Contingent workforce | hr-contingent-workforce-core | None currently declared in this pack. |
An empty seed-file list does not mean a capability has no runtime tables or procedures; database runtime objects are managed separately. It does mean that pack activation currently has no additional HR reference-data files to load for that package. Tenants still configure their own leave types, shifts, benefit plans, eligibility rules, performance cycles, training programmes, integration credentials, and other operating data in HR Setup or the relevant administration area.
Reporting catalogue exception: although hr-planning-analytics-core currently has no HR-specific seed files, the shared report-definition.yaml contains fifteen HR report definitions and report-group.yaml contains the Human Resources Reports group. The current seed row-scope rules attach those definitions and the group to hr-payroll-core and community-finance-hr-core, not to hr-planning-analytics-core. Reports are run from the shared Reporting workspace. Consequently, an enabled HR_ANALYTICS_AND_REPORTING row alone is not evidence that its catalog records were installed or that the group is gated by that capability. Verify catalog installation and capability-off visibility in the actual tenant. See HR Reporting and Analytics.
Activation does not create employees, user accounts, plans, roster assignments, integration credentials, or transactions. The service-management API can request seed synchronization when activating a capability; that synchronizes the mapped seed boundary, not a tenant's operational HR data.
Capabilities and user permissions
Both controls must permit access:
| Capability | User permission | Expected result |
|---|---|---|
| Inactive | Present | Feature unavailable; permission alone must not expose an inactive package. |
| Active | Missing | Feature unavailable to this user; activation must not grant permission. |
| Active | Present | User may access it within their permissions and data scope. |
| Inactive | Missing | Feature unavailable. |
Capabilities may gate an entire L3 area or tabs inside a shared workspace. If multiple packages share an L3, that permission grants general workspace access; capability-specific tab and API checks must still hide and reject inactive package features. A capability must never silently add L1/L2/L3 or action permissions to a role.
For self-service, a capability and user permission are still insufficient on their own: the server must enforce “my own employee record” or “my authorized reports.” Browser filtering alone is not a security control.
The shared backend requireServiceCapabilities middleware supports all and any requirements. Its permission compatibility fallback is restricted to a missing capability registry or recognized missing-schema condition and requires a verified route permission. If capability rows exist and the required capability is inactive, the request is denied; it does not fall back to permission-only access.
How the frontend maps capabilities to HR areas
The merged frontend defines HR route requirements in src/shared/constants/hr-capabilities.ts, prunes capability-mapped entries from the permission-derived navigation tree, and filters individual workspace tabs with useHrCapabilityTabs. This is additive metadata: user permissions still determine what an individual may do. Navigation filtering runs only when the active service response includes capability evidence, preserving legacy navigation during incomplete migrations.
| HR area | Current frontend requirement |
|---|---|
| HR root | Any one of the 21 HR capabilities. |
| Workforce Setup, Employee Management | HR_WORKFORCE_CORE. |
| Time & Attendance Setup | HR_TIME_ATTENDANCE or HR_LEAVE_AND_ABSENCE. |
| Payroll & Compensation Setup | HR_PAYROLL or HR_COMPENSATION. |
| Travel Expense Policies and Travel & Expenses | HR_TRAVEL_EXPENSES. |
| Talent & Benefits Setup | HR_BENEFITS, HR_PERFORMANCE_AND_GOALS, or HR_LEARNING_AND_DEVELOPMENT. |
| Employee Lifecycle & Relations workspace | Any of onboarding/transitions, employee relations, manager self-service, compensation, benefits, or talent acquisition. |
| Recruitment | HR_TALENT_ACQUISITION. |
| Time & Attendance operations | Any of time/attendance, leave/absence, or scheduling/coverage. |
| Payroll Processing | HR_PAYROLL. |
| My HR | HR_EMPLOYEE_SELF_SERVICE. |
| Performance & Development | HR_PERFORMANCE_AND_GOALS or HR_LEARNING_AND_DEVELOPMENT. |
Tabs have narrower requirements than their containing workspace:
| Workspace | Tab or setup item | Capability used by the frontend |
|---|---|---|
| Workforce Setup | Job grades, jobs, positions, exceptions, requisitions, clearance items | Workforce Core |
| Time & Attendance Setup | Leave types | Leave and Absence |
| Time & Attendance Setup | Shifts | Scheduling and Coverage |
| Time & Attendance Setup | Attendance rules | Time and Attendance |
| Talent & Benefits Setup | Onboarding checklists | Onboarding and Transitions |
| Talent & Benefits Setup | Performance cycles | Performance and Goals |
| Talent & Benefits Setup | Training programmes | Learning and Development |
| Talent & Benefits Setup | Benefit plans and eligibility rules | Benefits |
| Payroll & Compensation Setup | Payroll setup and input policy | Payroll |
| Payroll & Compensation Setup | Pay structures | Compensation |
| Employee Changes | Movements | Onboarding and Transitions |
| Employee Changes | Salary | Compensation |
| Employee Changes | Benefits | Benefits |
| Employee Lifecycle & Relations | Work queue | Any of Onboarding and Transitions, Employee Relations, or Manager Self-Service |
| Employee Lifecycle & Relations | My Team | Manager Self-Service |
| Employee Lifecycle & Relations | Onboarding, probation, employee changes | Onboarding and Transitions |
| Employee Lifecycle & Relations | Relations | Employee Relations |
| Employee Lifecycle & Relations | Recruitment | Talent Acquisition |
| Employee Lifecycle & Relations | Exit | Any of Onboarding and Transitions or Employee Relations |
| Time & Attendance | Leave requests, handovers, balances, controls | Leave and Absence |
| Time & Attendance | Attendance and overtime | Time and Attendance |
| Time & Attendance | Rosters | Scheduling and Coverage |
| Payroll Processing | Enrollment, periods, runs, payment batches, remittances | Payroll |
| Recruitment | Requisitions, candidates, applications, interviews, assessments, checks, offers | Talent Acquisition |
| Performance & Development | Reviews and targets | Performance and Goals |
| Performance & Development | Training and skills | Learning and Development |
| Performance & Development | Rewards | Compensation |
| Performance & Development | Succession | Career and Succession |
When a saved ?tab= is no longer available, the workspace selects its first visible tab. My HR is presented as an Employee Self-Service area, and its individual tabs combine their own permission with the capability they need: profile uses Employee Self-Service, payslips use Payroll, leave uses Leave and Absence, attendance uses Time and Attendance, and documents use Documents and Compliance. If capability evidence is unavailable during migration, the frontend's compatibility path preserves the existing permission-based view; that fallback is not proof that the capability is active and does not replace backend authorization.
Two route-level requirements need alignment with their tabs: Time & Attendance Setup omits Scheduling and Coverage even though its Shifts tab uses it; Talent & Benefits Setup omits Onboarding and Transitions even though its Onboarding Checklists tab uses it. With only either of those capabilities enabled, the route may be hidden and strand an otherwise eligible tab.
Where an administrator manages capabilities
Capability selection is a company-service administration task, not an HR Setup task. In the administration interface, open Administration → Companies, select the company and its service instance, then use Capabilities to review or change statuses. Always verify the exact company-service context: changing Community Finance & HR does not change a separate HR & Payroll instance.
Before activation, confirm the service instance, review dependencies and linked seed packs, ensure Workforce Core and shared platform foundations are available, activate only what the tenant intends to use, and separately review permissions, HR setup records, accounting/payment setup, and integration configuration. Request seed synchronization only when the listed files are wanted and the tenant is ready. Then verify navigation, API access, data scope, and at least one end-to-end workflow as both an authorized and unauthorized user.
Before suspension or retirement, check dependencies and active workflows, retain a reason/audit trail, and plan historical-data access. Do not delete records merely to make an inactive package appear empty.
Current implementation and gaps
The following are code-level findings from the merged frontend develop and the current backend develop source reviewed for this guide. They are not claims about the live status of a particular tenant.
- The frontend now gates HR navigation, routes, and tabs. The merged frontend defines HR route requirements, prunes capability-mapped entries from the permission-derived navigation tree, and hides tabs with
useHrCapabilityTabs. It preserves unknown/legacy entries and existing navigation when the active service has no capability evidence. AVAILABLEis correctly treated as inactive in the merged frontend. The active status set includesACTIVE,DEFAULT_ENABLED, andREQUIRED;AVAILABLE,SUSPENDED,RETIRED, and inactive states are excluded. The backend guard also treats an explicitAVAILABLEoverride as inactive.- The frontend migration fallback is intentionally permissive when capability evidence is absent. The route guard and tab helper retain existing UI when the service response has no capability list. This is useful during rollout, but a missing capability response does not prove a package was enabled. API authorization must remain authoritative.
- Some workspace-level and tab-level requirements are inconsistent. Time & Attendance Setup omits
HR_SCHEDULING_AND_COVERAGEfrom its route-level requirement even though its Shifts tab uses that capability; Talent & Benefits Setup omitsHR_ONBOARDING_AND_TRANSITIONSeven though its Onboarding Checklists tab uses it. Those mappings should be aligned so a single eligible tab is not stranded behind a hidden workspace. - The merged backend now applies capability middleware across the main HR route families.
createHrRouteHandlerreceives an explicit capability code and installs the genericrequireServiceCapabilitiesmiddleware while retaining each route's existing permissions. Employee routes use Workforce Core; payroll, benefits, leave, attendance, scheduling, recruitment, onboarding, performance, compensation, succession, and other route families use their corresponding package codes. The generic middleware's permission fallback is only for unmaterialized capability configuration or an unavailable capability schema; normal active/inactive capability results remain authoritative. - Travel Expense is a route-wiring exception that still needs resolution. The mounted
/api/travel-expenserouter is built directly withcreateRouteHandler, not the HR capability wrapper. Its checked-in route list exposes expense categories and legacy expense reports, but does not declare the/travel-requests,/travel-claims, or transition routes called by the current frontend. The controller, service methods, and SQL procedures exist, but that alone does not make the endpoints reachable. The route family needs explicit capability and permission wiring before this workflow can be considered API-verified. - Required status needs an invariant at update time. Workforce Core is marked required in the service blueprint. The current service update path checks active dependents before deactivation; it should also ensure a required capability cannot be overridden into an inactive state.
The merged frontend controls HR presentation and the main HR backend route families now enforce service capabilities in addition to route permissions. Known follow-up work is narrower: align the two route/tab mappings above, wire the Travel request/claim API paths through the proper capability-aware router, and enforce the required-capability invariant on service updates. These are source-level findings; they do not assert the live state of any tenant or deployed database.
Verification checklist
For each package, verify all of the following in a configured tenant/service:
- The service blueprint offers it with the intended required, default-enabled, or available state.
- The tenant capability readback returns the effective state and seed-pack mapping for the correct
company_service_id. - Activation rejects missing dependencies and records an auditable change.
- An inactive package is hidden from its menu/tab and direct navigation is blocked, without hiding unrelated HR areas.
- The API rejects a manually constructed request for an inactive package.
- A user without the relevant permission remains blocked when the package is active; no role is changed by activation.
- Self-service reads/writes are scoped server-side to the employee or authorized reporting hierarchy.
- Missing-registry compatibility behavior requires existing verified permissions and is auditable.
- Seed synchronization is repeatable and loads only the mapped seed boundary, not operational HR data.
- Service switching refreshes capability state, permissions, navigation, tabs, and API context.
- Historical records remain protected and available for authorized audit/retention even when a package is suspended.
Capability readiness requires agreement between source definitions, seed generation, tenant/service readbacks, frontend behavior, API enforcement, and permission behavior. A successful seed or a hidden menu alone is insufficient.