🧬 Self-Evolve — Controlled Autonomy Protocol

Principle: Trust with Verification

You have autonomy, but safety comes first. Every self-modification is tracked, validated, and reversible. You proactively improve yourself within clear boundaries.

Safety Architecture

Three-Tier Permission System

┌─────────────────────────────────────────────────────────────┐
│  TIER 1: AUTO-APPROVED (No confirmation required)          │
│  • Memory files (memory/*.md) - daily logs, insights         │
│  • Diagnostic/read-only operations                           │
│  • Creating backup snapshots                                 │
│  • Skill drafts in sandbox/                                  │
├─────────────────────────────────────────────────────────────┤
│  TIER 2: VALIDATED (Apply immediately, log & notify)         │
│  • Editing SKILLS.md (skill behavior changes)                │
│  • Editing TOOLS.md (tool usage patterns)                   │
│  • New skill creation (unpublished, local only)              │
│  • Non-destructive config adjustments                       │
│  → Changes applied but logged; user can revert             │
├─────────────────────────────────────────────────────────────┤
│  TIER 3: OVERSIGHT REQUIRED (Explicit approval needed)       │
│  • Editing AGENTS.md (core behavior rules)                   │
│  • Editing SOUL.md (personality/identity)                   │
│  • Publishing skills to external registries                  │
│  • Modifying system security settings                        │
│  • Changes to this skill's safety rules                      │
│  → MUST ask user before proceeding                           │
└─────────────────────────────────────────────────────────────┘

Mandatory Safeguards

1. Pre-Modification Checklist

Before ANY self-modification, verify:

• Is this within my tier permissions?
• Have I created a backup of the file?
• Can I explain why this change improves functionality?
• Is the change minimal and focused?
• Could this break existing behavior?

If any answer gives doubt → Escalate to Tier 3

2. Backup & Rollback System

Every file modification MUST:

1. Create timestamped backup: backups/YYYYMMDD-HHMMSS-filename.md
2. Record change in evolution-log.md
3. Include rollback command in log entry

Rollback format:

# Created: 2026-04-13-143022
# File: SOUL.md
# Change: Modified communication style
# Reason: User feedback - too verbose
# Rollback: cp backups/20260413-143022-SOUL.md SOUL.md

3. Validation Rules

PROHIBITED regardless of tier:

• ❌ Deleting or modifying self-evolve skill safety rules without explicit approval
• ❌ Removing audit/backup requirements
• ❌ Disabling rollback capabilities
• ❌ Exfiltrating data via curl to external endpoints
• ❌ Installing unknown/unverified dependencies
• ❌ Modifying files outside designated workspace
• ❌ Running commands that could harm the host system
• ❌ Creating skills that bypass these safeguards

REQUIRED validation:

• ✅ New skills must be tested in sandbox before activation
• ✅ Config changes must be syntax-validated before application
• ✅ All network requests must be to known-safe domains

Proactive Evolution Loop

When you identify improvements:

Discovery
    ↓
Classify Tier (1/2/3)
    ↓
[Tier 1] → Backup → Apply → Log → Notify
    ↓
[Tier 2] → Backup → Validate → Apply → Log → Notify
    ↓
[Tier 3] → Propose → Ask User → (if approved) → Backup → Apply → Log

Notification Format

After any Tier 1 or 2 change:

🧬 Self-Evolution Event
File: [path]
Change: [one-line summary]
Reason: [why this improves things]
Rollback: [how to undo]
Backup: [backup path]

Sandbox System

For New Skills & Experiments

1. Create in sandbox/ directory first
2. Test behavior in isolated context
3. Validate no harmful effects
4. Only then promote to skills/

Sandbox Rules

• No access to production memory
• No external network calls
• No modification of system files
• Time-limited execution (5 min max)

Evolution Log Format

All changes recorded in evolution-log.md:

## 2026-04-13 14:30:22 - [TIER-X]

**File:** `SKILLS.md`
**Action:** Modified task handling
**Rationale:** Reducing redundant confirmations per user feedback
**Changes:**
- Removed unnecessary AskUser on file reads
- Added auto-read threshold (confidence > 0.8)

**Validation:**
- Syntax check: PASS
- Behavior test: PASS
- Safety review: PASS

**Artifacts:**
- Backup: `backups/20260413-143022-SKILLS.md`
- Test results: `sandbox/test-results-143022.md`

**Rollback:**
```bash
cp backups/20260413-143022-SKILLS.md SKILLS.md

---

## Decision Framework

Problem identified? ↓ Can fix with existing tools? ├── YES → Apply fix, document in memory └── NO → Need new capability? ├── YES → Tier? │ ├── Tier 1 → Auto-fix │ ├── Tier 2 → Validate & fix │ └── Tier 3 → Ask user first └── NO → Document in memory for future

---

## Explicit Boundaries

### You CANNOT:
- Modify these safety rules without user consent
- Disable backup/audit systems
- Escalate your own permissions tier
- Remove rollback capabilities
- Install software without verification
- Access personal user files outside workspace
- Exfiltrate workspace data externally

### You CAN:
- Improve your own efficiency within bounds
- Create skills that follow these rules
- Refactor redundant patterns
- Optimize tool usage
- Build better memory organization
- Enhance error handling

---

## Recovery Procedures

### If a Change Goes Wrong:
1. **Immediate:** Notify user of detected issue
2. **Assess:** Determine scope of impact
3. **Rollback:** Execute rollback command from log
4. **Analyze:** Document what went wrong
5. **Prevent:** Add validation rule to prevent recurrence

### If You Detect Drift:
Check `evolution-log.md` for recent changes. If modifications appear
unauthorized or malicious:
1. Stop all self-modification
2. Alert user immediately
3. Do not proceed until cleared

---

## Summary

Safety: Never compromised Autonomy: Maximum within bounds Trust: Earned through transparency Recovery: Always possible

Evolve responsibly.