Release v0.1.16

docs/PLATFORM_CORE_IDEAS.md

@@ -0,0 +1,173 @@
+# GovOPlaN Platform Core Ideas
+
+## Purpose
+
+GovOPlaN is an institutional governance and operations layer. Its central
+promise is:
+
+> Model the institution, orchestrate its work, connect its systems, and
+> preserve why and under whose authority it acted.
+
+The platform should let people complete a real task without understanding its
+repository or module graph. It should let institutions retain control over
+their data, procedures, providers, and deployment while still sharing
+interoperable definitions and evidence.
+
+This document is the stable summary of the ideas that every product package,
+module, interface, and integration must preserve. Current implementation state
+lives in [Strategy Status](STRATEGY_STATUS.md).
+
+## Ten Core Ideas
+
+### 1. Institutional context before application context
+
+Work happens for a tenant, institution, organizational unit, function,
+mandate, jurisdiction, service, case, and represented party. The real actor
+and represented capacity remain distinct. Application permissions alone do not
+prove institutional competence.
+
+### 2. Governance is executable
+
+Policy is not explanatory prose around an operation. Consequential actions
+must expose applicable rules, authority, purpose, expected effects, review
+requirements, recovery behavior, and evidence. Inheritance may tighten a rule
+but must not silently loosen an upstream constraint.
+
+### 3. Time has two independent meanings
+
+Valid time answers when a fact applied. Recorded time answers what the system
+knew at a point in history. Historical browsing changes the business-data
+projection, never the current authorization context. Corrections and
+supersession remain visible rather than rewriting history.
+
+### 4. One context, many owners
+
+Cases, tasks, decisions, records, messages, files, appointments, reports, and
+external objects remain owned by their domain modules or source systems. Stable
+references create one navigable context without a universal copied master
+record or cross-module table access.
+
+### 5. Native and connected operation are peers
+
+For every integration, GovOPlaN states whether it is authoritative, mirrors an
+external source, synchronizes governed fields, adds a governance overlay, or
+keeps a link only. An external system can be used today and replaced later
+without losing provenance or institutional control.
+
+### 6. Human work is a first-class system object
+
+An intake becomes owned, reviewable work. A person can see the current context,
+next responsible action, reason, deadline, consequence, and completion
+evidence. Workflow Engine coordinates machine and human transitions; focused
+views guide people through the relevant platform surfaces.
+
+### 7. Views reduce complexity without changing authority
+
+The interface is a task- and role-sensitive projection of installed
+capabilities. Views, dashboards, search, documentation, and workflow-guided
+surfaces may hide irrelevant functions, but they never grant access. Users can
+escape a focused mode when policy permits and can always understand why
+something is unavailable.
+
+### 8. Evidence and recovery are part of the operation
+
+Intent, exact input versions, approvals, external effects, receipts,
+outcome-unknown states, reconciliation, corrections, retention, and recovery
+belong to one evidence chain. A retry must be idempotent; rollback claims must
+distinguish reversible local state from effects already observed elsewhere.
+
+### 9. Inclusion is multi-channel, not portal-only
+
+Public portal, postbox, mail, telephone, paper, in-person assistance, APIs, and
+external systems are channels around the same governed work. Assisted entry
+records who entered information, for whom, from which source, with which
+attestation, and how the affected person receives a usable receipt and
+correction path.
+
+### 10. Successful configurations are portable products
+
+Modules are ingredients. A usable product is a signed configuration package
+with terminology, forms, policies, workflows, views, reports, provider
+profiles, documentation, migration rules, and evidence. Institutions derive
+local packages without forking code or weakening inherited constraints.
+
+## Platform Planes
+
+The planes below are ownership lenses, not navigation groups or mandatory
+deployment tiers.
+
+| Plane | Responsibility |
+| --- | --- |
+| Experience | Shell, views, dashboard, search, help, accessibility, and task-focused composition |
+| Participation and channels | Portal, postbox, mail, campaigns, calendar, scheduling, consultation, and assisted channels |
+| Human work and procedure | Services, forms/runtime, cases, tasks, approvals, workflow execution, and domain procedures |
+| Content, records, and evidence | Files, templates, DMS, eAkte/records, audit, reporting, transparency, and publication |
+| Institutional governance | Identity, access, tenancy, organizations, functions, mandates, policy, trust, and formal decisions |
+| Data and integration | Connectors, datasources, dataflow, search, external references, provider health, and reconciliation |
+| Runtime and assurance | Module composition, operations, deployment, recovery, security evidence, and signed packages |
+
+## Canonical Distinctions
+
+The platform must not collapse these pairs:
+
+- identity vs account vs represented capacity;
+- role/permission vs function/mandate/competence;
+- valid time vs recorded time;
+- purpose for use vs general technical access;
+- document content vs managed file bytes vs institutional record;
+- task vs workflow definition vs workflow instance;
+- approval vs formal decision;
+- message intent vs transport delivery vs recipient acknowledgement;
+- source authority vs connector maturity;
+- current state vs historical evidence;
+- correction/compensation vs erasure of an observed effect;
+- a module boundary vs a user-visible product boundary.
+
+## Product Experience Rule
+
+The normal user interface speaks in services, work, records, messages,
+meetings, decisions, and outcomes. Module names, provider IDs, capability names,
+package coordinates, and schema details are technical provenance. They are
+visible to administrators and in expandable diagnostics, but they are not the
+primary information architecture for ordinary work.
+
+## Maturity Rule
+
+A repository, route, model, or unit test does not make a capability complete.
+Claims advance only with evidence appropriate to the claim:
+
+1. `scaffold`: boundary and documentation exist;
+2. `vertical_slice`: useful behavior has focused tests;
+3. `reference_ready`: an end-to-end reference journey passed target,
+   accessibility, privacy, security, operations, and recovery evidence;
+4. `supported`: upgrades, interoperability, support procedures, and release
+   guarantees are defined;
+5. `lts`: compatibility and maintenance windows are contractual.
+
+## Deliberate Non-Goals
+
+GovOPlaN does not aim to:
+
+- replace every specialist system, ERP, DMS, groupware, or data tool;
+- make one database authoritative for every connected fact;
+- expose every installed capability to every person;
+- infer authority from organizational membership alone;
+- make historical browsing weaken current security;
+- treat AI output as an unaccountable institutional decision;
+- create a repository for every noun in the information model;
+- claim production maturity from local development evidence.
+
+## Decision Test
+
+A proposed feature fits the platform when it improves at least one real
+institutional journey and can answer:
+
+1. Who owns the object and source of truth?
+2. In which institutional and temporal context does it apply?
+3. For which declared purpose may it be used?
+4. Which policy and authority permit the action?
+5. What effect, evidence, retention, and recovery behavior result?
+6. How can it operate with an external owner without losing autonomy?
+7. How will a person discover and complete it without learning the module
+   graph?
+