From 03d168310f263f85f78e392683fc2d77c25eb4e0 Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Fri, 10 Jul 2026 12:51:22 +0200 Subject: [PATCH] chore: sync GovOPlaN module split state --- docs/SERVICE_DIRECTORY_CONCEPT.md | 58 +++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 docs/SERVICE_DIRECTORY_CONCEPT.md diff --git a/docs/SERVICE_DIRECTORY_CONCEPT.md b/docs/SERVICE_DIRECTORY_CONCEPT.md new file mode 100644 index 0000000..ea53bd6 --- /dev/null +++ b/docs/SERVICE_DIRECTORY_CONCEPT.md @@ -0,0 +1,58 @@ +# Role-Based Service Directory Concept + +GovOPlaN Portal should expose a role-aware service directory. The directory is +not a marketing catalogue; it is the user-facing map of what a person can do in +the configured institution. + +## Purpose + +The service directory should help users find the right administrative action +without knowing the internal module layout. Available services depend on +tenant, role, organization unit, policies, installed modules, and configuration +packages. + +Examples: + +- apply for a permit +- submit documents for an existing case +- request an appointment +- send a secure postbox message +- report an issue +- book a resource +- start an internal workflow + +## Contract + +A service entry should describe: + +- service key and label +- owning module or configuration package +- audience and role/function requirements +- required installed/enabled modules +- required capabilities +- form, workflow, postbox, task, or external connector entry point +- policy and availability blockers +- user-facing explanation and required documents +- audit and evidence expectations + +The portal should request service contributions through core-mediated +capability and UI contribution contracts. It must not import domain module +internals. + +Service visibility must consume access semantics through kernel capabilities: + +- `access.semanticDirectory` resolves the actor's identity, account, + organization-unit function assignments, delegations, and role mappings. +- `access.explanation` provides the explanation shown when a service is + available or blocked because of a missing function, role, right, or policy. + +Service entries should support function requirements directly, not only role +requirements. A function requirement may apply to one organization unit or to +that unit and all subunits, matching the access assignment scope. + +## UX Rule + +The directory should explain unavailable services when the reason is useful: +missing role, disabled module, tenant policy, missing connector, maintenance +mode, or unavailable external provider. It should hide only services that are +irrelevant or intentionally undiscoverable by policy.