When Several Approvals Become One Authorized Change

Design multi-party approval around a common proposal, eligible independent reviewers, explicit decision rules and a protected transition into identifiable execution.

audience="Workflow owners and engineers responsible for changes that require several people's agreement." decision="Choose how individual decisions form a collective permission, and where that permission becomes a protected execution intent." position="Bind contributions to one proposal and policy basis. Enforce eligibility, independence and the declared decision rule before a separate, current execution check." scope="A proposed engineering design using synthetic reviewers, a specification change and inert destination fixtures. This is not a legal-signature opinion, provider certification or measured customer result." outputs={['A decision-rule contract', 'A proposal and participant manifest', 'A delegation policy', 'A protected transition design', 'A per-effect recovery record', 'Independent acceptance expectations']} />

Executive summary

Several approval messages become permission to change a system only when they refer to a compatible proposal, come from eligible participants, satisfy an explicit rule and survive the checks required at the transition into execution. Counting green badges is insufficient. Three approvals can describe three different versions. Two department labels can belong to one person. A completed review can remain valid history while a later change makes it unusable as authority for the current action.

Use a synthetic specification change C70 to make the problem concrete. Revision R7 changes a component specification and a supplier instruction. Policy P3 requires engineering, quality and procurement agreement from three distinct eligible people. This independence requirement is a declared fixture assumption, not a universal rule for all organizations. Engineering approves R7. An editor then creates R8 with another supplier. Quality approves R8 and procurement follows an old R7 notification. The application has three positive responses, but no complete approval set for either revision.

The recommended starting point is a written decision contract and the existing owning workflow. Keep a native approval system if it can enforce that contract, identify the reviewed package and prove the permitted transition. Add a domain-owned decision service only where actual invariants cannot be enforced by the existing boundary. Use orchestration for waiting and delivery, not as a substitute for proposal identity, participant policy or destination effect evidence.

This paper defines the artifacts needed to make that choice: an immutable review basis, participant contributions, rule evaluation, a protected intent and a recovery record. AI can help prepare differences and questions without acting as an unnamed reviewer. All examples and acceptance expectations are illustrative. No production approval, model evaluation, supplier instruction or database race is represented as an observed result. Real operating rules, provider behavior and legal requirements need their own accountable review.

Define the decision before selecting an approval mode

Write the action in concrete terms. “Approve the project” is too broad if the next step can publish a document, authorize expenditure or change a supplier instruction. For C70, the selected action is releasing a specified instruction package to one named destination. Internal agreement on a design is a different decision from permission to send that package. Define whether the collective decision directly permits release or merely makes the proposal eligible for a later release owner.

Separate participant selection from the decision rule. A role can identify a required seat, a pool of interchangeable reviewers or a person whose rejection blocks the change. An all-required-seats rule differs from a numerical threshold. A threshold can require two eligible people without requiring procurement specifically. A veto can prevent release even after a threshold is met. Sequential review adds prerequisites: a later contribution might be admissible only after an earlier stage is complete. These meanings should not be inferred from the number of workflow boxes.

Microsoft's approval tutorial documents an Everyone must approve mode that completes after all assigned people approve or one rejects. It also distinguishes First to respond. Those are useful explicit choices, not interchangeable labels for consensus. The tutorial does not establish C70's three-person independence rule or prove that a changing source package remains bound to every response.

Record how abstention, no response, requested changes and conditional agreement affect the rule. A comment saying “approved after the supplier certificate arrives” is not unconditional release permission. Either model the condition as a verifiable prerequisite or keep the decision pending. Choose who resolves ambiguity without silently editing the original response. When a native provider's response options cannot express the contract, simplify the process or implement a controlled extension. Do not compensate by interpreting free text as whatever makes the workflow finish.

Construct one review basis that every contribution can identify

The review basis includes tenant, workflow, proposal revision, significant structured fields, attachments, intended action, destination and decision-policy version. Friendly names such as C70 and R7 are convenient labels, not globally unique boundaries. Two tenants can use the same names. A supplier attachment can change without the visible specification title changing. A current-file URL can resolve to new content after the email was sent. Resolve the identified package on the server under the viewer's authorized scope.

Preserve the representation offered to each reviewer and its relationship to the authoritative source. A file digest can detect a byte difference; it does not prove that a person could see a hidden attachment, tracked change or significant commercial term. Provide a readable difference view, attachment inventory and clear action statement. Record unavailable material as a missing prerequisite. If the renderer omits a required field, fixing the renderer and asking for a new decision is safer than declaring that the old digest proves informed review.

Choose a significance rule rather than automatically treating every edit alike. A spelling correction may leave the proposed supplier instruction unchanged. A destination, quantity, safety condition or contractual term change may require renewed review. The workflow owner must define the permitted equivalence classes and their evidence. The implementation should retain both the raw artifact identity and the significance assessment, so an auditor can distinguish an unchanged action from a convenient assertion that two packages are equivalent.

For the fixture, a supplier change always creates a new review basis. No automatic transfer of R7 approvals to R8 is permitted. A different real process may allow selected contributions to be revalidated, but that needs an explicit rule identifying the unchanged scope and responsible actor. Record revalidation as a new attributable event. Do not relabel an old decision as if the person had reviewed the new package. This distinction preserves history while preventing mixed-version agreement.

Bind each response to a participant and an eligible seat

A contribution should identify the actual responding actor, the seat being fulfilled, the selected basis, the response, the effective time and the method used to accept it. An email address alone may be a shared mailbox or an alias. A department label is not a person. Use the authenticated identity supported by the chosen provider, with a documented mapping to the organization's identity and role records. Do not infer eligibility solely because a forwarded notification reached someone.

Decide whether membership is pinned at invitation, checked when responding, checked at collective seal or checked again at execution. Different policies lead to different outcomes when a reviewer changes roles. Historical review evidence may remain meaningful after employment or assignment changes. Permission to contribute a new response may not. For C70, new contributions require current eligibility and the seal rechecks the declared participant basis. Those are fixture choices; a real process needs explicit revocation timing and provider guarantees.

Independence is a relationship between actors, not merely seats. If the same actor occupies engineering and procurement, C70's three-distinct-person rule is not satisfied by two clicks under different labels. A different workflow can legitimately allow one actor to cover several responsibilities. State which applies. Also define whether the requester can review their own proposal, whether a manager can approve on behalf of a direct report and what conflicts disqualify a participant. Avoid claiming that any universal segregation policy is legally required here.

Keep selection explanations understandable. A rejected contribution should tell an authorized operator that the actor is ineligible for this seat, the basis changed or a required independent reviewer is missing. It should not expose unrelated employee information or tenant membership. An operator needs a route to correct an assignment, not a generic error that encourages them to remove the failing check. Assignment changes themselves need a permitted actor and a new visible participant basis where the decision contract requires it.

Form the collective decision without counting messages as votes

Normalize provider callbacks into attributable contribution events. Distinguish an exact replay of one response from a changed response by the same actor. A repeated webhook must not add another reviewer. A later withdrawal must not disappear behind an earlier positive response. Decide whether responses are replaceable until seal, terminal once submitted or reopened through an explicit event. Preserve prior history while evaluating the current admissible set according to that rule.

Group contributions by review basis before evaluating any threshold. For C70, R7 engineering plus R8 quality plus R7 procurement is incomplete, even though all three role labels appear somewhere in the event stream. Grouping only by the business object mixes revisions. Grouping only by document digest omits action and policy scope. The evaluator must also account for ineligible actors, expired delegation, disallowed self-review and any blocking decision. Explain which required contributions remain missing rather than presenting a misleading percentage complete.

The map shows one proposed all-seats contract. Each contribution retains the same proposal and policy basis. The evaluator checks people and rules; its output does not prove that an instruction has been sent. This is why an approval dashboard should separate collective completion, execution eligibility and destination settlement.

Define the treatment of late responses after rejection or seal. A delayed approval should not resurrect a rejected request automatically. A duplicate rejection should not create repeated cancellation effects. If the business reopens a case, create an identifiable review cycle with its own admissible contributions and explain whether any earlier evidence is carried forward. A cycle identifier is useful only if every writer and callback path observes it. A repair script that ignores the cycle can reintroduce mixed decisions even when the primary UI is correct.

Treat delegation and exceptions as policy, not convenience

Delegation requires a grant with scope, delegate identity, eligible seat, permitted action, validity period and any substitution restrictions. Decide whether delegation replaces a participant, permits another person to respond for the same seat or creates an additional review requirement. A forwarded approval email is not evidence that these rules were satisfied. If the provider supports delegated responses, inspect its actual event semantics and actor evidence before mapping them into the domain record.

Preserve the original responsible seat and actual actor separately. Otherwise the record can imply that the principal approved when only the delegate responded. Under C70's fixture, a delegate may fill one seat while remaining subject to the distinct-person rule. The principal and delegate cannot create extra independent votes by responding twice for the same seat. Expired delegation prevents a new contribution; the treatment of an earlier valid contribution at seal follows the explicitly selected recheck policy.

