# GovOPlaN Product Input Register

## Purpose

This document preserves and normalizes product ideas and user-story notes that
inform GovOPlaN without turning a private note file into a second backlog.
Gitea issues remain the source of live work state; the stable platform direction
remains in [Platform Core Ideas](PLATFORM_CORE_IDEAS.md), the
[Connected Governance Platform Roadmap](CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md),
and the [Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md).

The register was reconciled on 2026-08-06 from:

- `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/ideas.md`;
- `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/user_stories.txt`.

The source notes remain useful as the original capture. This maintained version
uses consistent terminology, makes ownership explicit, and records where an
idea enters the product program.

## Product Themes

### Operable and scalable installation

An operator should be able to install, update, reconfigure, scale, back up,
restore, pause, and retire GovOPlaN through one explainable control plane.
Existing infrastructure may be reused or managed components may be provisioned.
The WebUI and CLI must invoke the same governed operations, show the planned and
completed effects, preserve recovery evidence, and never claim rollback for an
external effect that cannot actually be reversed.

This theme is owned by Core, Admin, Ops, Policy, Files, and the signed product
package. It is tracked primarily by GovOPlaN #13 and the production evidence
issues. It advances in parallel with, but does not replace, actor-facing
reference journeys.

### Focused, consistent work

People should see the work and tools relevant to the current task, not the
installed module graph. Views may be defined by administrators, groups, or
users within policy. Workflow instances may pin a governed View. Contextual
help, predictable action placement, consistent central components, visible
intermediate results, and plain institutional terminology are product
requirements.

Small task-local actions such as writing a Mail or Postbox message, completing
a Template, or manipulating Files should be launchable without abandoning the
current context. These actions remain owned by their modules and use bounded
overlays or workspaces; the shell supplies discovery and return context rather
than reimplementing them.

The accepted first presentation is the optional, configurable Quick Access
rail: Work, Calendar, Messages and Files. Messages may compose Mail, Postbox
and future chat contributions while preserving their separate authority and
channel semantics. System and tenant administrators govern availability and
forced entries; users select categories and ordering within those ceilings.
Modules register typed contributions through Core and continue to work when
Quick Access is absent.

This theme is owned by Core experience contracts, Views, Dashboard, Tasks,
Workflow Engine, Quick Access, Docs, and the contributing feature modules. The
first proof is the resumable service-to-decision/eAkte journey in GovOPlaN #42.

### Governed human work

An intake or event becomes owned work with a responsible actor or function,
priority, deadline, current action, consequence, source context, and completion
evidence. Tasks owns explicit work items and the unified work inbox. Workflow
Engine owns process execution, waits, retries, and handoffs. Domain modules own
the business objects and commands. Notifications attract attention but do not
replace durable work state.

This distinction applies to service requests, technical support, approvals,
data reconciliation, campaigns, meetings, decisions, records, and failed
automation. It is the immediate shared implementation priority because users
must be able to leave work and resume it safely.

### Institutional responsibility and workforce context

Organization units, functions, mandates, assignments, delegations, and acting
context determine institutional responsibility. Presence, absence, illness,
availability, and similar status are effective-dated operational facts used to
route work, suppress or redirect notifications, explain planning, and trigger
policy. They are not merely profile decorations and they do not replace the IDM
lifecycle status of an identity or account.

Time recording, absence management, sickness reporting, return-to-work
management, and applicant management form a possible workforce package. The
first implementation must be driven by a real journey and legal/privacy
profile; no new module boundary is implied solely by this register.

### Integration-first and provider-neutral operation

GovOPlaN should integrate tightly with software already used by an institution
and offer native alternatives only where that produces a better governed
outcome. Core-mediated provider contracts expose stable, vendor-neutral
capabilities; adapters encapsulate specific products. Authority, synchronized
fields, conflict behavior, health, credential custody, provenance, and
retirement must be explicit.

The LBV Baden-Wuerttemberg idea is retained as a candidate workforce/payroll
integration profile and as a test of provider-neutral contracts. Desktop and
groupware integration for Microsoft Office, Outlook, LibreOffice, Thunderbird,
file managers, Windows, Unix, and macOS should use standards, deep links,
protocol handlers, synchronization, and governed connectors before custom
desktop software is introduced.

### Inclusive channels and device surfaces

Portal, Postbox, Mail, telephone, paper, in-person assistance, API, desktop,
and mobile are channels around the same governed work. A responsive or native
mobile surface must not create a second authority or data model. Assisted work
records representation, source, attestation, receipt, correction, and delivery
choice. People may opt into permitted distribution channels while policy keeps
mandatory channels and legal delivery requirements explicit.

Video meetings, chat, instant messaging, and forums are retained as governed
collaboration-channel candidates. The default direction is integration with an
established provider through typed message, meeting, participant, evidence, and
retention contracts before building another communications stack.

### Meetings, deliberation, decisions, and voting

