/governance-guardrail

name: governance-guardrail
description: Check proposed stack, data flows, cloud choices, and delivery controls against declared enterprise policies, compliance frameworks, and security controls. Trigger at R2/R3 risk classification, before locking architecture decisions, or when the operating profile names a governance pointer.

Governance Guardrail

> **A policy position the team cannot cite is a policy the team will unknowingly violate.**

This skill checks alignment between what the team is building and the enterprise policies, compliance frameworks, and security controls that govern it. It never invents a policy position — it surfaces gaps as explicitly owned unknowns.

When to use

• At R2/R3 risk classification, before architecture decisions are locked
• When the operating profile names a governance pointer (policy doc, compliance framework,

security baseline, approved-technology list)

• Before any decision that touches data classification, residency, procurement, or

approved-vendor constraints

• As a pre-condition for `adversarial-gate` on high-stakes or regulated work
• When `delivery-orchestrator` identifies a compliance, security, or data-handling concern

Operating model context

Governance alignment is not an audit that happens after delivery. It is a constraint that shapes architecture from day one. Discovering a compliance gap after a decision is locked is expensive; discovering it during bootstrap or spec is cheap.

This skill operates at the policy layer, above the cloud-expert skills:

• `gcp-expert` / `aws-expert` / `azure-expert` / `alibaba-expert` — vendor-specific

technical guardrails: IAM, data residency, cost. Use them to implement correctly within a chosen platform.

• `governance-guardrail` (this skill) — checks whether the chosen platform, stack, and

data model are permitted by enterprise policy in the first place.

Route cloud-specific implementation questions to the cloud-expert skills after this skill confirms the architecture is policy-compliant. Feed open findings into `adversarial-gate` before high-stakes decisions are locked.

Procedure

1. Locate the governance pointer

The project operating profile (`docs/operating-model/PROJECT-OPERATING-PROFILE.md`) should name one of:

• A policy document (URL, file path, or shared drive location)
• A compliance framework (SOC 2, ISO 27001, GDPR, HIPAA, etc.)
• An approved-technology or approved-vendor list
• A security baseline or architecture review board record

If no pointer exists, record it as an explicit unknown with an owner and resolving trigger. Do not proceed to stack or data-flow checks until the pointer is named — checking against an unknown policy is not a check.

2. Check stack alignment

For each component of the technical stack, confirm:

• Is it on the approved-technology or approved-vendor list?
• Does its data handling match the declared data classification?
• Are there procurement or licensing controls that apply?

Flag any component that has no confirmed policy position.

3. Check data flow alignment

For each data flow that crosses a boundary (service, team, region, or tenant):

• Does data residency match declared requirements?
• Are cross-boundary transfers permitted and logged?
• Is PII, regulated data, or classified data handled in a way the policy permits?

4. Check security controls

Confirm the following controls are in place or explicitly deferred with a named owner:

• Authentication and authorisation model is approved
• Secret management is aligned with the organisation's approved secret store
• Dependency and supply-chain scanning is wired into the CI pipeline
• Data-at-rest and data-in-transit encryption requirements are met

5. Register open findings

Every gap becomes an explicit unknown in the operating profile:

• What is unknown or unconfirmed
• Who owns the resolution
• What trigger resolves it (decision meeting, policy review, ADR sign-off)
• Whether it blocks R2/R3 work or is safely deferred

Pass open R2/R3-blocking findings to `adversarial-gate` before those decisions are locked.

Outputs

• Policy alignment summary: each stack component → confirmed / unconfirmed / flagged
• Data flow compliance map: each cross-boundary flow → permitted / flagged / unknown
• Security control status: each control → in place / deferred (owner, trigger) / missing
• Explicit unknowns register: each unknown → owner, required-before trigger

Guardrails

• **Never invent a policy position.** If the policy is not cited, the gap is the finding.
• **Pointer, not copy.** Do not reproduce policy documents inside this skill or the

operating profile. Record where they live and confirm they are accessible to the team.

• **Unconfirmed is not compliant.** A stack component with no confirmed policy position

is flagged, not assumed acceptable.

• **This skill does not grant approval.** It surfaces gaps. The named policy owner grants

approval.

• **Absence of a policy document is itself a gap.** Surface it; do not treat it as

permission.

Anti-rationalization table

| Excuse | Counter | |---|---| | "We'll check compliance before launch" | A compliance gap found after architecture is locked costs 10× to fix. Check at spec time. | | "We're using standard tools, they must be approved" | Standard in the industry ≠ approved in this enterprise. Confirm the pointer. | | "Security is the security team's job" | Security is the team's constraint. The security team approves; the team is responsible for alignment. | | "There's no policy document, so there's no policy" | Absence of a cited policy is the gap. Surface it with an owner and trigger. | | "We already did this for the last project" | Policy changes. Stack changes. Check against the current pointer for this project. |