diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 00000000..0c19bffd
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,84 @@
+# Procest Documentation
+
+Procest is a case management (zaakgericht werken) application for Nextcloud, designed for Dutch government organizations. It provides a complete case management solution built on top of OpenRegister.
+
+## Screenshots
+
+| Feature | Screenshot |
+|---------|------------|
+| Dashboard | ![Dashboard](screenshots/dashboard.png) |
+| My Work | ![My Work](screenshots/my-work.png) |
+| Cases | ![Cases](screenshots/case-management.png) |
+| Tasks | ![Tasks](screenshots/task-management.png) |
+| Case Types | ![Case Types](screenshots/case-types.png) |
+| Admin Settings | ![Settings](screenshots/admin-settings.png) |
+| ZGW Configuration | ![ZGW Config](screenshots/zaaktype-configuratie.png) |
+
+## Feature Documentation
+
+### Core Features (with screenshots)
+
+| Feature | Description | Status |
+|---------|-------------|--------|
+| [Dashboard](features/dashboard.md) | Overview with case statistics, status chart, and personal work queue | Implemented |
+| [Case Management](features/case-management.md) | List, filter, and manage cases in table or card view | Implemented |
+| [Case Dashboard View](features/case-dashboard-view.md) | Individual case detail page with status, tasks, and documents | In development |
+| [My Work](features/my-work.md) | Personal work queue showing assigned cases and tasks | Implemented |
+| [Task Management](features/task-management.md) | List, create, and manage tasks associated with cases | Implemented |
+| [Case Types](features/case-types.md) | Configure case type definitions with ZGW-compliant properties | Implemented |
+| [Admin Settings](features/admin-settings.md) | Application configuration, schema mapping, and version info | Implemented |
+| [Zaaktype Configuratie](features/zaaktype-configuratie.md) | ZGW API field mapping between OpenRegister and Dutch ZGW standard | Implemented |
+
+### Case Processing Features (text-only)
+
+| Feature | Description | Status |
+|---------|-------------|--------|
+| [Werkvoorraad](features/werkvoorraad.md) | Team work queue for unassigned cases | Planned |
+| [Roles and Decisions](features/roles-decisions.md) | Role assignment and formal decision recording | Partial |
+| [Zaak Intake Flow](features/zaak-intake-flow.md) | Case registration and intake process | Planned |
+| [Complaint Management](features/complaint-management.md) | Citizen complaint handling (klachtafhandeling) | Planned |
+| [Consultation Management](features/consultation-management.md) | Public participation and consultation processes | Planned |
+| [Milestone Tracking](features/milestone-tracking.md) | Case lifecycle checkpoint monitoring | Planned |
+| [Case Email Integration](features/case-email-integration.md) | Email-to-case and case correspondence | Planned |
+| [WOO Case Type](features/woo-case-type.md) | Open Government Act disclosure requests | Planned |
+| [VTH Module](features/vth-module.md) | Permits, supervision, and enforcement | Planned |
+| [Case Sharing](features/case-sharing-collaboration.md) | Multi-user and cross-org case collaboration | In development |
+| [AI-Assisted Processing](features/ai-assisted-processing.md) | LLM-powered case analysis and document processing | In development |
+
+### Administrative Features (text-only)
+
+| Feature | Description | Status |
+|---------|-------------|--------|
+| [Appointment Scheduling](features/appointment-scheduling.md) | Meeting and hearing scheduling | Planned |
+| [B&W Parafering](features/bw-parafering.md) | Executive approval workflow | Planned |
+| [Legesberekening](features/legesberekening.md) | Municipal fee calculation | Planned |
+| [Mobiel Inspectie](features/mobiel-inspectie.md) | Mobile field inspection interface | Planned |
+
+### Integration Features (text-only)
+
+| Feature | Description | Status |
+|---------|-------------|--------|
+| [OpenRegister Integration](features/openregister-integration.md) | Core data layer via OpenRegister | Implemented |
+| [MijnOverheid Integration](features/mijn-overheid-integration.md) | National citizen portal integration | Planned |
+| [StUF Support](features/stuf-support.md) | Legacy Dutch government data exchange | Planned |
+
+### Platform Features (text-only)
+
+| Feature | Description | Status |
+|---------|-------------|--------|
+| [Prometheus Metrics](features/prometheus-metrics.md) | Production monitoring and alerting | Planned |
+| [Register i18n](features/register-i18n.md) | Multilingual support (nl/en) | Partial |
+| [Base Register Seed Data](features/base-register-seed-data.md) | Pre-configured case types and definitions | Implemented |
+| [Multi-Tenant SaaS](features/multi-tenant-saas.md) | Multi-organization support | Planned |
+| [Case Definition Portability](features/case-definition-portability.md) | Export/import case type configurations | Planned |
+
+## Architecture
+
+Procest is built as a Nextcloud app with the following architecture:
+
+- **Frontend**: Vue.js single-page application within the Nextcloud framework.
+- **Backend**: PHP (Nextcloud app structure with controllers, services, and mappers).
+- **Data Layer**: OpenRegister (flexible register/schema/object model).
+- **API**: ZGW-compatible REST API via configurable field mapping.
+- **AI**: Integration with Nextcloud ExApps (Ollama, Presidio, etc.).
+- **Theming**: NL Design System tokens via the nldesign Nextcloud app.
diff --git a/docs/features/admin-settings.md b/docs/features/admin-settings.md
new file mode 100644
index 00000000..64158e95
--- /dev/null
+++ b/docs/features/admin-settings.md
@@ -0,0 +1,34 @@
+# Admin Settings (Configuration)
+
+The Configuration page (under Settings) provides the central administration panel for Procest.
+
+![Admin Settings](../screenshots/admin-settings.png)
+
+## Overview
+
+The Configuration page displays:
+
+### Version Information
+- Application name and version
+- Update status indicator
+- Re-import configuration button for resetting to defaults
+
+### Application Information
+- **Application Name**: Procest
+- **Version**: Displays the current installed version
+
+### Support
+- Support email: support@conduction.nl
+- SLA inquiries: sales@conduction.nl
+
+## Schema Configuration
+
+The configuration section allows administrators to map Procest to OpenRegister schemas. See the [Case Types](case-types.md) documentation for the full list of configurable schema mappings.
+
+## ZGW API Mapping
+
+![ZGW API Mapping](../screenshots/zaaktype-configuratie.png)
+
+The settings page includes the ZGW (Zaakgericht Werken) API mapping configuration, which maps English-language OpenRegister property names to their Dutch ZGW API equivalents. This ensures compatibility with the Dutch government's ZGW standard for case management.
+
+Each ZGW resource type (zaak, zaaktype, status, etc.) can be individually configured with custom field mappings.
diff --git a/docs/features/ai-assisted-processing.md b/docs/features/ai-assisted-processing.md
new file mode 100644
index 00000000..e426ca3d
--- /dev/null
+++ b/docs/features/ai-assisted-processing.md
@@ -0,0 +1,30 @@
+# AI-Assisted Processing
+
+The AI-assisted processing feature leverages large language models and AI services to assist case workers with case analysis, document processing, and decision support.
+
+## Overview
+
+AI-assisted processing integrates with Nextcloud's AI infrastructure (ExApps like Ollama and OpenWebUI) to provide intelligent assistance during case handling.
+
+## Planned Features
+
+- **Document summarization** -- Automatically summarize long documents attached to cases.
+- **Classification** -- Auto-classify incoming cases by type based on content analysis.
+- **Anonymization** -- Redact personal data from documents for WOO publication using Presidio.
+- **Suggested responses** -- Generate draft responses based on case content and templates.
+- **Similar case finding** -- Find historically similar cases to inform decision-making.
+- **Deadline risk assessment** -- Predict which cases are at risk of exceeding their deadline.
+- **Translation** -- Translate case documents for multilingual communication.
+- **Data extraction** -- Extract structured data from unstructured documents.
+
+## AI Infrastructure
+
+Procest leverages the following AI services (available via Docker profiles):
+- **Ollama** -- Local LLM inference.
+- **OpenWebUI** -- Chat interface for AI interaction.
+- **Presidio** -- PII detection and anonymization.
+- **TGI** -- Text Generation Inference for high-performance LLM serving.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/ai-assisted-processing/spec.md` and is under development.
diff --git a/docs/features/appointment-scheduling.md b/docs/features/appointment-scheduling.md
new file mode 100644
index 00000000..d37a50da
--- /dev/null
+++ b/docs/features/appointment-scheduling.md
@@ -0,0 +1,22 @@
+# Appointment Scheduling (Afspraken)
+
+The appointment scheduling feature enables case workers to schedule meetings, hearings, and appointments related to case processing.
+
+## Overview
+
+Many case types require in-person or virtual meetings (e.g., complaint hearings, permit consultations, inspections). This feature integrates appointment scheduling into the case workflow.
+
+## Planned Features
+
+- **Appointment creation** -- Schedule appointments linked to specific cases.
+- **Calendar integration** -- Sync with Nextcloud Calendar for availability management.
+- **Participant management** -- Invite internal and external participants.
+- **Location management** -- Track physical or virtual meeting locations.
+- **Reminder notifications** -- Send reminders to participants before appointments.
+- **Appointment types** -- Configure different appointment types (hearing, consultation, inspection, etc.).
+- **Outcome recording** -- Document appointment outcomes and link them to the case file.
+- **Rescheduling** -- Handle cancellations and rescheduling with notification to all parties.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/appointment-scheduling/spec.md` and is planned for future implementation.
diff --git a/docs/features/base-register-seed-data.md b/docs/features/base-register-seed-data.md
new file mode 100644
index 00000000..ec033784
--- /dev/null
+++ b/docs/features/base-register-seed-data.md
@@ -0,0 +1,32 @@
+# Base Register Seed Data
+
+The base register seed data feature provides pre-configured case types, status types, and role definitions that are automatically imported when Procest is first installed.
+
+## Overview
+
+To provide a functional out-of-the-box experience, Procest includes seed data that sets up common Dutch government case types and their associated configurations.
+
+## Included Seed Data
+
+### Case Types
+- **Bezwaar** -- Objection procedure (openbaar confidentiality).
+- **Vergunning** -- Permit application (openbaar confidentiality).
+- **Melding** -- Public space report (geheim confidentiality).
+- **Vergunning aanvraag** (VRG-001) -- Environmental permit application.
+
+### Status Types
+Pre-defined statuses for the standard case lifecycle.
+
+### Role Types
+Standard roles such as behandelaar (handler), initiator, and belanghebbende (stakeholder).
+
+### Decision Types
+Common decision types for government case processing.
+
+## Import Mechanism
+
+Seed data is imported via the "Re-import configuration" button in the Settings > Case Types page. This reads JSON seed files bundled with the application and creates the corresponding OpenRegister objects.
+
+## Status
+
+This feature is implemented. Seed data is automatically imported on first install and can be re-imported via the admin settings.
diff --git a/docs/features/bw-parafering.md b/docs/features/bw-parafering.md
new file mode 100644
index 00000000..962573c5
--- /dev/null
+++ b/docs/features/bw-parafering.md
@@ -0,0 +1,26 @@
+# B&W Parafering (Executive Approval Workflow)
+
+The B&W parafering feature implements the formal approval workflow for decisions that require authorization by the Board of Mayor and Aldermen (College van Burgemeester en Wethouders).
+
+## Overview
+
+In Dutch municipal government, certain decisions must be formally approved (geparafeerd) by the B&W (Board of Mayor and Aldermen). This feature provides a structured digital approval workflow.
+
+## Planned Features
+
+- **Approval routing** -- Route decisions through the required approval chain.
+- **Digital signing** -- Support for digital parafering (initialing/signing) by authorized officials.
+- **Mandate checking** -- Verify that the approver has the required mandate for the decision type.
+- **Approval history** -- Track the full approval chain with timestamps and approver identities.
+- **Rejection handling** -- Handle rejections with feedback and re-routing.
+- **B&W agenda integration** -- Link approval items to B&W meeting agendas.
+- **Delegation** -- Support for delegated approval authority.
+- **Batch approval** -- Allow authorized officials to approve multiple items in a single session.
+
+## Legal Context
+
+Municipal decisions often require formal authorization at specific mandate levels. The B&W parafering workflow ensures compliance with the municipality's mandate register (mandaatregister).
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/bw-parafering/spec.md` and is planned for future implementation.
diff --git a/docs/features/case-dashboard-view.md b/docs/features/case-dashboard-view.md
new file mode 100644
index 00000000..7e932882
--- /dev/null
+++ b/docs/features/case-dashboard-view.md
@@ -0,0 +1,25 @@
+# Case Dashboard View
+
+The case dashboard view shows the detail page for an individual case, accessible by clicking on a case from the My Work list or the Cases list.
+
+![Case Dashboard View](../screenshots/case-dashboard-view.png)
+
+## Overview
+
+The case detail view is accessed via the URL pattern `/apps/procest/cases/{uuid}`. When navigating to a specific case (e.g., from the My Work list), the application loads the case detail page.
+
+## Current State
+
+The case detail view is under active development. The page loads at the correct route but the content area is currently blank, indicating that the case dashboard component is still being implemented.
+
+## Planned Features
+
+Based on the spec, the case dashboard view will include:
+
+- **Case header** -- Title, identifier, status badge, and case type.
+- **Status timeline** -- Visual representation of the case lifecycle stages.
+- **Case details panel** -- Key properties such as dates, handler, initiator, and confidentiality level.
+- **Tasks section** -- List of tasks associated with the case.
+- **Documents section** -- Attached documents and correspondence.
+- **Audit trail** -- History of status changes and actions taken on the case.
+- **Actions** -- Buttons for common operations like changing status, adding tasks, or uploading documents.
diff --git a/docs/features/case-definition-portability.md b/docs/features/case-definition-portability.md
new file mode 100644
index 00000000..cd933ffc
--- /dev/null
+++ b/docs/features/case-definition-portability.md
@@ -0,0 +1,27 @@
+# Case Definition Portability
+
+The case definition portability feature enables exporting and importing case type configurations between Procest instances.
+
+## Overview
+
+Organizations should be able to share their case type definitions, workflows, and configurations with other Procest users. This feature provides standardized export/import capabilities.
+
+## Planned Features
+
+- **Export** -- Export case type definitions as portable JSON/YAML packages.
+- **Import** -- Import case type definitions from other Procest instances.
+- **Version management** -- Track versions of case type definitions.
+- **Marketplace** -- Share case type definitions through a central catalog (e.g., via OpenCatalogi).
+- **Dependency resolution** -- Handle dependencies between case types (e.g., sub-case types, related schemas).
+- **Migration** -- Support upgrading case type definitions while preserving existing case data.
+- **Validation** -- Validate imported definitions before applying them.
+
+## Use Cases
+
+- A municipality develops a specialized WOO case type and shares it with other municipalities.
+- A software vendor provides pre-built case type packages for common government processes.
+- An organization migrates case type definitions from a test environment to production.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/case-definition-portability/spec.md` and is planned for future implementation.
diff --git a/docs/features/case-email-integration.md b/docs/features/case-email-integration.md
new file mode 100644
index 00000000..b136db2e
--- /dev/null
+++ b/docs/features/case-email-integration.md
@@ -0,0 +1,22 @@
+# Case Email Integration
+
+The case email integration feature enables linking email communication to cases and creating cases from incoming emails.
+
+## Overview
+
+Email is a common communication channel in Dutch government case processing. This feature bridges email and case management to ensure all correspondence is properly filed and traceable.
+
+## Planned Features
+
+- **Incoming email to case** -- Automatically or manually create cases from incoming emails.
+- **Email filing** -- Associate sent and received emails with existing cases.
+- **Email templates** -- Predefined templates for common case correspondence.
+- **Correspondence tracking** -- Track all email interactions within the case audit trail.
+- **Attachment handling** -- Automatically attach email attachments as case documents.
+- **Notification emails** -- Send automated status update emails to case participants.
+- **Reply tracking** -- Link email replies back to the originating case.
+- **Integration with Nextcloud Mail** -- Leverage the built-in Nextcloud Mail app for email handling.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/case-email-integration/spec.md` and is planned for future implementation.
diff --git a/docs/features/case-management.md b/docs/features/case-management.md
index f2ea9047..d66624c2 100644
--- a/docs/features/case-management.md
+++ b/docs/features/case-management.md
@@ -1,83 +1,32 @@
 # Case Management
 
-Core entity and lifecycle for tracking structured work. A case is a coherent body of work with defined status phases, deadlines, and outcomes, following CMMN 1.1 concepts.
+The Cases view provides a list of all cases in the system, with support for table and card display modes.
 
-## Specs
+![Case Management](../screenshots/case-management.png)
 
-- `openspec/specs/case-management/spec.md`
+## Overview
 
-## Features
+The cases list supports two view modes, toggled via the Cards/Table radio buttons:
 
-### Case CRUD (MVP)
+- **Table view** (default) -- Displays cases in a sortable, column-based table.
+- **Cards view** -- Displays cases as individual cards for a more visual layout.
 
-Full create, read, update, and delete for case records. Cases are stored as `schema:Project` in OpenRegister.
+## Actions
 
-- Case list view with search, sort, filter, and pagination
-- Case detail view with panels for status, deadline, participants, properties, documents, tasks, decisions, and activity
-- Fields: title, description, status, deadline, handler, caseType, result, confidentiality, parentCase
-- Case type validation on creation (inherits allowed statuses, deadline rules, etc.)
+- **Add Item** -- Creates a new case.
+- **Actions** -- Bulk actions menu for selected cases.
 
-### Case List View (MVP)
+## Current State
 
-Data-dense table view for browsing and managing cases:
+The case list view is functional but depends on the OpenRegister object type "case" being properly registered. If the object type is not configured, a "No items found" message is displayed.
 
-- Search across title and description
-- Filter by status, case type, handler
-- Sort by deadline, status, created date
-- Quick status change directly from list rows
+## Data Model
 
-### Case Detail View (MVP)
-
-Comprehensive detail layout with multiple information panels:
-
-- Status timeline visualization showing passed/current/future statuses
-- Deadline countdown (days remaining or days overdue)
-- Participants panel showing assigned roles
-- Custom properties panel (from case type definitions)
-- Required documents checklist
-- Tasks section with linked task list
-- Decisions section
-- Activity timeline
-
-### Status Lifecycle (MVP)
-
-Cases progress through statuses defined by their case type. Status changes are constrained by the case type configuration and recorded in the audit trail.
-
-- Status timeline visualization on detail view
-- Quick status change from list view
-- Status history tracking
-
-### Case Result Recording (MVP)
-
-When a case reaches a terminal status, a result is recorded documenting the outcome. Results link to result types defined in the case type.
-
-### Case Deadline (MVP)
-
-Processing deadlines are auto-calculated from the case type's duration configuration (ISO 8601). The detail view shows a countdown with days remaining or days overdue indicator.
-
-### Case Validation Rules (MVP)
-
-- Title is required
-- Case type must be valid and published
-- Status must be an allowed status for the case type
-- Deadline auto-calculated from case type duration
-
-### Audit Trail (MVP)
-
-Full audit trail tracking who changed what and when, including status transitions, field changes, and participant modifications.
-
-### Planned (V1)
-
-- Sub-cases (parent/child hierarchy)
-- Document completion checklist (required vs present)
-- Property completion indicator (% required fields filled)
-- Days in current status indicator
-- Case suspension and extension
-- Confidentiality levels
-- Case templates and cloning
-
-### Planned (Enterprise)
-
-- CMMN runtime (sentries, entry/exit criteria)
-- Bulk case operations
-- Configurable status workflows per type
+Cases are stored as OpenRegister objects backed by a configurable schema. Each case typically contains:
+- Case identifier (e.g., ZAAK-TEST-004)
+- Title
+- Status
+- Assigned handler
+- Start date and deadline
+- Case type reference
+- Related documents and tasks
diff --git a/docs/features/case-sharing-collaboration.md b/docs/features/case-sharing-collaboration.md
new file mode 100644
index 00000000..1e3b6c70
--- /dev/null
+++ b/docs/features/case-sharing-collaboration.md
@@ -0,0 +1,22 @@
+# Case Sharing and Collaboration
+
+The case sharing and collaboration feature enables multiple users and organizations to work together on cases.
+
+## Overview
+
+Government case processing often requires collaboration between departments, organizations, or external parties. This feature provides the tools to share cases and collaborate securely.
+
+## Planned Features
+
+- **Case sharing** -- Share cases with other users or groups within the Nextcloud instance.
+- **Cross-organization sharing** -- Share cases with users in federated Nextcloud instances.
+- **Role-based access** -- Define what shared users can see and do (view, edit, comment).
+- **Commenting** -- Add comments and notes to shared cases.
+- **Activity feed** -- Track all collaborative actions on a case.
+- **Notifications** -- Notify collaborators of case changes.
+- **Document co-editing** -- Collaboratively edit case documents using Nextcloud's built-in editing capabilities.
+- **Handoff workflows** -- Formally transfer case responsibility between handlers or departments.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/case-sharing-collaboration/spec.md` and is under development.
diff --git a/docs/features/case-types.md b/docs/features/case-types.md
index e1297c4e..5eca6d04 100644
--- a/docs/features/case-types.md
+++ b/docs/features/case-types.md
@@ -1,65 +1,41 @@
 # Case Types
 
