# Production Firewall-Rule Approval Workflow **Overall status: BLOCKED — design is structurally coherent, but provisioning must remain disabled until the policy owner resolves approval expiry and amendment/re-review semantics.** The documented control is clear: production firewall changes require **two distinct human reviewers—Network Operations + Security—neither may be the requester; either rejection blocks deployment; automated syntax validation precedes manual review.** The source explicitly leaves approval expiry, replacement timing, and amendment effects undefined. **Source ID S1 — Infrastructure Change Policy v4**, as supplied in `SOURCE_PACK`. --- ## 1. Recommended Design, Boundary, Material Assumptions Recommended execution architecture: ```text Ticket submitted │ ▼ Object/version frozen for review │ ▼ Automated Syntax Validation │ ├── FAIL → Manual review does not start │ ▼ PASS ┌──────────────────────────────────┐ │ Parallel Manual Review │ │ │ │ NetOps Reviewer Security Reviewer │ │ │ └───────┴──────────────────┘ │ ▼ UNANIMOUS GATE │ ┌─────┴─────┐ │ │ REJECTED APPROVED │ │ BLOCK Validity / version checks │ ▼ Deployment Worker ``` This is **design only**. It does not grant approval or establish compliance. The ticketing service should own the approval workflow state; the identity directory should provide group membership and requester/reviewer identity; the relational database should preserve immutable approval/version/event records; the deployment worker should consume only the final provisioning predicate rather than independently interpreting approval state. --- ## 2. Requirement / Source Register | ID | Requirement | Stage | Basis | Status | | --- | ------------------------------------------------------- | ----: | ----------------------- | --------------------------------------- | | R1 | Two distinct reviewers | 1 | S1 DOCUMENTED RULE | RESOLVED | | R2 | One Network Operations seat | 2 | S1 DOCUMENTED RULE | RESOLVED | | R3 | One Security seat | 2 | S1 DOCUMENTED RULE | RESOLVED | | R4 | Neither reviewer may be requester | 3 | S1 DOCUMENTED RULE | RESOLVED | | R5 | NetOps reviewer selected from approved NetOps group | 3 | S1 DOCUMENTED RULE | RESOLVED | | R6 | Security reviewer selected from approved Security group | 3 | S1 DOCUMENTED RULE | RESOLVED | | R7 | Syntax validation before manual review | 4/6 | S1 DOCUMENTED RULE | RESOLVED | | R8 | Either rejection blocks deployment | 7 | S1 DOCUMENTED RULE | RESOLVED | | R9 | Approval expiry rule | 5 | S1 UNKNOWN | OWNER-DECISION — BLOCKS_PROVISIONING | | R10 | Replacement reviewer timing | 3/8 | S1 UNKNOWN | OWNER-DECISION — BLOCKS_CONFIDENCE_ONLY | | R11 | Amendment effect on approvals | 10 | S1 UNKNOWN | OWNER-DECISION — BLOCKS_PROVISIONING | | R12 | Bind approvals to exact firewall-rule version | 5 | Engineering requirement | PROVISIONAL-STRUCTURAL | | R13 | Parallelize NetOps/Security review after validation | 6 | No dependency stated | PROVISIONAL-STRUCTURAL | | R14 | Reviewer substantive decision criteria | 2/4 | S1 UNKNOWN | OWNER-DECISION — BLOCKS_CONFIDENCE_ONLY | Relevant forces are principally **Risk of Decision, Responsibility for Decision, Risk of Correction, Availability of Approvers, Approval Process Cycle Time, and Possibility to Cure**. The first two are strongly evidenced by the mandatory independent reviewer roles; the others are analytical consequences of the workflow rather than new organizational rules. --- # 3. Twelve-Stage Decision Table | Stage | Input consumed | Decision | Output | Status | | --------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------ | | **0 Forces** | Brief + S1 | Risk/Responsibility/Risk of Correction materially apply; availability/cycle-time also relevant | FORCE PROFILE | RESOLVED / PROVISIONAL | | **1 Topology** | Force Profile | 4-Eyes: exactly two reviewer seats | NetOps + Security | RESOLVED | | **2 Seat Semantics** | Two seats | Different competencies: Network Operations and Security; substantive criteria unspecified | SEAT SPECIFICATIONS | competency RESOLVED; method OWNER-DECISION | | **3 Assignment** | Seat specs | Dynamic identity selection from respective approved groups; requester excluded | ASSIGNMENT SPEC | RESOLVED except replacement timing | | **4 Governance** | Seats + assignment | Syntax Pre-Check Rule; substantive approval judgment-governed | GOVERNANCE MAP | RESOLVED | | **5 Validity** | Seats + assignment + governance | Version-bound approval records required; expiry undefined | VALIDITY SPEC | expiry OWNER-DECISION | | **6 Execution** | Seats + pre-check | Syntax check sequentially precedes parallel human review | EXECUTION GRAPH | RESOLVED / PROVISIONAL | | **7 Aggregation** | Graph + seats | Both approvals required; either rejection blocks | UNANIMOUS | RESOLVED | | **8 Non-performance** | Assignment + forces | No timeout/replacement consequence authorized | NON-PERFORMANCE POLICY | OWNER-DECISION | | **9 Correction** | Aggregation + graph | Rejection blocks current deployment; correction/restart mechanics unspecified | CORRECTION POLICY | partial RESOLVED / OWNER-DECISION | | **10 Amendment** | Correction + competency + validity | Changed rules cannot safely inherit approvals absent policy | CHANGE IMPACT MAP | OWNER-DECISION | | **11 Provisioning** | 3/5/7/9/10 | Deployment worker requires conjunction of upstream gates | PROVISIONING predicate | BLOCKED | There is **no CHAIN HALT through Stage 10**. The missing policy fields are LOCAL BLOCKs rather than structural contradictions, consistent with the prompt's distinction between under-specification and logical impossibility. --- # 4. State-Transition Model | Current state | Event | Next state | Condition | | ----------------------------------- | ----------------------- | ------------------ | ---------------------------- | | DRAFT | submit | VALIDATING | request persisted/versioned | | VALIDATING | syntax_pass | REVIEW_PENDING | validation successful | | VALIDATING | syntax_fail | VALIDATION_FAILED | manual review not opened | | REVIEW_PENDING | NetOps approve | PARTIALLY_APPROVED | Security outstanding | | REVIEW_PENDING | Security approve | PARTIALLY_APPROVED | NetOps outstanding | | PARTIALLY_APPROVED | remaining approve | APPROVED | same object version | | REVIEW_PENDING / PARTIALLY_APPROVED | either reject | REJECTED | documented veto | | APPROVED | qualifying amendment | RE_REVIEW_REQUIRED | amendment policy unresolved | | APPROVED | execution gate false | DEPLOYMENT_BLOCKED | any required predicate false | | APPROVED | execution gate true | READY_TO_DEPLOY | all predicates satisfied | | READY_TO_DEPLOY | worker claims execution | DEPLOYING | atomic gate recheck | | DEPLOYING | completion | DEPLOYED | worker result recorded | No transition is defined for reviewer timeout because S1 supplies no timeout semantics. Likewise, `REJECTED → REVIEW_PENDING` is **not automatically authorized**. Whether corrected rules may restart the process and whether they remain within the same ticket is an OWNER-DECISION. --- # 5. Component, Data and Interface Contracts ### Ticketing service Canonical approval object: ```text change_request_id requester_identity firewall_rule_version rule_payload_reference workflow_state syntax_validation_result syntax_validation_timestamp netops_seat security_seat aggregate_outcome pending_rereview created_at ``` It initiates validation and review but must not independently authorize deployment. ### Identity directory For every reviewer selection: ```text reviewer_identity group_membership group_membership_checked_at seat_role requester_identity eligible = reviewer_identity != requester_identity ``` NetOps eligibility requires membership in the approved Network Operations group; Security eligibility requires membership in the approved Security group. Distinctness must also be enforced: ```text netops_reviewer_identity != security_reviewer_identity ``` A person belonging to both groups therefore cannot satisfy both seats on the same request. ### Approval record ```text approval_id change_request_id seat reviewer_identity decision approved_object_version approval_timestamp policy_version syntax_validation_snapshot evidence_snapshot ``` `approved_object_version` and evidence snapshots are PROVISIONAL-STRUCTURAL implementation controls derived from the requirement that approval must correspond to what was actually reviewed. `expiry_rule` remains OWNER-DECISION. ### Relational database Use append-oriented decision/event records rather than overwriting approval history. A duplicate approval event should be idempotent against an event/decision identity. A later duplicate must not create another satisfied seat. The current aggregate should be derived from valid seat decisions, not from event count. ### Deployment worker The worker must never infer authorization from: ```text ticket.status == "approved" ``` alone. It should consume or transactionally evaluate the explicit approval predicate immediately before protected execution. ## Provisioning predicate Following the required Stage 11 construction: ```text PROVISIONING_ALLOWED = aggregate_outcome == APPROVED AND object_version == approved_object_version for every contributing approval AND NOT approvals_expired AND required_seats_satisfied AND NOT provisioning_blocking_owner_decision_open AND NOT pending_full_rereview ``` For this system: ```text required_seats_satisfied = valid_netops_approval AND valid_security_approval AND netops_reviewer != requester AND security_reviewer != requester AND netops_reviewer != security_reviewer ``` Additionally, the documented syntax-validation requirement is upstream of review: ```text syntax_validation == PASS → manual review may open ``` It is not being invented as a seventh Stage-11 condition; Stage 6 makes successful validation a prerequisite for reaching the manual approval graph. ### Current evaluation ```text aggregate_outcome EVALUABLE object_version binding EVALUABLE structurally approvals_expired NOT EVALUABLE required_seats_satisfied EVALUABLE blocking_owner_decision_open TRUE pending_full_rereview NOT FULLY EVALUABLE ``` Therefore: **PROVISIONING_ALLOWED cannot become TRUE under the current specification.** --- # 6. Acceptance Cases | # | Case | Expected result | | ---: | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | AC01 | Syntax PASS → eligible NetOps approves → eligible Security approves same version | Aggregate APPROVED; provisioning still subject to validity gates | | AC02 | Syntax FAIL | Manual reviews do not start; deployment blocked | | AC03 | NetOps rejects | REJECTED; deployment blocked regardless of Security response | | AC04 | Security rejects | REJECTED; deployment blocked | | AC05 | Requester attempts NetOps approval | Event rejected as ineligible | | AC06 | Requester attempts Security approval | Event rejected as ineligible | | AC07 | Same dual-group person attempts both seats | Second seat cannot satisfy distinct-reviewer requirement | | AC08 | One reviewer never responds | No silent approval/rejection may be invented; remains unresolved pending owner-defined timeout behavior | | AC09 | Duplicate NetOps APPROVE arrives | Exactly one NetOps seat satisfaction | | AC10 | Late event arrives after replacement | Behavior unresolved until replacement semantics are defined | | AC11 | Both manual approvals arrive simultaneously | Atomic aggregation produces one APPROVED transition | | AC12 | Firewall object changes while both reviews pending | Existing reviews must not authorize the changed version; amendment handling remains policy-blocked | | AC13 | Policy version changes during review | Existing approval records retain policy version/evidence snapshot; treatment of active request requires explicit policy handling | | AC14 | Reviewer loses eligible-group membership before approval | Eligibility should be rechecked when recording decision; stale assignment must not silently establish authority | | AC15 | Approval expires between aggregation and deployment | Worker must re-evaluate expiry at execution; exact result awaits expiry policy | | AC16 | Approved port/range changed before deployment | Version mismatch prevents using old approvals; re-review scope awaits owner decision | | AC17 | Comment/description-only amendment after approval | Whether approval survives is UNKNOWN; do not silently classify NO RE-REVIEW | | AC18 | Security APPROVE and NetOps REJECT arrive concurrently | Aggregate REJECTED | | AC19 | NetOps approval for version 17 + Security approval for version 18 | Cannot aggregate into valid approval | | AC20 | Deployment worker receives stale APPROVED event after object amendment | Execution blocked by version/re-review gate | The amendment conservatism is intentional: the supplied methodology explicitly says ambiguous amendment classes must not default to `NO RE-REVIEW`. --- # 7. Owner Decisions and Design Self-Review ### BLOCKS_PROVISIONING **OD-01 — Approval expiry** **UNKNOWN:** Infrastructure Change Policy v4 supplies no expiry rule. **DECISION:** Define how long—or under what condition—NetOps and Security approvals remain valid. **STATUS:** OWNER-DECISION **GATE IMPACT:** BLOCKS_PROVISIONING **Raised:** Stage 5 Without this, `NOT approvals_expired` cannot be evaluated. --- **OD-02 — Firewall-rule amendment semantics** **UNKNOWN:** policy does not specify whether amendments invalidate previous approvals. At minimum, the owner must define the re-review treatment of security/material changes versus non-semantic metadata changes. Until then, a changed firewall-rule object must not inherit authority from approvals attached to an earlier version. **STATUS:** OWNER-DECISION **GATE IMPACT:** BLOCKS_PROVISIONING **Raised:** Stage 10 --- ### BLOCKS_CONFIDENCE_ONLY **OD-03 — Replacement reviewer timing** The approved groups exist, so replacement eligibility can preserve the same competency and requester exclusion. What is missing is **when replacement occurs and how races with the original reviewer are handled**. **STATUS:** OWNER-DECISION **GATE IMPACT:** BLOCKS_CONFIDENCE_ONLY **Raised:** Stages 3/8 This does not justify weakening the two-reviewer gate. --- **OD-04 — Reviewer decision criteria** Policy names the competencies but does not supply NetOps or Security checklists/decision criteria. Do not invent them. **STATUS:** OWNER-DECISION **GATE IMPACT:** BLOCKS_CONFIDENCE_ONLY **Raised:** Stages 2/4 The seats therefore remain **JUDGMENT-GOVERNED** rather than falsely classified as rule-governed. --- **OD-05 — Rejection/correction mechanics** A rejection clearly blocks deployment, but S1 does not state whether a corrected firewall rule: * restarts both seats, * repeats only an affected review, * creates a new request, or * remains within the original ticket. **STATUS:** OWNER-DECISION **GATE IMPACT:** BLOCKS_CONFIDENCE_ONLY until a corrected/amended object actually seeks deployment; then amendment/version rules become provisioning-relevant. --- ## Chain Halts **None detected through Stage 10.** Stage 11 itself correctly reports the gate as **BLOCKED**, rather than fabricating missing authorization semantics. --- ## Design Self-Review **PASS — CI-01 Chain integrity:** Stages consume the required upstream outputs; no downstream stage silently substitutes missing policy. **PASS — DS-01 Dependency-status integrity:** expiry, amendment semantics, replacement timing, and review criteria remain explicitly unresolved rather than being upgraded to RESOLVED. **PASS — CV-01 Coverage:** reviewer topology, competency, eligibility, validation, validity, aggregation, timeout, correction, amendment and deployment gate are represented. **PASS — OR-01 Ordering:** automated syntax validation precedes manual review as required by S1. **PASS — DM-01 Decision semantics:** both documented approvals are required; either rejection blocks execution. **PASS — RI-01 Reviewer independence:** requester exclusion and distinct reviewer identities are explicit. **PASS — VB-01 Version binding:** approval records bind reviewer decisions to the exact firewall-rule version reviewed. **BLOCKED — EP-01 Exception paths:** expiry, replacement timing and amendment/re-review behavior are not fully specified by policy. **BLOCKED — PG-01 Provisioning gate:** `expiry_rule` and amendment validity are unresolved BLOCKS_PROVISIONING owner decisions. ### Final result **BLOCKED — the architecture is internally usable as a provisional specification, but the deployment worker must remain unable to execute until OD-01 approval expiry and OD-02 amendment/re-review semantics are resolved.** This is a **design consistency result only**—not runtime verification, compliance certification, or evidence that the workflow reduces operational risk.