12 KiB
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, the Connected Governance Platform Roadmap, and the Reference Journey Program.
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:
- link it to a named reference journey or explicit discovery issue;
- identify the owning module and external authority;
- create or update the Gitea issue with acceptance criteria;
- keep live status out of this document;
- update this register only when the durable interpretation changes.