govoplan-approvals/docs/APPROVALS_DOMAIN_BOUNDARY.md

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.

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 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.