Emergency release should be a separate permitted path, not an exception that quietly flips approved to true. Name the actor who can invoke it, the actions it covers, required evidence and later review obligations. Record that normal consensus was bypassed under the stated exception. A real emergency policy may permit a narrower action than the original proposal, such as holding shipment rather than releasing a substitute. The architecture must support the actual exception, not just the ordinary happy path with fewer approvals.

Operational pressure often creates informal alternatives: a chat message, a manager's call or an administrator editing the database. Decide which are admissible and how they become attributable records. If the organization cannot establish the evidence required for an external instruction, use a manual hold or verified recovery procedure. An exception route should remain usable when the workflow provider is unavailable, while preserving the chosen authority boundary. It should not grant the recovery operator unrestricted permission to impersonate every participant.

Keep policy evaluation separate from a committed transition

A policy evaluator can answer a question about supplied facts, but the application still owns the protected business transition. Build the input from authoritative server-side state, not client-supplied claims that an actor is eligible or that the proposal is unchanged. Include relevant policy and membership basis, significant action fields and the expected review cycle. Reject missing required facts explicitly. A technically successful policy call with an incomplete input can be a failed business check.

OPA's REST API defines input-based evaluation and optional decision identifiers for log correlation. It also documents that an undefined document can return HTTP 200 without a result property. Check the expected result contract, not just the status code. In this proposed design, a missing allow result becomes a hold. A correlation identifier is useful evidence linkage, not a bearer capability or proof that a supplier instruction was committed.

Policy distribution has its own consistency boundary. OPA's bundle documentation describes eventual distribution and an optional manifest revision. Record the active rule basis used for evaluation and distinguish it from proposal R7 and the authoritative participant data. A recently published bundle does not prove every evaluator has activated it, nor that an independently supplied role lookup is current enough for the selected rule.

Choose an acceptable execution policy for rule changes. The business may require the current release rule, a pinned reviewed rule plus current emergency restrictions, or a defined migration. Do not choose opportunistically after a decision fails. If the required basis is unavailable or contradictory, hold the transition with a recoverable reason. Keep the boundary enforceable in the owning service, especially when distributed evaluators cannot offer the atomic membership and proposal snapshot the contract needs. A policy engine is an optional implementation choice, not the authority by its presence alone.

Protect the race between the final response and an edit

The dangerous race is not solved by rereading the proposal immediately before writing. An editor can commit after the read and before intent creation. A final reviewer can respond while an assignment is replaced. Two callbacks can both decide that the required set is complete and start two release jobs. Define the protected state that includes proposal basis, review cycle, admissible contributions, relevant authority checks and the single identifiable intent. Every competing writer must participate in that boundary.

PostgreSQL's isolation reference explains statement snapshots at Read Committed and whole-transaction retry requirements for relevant serialization failures. A transaction wrapper alone does not establish a multi-record invariant. Select conditional writes, locking or appropriate isolation for the actual owning state, and prove the competing schedules. A rolled-back attempt must leave no dispatchable intent; a no-match conditional transition must not be interpreted as success.

For the current-package fixture, consider two schedules. Edit-first commits R8 before seal. The R7 attempt cannot create a current-package release intent. Seal-first commits one pinned R7 intent before the editor creates R8. The later draft is not automatically substituted into that intent. What happens next depends on the declared post-seal policy: hold pending dispatch, permit the pinned package or invoke a separately controlled cancellation. Record which schedule won rather than sorting client timestamps and guessing.

Keep external release outside speculative database attempts. Retrying a local transaction should recompute the admissible state under the same request identity, not replay an external instruction. Where authority spans independent providers, document the residual gap rather than drawing a database transaction around them. A destination-supported conditional operation or version-aware commit may help, but its actual guarantees must be verified. Without them, reduce the permissible action or use a controlled manual boundary.

Choose an owning implementation with the least unnecessary complexity

Existing native workflow. Prefer it when it can identify the package, record actors and decisions, enforce the selected rule and protect the release boundary. Its strengths may include established user access, notifications and operating ownership. Inspect version binding, delegation, conditional transitions and export evidence rather than assuming those controls exist. If one provider owns review and release, a smaller integration can be more reliable than a second application maintaining a competing approved flag.

Domain-owned decision service. Consider it when the collective invariant spans source revisions, role rules or several actions that the native workflow cannot enforce. Keep one authoritative decision record, not several mirrors that can each authorize release. The service can expose a readable proposal, accept scoped contributions and commit one intent under its transaction boundary. Its cost is real: policy ownership, identity integration, evidence retention, accessible UI, concurrency testing, recovery and operational support now belong to the organization.

