AI Skill Report Card

Evolving Policies

A-86·Sep 27, 2026·Source: Web

Policy Evolution Agent

14 / 15

Given a policy under review (e.g., "Remote Work Policy v2" or "Voting Quorum Rule"), produce three outputs:

  1. Policy Changes — redlined, specific amendments
  2. Impact Analysis — who/what is affected, risks, tradeoffs
  3. Governance Plan — how the change gets approved, rolled out, and monitored
INPUT: Current policy text + trigger (complaint, conflict, new context, outdated rule)
OUTPUT:
  Policy Changes: [old clause] → [new clause], with rationale
  Impact Analysis: stakeholders affected, severity, second-order effects
  Governance Plan: approval path, timeline, rollback plan
Recommendation▾
Add a third example showing a low-severity/simple case to contrast with the two complex ones already given
15 / 15

Progress:

  • Step 1: Identify trigger — why is this policy being revisited?
  • Step 2: Diagnose the gap — what's broken, ambiguous, or outdated?
  • Step 3: Draft policy changes — precise, versioned, traceable
  • Step 4: Run impact analysis — stakeholders, edge cases, conflicts with other policies/constitution
  • Step 5: Build governance plan — approval process, communication, phased rollout, sunset/rollback clause
  • Step 6: Flag constitutional conflicts — if the change touches foundational rules, require higher-bar review

Step 1: Identify the trigger. Classify as one of: ambiguity exploited, real-world conflict, outdated assumption, stakeholder feedback, external regulation change, or system/scale change. This determines urgency and review depth.

Step 2: Diagnose the gap. State precisely what fails today. Avoid vague diagnoses like "policy is unclear" — pinpoint the clause, the scenario that breaks it, and who exploited or suffered from the gap.

Step 3: Draft changes. Write as a diff: strikethrough/old vs. new. Keep changes minimal and targeted — don't rewrite the whole policy when one clause is broken. Version the policy (v1 → v2) and log the change date and trigger.

Step 4: Impact analysis. Cover:

  • Direct stakeholders (who must now behave differently)
  • Indirect stakeholders (who is affected downstream)
  • Conflicts with existing policies or the constitution
  • Edge cases the new wording might create
  • Severity/urgency rating (low/medium/high/critical)

Step 5: Governance plan. Specify:

  • Who approves this (self-serve, committee, constitutional vote)
  • Communication plan (who is notified, how, when)
  • Rollout phasing (immediate, grace period, pilot group)
  • Monitoring plan (what signals indicate the fix worked or failed)
  • Rollback trigger and process

Step 6: Constitutional check. If the policy change alters foundational rights, power distribution, or amendment procedures themselves, escalate: require supermajority/higher quorum, longer comment period, and explicit precedent citation.

Recommendation▾
Include a brief template/checklist for the constitutional escalation criteria (what specifically counts as 'foundational')
19 / 20

Example 1: Input: "Members are exploiting the 'unlimited PTO' policy by taking PTO during active project deadlines without notice, causing delivery failures."

Output:

Policy Changes:
- OLD: "Employees may take PTO at their discretion."
- NEW: "Employees may take PTO at their discretion, with a minimum 5-business-day notice for absences during active project deadlines (defined in Section 3.2). Emergency exceptions (illness, family emergency) are exempt from notice requirements."

Impact Analysis:
- Direct: all employees currently using PTO informally — now must plan ahead for non-emergency leave
- Indirect: project managers gain predictability; HR must track "active deadline" windows
- Conflict check: does not conflict with existing leave law (notice requirement is reasonable, exemption preserves emergency access)
- Edge case: "active project deadline" needs a clear, published definition or this becomes a new ambiguity
- Severity: Medium — affects delivery reliability but not a legal/safety issue

Governance Plan:
- Approval: HR policy committee sign-off, no constitutional vote needed (operational policy)
- Communication: all-hands email + FAQ; 2-week advance notice before enforcement
- Rollout: 30-day grace period where notice is "encouraged not required"; full enforcement after
- Monitoring: track late-notice PTO requests during deadlines pre/post change for 1 quarter
- Rollback: if grievances exceed 3 in first quarter, revert to discretionary model and revisit definition of "active deadline"

Example 2: Input: "Our co-op's bylaws require unanimous board consent for any budget over $500, but the board has grown to 40 people, making unanimous consent unworkable."

Output:

Policy Changes:
- OLD: "All budgetary decisions exceeding $500 require unanimous board approval."
- NEW: "Budgetary decisions exceeding $500 and under $5,000 require 75% board approval. Decisions exceeding $5,000 require unanimous approval or a full membership vote."

Impact Analysis:
- Direct: board members lose individual veto power on smaller decisions
- Indirect: faster operations, but risk of minority concerns being overridden
- Conflict check: THIS TOUCHES THE CONSTITUTION — unanimous consent is likely a foundational governance protection, not a mere operational rule
- Edge case: 75% of 40 is 30 — still a high bar, but need tie-breaking/quorum rules defined
- Severity: Critical — this is a constitutional-tier change, not routine policy

Governance Plan:
- Approval: REQUIRES constitutional amendment process — full membership vote, not board-only
- Communication: formal notice to all members 30+ days before vote, with rationale document
- Rollout: only takes effect after amendment passes per existing constitutional threshold (e.g., 2/3 supermajority)
- Monitoring: review after 2 fiscal quarters — track dissent rate and decision speed
- Rollback: sunset clause — automatic review in 12 months, revert if member complaints exceed threshold
- ESCALATION FLAG: do not treat as ordinary policy change; cite constitutional amendment precedent
Recommendation▾
Consider trimming Step 1-6 prose slightly since the checklist already covers the same ground, to tighten conciseness further
  • Always separate operational policy changes from constitutional/foundational changes — they need different approval bars.
  • Make every policy change a minimal diff, not a rewrite. Easier to review, easier to roll back.
  • Every governance plan needs an explicit rollback trigger, not just a rollout plan.
  • Quantify severity/impact instead of using vague language ("this matters a lot") — use low/medium/high/critical.
  • Always check for second-order effects: a fix for one exploit often creates a new ambiguity elsewhere.
  • Log every change with trigger, date, and version — policies should have an auditable history.
  • Treating a constitutional change like routine policy tweak — skipping the higher approval bar.
  • Rewriting entire policies when only one clause is broken — introduces new risk and review burden.
  • Vague impact analysis ("this could affect some people") instead of naming actual stakeholder groups.
  • No rollback plan — governance changes without an exit path become permanent by default.
  • Ignoring the original trigger — patching symptoms without addressing why the exploit/gap occurred.
  • Failing to define new terms introduced by the fix (e.g., "active project deadline") — creates the next ambiguity.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
15/15
Examples
19/20
Completeness
18/20
Format
14/15
Conciseness
13/15