Skip to content

[Task]: Implement governed execution manager #16

Description

@rian-be

Summary

Add a governance execution manager that closes the runtime loop from approved request to mutation execution and terminal governance decision.

Goal

Ensure every approved governance request flows through one explicit execution path that performs version resolution, invokes the core mutation engine, records the execution outcome, persists the final governance state, and correlates request-level and execution-level audit/history data.

Problem

Governance currently has the building blocks needed to defer and approve a request:

  • request lifecycle
  • approval workflow
  • version resolution
  • request storage and decision history

What is still missing is the mandatory orchestration step that turns an approved request into governed mutation execution. Today those pieces can be composed, but they are not yet one durable runtime contract.

Scope

  • Introduce GovernanceExecutionManager or equivalent orchestration service
  • Load approved requests and validate that they are still eligible for execution
  • Always perform version resolution before execution begins
  • Execute the underlying mutation through the core runtime when resolution allows it
  • Persist execution outcome, resulting state version, and terminal governance decision
  • Mark requests as Executed, rejected as stale, or sent back to renewed approval / revalidation
  • Emit audit and history records that correlate request-level and execution-level outcomes
  • Add runnable example coverage for the full governed execution loop

Design Expectations

  • The execution manager should own the whole transition from approved request to terminal governance outcome.
  • Version resolution must not be optional once a request enters the governed execution path.
  • Execution outcome should be visible both in governance request history and in runtime audit/history stores.
  • Failures should be domain-expressive rather than hidden behind incidental infrastructure exceptions.

Acceptance Criteria

  • Approved requests cannot bypass version resolution before execution
  • Execution outcome is persisted back onto the request lifecycle
  • Resulting state version is stored when execution succeeds
  • Rejected / stale / renewed approval branches are explicit and auditable
  • End-to-end tests cover approved request -> resolution -> execution -> terminal decision
  • At least one runnable example demonstrates the full governed execution loop

Non-Goals

  • This issue does not include EF Core / PostgreSQL persistence providers
  • This issue does not add compensation semantics
  • This issue does not redesign async policy integration

Notes

Current governance runtime has lifecycle, approval, and version-resolution primitives. The main missing behavior is one mandatory execution path that turns an approved request into governed mutation execution.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No fields configured for Task.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions