Approval Chains — Proposed Guide
Planned API — Reference OnlyApproval Chains: A chain describes an ordered set of review responsibilities for a business request. It should explain how a request advances and what…
Overview
A chain describes an ordered set of review responsibilities for a business request. It should explain how a request advances and what happens when a reviewer cannot act.
Key concepts
Keep chain definition separate from an instantiated review. Record the chain version selected for the request.
Implementation considerations
Changing a chain should not rewrite decisions already recorded under an older version. Define whether pending reviews retain their original routing.
Illustrative data model
This local fixture shows a possible representation for the concepts above. It is not an endpoint response, production configuration or a claim that the described capability is implemented.
{
"reference_only": true,
"topic": "Approval Chains",
"chain_id": "chain_example_123",
"version": 1,
"reviewer_ids": [
"usr_example_123"
]
}Design review checklist
- Document which organization owns the approval chains representation and which actor may view or change it.
- Test the boundaries of chain id, version, reviewer ids using synthetic values, including missing or inconsistent references.
- Before future implementation, obtain an approved contract and review failure behavior. This documentation does not authorize production activation.
Proposed data types
| Name | Type | Description |
|---|---|---|
| chain_id | string | Stable fictional chain reference; not a secret and not evidence that a resource exists. |
| version | integer | Illustrative resource revision for detecting stale updates; no live concurrency contract is published. |
| reviewer_ids | array<string> | Fictional reviewer references; validate ownership and avoid duplicate membership. |