docs: organize cross-product documentation
This commit is contained in:
@@ -0,0 +1,203 @@
|
||||
# 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](reference/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.
|
||||
Reference in New Issue
Block a user