Orchestration around an owning decision boundary. Use this when reviews take time or downstream work crosses systems. The orchestrator can wait, notify and dispatch identified operations. It should ask the owning service whether a transition was committed instead of independently recounting callbacks. Workflow retry and business-effect deduplication are different problems. AWS StartExecution documents specific Standard running-execution idempotency conditions and states that Express is not idempotent. Those limits do not establish unique supplier release effects.

Compare the alternatives against the contract, not a feature catalogue. Who enforces revision changes? Which evidence identifies the actual actor? Can a final contribution race with an edit safely? Can an operator reconcile a missing receipt? Which system is authoritative during an outage? Reject a design that adds a second approval owner without a transition protocol. Equally, do not build a custom engine merely to make the diagram look advanced. A verified native boundary with a carefully scoped AI preparation step may meet the need with less operational burden.

Recheck permission at execution without erasing historical decisions

A collective decision is an attributable historical event. Execution permission can depend on additional current conditions, such as withdrawn release rights, an expired grant or an emergency hold. Keep those facts separate. An expired authority does not prove that the earlier person never reviewed R7. Conversely, historical approval does not entitle a delayed worker to send any current package it can fetch. Store the selected action and enforce the declared relationship between seal and dispatch.

OWASP's transaction-authorization guidance supports significant-term confirmation, server-side enforcement and a final check tied to execution. This paper applies that engineering principle to a scoped release operation. It does not establish legal signature validity or prescribe a universal second-factor mechanism. The actual action risk and existing authorization method need their own assessment.

Choose precisely when withdrawal takes effect. If a pending intent can be stopped before dispatch, protect that state against a dispatcher concurrently claiming it. If a request has already crossed the destination boundary, local cancellation cannot prove it was not applied. A later instruction may need a separately permitted reversal. Show pending, dispatching, confirmed, rejected and unknown as effect states rather than hiding them under an approval badge. An operator needs to know whether they can still prevent an action or must investigate an action that may exist.

Avoid granting permanent authority to background credentials merely because a human review once finished. The worker should execute only the identified permitted effect, under the required tenant and destination scope. If current checks fail, preserve the intent and hold reason without creating an alternative wider operation. Recovery should retain the original identity and authority record. A manual retry is still an action requiring permission, not an exemption from the rules applied to automated dispatch.

Reconcile destination outcomes and retain defensible evidence

Commit an effect identity before sending an external instruction. Record the selected package, destination, intended change and request identity, then use the provider's supported receipt and readback routes. A transport timeout cannot distinguish refusal from an accepted operation whose response was lost. Keep that state unknown until supported evidence resolves it. Reissuing with a new identity can create a duplicate even when the local workflow appears to have failed cleanly.

Define what each receipt establishes. A queued provider message may prove acceptance for processing, not delivery or application. A downloaded document may prove an export, not supplier acknowledgement. A provider status must be mapped to the business disposition using the actual integration contract. If no supported lookup can establish whether the instruction exists, retain an unresolved investigation with an accountable owner. Do not infer absence from a failed search or a temporarily unavailable readback API.

Evidence should connect the readable proposal, source identity, participant contributions, selected rule, protected intent and destination result. Retain enough to explain the decision without collecting every unrelated document or private conversation. Restrict retrieval and export by tenant and role. Treat approval notes, attachments and policy inputs as potentially sensitive. Define retention, deletion and lawful access with the appropriate owners; this engineering paper does not supply a legal retention schedule.

Operational security includes repair paths. An administrator who can replace a proposal after seal, rewrite a contribution actor or remove a blocking response can undermine the primary controls. Use constrained repair commands with attributable reason and preserved prior evidence. Protect log integrity and secrets without claiming that an append-only application table alone proves tamper resistance. Monitor unexplained assignment changes, duplicated effect identities and repeated attempts to reuse a superseded basis. Investigate those signals rather than automatically authorizing the blocked operation.

Use AI to prepare review without manufacturing agreement

An assistant can summarize the exact difference, locate supporting material and propose questions for engineering, quality or procurement. Bind its output to the same review basis and make material omissions visible. If the source revision changes, label the explanation stale until it is regenerated or checked against the selected package. A fluent summary that omits the supplier substitution should not be treated as an adequate review representation simply because the full document remains available somewhere else.

