GOVERNANCE-GATE-SPEC

Layer 2 Procedural File 1 of 6 — The Dash / NornGate at SBS Implements: 00-Take-Notice.md and 00-Single-Maintainer-Appendix.md (G2). Enforced by: Tyr (G1 scope) and Forseti (G2 routing).
Purpose
The procedural surface for human authorization capture. Every material action The Dash takes is queued, evidenced, decided, and linked into Urd’s ledger through this specification. If it is not in the matrix, it is not permitted — the matrix is the menu of all human-authorizable action types.
Authorization Classes
•           PAWF — Pre-Authorized Workflow. Recurring, reversible, fully documented action types approved once as a class (e.g., daily Sif reconciliation runs, Frigg’s standard cadence fires). PAWF status is reviewed quarterly; abuse or drift revokes the class.
•           SA — Single Approver. One named human approver (per the Delegation Map). Most operational actions.
•           DA — Dual Approver. Two named humans, or one human + documented second capacity per the Single-Maintainer-Appendix capacity-notation rule. Financial postings and external sends above threshold.
•           BR — Board-Required. Constitutional weight: policy changes, new data-flow pairs to regulated systems, LaMusica boundary questions (answer is no absent amendment), model-fleet governance changes.
Authorization Roles
Primary Approver (IT Director) · Department Authority (per Delegation Map) · Duty Approver (on-call designate) · Break-Glass Roster (per Appendix — reversible, time-critical actions only, retroactive review within one business day).
The SBS Action-Category Matrix
#
Category
Class
Notes
1
External customer send (Baldr)
SA
G3-validated draft; suppression check
2
External send with financial terms (quote/invoice)
DA
Sif-verified figures
3
Mass outbound campaign
DA
AI-disclosure slot verified
4
Batch invoicing / ETL execution (Thor)
SA
Idempotency proof attached
5
Financial posting to Oracle/SAP
DA
Four-record sequence required
6
Reconciliation-driven adjustment
DA
Sif flags; humans correct — never auto
7
Recurring schedule change (Frigg)
SA
Calendar-visible
8
Statutory-adjacent schedule item (FCC)
DA
Deadline itself immovable
9
Credential grant / scope expansion (Tyr)
SA
Just-in-time, TTL-bound
10
New data-flow pair (Njord)
DA
G1 permit per pair; §802 retention
11
Model deployment / rotation (Idunn)
SA
Same-gates evaluation evidence
12
Knowledge-domain access grant (Mimir)
SA
Domain-scoped per SKILL
13
Policy change (Tyr’s store)
BR
policy_change-class record
14
Sandbox egress permit (Vidar)
DA
Per-workload; no standing egress
15
DLQ reprocessing of policy-denied item (Hel)
DA
Only after policy itself changes
16
Break-glass action
Roster
Retroactive review mandatory
17
LaMusica boundary
BR + amendment
Default answer: denied
Queue Mechanics
•           Lifecycle states: draft → submitted → under_review → approved / conditionally_approved / rejected / escalated / withdrawn → authorized → executed → reconciled → closed. The executed → reconciled → closed loop is mandatory for categories 4–6 and 10: Sif verifies the committed action against downstream records before closure. No queue jumping (Forseti A.12).
•           Request schema: requesting agent; category; declared scope; evidence package; status-preamble reference (Take-Notice); urgency class; expiry.
•           Evidence packages: PAWF — class record reference; SA — action spec + agent SKILL citation; DA — plus independent verification (Sif or second agent); BR — plus risk assessment and alternatives considered.
•           Timeout & escalation: an expired or unavailable approval holds the action — held is a state, never executed (Baldr’s rule). Escalation path: Duty Approver → Break-Glass Roster → deferral.
•           Authorization handle: every approval mints a handle ID that propagates through G3/G4 into Urd’s ledger, binding decision to commit.
Recusal & Conflict
Where the approver’s own interests or capacities collide, the Single-Maintainer-Appendix substitutes apply: second approver, dual-agent attestation (reversible only), or deferral. Capacity notation is mandatory when the IT Director acts in more than one role.
Authoritative For
Approval-queue operation; auditor review of the control environment; evidence standards for any disputed authorization.
What’s Not Here
Incident classification (00-Incident-Response-Matrix); audit-trail mechanics (10-Audit-Trail-Spec); deployment sequencing (10-Deployment-Playbook).
Modification Protocol
Proposal drafted by the responsible agent → legal/sufficiency review where statutory interpretation is implicated → Odin staffs the synthesis pass → G2 request with full evidence package → human decision per the Single-Maintainer-Appendix authority structure. Approved modifications are versioned (1.0 → 1.1 minor; 1.x → 2.0 material) and captured in Urd’s ledger as policy_change-class records. Layer 1 files are not modified by this protocol — they require SBS Board / IT Governance authorization via Asgard Policy Review.
Document Control: SBS-DASH-PROC-01 · v1.1 · 2026-08-05 · SHA-256 (content above): a7f2…a512 · Sealed under Audit-Trail-Spec § 8.2. Modification authority: SBS Board / IT Governance via Asgard Policy Review (Governance-Gate); revalidation propagates per Tyr-SKILL § 3.4.