58 lines
2.8 KiB
Markdown
58 lines
2.8 KiB
Markdown
# Approvals domain boundary and operations
|
|
|
|
Approvals owns generic, reusable sign-off chains. A request freezes an exact
|
|
module-owned subject revision, ordered steps, eligible actor selectors,
|
|
required counts, rejection behavior, due dates, signature requirements,
|
|
separation-of-duties rules, and policy references.
|
|
|
|
Approvals does not own the subject's business state. A Campaign remains a
|
|
Campaign and a Decision remains a Decision. Consumers call
|
|
`approvals.requests.check_approved` with the exact subject identity and version
|
|
before performing their consequential transition. A previously approved
|
|
request cannot authorize a changed subject revision.
|
|
|
|
## Actor and decision semantics
|
|
|
|
Selectors can target an account, group, role, function assignment, or any
|
|
authenticated account. They are evaluated against trusted principal claims.
|
|
Delegated decisions are accepted only when the principal already carries the
|
|
matching acting-for account. The actual and represented account plus the
|
|
trusted delegation identifier are retained.
|
|
|
|
Requests can prohibit requester self-approval and can require distinct actors
|
|
across steps. Each decision is append-only, reasoned, optimistic-concurrency
|
|
protected, and idempotent. Signature-required steps store a provider-owned
|
|
signature reference; Approvals does not implement document signing or key
|
|
custody. A fail-fast rejection ends the request. Due steps can enter an
|
|
explicit escalated state without silently changing their outcome.
|
|
|
|
When Tasks is enabled, Approvals projects only currently actionable steps into
|
|
the common work inbox. The projection applies the same selector, expiration,
|
|
prior-decision, unique-actor, evidence-role, and requester-separation checks as
|
|
the decision command. Approvals remains the owner of decision and completion
|
|
state; Tasks receives no copied approval record.
|
|
|
|
## Recovery and scale-out
|
|
|
|
All API and worker nodes use the logically shared database. Back up and restore
|
|
these tables as one consistency unit:
|
|
|
|
- `approval_request_revisions`
|
|
- `approval_decision_records`
|
|
- `approval_lifecycle_events`
|
|
- `approval_replays`
|
|
|
|
After restore, verify one current revision per tenant/request, contiguous event
|
|
sequences, unique actor decisions per step, decision receipt hashes, and exact
|
|
subject bindings. Consumers must re-run `check_approved`; they must not infer
|
|
approval from cached UI state. Before destructive retirement, snapshot the
|
|
database and reconcile every module object that retains an Approval reference.
|
|
|
|
## Optional integrations
|
|
|
|
Workflow Engine may wait for completion, Tasks may aggregate actionable work,
|
|
and Notifications may announce an assignment, due date, escalation, or
|
|
outcome. Audit may retain additional cross-domain evidence. Policy may provide
|
|
chain templates. These integrations use capabilities and events; none reads
|
|
Approval tables directly.
|