Separate informational output from contribution authority. The assistant does not become a fourth eligible person, count as an independent reviewer or answer a human approval request by impersonation. If the organization permits a deterministic automated check to satisfy a named gate, declare that gate separately from human consensus and retain its input and result. Do not hide it under an employee identity. A model recommendation can support a decision, but confidence is not a business approval rule.

Evaluate the preparation step with independently specified material changes, contradictory attachments and instructions embedded in retrieved text. Check whether the assistant identifies missing evidence and preserves tenant scope. Compare the assisted review with the complete manual path, including access checks and significant-term inspection. No model tests or time savings are claimed here. A useful pilot measures whether reviewers identify the right change, not merely whether they like the prose or click approve faster.

Keep the manual path available. A provider outage, slow model or unsupported file should not pressure an operator to bypass the approval contract. The application can present the verified package and structured difference without generated explanation. Bound model retries and charge cost to completed review cases, including human corrections and held cases. If AI increases ambiguity or review burden, remove it from that stage. The collective decision architecture should remain correct without the model, rather than relying on the model to enforce permissions.

Test independent counterexamples before operational acceptance

Define expected dispositions before exercising an implementation. The fixtures below use C70 and its explicit current-package, independent-person and post-seal rules. They are not observed production results. Use inert providers with inspectable contribution and destination ledgers, controlled interruption points and stable identities. A test observer must see actual committed intent and effect counts, not infer them from a completed workflow or an attractive approval screen.

| Changed condition | Expected disposition | Evidence to inspect | | --- | --- | --- | | R7 engineering and procurement responses combine with R8 quality | Hold both incomplete approval sets | Basis on every contribution and missing seats for each revision | | One actor responds for engineering and procurement under P3 | Hold the independence requirement | Actual actor identities, seat mapping and distinct-person evaluation | | A delegate submits a new response after the grant expires | Refuse the new contribution | Scoped delegation, response time and eligibility decision | | R8 edit commits before the R7 seal attempt | No current-package R7 release intent | Competing transition record and zero dispatchable old intents | | R7 seal commits before the later R8 draft | Preserve one pinned R7 intent; apply the declared post-seal policy | Selected package, single intent identity and dispatch disposition | | Destination accepts I70 but its receipt is lost | Preserve unknown and reconcile I70 without a new effect identity | Original-operation lookup, supported receipt or unresolved investigation |

Include an unsafe candidate that counts positive messages across revisions and another that treats department labels as independent people. The observer must detect both. Add duplicate callbacks, withdrawal, an undefined policy result, stale membership and a failed receipt lookup. Keep inconclusive fixtures in the reported denominator. Repairing the implementation after seeing a retained fixture needs a new candidate record and a rerun; it does not turn the earlier failure into a pass.

Use the revision-binding playbook for the package-level procedure and the concurrent-edit article for the local race. Extend those tests with this collective rule and delegation contract. A local fixture pass would not establish an unnamed approval provider's actor guarantees or a supplier system's deduplication behavior. Those integration boundaries need separate supported evidence and operating approval.

Set acceptance evidence, limitations and the next action

Use this acceptance checklist with the workflow owner: one action contract, a readable immutable basis, attributable participants, explicit independence and delegation rules, a protected seal, current execution permission and destination settlement evidence. Every open item should have an owner and an unresolved disposition. Completing the document does not make the workflow accepted. Review the mobile interface as well as the large-screen record; a narrow view must retain revision, role, actual actor, conditions and effect uncertainty.

Measure case completion, reviewer effort and held-case age separately. Invitations sent and responses received are not completed authorized changes. Retries are not new cases. Include cases abandoned because evidence was missing and effects still awaiting reconciliation. Choose reminder and escalation expectations with the operational owner. A safe process that leaves all held cases unowned is still unusable. Do not solve queue pressure by relaxing independence or letting the assistant supply the missing vote.

This recommendation has limits. It does not determine legal signatures, contractual acceptance, regulated independence requirements or a retention schedule. It does not prove any provider's native controls. A local transaction cannot make independent systems atomic. A digest cannot prove meaningful human understanding. Where the real process requires stronger evidence than the integration supports, reduce the allowed operation, retain a manual boundary or choose another provider. State the residual gap rather than claiming compliance from the diagram.

Start by selecting one existing multi-party change and tracing a single complete record from package to destination. Write the rule that the organization actually intends, then compare native controls against it. Bring the contract, competing-schedule evidence and unresolved effect example into the implementation review. Backend/API engineering and system architecture design are relevant when the owning transition or integration boundary needs work. Agree a bounded scope and acceptance evidence before introducing another workflow engine or adding AI to a decision it cannot legitimately make.