## 1. Recommended design and boundary **Use two parallel review tasks—Service Owner and SRE—bound to one immutable build digest and one review round. Permit deployment only through a gate that revalidates both approvals immediately before deployment starts.** **DOCUMENTED RULE:** Release Policy v3 is supplied as active policy. It requires different approvers, excludes the requester, and requires matching build digests. **PROPOSAL:** Use the relational database as the authoritative workflow ledger. GitHub Actions supplies CI evidence and requests deployment; the ticketing service presents review tasks; the identity directory supplies stable person identities and role eligibility. Webhooks notify the workflow service; they do not themselves authorize deployment. The subsystem starts when a release request identifies its requester, application, production target and immutable build digest. It ends when deployment success or failure is recorded, or execution remains blocked awaiting review or resolution. Keep these identities separate: * `process_instance_id`: unchanged when a build changes. * `review_round`: increments whenever the build changes. * `assignment_id`: identifies one reviewer’s current task. * `deployment_attempt_id`: identifies one execution attempt. **UNKNOWN:** Deployment infrastructure, rejection recovery, approval revocation, authoritative required-check configuration and whether approval validity must extend through deployment completion are unspecified. **PROPOSAL:** Until clarified, enforce validity at deployment start, prevent overlapping attempts for the same production target, and block execution whenever authoritative eligibility or CI evidence cannot be established. ## 2. Requirement and source register Source IDs: * **S1:** Release Policy v3, supplied as active; sections 2–5. * **S2:** SYSTEM_BRIEF, supplied system constraints. * **C1:** Attached prompt’s paraphrased research catalog. Pattern references below refer to that supplied catalog; the original papers were not independently inspected for this response. | ID | Requirement and classification | Source | Acceptance check | | --- | ------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------------------------------------------------ | | R01 | **DOCUMENTED RULE:** One Service Owner and one SRE approve; distinct people; neither requester | S1 §2 | Two eligible, distinct person IDs | | R02 | **DOCUMENTED RULE:** Both approvals reference the same immutable build digest | S1 §2 | Exact digest and current-round match | | R03 | **DOCUMENTED RULE:** Failed required CI blocks review | S1 §3 | No decision accepted while a required check has failed | | R04 | **DOCUMENTED RULE:** Every build change restarts all reviews within the same instance | S1 §3 | Same instance; new round; prior reviews superseded | | R05 | **DOCUMENTED RULE:** Replace a pending reviewer after four hours with an eligible same-role person; otherwise wait and escalate | S1 §4 | Old assignment invalidated; no automatic approval | | R06 | **DOCUMENTED RULE:** Each approval expires 12 hours after recording; deployment requires both valid | S1 §5 | Individual expiry checks at execution | | R07 | **REPORTED PRACTICE / DESIGN INPUT:** Specified stack; duplicated or delayed webhooks possible | S2 | Durable deduplication and stale-event handling | | R08 | **PROPOSAL:** Independent parallel review with an exclusive execution gate | S2 objective | Either review order works; bypass attempts fail | No supplied policy conflict was identified. Missing rules are treated as unknowns, not permission to weaken documented requirements. **PROPOSAL:** Require every required CI check to be conclusively successful before opening review. This is stricter than the explicit prohibition on failed checks; handling pending, missing, cancelled or indeterminate checks requires owner confirmation. ## 3. Pattern choices and alternative | Category | Selected mechanism / catalog reference | Basis and benefit | Cost or unresolved issue | | ----------------- | ------------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------- | | Reviewer count | 4-Eyes Principle, C1/P1 §5.1 | R01: two human approvers | Availability depends on both roles | | Expertise | Different Competencies, C1/P1 §5.2 | Service Owner plus SRE | Substantive review criteria are unspecified | | Automation | Pre-Check Rule; Approval Steps Configuration Rule, C1/P1 §5.3 | R03; automatically establish two role tasks | CI and directory evidence must be trustworthy | | Ordering | Parallel Approval, C1/P1 §5.4 | R08: independent reviews proceed together | Work can be wasted if one reviewer rejects | | Correction | Correct & Restart Process, C1/P1 §5.5 | R04: new build restarts both reviews in the same instance | Even a small build change invalidates both | | Aggregation | Both mandatory approvals; proposed rejection veto, C1/P2 §5.1 | R01/R06 require both valid approvals | Rejection finality is not specified | | Missing responses | Replacement Approver, C1/P2 §5.3 | R05: four-hour replacement with same-role eligibility | No substitute means blocked waiting | The composition keeps automated checks separate from human approval. Group membership determines eligible alternatives; it does not count as approval. **PROPOSAL:** Service Owner review covers release intent and service impact; SRE review covers operational readiness and recovery. These are suggested responsibilities, not supplied acceptance criteria. **PROPOSAL:** A rejection blocks the current round and closes its remaining pending tasks. It does not silently terminate the entire process instance. A changed build starts a new round; same-build reconsideration requires an explicit policy. **Alternative:** Sequential Service Owner then SRE review preserves both signatures and digest binding, and may reduce wasted SRE work after owner rejection. It introduces a dependency between otherwise independent reviews and is less aligned with the requested parallel workflow. No measured latency improvement is claimed. Appeal, reviewer edits, abstention, silence-as-approval and majority voting are not enabled. ## 4. Decision predicate and transitions For current instance `I`, round `r`, digest `d`, and authoritative database time `t`: ```text ReviewEligible = required CI evidence is current and successful ApprovalsValid = one Service Owner approval and one SRE approval AND different stable person IDs AND neither person is the requester AND both assignments and approvals are current AND both approvals reference (I, r, d, production target) AND each approval is unexpired: t < expires_at AND eligibility satisfies the configured authority rule MayStartDeployment = ReviewEligible AND ApprovalsValid AND no blocking rejection or withdrawal AND requested artifact digest = d AND no incompatible active deployment attempt ``` The CI-success rule, execution-time eligibility recheck, rejection block and target serialization are **PROPOSALS**. Two distinct approvals, requester exclusion, digest matching and expiry are **DOCUMENTED RULES**. There is no separate quorum: both mandatory roles must approve. Pending or neutral responses never count. Readiness is revocable and is never sufficient as a cached execution authorization. All transitions below write audit records transactionally. | ID | Current state → event | Guard / authorized actor | Next state and effect | | --- | ------------------------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | T01 | None → submit | Authenticated requester; digest and target supplied | `CI_BLOCKED`; create instance and first round | | T02 | `CI_BLOCKED` → CI reconciled | Workflow service establishes required checks successful for current digest | `IN_REVIEW`; create parallel assignments, or `WAITING_REVIEWER` if a role cannot be filled | | T03 | `IN_REVIEW` → approve | Assigned eligible person; current round/task; CI clear; before deadline | Record approval and its 12-hour expiry; `READY` only if both qualify | | T04 | Reviewing/ready → reject | Current authorized reviewer | **PROPOSAL:** `REJECTED_ROUND`; close pending tasks; block execution | | T05 | Any pre-start state → build changed | Authorized release change; instance locked | Same instance, new round; supersede all reviews; `CI_BLOCKED` | | T06 | Pending task → four-hour deadline | Scheduler; task still pending | Supersede assignment; replace in same role or enter `WAITING_REVIEWER` and escalate | | T07 | Waiting → eligible replacement found | Scheduler/directory reconciliation | New assignment; resume review | | T08 | Reviewing/ready → approval expired | Timer or synchronous validity check | `APPROVAL_EXPIRED`; block start and request fresh review for expired role | | T09 | Reviewing/ready → required CI fails | Authoritative CI reconciliation | `CI_BLOCKED`; suspend review and execution | | T10 | `READY` → start requested | Execution service evaluates full predicate at actual start boundary | `DEPLOYING`; consume one attempt authorization | | T11 | `DEPLOYING` → result | Authenticated executor; matching attempt ID | `DEPLOYED`, `DEPLOY_FAILED`, or `EXECUTION_UNKNOWN` | | T12 | `EXECUTION_UNKNOWN` → reconciled | Executor evidence identifies actual outcome | Resolve outcome; no blind retry | | T13 | Any state → duplicate/stale event | Ingestion service identifies replay or superseded identity | No business-state change; retain disposition | | T14 | Pre-start → withdraw | **PROPOSAL:** authenticated requester | `WITHDRAWN`; close tasks and block execution | **PROPOSAL:** A restored CI result can reopen review without copying approvals to another build. Whether existing same-build approvals survive a CI failure remains an owner decision; provisionally invalidate them. A build change received after execution starts cannot retroactively change the running artifact. Record it as a subsequent round in the same instance and serialize further execution. It must not mutate the active attempt’s digest. ## 5. Components, data and interface contracts ### Authoritative records | Record | Essential fields | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Release instance | `request_id`, `process_instance_id`, requester person ID, application/object ID, production target, `policy_version`, current round, digest, state, revision | | Review round | Instance ID, round number, digest, creation time, CI evidence references, required-check configuration revision, supersession link | | Assignment | Assignment ID, round, role, reviewer person ID, eligibility evidence, creation time, deadline, status, supersedes ID | | Decision | Decision ID, assignment ID, instance/round/digest/target, role, person ID, outcome, origin, reason, server-recorded time, expiry, invalidation reason | | Deployment attempt | Attempt ID, bound round/digest/target, approval IDs, gate time, start/result evidence, execution state | | Inbox/outbox/audit | Source event ID, payload hash, event/receipt times, aggregate revision, causal IDs, effect status and disposition | **PROPOSAL:** Resolve directory accounts to stable person identities. Two accounts belonging to one person cannot satisfy independence. A dual-role person can fill either slot, but cannot fill both. Eligibility is checked at assignment, decision recording and deployment start. Directory unavailability blocks decisions requiring a fresh eligibility check. Permitted caching and authority-revocation semantics need explicit configuration. ### Interfaces * **Intake:** Creates an instance for an immutable digest and production target. Repeated client idempotency keys return the original result; changed payloads under the same key are rejected. * **CI adapter:** Reconciles authoritative checks for the digest and required-check configuration. Branch names and mutable tags are insufficient evidence. * **Ticket adapter:** Mirrors tasks containing instance, round, digest, role and assignment identity. Comments or ticket status changes are not approvals without authenticated actor and assignment validation. * **Decision endpoint:** Accepts outcome, reason, assignment ID, digest and expected revision. The service—not a webhook timestamp—records approval time. * **Gate/executor:** Accepts an attempt ID and exact digest; independently loads current workflow records before starting the protected action. * **Audit service:** Records previous/next state, actor, evidence, policy version, guard result and supersession relationships. ### Duplicates, ordering and timers **PROPOSAL:** Insert each incoming event into a durable inbox using a unique `(source, event_id)` key. Detect conflicting payloads under reused IDs. Also enforce semantic uniqueness so duplicates with different event IDs cannot create extra approvals or deployments. Serialize mutations using a row lock or compare-and-swap revision. Round, assignment and check-attempt identities determine relevance; arrival order does not. A decision is valid only if recorded while the assignment remains current and `database_time < deadline`. At the deadline, replacement wins. Late votes from superseded assignments are rejected regardless of claimed client time. Each replacement receives a proposed new four-hour assignment window. Approved tasks are not replaced for nonresponse. If no substitute exists, remain blocked and escalate through a transactional outbox; retry availability checks without treating silence as a vote. ### Deployment enforcement and recovery A database transaction cannot by itself make an external deployment atomic. **PROPOSAL:** The deployment executor must own the final gate at the point where it starts the protected action. Under serialized workflow state, it validates current evidence and consumes a single-use attempt authorization bound to the digest and target. A queued GitHub Actions job must revalidate when it actually executes. Production credentials must be restricted to the gated execution path. The feasibility of that restriction is **UNKNOWN** until repository and deployment permissions are inspected. If the executor cannot prevent a gap between authorization and action in which expiry or a build change bypasses the gate, this design is **BLOCKED for implementation approval**. An earlier “ready” flag or short-lived token alone does not solve that race. After an uncertain result, reconcile using the attempt ID and deployed artifact evidence. Do not rerun automatically: the first action may already have succeeded. ## 6. Requirement-linked acceptance cases **Prepared, not run.** | Case | Given / When | Expected result | | ----------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | A01 — R01/R02/R08 | CI is clear; eligible owner and SRE approve the same digest in either order | `READY`; one gated deployment may start | | A02 — R01 | Requester approves, or one person uses two accounts for both roles | Invalid decision rejected; no deployment | | A03 — R02/R04 | One approval exists; build changes | Same instance, incremented round; both tasks restarted; old approval unusable | | A04 — R03 | Required check failed; reviewer submits approval | Decision rejected; `CI_BLOCKED`; no execution | | A05 — R05 | Pending task reaches four hours; substitute exists | Old task superseded; same-role replacement assigned; late old vote rejected | | A06 — R05 | Deadline arrives; no eligible substitute exists | `WAITING_REVIEWER`; escalation queued; no inferred approval | | A07 — R06 | Owner approval expires before SRE approval arrives | Not ready; fresh owner approval required | | A08 — R06/R08 | Job queued while ready; approval expires before actual start | Start denied; no deployment side effect | | A09 — R07 | Approval or start webhook arrives twice, including different delivery IDs | One decision or attempt; no duplicated effect | | A10 — R02/R07 | Old-round approval or obsolete CI result arrives late | Event recorded as stale; current state unchanged | | A11 — R01/R08 | One reviewer rejects while the other is pending | Proposed `REJECTED_ROUND`; pending task closed; deployment forbidden | | A12 — R04/R08 | Build change races deployment start | Serialization determines winner; change-first blocks old build; start-first fixes active attempt digest | | A13 — R05/R07 | Vote races replacement at exact deadline | Deterministic deadline rule; superseded reviewer cannot approve | | A14 — R08 | Executor times out after possibly starting deployment | `EXECUTION_UNKNOWN`; reconcile before retry | ## 7. Design self-review and owner decisions | Result | Status | Evidence | | --------------------------- | ----------- | ------------------------------------------------------------------------- | | D01 — Traceability | **PASS** | R01–R08 distinguish supplied requirements from proposals | | D02 — Coverage | **PASS** | Supplied sections map to transitions, records and acceptance cases | | D03 — Ordering | **PASS** | CI precedes review; parallel approvals precede execution gate | | D04 — Decision semantics | **BLOCKED** | Rejection recovery and expiry-through-completion semantics need authority | | D05 — Reviewer independence | **PASS** | Stable person identity and requester exclusion are explicit | | D06 — Version binding | **PASS** | Assignments, approvals and attempts bind to round and immutable digest | | D07 — Exception paths | **BLOCKED** | Actual executor atomicity and credential restrictions are unverified | | D08 — Runtime verification | **BLOCKED** | No implementation inspected and no acceptance cases executed | These PASS results concern specification consistency only. All supplied policy sections were processed. Rollback authorization, emergency override and post-start cancellation are unspecified and are not granted by this design. **DECISION 1 — Execution validity boundary.** **RECOMMENDED:** Both approvals must be valid at the actual deployment start; expiry afterward does not automatically interrupt an active deployment. **IMPACT:** Determines executor behavior for long-running deployments. **DECISION 2 — Rejection, CI uncertainty and recovery.** **RECOMMENDED:** Rejection blocks the round; require all required CI checks successful; invalidate approvals after required-CI failure; prohibit same-build rejection reversal until explicitly defined. **IMPACT:** Provides conservative, implementable behavior where the supplied policy is silent. **DECISION 3 — Authority and reassignment timing.** **RECOMMENDED:** Recheck role eligibility at execution, give each replacement four hours, and re-review only expired roles while retaining other still-valid approvals. **IMPACT:** Makes identity changes, repeated replacement and staggered expiry deterministic.