feat: implement institutional governance and recovery architecture

docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md

@@ -16,6 +16,7 @@ cross-product vision that sequence serves.
 
 Read it together with:
 
+- the [institutional governance target architecture](INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md)
 - the [selected reference-journey program](REFERENCE_JOURNEY_PROGRAM.md)
 - the [current capability and infrastructure fit assessment](CAPABILITY_AND_INFRASTRUCTURE_FIT.md)
 - the [interface pattern language](INTERFACE_PATTERN_LANGUAGE.md)
@@ -151,7 +152,7 @@ responsibilities, not a new dependency hierarchy.
 | Participation and channels | Let internal and external actors enter, receive, discuss, schedule, and respond through suitable channels. | Portal, postbox, mail, notifications, calendar, scheduling, appointments, campaign, consultation, poll |
 | Work coordination | Turn an input into owned, reviewable work and make exceptions visible. | Forms/runtime, cases, tasks, approvals, workflow, booking, resources, domain modules |
 | Evidence and institutional memory | Preserve what was known, decided, produced, sent, received, retained, corrected, and disclosed. | Files, templates, DMS, records, audit, search, reporting, transparency |
-| Institutional governance | Establish who may act, in which capacity, for which organization and tenant, under which policy. | Identity, access, IDM, tenancy, organizations, policy, identity trust, risk/compliance |
+| Institutional governance | Establish who may act, in which capacity, for which organization and tenant, under which mandate, jurisdiction, and policy. | Identity, access, IDM, tenancy, organizations, policy, identity trust, risk/compliance; candidate mandate and decision contracts |
 | Integration and operations | Connect sources and destinations, operate them safely, and prove their health and recovery. | Connectors, REST/SOAP and public-sector protocols, mail/calendar/file adapters, ERP handoffs, ops, release and configuration packages |
 
 Across these planes, GovOPlaN should maintain a connected context graph rather
@@ -1136,11 +1137,12 @@ boundary, and retain operational, security, and evidence guarantees.
 | Addresses and directories | Implemented adapters exist but configuration/target proof varies | Directory source, privacy, conflict and lifecycle package | Reusable people/contact source capability |
 | Docs/admin/ops/dashboard | Useful cross-product surfaces with incomplete rollout | Configured-system inventory, guided config, monitoring/recovery evidence | Explainability and operation of the configured product |
 | Organizations/identity/IDM/access/postbox | Normalized ownership concepts and uneven runtime slices | Function-bound delivery, reassignment/delegation, vacancy and access-evidence proof | Institutional responsibility and durable communication spine |
-| Forms/cases/tasks/approvals/search | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey | Reusable administrative coordination layer |
-| Templates/reporting/data sources | Boundary concepts or scaffolds | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption |
-| Analytical data products/dataflow | Selected direction; platform contracts not yet implemented | One bounded university source-to-indicator path with staging, quality, lineage and promotion proof | Transparent institutional BI and cross-process reporting |
+| Forms/cases/tasks/approvals | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey, with shared service, party, mandate, and decision semantics | Reusable administrative coordination layer |
+| Search | PostgreSQL-backed permission-aware provider and global/contextual UI foundation | Complete provider rollout, indexing operations, and target authorization/performance evidence | Optional cross-module discovery with OpenSearch only as an adapter |
+| Templates/reporting/data sources | Templates and governed Datasources foundations exist; Reporting remains an early semantic-model slice | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption |
+| Analytical data products/dataflow | Typed graph/runtime foundations, triggers, staging integration, reusable definitions, and golden-flow fixtures exist | One bounded university source-to-indicator path with quality, lineage, promotion, and target-performance proof | Transparent institutional BI and cross-process reporting |
 | DMS/collaborative editing | Boundary concept and tag-only scaffold | One Files-backed version lifecycle, then one provider-neutral editing session | Collaborative documents, review, approval and records-ready renditions |
-| Workflow/automation | Concept only; no discoverable Workflow runtime; program postponed | Stable action/effect providers and an explicitly reprioritized bounded journey | Configurable governed process coordination |
+| Workflow/automation | Headless Workflow Engine and optional editor are implemented foundations with versioned module baselines, BPMN interchange, action/effect execution, and reconciliation | Prove one resumable human/system journey with target recovery and conformance evidence | Configurable governed process coordination without becoming a second domain layer |
 | Domain modules | Mostly boundary concepts or seeds | Only the modules required by a reference package | Reusable semantics above the shared spine |
 | Connectors and protocols | Catalogue/strategy plus several module-specific adapters | Profile/runtime, source-of-truth, health and one real landscape | Coexistence with institutional IT |
 | Records/transparency/risk-compliance/export screening | Planned or early concepts | Evidence contracts and one regulated reference story | Institutional memory, oversight, and assurance |
@@ -1216,8 +1218,9 @@ provides all applicable evidence below.
 ## Near-term portfolio order
 
 This order is now selected. Detailed slices and gates are in the
-[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow-driven
-user-story implementation remains paused.
+[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow Engine and
+the optional editor may support these stages, but Workflow work enters the
+portfolio only through an explicit bounded package or reference journey.
 
 0. **Continuous safe foundation.** Keep the composition green and version
    aligned; close connector destination pinning, response limits, throttling,
@@ -1250,8 +1253,9 @@ user-story implementation remains paused.
    target acceptance for calendar/scheduling/poll and other shipped foundations
    without displacing the selected reference path; implement new feature
    programs only when they are required by a stage or explicitly reprioritized.
-7. **Resume Workflow only by explicit priority decision.** When resumed, start
-   with stable actions from a demonstrated package; do not turn it into a
+7. **Use Workflow only through bounded journeys.** The headless engine and
+   optional editor now exist. Extend them through stable module-owned actions,
+   versioned baselines, and demonstrated packages; do not turn Workflow into a
    second domain layer.
 
 ## Product decisions to make progressively
@@ -1263,8 +1267,8 @@ them; they do not block the product vision today.
   reference release?
 - Which real identity, groupware, file/DMS, and deployment stack should define
   the first integration profile?
-- When should the postponed Workflow program resume, and which single package
-  will constrain its first implementation?
+- Which demonstrated package should provide the first target-accepted Workflow
+  execution and recovery profile?
 - Which objects and fields remain authoritative in GovOPlaN versus each target
   system, and which conflict/failure behavior is acceptable?
 - Which default participant privacy profiles should ship for scheduling,