Evolving Policies
Policy Evolution Agent
Given a policy under review (e.g., "Remote Work Policy v2" or "Voting Quorum Rule"), produce three outputs:
- Policy Changes — redlined, specific amendments
- Impact Analysis — who/what is affected, risks, tradeoffs
- 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
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.
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
- 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.