An institutional meeting spans scheduling, participants and mandates,
documents, agenda, discussion, formal motions, votes, decisions, minutes,
follow-up work, publication, and eligible expense settlement. Committee owns
the meeting and deliberation semantics while Calendar, Scheduling, Files,
Templates, Decisions, Tasks, Reporting, Ledger, and Voting contribute optional
capabilities.

Voting requiring certified assurance remains a provider program. POLYAS is the
first external profile; a native provider may progress only through the
controlled assurance and certification program already tracked in Voting.

### Controlled data work and understandable reporting

People should manipulate data through immutable inputs, previewed operations,
intermediate materializations, reversible definition changes, durable review
decisions, quality rules, and complete lineage. Reports expose their definitions
and source revisions so controllers can understand and change how a result is
produced. Technical support may package controlled workflows that let
non-technical users safely operate otherwise hidden data.

The monthly-data journey is the first proof. Sanctions screening follows on the
same source, snapshot, transformation, review, reporting, workflow, and
delivery contracts.

### Institutional memory and consequence

Decisions should be prepared, discussed, made, communicated, implemented, and
filed with their authority and consequences visible. A record/eAkte provides
the familiar administrative context across exact source revisions without
copying ownership from Cases, Decisions, Files, Forms, Campaign, Postbox, or
other modules. The institutional digital twin may later use governed
projections to model and simulate organizational change, but simulation output
never becomes authority without an explicit adoption decision.

## Normalized Story Catalogue

The following catalogue preserves the intent of the collected notes. It is an
orientation index, not a completion checklist.

| Actor and desired outcome | Product owner or composition | First proof |
| --- | --- | --- |
| Operator installs, updates, scales, backs up, restores, and rolls back through one explainable workflow | Core, Admin, Ops, signed package | GovOPlaN #13 and target-evidence lane |
| System and tenant module administrators govern module availability and lifecycle | Core, Admin, Policy, Tenancy | Module entitlement and lifecycle composition |
| User works in a decluttered, consistent and task-sensitive interface | Views, Core, Dashboard, Workflow, Docs | Service-to-decision workspace |
| Policy maker defines inherited, explainable and enforced rules | Policy plus every consequential owner | Information-governance adoption gate |
| Controller and auditor reconstruct results, rules, evidence and correction paths | Audit, Reporting, Records, Dataflow | Monthly-data and eAkte journeys |
| User sees institutional terminology, current progress, intermediate results and consequences | Domain owner, Tasks, Workflow, Views | All reference journey acceptance tests |
| Voting body and voter obtain independently assured democratic voting | Voting, Committee, Identity Trust, Encryption | POLYAS profile and controlled native-provider program |
| Support staff packages safe guided manipulation of hidden data | Workflow, Dataflow, Tasks, Views | Monthly reconciliation workflow |
| Data worker performs controlled, understandable and recoverable transformations | Datasources, Connectors, Dataflow, Reporting | GovOPlaN #8 |
| Decision maker prepares, deliberates, decides, records and follows consequences | Committee, Decisions, Tasks, Records, Reporting | Service-to-decision journey |
| Management delegates responsibility and receives governed activity reports | Organizations, IDM, Access, Policy, Reporting | Function-bound Postbox and work inbox |
| Institution models and simulates organizational change | Organizations, Policy, Dataflow, Reporting, Digital Twin | Later governed digital-twin package |
| Sender distributes generated files to functions without knowing incumbents | Campaign, Distribution Lists, Postbox, Organizations, IDM | Governed communication package |
| Function holder receives current and policy-selected historical work and information | IDM, Access, Postbox, Tasks, Records | Postbox reassignment/history tests |
| Administrative worker accesses one familiar eAkte context across exact owned objects | Records and record-source providers | GovOPlaN #42 and Records #8 |
| User invokes common message, template and file actions without leaving the current task | Core shell, Views, Workflow and contributing modules | Task-local action contract and service workspace |

## Idea Preservation Map

| Original idea cluster | Preserved direction |
| --- | --- |
| Time recording, absence, sickness, reintegration, applicant management | Governed workforce-context journey; effective-dated status and privacy profile before module expansion |
| LBV BW interface | Candidate provider-neutral workforce/payroll connector profile |
| Abstract interfaces | Versioned Core contracts with product adapters and explicit source authority |
| Desktop and groupware integration | Standards, connectors, deep launch and synchronization before custom clients |
| GovOPlaN app/mobile-first pages | Responsive shared semantics; native shell only when a proven journey needs device capabilities |
| Video, chat, instant messaging and forum | Optional governed collaboration providers with retention/evidence contracts |
| Somacos Session-style meeting management | Committee-led meeting composition across Calendar, Files, Decisions, Templates, Tasks, Reporting and Ledger |
| Stronger software integration | Integration-first roadmap rule and first full external product connectors |

## Maintenance

When a source idea becomes actionable:

1. link it to a named reference journey or explicit discovery issue;
2. identify the owning module and external authority;
3. create or update the Gitea issue with acceptance criteria;
4. keep live status out of this document;
5. update this register only when the durable interpretation changes.