Sync wiki from project files

Codex-Project-Index.md

@@ -6,4 +6,5 @@ This page is generated from repository and product-directory project files.
 
 - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-access/README.md`
 - [Repo-docs-ACCESS-MODULE-BOUNDARY](Repo-docs-ACCESS-MODULE-BOUNDARY) - `/mnt/DATA/git/govoplan-access/docs/ACCESS_MODULE_BOUNDARY.md`
+- [Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL](Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL) - `/mnt/DATA/git/govoplan-access/docs/IDENTITY_ACCOUNT_FUNCTION_MODEL.md`
 - [Repo-docs-OPENDESK-IDENTITY-BOUNDARY](Repo-docs-OPENDESK-IDENTITY-BOUNDARY) - `/mnt/DATA/git/govoplan-access/docs/OPENDESK_IDENTITY_BOUNDARY.md`

Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md

@@ -0,0 +1,64 @@
+<!-- codex-wiki-sync:563b1b7d950e185399744df6 -->
+
+> Mirrored from `/mnt/DATA/git/govoplan-access/docs/IDENTITY_ACCOUNT_FUNCTION_MODEL.md`.
+> Origin: `repository`.
+> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
+
+---
+# Identity, Account, Function, Role, And Right Model
+
+GovOPlaN access should distinguish identity facts from organizational
+responsibility and authorization decisions.
+
+Directory services, identity providers, and IDM systems may authenticate people
+and provide membership facts. GovOPlaN access owns the platform projection used
+for sessions, tenant membership, groups, functions, roles, delegation, and
+permission decisions.
+
+## Semantic Layers
+
+- Identity: the real person, service, or external subject.
+- Account: the login or technical account used to authenticate.
+- Tenant membership: the person's participation in a tenant.
+- Organization unit: the administrative unit where responsibility applies.
+- Function: a responsibility held in an organization unit, such as case clerk,
+  intake desk, treasurer, or committee secretary.
+- Role: a permission bundle or workflow authority attached to a function,
+  group, or explicit assignment.
+- Right: the concrete scope or action permission evaluated at runtime.
+
+The UI and API should avoid collapsing these layers into one generic group
+concept. Directory groups can feed mappings, but they should not silently become
+business authority without a governed mapping rule.
+
+## Boundary
+
+Access owns:
+
+- account and tenant membership projection
+- groups, roles, function assignments, and delegation facts
+- permission decisions and explain responses
+- identity and membership change events
+- SCIM/OIDC/SAML/LDAP mapping effects when implemented
+
+Access does not own:
+
+- mailboxes, calendars, files, cases, tasks, or postboxes
+- module-specific ACL records beyond stable principal/group/role references
+- external provider internals except where they mutate access-owned state
+
+## Required Explainability
+
+Access decisions should be explainable in concrete terms:
+
+- actor identity/account
+- tenant membership
+- organization unit
+- function assignment or group membership
+- role source
+- permission/right checked
+- delegation or system-actor context
+- policy or lock that changed the result
+
+This shape is required for postbox role access, workflow actions, service
+directory personalization, delegated administration, and audit review.