-Configuration system that controls case behavior. Case types define the allowed statuses, results, roles, custom fields, document requirements, and processing rules for cases.
-
-## Specs
-
-- `openspec/specs/case-types/spec.md`
-
-## Features
-
-### Case Type CRUD (MVP)
-
-Full create, read, update, and delete for case type configurations.
-
-- Fields: title, description, processingDeadline (ISO 8601 duration), defaultConfidentiality, validFrom, validUntil
-- Case types contain sub-collections: statusTypes, resultTypes, roleTypes, propertyDefinitions, documentTypes, decisionTypes
-
-### Draft/Published Lifecycle (MVP)
-
-Case types follow a two-phase lifecycle:
-
-- **Draft**: Can be freely edited. Cannot be used to create cases.
-- **Published**: Active and available for case creation. Changes require careful consideration.
-
-### Validity Periods (MVP)
-
-Case types have optional `validFrom` and `validUntil` dates, enabling version management. Only valid case types are available for new case creation.
-
-### Status Type Management (MVP)
-
-Ordered list of allowed statuses for the case type. Each status type has a name and order. Statuses define the lifecycle phases a case can progress through.
-
-- Add, reorder, edit, and delete status types
-- Order determines the expected progression sequence
-
-### Processing Deadline Configuration (MVP)
-
-ISO 8601 duration (e.g., `P30D` for 30 days, `P6W` for 6 weeks) that auto-calculates case deadlines from creation date.
-
-### Default Case Type Selection (MVP)
-
-One case type can be marked as the default, pre-selected when creating new cases.
-
-### Case Type Validation Rules (MVP)
-
-- Title is required
-- At least one status type required before publishing
-- Processing deadline must be valid ISO 8601 duration
-- validFrom must be before validUntil when both set
-
-### Planned (V1)
-
-- Extension and suspension configuration (rules for deadline modification)
-- Result type management (with archival rules: `bewaren` / `vernietigen`)
-- Role type management (with generic role mapping)
-- Property definition management (custom fields with type/validation)
-- Document type management (with direction: incoming/internal/outgoing)
-- Decision type management
-- Confidentiality default settings
-
-### Planned (Enterprise)
-
-- Case type versioning chains (auditable type evolution)
-- Case type import/export
-- Sub-case type restrictions
+The Case Types page (under Settings) allows administrators to manage case type definitions and their configurations.
+
+![Case Types](../screenshots/case-types.png)
+
+## Overview
+
+The page is divided into several sections:
+
+### Version Information
+Displays application metadata:
+- **Application Name**: Procest
+- **Version**: Current installed version
+- **Up to date**: Status indicator for configuration currency
+- **Re-import configuration**: Button to re-import default case type configurations
+- **Support**: Contact information for support (support@conduction.nl) and SLA inquiries (sales@conduction.nl)
+
+### Configuration
+Register and schema settings that link Procest to OpenRegister:
+- **Register** -- The OpenRegister register ID used for case data.
+- **Case schema** -- Schema ID for case objects.
+- **Task schema** -- Schema ID for task objects.
+- **Status schema** -- Schema ID for status objects.
+- **Role schema** -- Schema ID for role objects.
+- **Result schema** -- Schema ID for result objects.
+- **Decision schema** -- Schema ID for decision objects.
+- **Case type schema** -- Schema ID for case type definitions.
+- **Status type schema** -- Schema ID for status type definitions.
+
+### Case Type Management
+A table listing all configured case types with ZGW (Zaakgericht Werken) properties including catalogus, confidentiality, description, identifier, processingDeadline, title, and many more.
+
+Example case types include:
+- **Bezwaar** (BEZWAAR) -- Objection procedure, openbaar (public) confidentiality
+- **Vergunning** (VERGUNNING) -- Permit application, openbaar confidentiality
+- **Melding** (MELDING) -- Public space report, geheim (confidential)
+- **Vergunning aanvraag** (VRG-001) -- Environmental permit application
+
+### ZGW API Mapping
+Configuration for property mappings between English OpenRegister fields and Dutch ZGW API fields. Supported resources: zaak, zaaktype, status, statustype, resultaat, resultaattype, rol, roltype, eigenschap, besluit, besluittype, informatieobjecttype. Each mapping can be edited or reset to defaults.
diff --git a/docs/features/complaint-management.md b/docs/features/complaint-management.md
new file mode 100644
index 00000000..7a587d27
--- /dev/null
+++ b/docs/features/complaint-management.md
@@ -0,0 +1,30 @@
+# Complaint Management (Klachtafhandeling)
+
+The complaint management feature handles the registration, processing, and resolution of citizen complaints according to Dutch administrative law requirements.
+
+## Overview
+
+Complaint management is a specialized case type within Procest that follows the formal complaint handling procedure (klachtenprocedure) as defined in the Dutch General Administrative Law Act (Awb).
+
+## Planned Features
+
+- **Complaint registration** -- Structured intake form for complaints.
+- **Complaint categorization** -- Classify complaints by type, department, or subject.
+- **Hearing scheduling** -- Schedule and track hearings with the complainant.
+- **Investigation tracking** -- Document the investigation process and findings.
+- **Response deadlines** -- Track and enforce the legally required response periods.
+- **Ombudsman referral** -- Track escalation to the national or municipal ombudsman.
+- **Complaint resolution** -- Record outcomes (founded, unfounded, partially founded).
+- **Follow-up actions** -- Track corrective measures resulting from complaints.
+- **Reporting** -- Statistical reporting on complaint volumes, categories, and resolution times.
+
+## Legal Context
+
+Dutch municipalities are legally required to handle complaints according to Chapter 9 of the Awb, which prescribes:
+- Acknowledgment within 5 working days.
+- Hearing the complainant.
+- Resolution within 6 weeks (extendable by 4 weeks).
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/complaint-management/spec.md` and is planned for future implementation.
diff --git a/docs/features/consultation-management.md b/docs/features/consultation-management.md
new file mode 100644
index 00000000..7bab429e
--- /dev/null
+++ b/docs/features/consultation-management.md
@@ -0,0 +1,29 @@
+# Consultation Management (Inspraak)
+
+The consultation management feature handles public participation and consultation processes related to government decisions and policies.
+
+## Overview
+
+Consultation management supports the formal and informal processes where citizens and stakeholders can provide input on proposed government decisions, spatial plans, or policy changes.
+
+## Planned Features
+
+- **Consultation period management** -- Define start and end dates for consultation windows.
+- **Stakeholder registration** -- Track who has submitted input.
+- **Response collection** -- Collect and categorize consultation responses.
+- **Response processing** -- Review, assess, and respond to each submission.
+- **Consideration report** -- Generate the formal "nota van beantwoording" (response memorandum).
+- **Publication** -- Publish consultation documents and outcomes.
+- **Timeline tracking** -- Ensure compliance with legally mandated consultation periods.
+- **Notification** -- Notify stakeholders of outcomes and decisions.
+
+## Legal Context
+
+Various Dutch laws require public consultation, including:
+- Wet ruimtelijke ordening (Spatial Planning Act)
+- Omgevingswet (Environment and Planning Act)
+- Algemene wet bestuursrecht (General Administrative Law Act)
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/consultation-management/spec.md` and is planned for future implementation.
diff --git a/docs/features/dashboard.md b/docs/features/dashboard.md
index 3498d43c..8b73bbe1 100644
--- a/docs/features/dashboard.md
+++ b/docs/features/dashboard.md
@@ -1,63 +1,42 @@
 # Dashboard
 
