You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 89ba695
Browse filesBrowse the repository at this point in the historyBrowse files
Refine governance runtime and request lifecycle (#48)
# Summary
This PR expands the governance runtime by introducing governed execution
abstractions, refining the request model, and restructuring lifecycle
handling. It also improves the internal testing infrastructure and
updates the examples to reflect the new API.
## Highlights
### Governed execution
* Add governed execution abstraction models.
* Refine the governance execution runtime.
* Document runtime resolution helpers.
* Document the governed execution compensation model.
### Request model
* Refine governance request abstractions.
* Introduce a dedicated `MutationRequest.Lifecycle` object.
* Move lifecycle related properties into the lifecycle model to improve
cohesion and simplify the public API.
### Testing
* Reorganize shared runtime test fixtures.
* Reorganize governance and Redis provider test fixtures for focused
scenarios.
* Extract Redis-specific keyspace and serializer support where it
reduces repetition.
* Extract reusable runtime policy test support.
* Extract strongly typed side-effect test payloads.
### Examples
* Update governance examples to use the new request model and lifecycle
structure.
## Why
As the governance layer continues to evolve, the original request model
became increasingly difficult to extend. Grouping lifecycle information
into a dedicated object provides a cleaner API while making future
governance capabilities easier to implement.
This refactoring also prepares the runtime for richer execution
scenarios by:
* separating execution concerns from request representation,
* improving the organization of lifecycle state,
* reducing duplication across the test suite,
* documenting the execution and compensation model,
* providing clearer extension points for future governance providers.
## Breaking Changes
`MutationRequest` has been updated.
Lifecycle related members are now exposed through the `Lifecycle` object
instead of being located directly on the request.
Examples and tests have been updated accordingly.
## Closes
* Closes#25
* Closes#42
* Closes#44
* Closes#45
* Closes#46
* Closes#47
ADR-027 established governed execution as the point where approved governance requests enter the core mutation engine.
18
+
19
+
That execution path already persisted terminal request outcomes and already carried audit and history metadata, but it still lacked a first-class way to represent compensation:
20
+
21
+
-`MutationIntent.IsReversible` existed only as intent metadata
22
+
- rollback or corrective compensation had no durable request-level model
23
+
- original and compensating executions were not explicitly linked
24
+
- audit and history could show that a mutation happened, but not that a later governed execution compensated for it
25
+
26
+
Without an explicit compensation model, governed execution would treat rollback and forward correction as informal follow-up work. That is not sufficient once governance requests, request history, and durable execution outcomes become part of the public platform model.
27
+
28
+
## Decision
29
+
30
+
Governed compensation should be modeled as a first-class governed execution concern.
31
+
32
+
The model should introduce:
33
+
34
+
- explicit compensation plan contracts
35
+
- explicit execution classification for standard and compensating governed executions
36
+
- explicit links between original and compensating request records
37
+
- explicit request decision history for compensation behavior
38
+
- explicit audit and history metadata that preserves compensation semantics
39
+
40
+
Implemented shape:
41
+
42
+
-`GovernedCompensationPlan` describes the original request being compensated together with compensation kind, trigger, optional batch identity, and related request identifiers
43
+
-`GovernedCompensationKind` distinguishes restoration-style rollback from forward corrective compensation
44
+
-`GovernedCompensationTrigger` distinguishes operator-driven rollback from batch or failed-execution initiated compensation
45
+
-`GovernedExecutionKind` classifies governed execution as standard execution or compensation
46
+
-`GovernedExecutionLink` and `GovernedExecutionLinkType` link governed requests through `Compensates` and `CompensatedBy`
47
+
- request-level execution metadata is grouped under `GovernedExecutionDetails`
48
+
- compensation requests are created through dedicated request factory flow rather than being mixed into the baseline request factory path
49
+
- original requests receive a `Compensated` lifecycle decision when a compensating request executes successfully
50
+
51
+
Runtime behavior:
52
+
53
+
- compensation remains governed execution, not a utility outside the governance lifecycle
54
+
- successful compensating execution updates the compensating request and then links it back to the original request
55
+
- audit and history metadata must carry both execution kind and compensation metadata so the compensating behavior remains visible after persistence
56
+
57
+
## Design Rationale
58
+
59
+
- Compensation is a governance concern because it changes how durable requests, decisions, and execution outcomes are interpreted over time.
60
+
- Explicit links are preferable to inference from tags or metadata because they survive storage, querying, and future provider implementations more cleanly.
61
+
- Rollback and forward correction are not the same operational action, so the model should distinguish them even if the first tested path focuses on rollback.
62
+
- A dedicated compensation request factory keeps baseline request creation simpler while allowing compensation-specific semantics to remain explicit.
63
+
- Audit and history already form part of the governed execution contract, so compensation semantics should extend those flows rather than introducing a parallel reporting mechanism.
64
+
65
+
## Consequences
66
+
67
+
### Positive
68
+
69
+
- Governed execution now has durable compensation semantics instead of relying on convention.
70
+
- Original and compensating requests can be traversed explicitly.
71
+
- Audit, history, and request decision flows preserve why and how compensation happened.
72
+
- The model supports operator-driven rollback immediately and leaves room for broader compensation planning later.
73
+
74
+
### Negative
75
+
76
+
- The governance request model becomes more complex because execution metadata now carries compensation and linking semantics.
77
+
- Runtime execution must perform an additional persistence step to link successful compensation back to the original request.
78
+
- Future storage providers and query models must preserve the new compensation and linking fields consistently.
79
+
80
+
## Non-Goals
81
+
82
+
- automatic generation of reverse mutations
83
+
- distributed saga orchestration
84
+
- full batch compensation engine
85
+
- replacing explicit domain modeling for inherently irreversible mutations
86
+
87
+
## Related ADRs
88
+
89
+
- ADR-020: Governance MutationRequest Model
90
+
- ADR-022: Governance Request Decisions and Storage
Copy file name to clipboardExpand all lines: Docs/Decision/listadr.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,5 +49,6 @@ These ADRs describe the `ModularityKit.Mutator.Governance` extension layer and i
49
49
| ADR-031 | Governance Redis Serialization and Document Compatibility |[ADR-031](Adr/ADR_031_Governance_Redis_Serialization_and_Document_Compatibility.md)|
50
50
| ADR-032 | Governance Redis Concurrency and Index Maintenance Model |[ADR-032](Adr/ADR_032_Governance_Redis_Concurrency_and_Index_Maintenance_Model.md)|
51
51
| ADR-033 | Governance Query Model Decomposition |[ADR-033](Adr/ADR_033_Governance_Query_Model_Decomposition.md)|
52
+
| ADR-034 | Governed Execution Compensation Model |[ADR-034](Adr/ADR_034_Governed_Execution_Compensation_Model.md)|
52
53
53
54
> See individual ADRs for detailed context, decision rationale, and consequences.
0 commit comments