[User Story] Govern workforce presence, absence, and status as institutional context #44

New Issue

2026-08-06T14:10:03+02:00

zemion commented

2026-08-06 14:10:03 +02:00

Outcome

As an institution, we can represent effective-dated presence, absence, sickness, availability, and related workforce context so work routing, planning, notifications, and policy react consistently without conflating those facts with account or identity lifecycle state.

The discovery also covers time recording, sickness continuation, return-to-work management, applicant management, and an LBV Baden-Wuerttemberg integration profile. It must decide whether these form one bounded workforce package or enter through existing modules and connectors.

Acceptance criteria

Separate valid-time workforce facts from IDM/account lifecycle and from display-only presence.
Define privacy, purpose, retention, delegation, correction, and restricted health-data handling.
Identify consumers such as Tasks, Calendar, Mail, Tickets, Notifications, Reporting, Workflow Engine, Organizations, and Policy through Core-mediated contracts.
Select one real reference journey and source authority before creating another module boundary.
Define native, imported, synchronized, and link-only provider modes, including an LBV prototype candidate.
Add German-reference terminology and configured documentation.

Source orientation: docs/PRODUCT_INPUT_REGISTER.md.

## Outcome As an institution, we can represent effective-dated presence, absence, sickness, availability, and related workforce context so work routing, planning, notifications, and policy react consistently without conflating those facts with account or identity lifecycle state. The discovery also covers time recording, sickness continuation, return-to-work management, applicant management, and an LBV Baden-Wuerttemberg integration profile. It must decide whether these form one bounded workforce package or enter through existing modules and connectors. ## Acceptance criteria - Separate valid-time workforce facts from IDM/account lifecycle and from display-only presence. - Define privacy, purpose, retention, delegation, correction, and restricted health-data handling. - Identify consumers such as Tasks, Calendar, Mail, Tickets, Notifications, Reporting, Workflow Engine, Organizations, and Policy through Core-mediated contracts. - Select one real reference journey and source authority before creating another module boundary. - Define native, imported, synchronized, and link-only provider modes, including an LBV prototype candidate. - Add German-reference terminology and configured documentation. Source orientation: `docs/PRODUCT_INPUT_REGISTER.md`.

zemion added the module/policy

status

triage

module/idm codex/needs-human

type

user-story

module/organizations module/tasks area/governance

priority

p2

labels 2026-08-06 14:10:03 +02:00

zemion commented

2026-08-21 14:22:26 +02:00

Decision checkpoint before implementation:

Choose the owning boundary: recommend Organizations/IDM own assignments and people, a bounded workforce-status capability owns presence/absence facts, Policy owns purpose/visibility rules, and Tasks only consumes an effective availability signal.
Choose the first authoritative source and correction authority; define whether GovOPlaN is read-only, may approve corrections, or may write back.
Approve the minimum status vocabulary and explicitly exclude diagnoses/free-text health details from ordinary status. Restricted absence evidence needs separate purpose, visibility, retention, and audit rules.
Define effective-time, delegation, stale/offline, conflict, and manager/self-service precedence.

Manual inputs: a synthetic reference roster/status feed or sandbox, approved role/visibility matrix, retention schedule, and reference-journey acceptance cases. With those decisions, a provider-neutral effective-status contract and local governed provider can be implemented before any external adapter.

Decision checkpoint before implementation: - Choose the owning boundary: recommend Organizations/IDM own assignments and people, a bounded workforce-status capability owns presence/absence facts, Policy owns purpose/visibility rules, and Tasks only consumes an effective availability signal. - Choose the first authoritative source and correction authority; define whether GovOPlaN is read-only, may approve corrections, or may write back. - Approve the minimum status vocabulary and explicitly exclude diagnoses/free-text health details from ordinary status. Restricted absence evidence needs separate purpose, visibility, retention, and audit rules. - Define effective-time, delegation, stale/offline, conflict, and manager/self-service precedence. Manual inputs: a synthetic reference roster/status feed or sandbox, approved role/visibility matrix, retention schedule, and reference-journey acceptance cases. With those decisions, a provider-neutral effective-status contract and local governed provider can be implemented before any external adapter.

zemion added

and removed

labels 2026-08-21 14:22:27 +02:00

zemion commented

2026-08-23 11:23:49 +02:00

Decision recorded 2026-08-23: the recommended boundary is approved. Workforce presence, availability and absence will be modeled as effective-dated institutional facts, separate from account/identity lifecycle; restricted health facts remain purpose-bound and separately authorized. Native governed facts are the first reference mode, with external/LBV adapters added only against an authorized interface and test environment. The provider-neutral first slice can proceed autonomously; an LBV target test still requires external access.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#44