-Landing page providing an at-a-glance overview of case activity and personal workload with KPI cards, charts, and quick actions.
+The Procest dashboard is the landing page of the application, providing a high-level overview of the current user's case management workload.
 
-## Specs
+![Dashboard](../screenshots/dashboard.png)
 
-- `openspec/specs/dashboard/spec.md`
+## Overview
 
-## Features
+The dashboard displays four summary cards at the top:
 
-### KPI Cards (MVP)
+- **Open Cases** -- Total number of active/open cases (e.g., 15).
+- **Overdue** -- Cases that have exceeded their processing deadline.
+- **Completed This Month** -- Cases resolved within the current calendar month.
+- **My Tasks** -- Tasks assigned to the current user.
 
-Top row of metric cards showing key case management numbers:
+Below the summary cards, two panels provide quick access to key information:
 
-- Open Cases (count of non-terminal cases)
-- Overdue Cases (cases past their deadline)
-- Completed This Month (cases closed in current month)
-- My Tasks (tasks assigned to current user)
+### Cases by Status
+A horizontal bar chart showing the distribution of cases across different statuses. This gives case workers an immediate sense of the pipeline.
 
-### Cases by Status Chart (MVP)
+### My Work
+A list of cases assigned to the current user, showing:
+- Case type badge (CASE)
+- Case identifier (e.g., #ZAAK-TEST-006)
+- Days remaining until the processing deadline
 
-Visual chart showing the distribution of cases across status values, providing a quick overview of workflow bottleneck areas.
+## Actions
 
-### Overdue Cases Panel (MVP)
+Two primary action buttons are available at the top:
+- **New Case** -- Opens the case creation form.
+- **New Task** -- Opens the task creation form.
+- **Refresh dashboard** -- Reloads dashboard data (disabled when already current).
 
-Dedicated panel listing cases past their processing deadline, sorted by urgency. Direct click-through to case detail.
+## Navigation
 
-### My Work Preview (MVP)
-
-Compact preview of the user's top 5 assigned items (cases + tasks), linking to the full My Work view.
-
-### Quick Actions (MVP)
-
-Shortcut buttons for common operations — primarily "+ New Case" for fast case creation.
-
-### Dashboard Data Scope (MVP)
-
-All dashboard data respects RBAC permissions. Users only see metrics and cases they have access to.
-
-### Empty State (MVP)
-
-Fresh installations show a welcoming empty state with getting-started guidance instead of empty charts and zero-count cards.
-
-### Dashboard Refresh (MVP)
-
-Data refreshes on mount and supports manual refresh for up-to-date metrics.
-
-### Dashboard Layout (MVP)
-
-Responsive grid layout adapting to screen size, with KPI cards on top, charts in the middle, and activity/work previews below.
-
-### Planned (V1)
-
-- Cases by type chart (distribution across case types)
-- Recent activity feed (last 10 case events)
-- Average processing time KPI per case type
-
-### Planned (Enterprise)
-
-- Custom dashboards
-- SLA compliance meter
-- Handler workload heatmap
-- Trend analysis (case volume over time)
+The left sidebar provides navigation to all major sections:
+- Dashboard (current)
+- My Work
+- Cases
+- Tasks
+- Documentation
+- Settings (expandable, with Case Types and Configuration sub-pages)
diff --git a/docs/features/legesberekening.md b/docs/features/legesberekening.md
new file mode 100644
index 00000000..87a2efc3
--- /dev/null
+++ b/docs/features/legesberekening.md
@@ -0,0 +1,22 @@
+# Legesberekening (Fee Calculation)
+
+The legesberekening feature automates the calculation of municipal fees (leges) associated with permit applications and other government services.
+
+## Overview
+
+Dutch municipalities charge fees for various services, particularly permit applications. These fees are defined in the municipal fee ordinance (legesverordening) and can involve complex calculation rules.
+
+## Planned Features
+
+- **Fee schedule management** -- Configure fee schedules based on the municipal legesverordening.
+- **Automatic calculation** -- Calculate fees automatically based on case type and application details.
+- **Fee components** -- Support for multiple fee components (base fee, surcharges, reductions).
+- **Exemptions** -- Handle fee exemptions and reductions.
+- **Fee assessment** -- Generate formal fee assessments (aanslagen).
+- **Payment tracking** -- Track payment status and link to financial systems.
+- **Year-based rates** -- Support different fee rates per calendar year.
+- **Invoice generation** -- Generate invoices for calculated fees.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/legesberekening/spec.md` and is planned for future implementation.
diff --git a/docs/features/mijn-overheid-integration.md b/docs/features/mijn-overheid-integration.md
new file mode 100644
index 00000000..bb59e5c9
--- /dev/null
+++ b/docs/features/mijn-overheid-integration.md
@@ -0,0 +1,26 @@
+# MijnOverheid Integration
+
+The MijnOverheid integration enables citizens to view their case status and receive notifications through the national MijnOverheid portal.
+
+## Overview
+
+MijnOverheid is the Dutch national government portal where citizens can view their personal government-related information. This integration allows Procest to publish case status information to MijnOverheid.
+
+## Planned Features
+
+- **Status publication** -- Publish case status updates to MijnOverheid's Berichtenbox.
+- **Case overview** -- Show active and completed cases on the citizen's MijnOverheid page.
+- **Notifications** -- Send case notifications via MijnOverheid's notification system.
+- **Document sharing** -- Make case documents available through MijnOverheid.
+- **DigiD authentication** -- Support DigiD login for citizen-facing interfaces.
+- **Logius integration** -- Connect via the Logius infrastructure for MijnOverheid communication.
+
+## Technical Requirements
+
+- Compliance with MijnOverheid's API specifications.
+- Secure message delivery via the Berichtenbox standard.
+- BSN (Burgerservicenummer) handling for citizen identification.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/mijn-overheid-integration/spec.md` and is planned for future implementation.
diff --git a/docs/features/milestone-tracking.md b/docs/features/milestone-tracking.md
new file mode 100644
index 00000000..6fefbb1b
--- /dev/null
+++ b/docs/features/milestone-tracking.md
@@ -0,0 +1,27 @@
+# Milestone Tracking
+
+The milestone tracking feature monitors key progress points within a case lifecycle, providing visibility into case processing stages and deadlines.
+
+## Overview
+
+Milestones represent significant events or checkpoints in a case's lifecycle. They help case workers and managers track whether a case is progressing according to schedule.
+
+## Planned Features
+
+- **Milestone definitions** -- Define milestones per case type (e.g., "Intake complete", "Assessment done", "Decision published").
+- **Automatic milestone triggers** -- Milestones triggered automatically by status changes or other events.
+- **Manual milestone recording** -- Allow case workers to manually mark milestones as reached.
+- **Deadline tracking** -- Each milestone can have a target date derived from the case start date and processing rules.
+- **Overdue alerts** -- Notifications when milestones are not reached by their target date.
+- **Visual timeline** -- Display milestones on a visual timeline in the case dashboard view.
+- **Reporting** -- Track milestone completion rates and average time-to-milestone across case types.
+
+## Use Cases
+
+- Track that a permit application has been assessed within the legally mandated 8-week period.
+- Monitor that a complaint hearing was scheduled within 2 weeks of receipt.
+- Verify that all required documents were received before the review deadline.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/milestone-tracking/spec.md` and is planned for future implementation.
diff --git a/docs/features/mobiel-inspectie.md b/docs/features/mobiel-inspectie.md
new file mode 100644
index 00000000..2640c457
--- /dev/null
+++ b/docs/features/mobiel-inspectie.md
@@ -0,0 +1,23 @@
+# Mobiel Inspectie (Mobile Inspection)
+
+The mobile inspection feature provides a mobile-optimized interface for field inspectors to conduct and document inspections.
+
+## Overview
+
+Government inspectors often work in the field and need to document their findings on-site. This feature provides a responsive, mobile-friendly interface for inspection activities.
+
+## Planned Features
+
+- **Mobile-optimized UI** -- Responsive interface designed for tablet and smartphone use.
+- **Inspection checklists** -- Configurable checklists per inspection type.
+- **Photo capture** -- Take and attach photos directly from the mobile device.
+- **GPS location** -- Capture and record the inspection location.
+- **Offline support** -- Work offline and sync when connectivity is restored.
+- **Digital signature** -- Capture inspector and inspected party signatures.
+- **Quick findings** -- Predefined finding templates for common violations.
+- **Report generation** -- Generate inspection reports from collected data.
+- **Follow-up creation** -- Create enforcement cases directly from inspection findings.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/mobiel-inspectie/spec.md` and is planned for future implementation.
diff --git a/docs/features/multi-tenant-saas.md b/docs/features/multi-tenant-saas.md
new file mode 100644
index 00000000..e06ac85c
--- /dev/null
+++ b/docs/features/multi-tenant-saas.md
@@ -0,0 +1,26 @@
+# Multi-Tenant SaaS
+
+The multi-tenant SaaS feature enables Procest to serve multiple organizations from a single Nextcloud instance.
+
+## Overview
+
+For SaaS deployments, Procest must support multiple tenant organizations, each with their own case data, configurations, and user access controls.
+
+## Planned Features
+
+- **Tenant isolation** -- Strict data separation between tenants.
+- **Per-tenant configuration** -- Each tenant can have their own case types, workflows, and settings.
+- **Tenant onboarding** -- Streamlined process for adding new tenant organizations.
+- **Shared infrastructure** -- All tenants share the same Nextcloud instance and Procest installation.
+- **Tenant-specific branding** -- Support for NL Design System theme tokens per tenant.
+- **Usage metering** -- Track resource usage per tenant for billing purposes.
+- **Tenant admin role** -- Separate admin role for tenant-level administration.
+- **Cross-tenant sharing** -- Optional controlled sharing between tenants for inter-organizational case handling.
+
+## Implementation Approach
+
+Multi-tenancy is implemented through OpenRegister's register-level isolation, where each tenant gets their own register with separate schemas and objects.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/multi-tenant-saas/spec.md` and is planned for future implementation.
diff --git a/docs/features/my-work.md b/docs/features/my-work.md
index e719a94b..7b39064f 100644
--- a/docs/features/my-work.md
+++ b/docs/features/my-work.md
@@ -1,62 +1,33 @@
-# My Work (Werkvoorraad)
+# My Work
 
-Personal productivity hub aggregating all work items assigned to the current user — cases where they are the handler plus tasks assigned to them — into a single prioritized view. Answers: "What do I need to work on next?"
+The My Work view shows all cases and tasks assigned to the currently logged-in user, providing a personal work queue.
 
-## Specs
+![My Work](../screenshots/my-work.png)
 
-- `openspec/specs/my-work/spec.md`
+## Overview
 
-## Features
+The page displays a count of total items in the heading (e.g., "My Work (15)") and provides three filter tabs:
 
-### Personal Workload View (MVP)
+- **All (15)** -- Shows both cases and tasks combined.
+- **Cases (15)** -- Filters to show only cases.
+- **Tasks (0)** -- Filters to show only tasks.
 
-Unified list of cases (where user is handler) and tasks (assigned to user), combining both entity types into a single sorted view.
+A **Show completed** checkbox allows toggling visibility of finished items.
 
-- Item cards showing title, type badge (case/task), priority, and deadline/due date
-- Click-through navigation to case or task detail views
+## Work Items
 
-### Filter Tabs (MVP)
+Each item in the list shows:
+- **Type badge** -- "CASE" or "TASK" label.
+- **Title** -- The case or task name (e.g., "Test Case 4").
+- **Identifier** -- The case reference number (e.g., #ZAAK-TEST-004).
+- **Days remaining** -- Time until the processing deadline, with warning indicators (exclamation mark) for items needing attention.
 
-Filter tabs to focus on specific entity types:
+Items are grouped under an **UPCOMING** section header with a count.
 
-- **All**: Cases + tasks combined
-- **Cases**: Only cases where user is handler
-- **Tasks**: Only tasks assigned to user
+## Interaction
 
-### Temporal Grouping (MVP)
+Clicking on a case navigates to the case detail view at `/apps/procest/cases/{uuid}`. Clicking on a task would navigate to the task detail view.
 
-Items organized into urgency-based groups:
+## Data Source
 
-- **Overdue**: Past deadline/due date, highlighted with red indicators
-- **Due This Week**: Due within the current week
-- **Upcoming**: Due in the future beyond this week
-- **No Deadline**: Items without a deadline/due date
-
-### Sorting (MVP)
-
-Items sorted by priority first (urgent → high → normal → low), then by deadline/due date within each priority level.
-
-### Overdue Highlighting (MVP)
-
-Items past their deadline are visually distinct with red color indicators and overdue badges.
-
-### Default Filter (MVP)
-
-By default, only non-final items are shown (excludes completed/terminated cases and tasks). Users can toggle to include completed items.
-
-### Item Navigation (MVP)
-
-Clicking any item navigates to its detail view (case detail or task detail) for full context and actions.
-
-### Empty State (MVP)
-
-When no items are assigned, shows a friendly empty state indicating no current work items.
-
-### Planned (V1)
-
-- Cross-app workload: include Pipelinq leads/requests alongside Procest items
-- Concurrent state change handling (real-time updates)
-
-### Planned (Enterprise)
-
-- Workload analytics (items per user for management visibility)
+My Work items are fetched based on the current user's assignments. The view queries OpenRegister for cases and tasks where the logged-in user is the assigned handler.
diff --git a/docs/features/openregister-integration.md b/docs/features/openregister-integration.md
new file mode 100644
index 00000000..43dfbaa4
--- /dev/null
+++ b/docs/features/openregister-integration.md
@@ -0,0 +1,32 @@
+# OpenRegister Integration
+
+The OpenRegister integration is the foundational data layer for Procest, storing all case management data in OpenRegister's flexible register/schema/object model.
+
+## Overview
+
+Procest uses OpenRegister as its data backend rather than maintaining its own database tables. This provides flexibility, auditability, and interoperability with other OpenRegister-based applications.
+
+## Architecture
+
+- **Register** -- A single OpenRegister register holds all Procest data.
+- **Schemas** -- Separate schemas define the structure for cases, tasks, roles, decisions, results, case types, and status types.
+- **Objects** -- Individual cases, tasks, and other entities are stored as OpenRegister objects.
+
+## Configuration
+
+The integration is configured through the Settings > Configuration page:
+- Register ID
+- Schema IDs for each entity type (case, task, status, role, result, decision, case type, status type)
+
+## Features
+
+- **CRUD operations** -- Full create, read, update, delete operations on all entity types.
+- **Audit trail** -- OpenRegister provides automatic audit logging of all changes.
+- **File attachments** -- Case documents stored via Nextcloud Files, referenced from OpenRegister objects.
+- **Search** -- Full-text search across case data via OpenRegister's search capabilities.
+- **Validation** -- Schema-based validation ensures data integrity.
+- **API access** -- All data accessible via OpenRegister's REST API and MCP protocol.
+
+## Status
+
+This feature is implemented and actively used as the core data layer for Procest.
diff --git a/docs/features/prometheus-metrics.md b/docs/features/prometheus-metrics.md
new file mode 100644
index 00000000..aa3776fb
--- /dev/null
+++ b/docs/features/prometheus-metrics.md
@@ -0,0 +1,28 @@
+# Prometheus Metrics
+
+The Prometheus metrics feature exposes operational metrics for monitoring Procest in production environments.
+
+## Overview
+
+For enterprise deployments, Procest can expose metrics in Prometheus format, enabling integration with standard monitoring stacks (Prometheus + Grafana).
+
+## Planned Metrics
+
+- **Case counts** -- Total cases by status, type, and age.
+- **Processing times** -- Average and percentile processing times per case type.
+- **Deadline compliance** -- Percentage of cases resolved within their deadline.
+- **Queue depth** -- Number of unassigned cases in the werkvoorraad.
+- **User activity** -- Active case workers and their current workload.
+- **API response times** -- Latency of API endpoints.
+- **Error rates** -- API error rates and types.
+- **Storage usage** -- Document storage consumption.
+
+## Integration
+
+- Standard `/metrics` endpoint for Prometheus scraping.
+- Grafana dashboard templates for common monitoring views.
+- Alert rules for SLA compliance monitoring.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/prometheus-metrics/spec.md` and is planned for future implementation.
diff --git a/docs/features/register-i18n.md b/docs/features/register-i18n.md
new file mode 100644
index 00000000..2df94c20
--- /dev/null
+++ b/docs/features/register-i18n.md
@@ -0,0 +1,31 @@
+# Register i18n (Internationalization)
+
+The register i18n feature provides multilingual support for Procest, with Dutch (nl) and English (en) as the minimum required languages.
+
+## Overview
+
+As a Dutch government application, Procest must support Dutch as its primary language while also providing English translations for international users and developers.
+
+## Scope
+
+- **UI labels** -- All user interface elements translated.
+- **Case type names** -- Translatable case type titles and descriptions.
+- **Status labels** -- Translatable status names.
+- **Error messages** -- Translated error and validation messages.
+- **Documentation** -- Feature documentation available in multiple languages.
+- **Email templates** -- Translatable notification templates.
+
+## Implementation
+
+- Uses Nextcloud's standard i18n infrastructure (gettext/l10n).
+- Translation files stored in the `l10n/` directory.
+- Translatable strings marked with `t()` in Vue components and `$this->l->t()` in PHP.
+
+## Required Languages
+
+- **nl** (Dutch) -- Primary language for government users.
+- **en** (English) -- Required secondary language.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/register-i18n/spec.md` and is partially implemented.
diff --git a/docs/features/roles-decisions.md b/docs/features/roles-decisions.md
index 2916f4cd..cdb84e70 100644
--- a/docs/features/roles-decisions.md
+++ b/docs/features/roles-decisions.md
@@ -1,53 +1,32 @@
-# Roles & Decisions
+# Roles and Decisions
 
-Participation, outcomes, and formal decision-making on cases. Roles link participants to cases, results record outcomes, and decisions are formal administrative determinations.
+The roles and decisions feature manages the assignment of roles to case participants and the recording of formal decisions (besluiten) within cases.
 
-## Specs
+## Roles
 
-- `openspec/specs/roles-decisions/spec.md`
+Roles define who is involved in a case and in what capacity. Common role types in Dutch government case management include:
 
-## Features
+- **Behandelaar** (Handler) -- The case worker responsible for processing the case.
+- **Initiator** -- The person or organization that initiated the case (e.g., the applicant).
+- **Belanghebbende** (Stakeholder) -- Parties with a vested interest in the case outcome.
+- **Adviseur** (Advisor) -- Internal or external advisors consulted during case processing.
+- **Medeinitiator** -- Co-initiators of a case.
 
-### Role Assignment (MVP)
+### Role Management
+- Assign roles to users or external parties.
+- Track role history (who was assigned when).
+- Role-based access control for case data.
+- ZGW-compatible role types via the roltype mapping.
 
-Roles link participants (Nextcloud users or external contacts) to cases with specific role types.
+## Decisions (Besluiten)
 
-- Handler assignment shortcut: quick assign the primary case handler
-- Built-in generic roles: initiator, handler, advisor
-- Participant display on case detail view
-- Role validation: role type must be valid, participant must exist
+Decisions are formal administrative outcomes recorded against a case:
 
-### Case Result Recording (MVP)
+- **Decision types** -- Configurable via the besluittype ZGW mapping.
+- **Decision recording** -- Capture the decision text, date, and responsible authority.
+- **Decision publication** -- Track whether a decision requires publication.
+- **Appeal tracking** -- Link decisions to subsequent objection (bezwaar) cases.
 
-When a case reaches a terminal status, a result records the outcome.
+## Status
 
-- Result links to the case and optionally to a result type
-- Result description documents the outcome details
-- Closing a case requires recording a result
-
-### Planned (V1) — Role Types
-
-- Role type enforcement from case type configuration
-- Role-based case access (participants can only see cases they have a role on)
-- Custom role types per case type
-
-### Planned (V1) — Decisions
-
-Formal administrative determinations within cases:
-
-- Decision CRUD linked to cases
-- Decision validity periods (effectiveDate, expiryDate)
-- Decision types from case type configuration
-- Decision validation rules
-- Decisions section on case detail view
-
-### Planned (V1) — Result Types
-
-- Result type configuration per case type
-- Archival rules on result types (`bewaren` = preserve, `vernietigen` = destroy)
-- Result type enforcement on case closure
-
-### Planned (Enterprise)
-
-- DMN decision tables (automated decision logic)
-- Decision templates
+This feature is defined in the spec at `openspec/specs/roles-decisions/spec.md` and is partially implemented through the ZGW API mapping configuration.
diff --git a/docs/features/stuf-support.md b/docs/features/stuf-support.md
new file mode 100644
index 00000000..6bab84f9
--- /dev/null
+++ b/docs/features/stuf-support.md
@@ -0,0 +1,25 @@
+# StUF Support
+
+The StUF (Standaard Uitwisseling Formaat) support feature provides compatibility with the legacy Dutch government data exchange standard.
+
+## Overview
+
+StUF is a SOAP/XML-based standard historically used for data exchange between Dutch government systems. While being phased out in favor of REST-based APIs, many legacy systems still use StUF.
+
+## Planned Features
+
+- **StUF-ZKN** -- Support for the StUF Zaken (case management) message format.
+- **StUF-BG** -- Support for the StUF Basisgegevens (base data) message format.
+- **Message translation** -- Translate between StUF XML messages and OpenRegister's JSON objects.
+- **Endpoint provisioning** -- Expose StUF SOAP endpoints for legacy system integration.
+- **Message logging** -- Log all StUF messages for audit and debugging.
+- **Error handling** -- Proper StUF error responses (Fo/Fout messages).
+- **Asynchronous processing** -- Support for asynchronous StUF message patterns.
+
+## Migration Path
+
+StUF support is intended as a bridge technology, enabling organizations to connect legacy systems while migrating to modern ZGW APIs. The ZGW API mapping feature provides the forward-looking integration path.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/stuf-support/spec.md` and is planned for future implementation.
diff --git a/docs/features/task-management.md b/docs/features/task-management.md
index 188dfa70..e0551ef7 100644
--- a/docs/features/task-management.md
+++ b/docs/features/task-management.md
@@ -1,65 +1,33 @@
 # Task Management
 
-Work items within cases following CMMN 1.1 HumanTask concepts. Tasks are the primary mechanism for distributing and tracking work within a case.
+The Tasks view provides a list of all tasks in the system, functioning similarly to the Cases view.
 
-## Specs
+![Task Management](../screenshots/task-management.png)
 
-- `openspec/specs/task-management/spec.md`
+## Overview
 
-## Features
+The tasks list supports the same two view modes as cases:
 
-### Task CRUD (MVP)
+- **Table view** (default) -- Sortable column-based table.
+- **Cards view** -- Visual card layout.
 
-Full create, read, update, and delete for tasks linked to cases.
+## Actions
 
-- Fields: title, description, status, assignedTo, dueDate, priority, case (parent case reference)
-- Tasks inherit context from their parent case
+- **Add Item** -- Creates a new task.
+- **Actions** -- Bulk actions menu for selected tasks.
 
-### Task Status Lifecycle (MVP)
+## Current State
 
-Tasks follow CMMN PlanItem states:
+The task list view depends on the OpenRegister object type "task" being properly registered. Task schemas must be configured in the Settings > Configuration page.
 
-- `available` → `active` → `completed` / `terminated`
-- Status transitions are recorded for audit
+## Planned Features
 
-### Task Assignment (MVP)
+Based on the spec, task management will include:
 
-Tasks can be assigned to Nextcloud users. Assigned tasks appear in the user's My Work view.
-
-### Task List View (MVP)
-
-Browsable task list with search, sort, and filter:
-
-- Search across title and description
-- Filter by status, assignee, priority, parent case
-- Sort by due date, priority, status
-
-### Task Due Dates and Priorities (MVP)
-
-- Four priority levels: low, normal, high, urgent
-- Due date tracking with overdue highlighting
-- Priority + due date drive sorting in My Work view
-
-### Task Card Display (MVP)
-
-Compact card layout showing task title, status badge, priority indicator, due date, and assignee. Used in both list views and case detail task sections.
-
-### Task Completion (MVP)
-
-Completing a task transitions it to `completed` status and updates the parent case's task progress.
-
-### Overdue Task Management (MVP)
-
-Tasks past their due date are visually highlighted with red indicators. Overdue tasks surface prominently in My Work and dashboard views.
-
-### Planned (V1)
-
-- Kanban board view with drag-and-drop between statuses
-- Task checklist/sub-items
-- Task dependencies (blocked by)
-- Task templates per case type
-
-### Planned (Enterprise)
-
-- Automated task creation on case status change
-- Workload dashboard (tasks per user)
+- Task creation with title, description, assignee, and due date.
+- Task status workflow (open, in progress, completed, cancelled).
+- Association with parent cases.
+- Priority levels.
+- Task assignment and reassignment.
+- Due date tracking with overdue indicators.
+- Bulk status updates.
diff --git a/docs/features/vth-module.md b/docs/features/vth-module.md
new file mode 100644
index 00000000..3658a45b
--- /dev/null
+++ b/docs/features/vth-module.md
@@ -0,0 +1,38 @@
+# VTH Module (Vergunning, Toezicht, Handhaving)
+
+The VTH module handles the integrated process of permits (Vergunningen), supervision (Toezicht), and enforcement (Handhaving).
+
+## Overview
+
+VTH is a core government process domain that covers the entire lifecycle from permit application through compliance monitoring to enforcement actions. This module provides specialized case types and workflows for each VTH domain.
+
+## Planned Features
+
+### Vergunningen (Permits)
+- Permit application intake and processing.
+- Assessment workflows with multi-department review.
+- Conditions and requirements management.
+- Permit issuance and publication.
+
+### Toezicht (Supervision)
+- Inspection planning and scheduling.
+- Inspection report creation and filing.
+- Compliance status tracking.
+- Risk-based inspection prioritization.
+
+### Handhaving (Enforcement)
+- Violation recording and categorization.
+- Warning letters and formal notices.
+- Penalty decision processing.
+- Enforcement action tracking.
+- Legalization procedures.
+
+## Integration
+
+- **DSO Omgevingsloket** -- Receive permit applications from the national digital system.
+- **BAG/BRK** -- Link to building and cadastral registrations.
+- **Inspection tools** -- Integration with mobile inspection workflows.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/vth-module/spec.md` and is planned for future implementation.
diff --git a/docs/features/werkvoorraad.md b/docs/features/werkvoorraad.md
new file mode 100644
index 00000000..7a66b069
--- /dev/null
+++ b/docs/features/werkvoorraad.md
@@ -0,0 +1,29 @@
+# Werkvoorraad (Work Queue)
+
+The werkvoorraad (work queue) feature provides a team-level view of unassigned and pending work items that need to be picked up by case workers.
+
+## Overview
+
+Unlike "My Work" which shows items assigned to the current user, the werkvoorraad shows the shared pool of work that is available for the team or organizational unit.
+
+## Planned Features
+
+- **Unassigned cases** -- Cases that have not yet been assigned to a specific handler.
+- **Team queue** -- Cases assigned to a team or organizational unit rather than an individual.
+- **Priority sorting** -- Items sorted by urgency, deadline proximity, or priority level.
+- **Claim functionality** -- Allows a case worker to claim a case from the queue, assigning it to themselves.
+- **Filter by case type** -- Filter the queue by specific case types (e.g., Bezwaar, Vergunning, Melding).
+- **Filter by deadline** -- View items approaching their processing deadline.
+- **Bulk assignment** -- Assign multiple items from the queue to a specific handler.
+
+## Relationship to My Work
+
+The werkvoorraad and My Work views are complementary:
+- **Werkvoorraad**: "What work is available for the team?"
+- **My Work**: "What work is assigned to me?"
+
+Case workers typically check the werkvoorraad to pick up new work, which then appears in their My Work view.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/werkvoorraad/spec.md` and is planned for future implementation.
diff --git a/docs/features/woo-case-type.md b/docs/features/woo-case-type.md
new file mode 100644
index 00000000..0829157d
--- /dev/null
+++ b/docs/features/woo-case-type.md
@@ -0,0 +1,30 @@
+# WOO Case Type
+
+The WOO (Wet open overheid / Open Government Act) case type handles requests for government information disclosure.
+
+## Overview
+
+The WOO replaced the older WOB (Wet openbaarheid van bestuur) and requires Dutch government organizations to proactively publish information and handle disclosure requests within strict timeframes.
+
+## Planned Features
+
+- **WOO request intake** -- Structured intake form for WOO disclosure requests.
+- **Scope assessment** -- Determine which documents fall within the scope of the request.
+- **Document collection** -- Gather relevant documents from various sources.
+- **Redaction support** -- Mark documents or passages for redaction with legal grounds.
+- **Third-party consultation** -- Track consultations with third parties mentioned in documents (zienswijze procedure).
+- **Decision recording** -- Record the formal disclosure decision per document.
+- **Publication** -- Publish disclosed documents on the WOO platform.
+- **Deadline tracking** -- 4-week initial deadline, extendable by 2 weeks.
+- **Appeal handling** -- Link to bezwaar (objection) cases if the decision is appealed.
+
+## Legal Requirements
+
+The WOO prescribes:
+- Response within 4 weeks (extendable by 2 weeks).
+- Mandatory grounds for refusal (e.g., personal privacy, business confidentiality, state security).
+- Proactive publication obligations.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/woo-case-type/spec.md` and is planned for future implementation.
diff --git a/docs/features/zaak-intake-flow.md b/docs/features/zaak-intake-flow.md
new file mode 100644
index 00000000..c79e568d
--- /dev/null
+++ b/docs/features/zaak-intake-flow.md
@@ -0,0 +1,29 @@
+# Zaak Intake Flow
+
+The zaak intake flow manages the process of receiving, validating, and registering new cases (zaken) in the system.
+
+## Overview
+
+The intake flow is the entry point for new cases, whether they originate from citizen requests, internal processes, or external system integrations.
+
+## Planned Features
+
+- **Intake form** -- Structured form for capturing initial case information.
+- **Case type selection** -- Choose the appropriate zaaktype during intake.
+- **Automatic numbering** -- Generate unique case identifiers (e.g., ZAAK-2026-0001).
+- **Validation** -- Verify required fields and data quality during intake.
+- **Document attachment** -- Upload supporting documents during case creation.
+- **Initiator registration** -- Record the person or organization initiating the case.
+- **Initial status** -- Automatically set the initial status based on the case type configuration.
+- **Deadline calculation** -- Calculate the processing deadline based on the case type's configured processing period.
+- **Assignment** -- Optionally assign the case to a handler during intake or route to the werkvoorraad.
+
+## Integration Points
+
+- **DSO Omgevingsloket** -- Receive intake from the national digital permit system.
+- **E-mail intake** -- Create cases from incoming email.
+- **API intake** -- Accept cases via ZGW-compatible API endpoints.
+
+## Status
+
+This feature is defined in the spec at `openspec/specs/zaak-intake-flow/spec.md` and is planned for future implementation.
diff --git a/docs/features/zaaktype-configuratie.md b/docs/features/zaaktype-configuratie.md
new file mode 100644
index 00000000..bf0196ef
--- /dev/null
+++ b/docs/features/zaaktype-configuratie.md
@@ -0,0 +1,37 @@
+# Zaaktype Configuratie (Case Type Configuration)
+
+The zaaktype configuration is part of the Settings area and provides ZGW-compliant case type management.
+
+![Zaaktype Configuration](../screenshots/zaaktype-configuratie.png)
+
+## Overview
+
+This feature manages the mapping between Procest's internal case type definitions and the Dutch ZGW (Zaakgericht Werken) standard. It is accessible from the Case Types settings page.
+
+## ZGW Resource Mapping
+
+The configuration supports mapping for the following ZGW resource types:
+
+| Resource | Description |
+|----------|-------------|
+| zaak | Case instance |
+| zaaktype | Case type definition |
+| status | Case status instance |
+| statustype | Status type definition |
+| resultaat | Case result instance |
+| resultaattype | Result type definition |
+| rol | Role assignment |
+| roltype | Role type definition |
+| eigenschap | Custom property |
+| besluit | Decision instance |
+| besluittype | Decision type definition |
+| informatieobjecttype | Document type definition |
+
+Each mapping includes:
+- **Status** -- Enabled/Disabled indicator
+- **Edit** -- Opens the field mapping editor
+- **Reset** -- Restores the default mapping
+
+## Purpose
+
+The ZGW API mapping ensures that Procest can expose its data through ZGW-compatible API endpoints, enabling interoperability with other Dutch government systems that follow the ZGW standard (such as OpenZaak, Dimpact ZAC, and XXLLnc Zaken).
diff --git a/docs/screenshots/admin-settings.png b/docs/screenshots/admin-settings.png
new file mode 100644
index 00000000..39268ca6
Binary files /dev/null and b/docs/screenshots/admin-settings.png differ
diff --git a/docs/screenshots/case-dashboard-view.png b/docs/screenshots/case-dashboard-view.png
new file mode 100644
index 00000000..278a58f7
Binary files /dev/null and b/docs/screenshots/case-dashboard-view.png differ
diff --git a/docs/screenshots/case-management.png b/docs/screenshots/case-management.png
new file mode 100644
index 00000000..7f1e1c4f
Binary files /dev/null and b/docs/screenshots/case-management.png differ
diff --git a/docs/screenshots/case-types.png b/docs/screenshots/case-types.png
new file mode 100644
index 00000000..803ba552
Binary files /dev/null and b/docs/screenshots/case-types.png differ
diff --git a/docs/screenshots/dashboard.png b/docs/screenshots/dashboard.png
new file mode 100644
index 00000000..e34a6ac3
Binary files /dev/null and b/docs/screenshots/dashboard.png differ
diff --git a/docs/screenshots/my-work.png b/docs/screenshots/my-work.png
new file mode 100644
index 00000000..cb70a104
Binary files /dev/null and b/docs/screenshots/my-work.png differ
diff --git a/docs/screenshots/task-management.png b/docs/screenshots/task-management.png
new file mode 100644
index 00000000..7f1e1c4f
Binary files /dev/null and b/docs/screenshots/task-management.png differ
diff --git a/docs/screenshots/zaaktype-configuratie.png b/docs/screenshots/zaaktype-configuratie.png
new file mode 100644
index 00000000..2a482638
Binary files /dev/null and b/docs/screenshots/zaaktype-configuratie.png differ