# SophiaClaw Governance Requirements

**Version:** 2.0.0  
**Classification:** Public (Open Source)  
**Last Updated:** 2026-03-11

---

## 1. Executive Summary

The SophiaClaw Governance Framework (SOPHIA) provides a comprehensive system for controlling, auditing, and ensuring transparency in AI agent operations. This document defines the requirements for the governance layer that sits between user intent and AI execution, ensuring every action is understood, validated, and recorded.

### 1.1 Governance Philosophy

SophiaClaw governance is built on five pillars:

1. **Intent Capture**: Understand what the user wants before acting
2. **Policy Enforcement**: Apply rules automatically to all actions
3. **Approval Gates**: Require human approval for high-risk operations
4. **Immutable Audit Trail**: Record everything, permanently
5. **Conflict Detection**: Prevent interfering operations

### 1.2 Governance Architecture

```
┌─────────────────────────────────────────────────────────────────┐
│                    SOPHIA GOVERNANCE LAYER                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  User Request → Intent Service → Policy Engine → Gate Engine   │
│       │              │              │              │            │
│       │              │              │              │            │
│       ▼              ▼              ▼              ▼            │
│  ┌────────┐    ┌──────────┐   ┌──────────┐  ┌──────────┐      │
│  │ Channel│    │ Structure│   │ Evaluate │  │ Approve  │      │
│  │ Adapter│    │ Intent   │   │ Rules    │  │ or Block │      │
│  └────────┘    └──────────┘   └──────────┘  └──────────┘      │
│       │              │              │              │            │
│       │              ▼              ▼              ▼            │
│       │         ┌───────────────────────────────────┐          │
│       │         │     Bulletin Service (Audit)      │          │
│       │         └───────────────────────────────────┘          │
│       │                        │                                │
│       ▼                        ▼                                │
│  Execute Action ←──────── Claims Service (Conflicts)           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

---

## 2. Intent Capture Requirements

### 2.1 Intent Structure

| ID      | Requirement                                                                            | Priority | Implementation         |
| ------- | -------------------------------------------------------------------------------------- | -------- | ---------------------- |
| GOV-101 | The system SHALL capture raw user input as the source of truth                         | P0       | Store original message |
| GOV-102 | The system SHALL extract structured intent: what, why, scope, risk level, deliverables | P0       | Rule-based extraction  |
| GOV-103 | The system SHALL assign a unique UUID to each intent                                   | P0       | Intent ID              |
| GOV-104 | The system SHALL bind intent to session ID                                             | P0       | Traceability           |
| GOV-105 | The system SHALL record intent source (channel, user, timestamp)                       | P0       | Attribution            |
| GOV-106 | The system SHALL allow users to correct structured intent before approval              | P0       | User control           |
| GOV-107 | The system SHALL store all intents in SQLite with full indexing                        | P0       | Persistence            |
| GOV-108 | The system SHALL support intent status: draft, approved, rejected, expired             | P1       | Lifecycle              |

### 2.2 Intent Schema

```typescript
interface Intent {
  id: string; // UUID v4
  source: "user" | "system" | "scheduled";
  rawInput: string; // Original user message
  structured: StructuredIntent; // Extracted structure
  channelId: string; // Source channel
  senderId: string; // User identifier
  sessionId: string; // Bound session
  status: "draft" | "approved" | "rejected" | "expired";
  approvedAt?: string; // ISO8601
  approvedBy?: string; // User ID
  createdAt: string; // ISO8601
}

interface StructuredIntent {
  what: string; // What action to take
  why: string; // Why/justification
  scope: string[]; // Files, directories, resources
  riskLevel: "low" | "medium" | "high" | "critical";
  deliverables: string[]; // Expected outputs
}
```

### 2.3 Intent Extraction

| ID      | Requirement                                                                  | Priority | Notes                  |
| ------- | ---------------------------------------------------------------------------- | -------- | ---------------------- |
| GOV-111 | The system SHALL implement rule-based intent extraction (v2)                 | P0       | Current implementation |
| GOV-112 | The system SHALL extract "what" from first sentence or 500 chars             | P0       | Heuristic              |
| GOV-113 | The system SHALL extract "why" from keywords: "because", "to", "so that"     | P0       | Heuristic              |
| GOV-114 | The system SHALL determine risk level from keywords (delete, destroy, spend) | P0       | Risk assessment        |
| GOV-115 | The system SHALL extract scope from file patterns and paths                  | P1       | Resource targeting     |
| GOV-116 | The system SHALL extract deliverables from expected outcomes                 | P1       | Success criteria       |
| GOV-117 | The system SHALL support LLM-enhanced intent extraction (future)             | P2       | Planned improvement    |

### 2.4 Intent Lifecycle

| ID      | Requirement                                                               | Priority | Notes           |
| ------- | ------------------------------------------------------------------------- | -------- | --------------- |
| GOV-121 | The system SHALL create intent in "draft" status                          | P0       | Initial state   |
| GOV-122 | The system SHALL require explicit approval before advancing to "approved" | P0       | Human authority |
| GOV-123 | The system SHALL allow intent rejection with reason                       | P1       | User control    |
| GOV-124 | The system SHALL expire intents after 24 hours if unapproved              | P2       | Cleanup         |
| GOV-125 | The system SHALL allow intent modification before approval                | P1       | Flexibility     |
| GOV-126 | The system SHALL log all intent state transitions to bulletin             | P0       | Audit           |

### 2.5 Intent Presentation

| ID      | Requirement                                                         | Priority | Notes          |
| ------- | ------------------------------------------------------------------- | -------- | -------------- |
| GOV-131 | The system SHALL present structured intent to user for confirmation | P0       | Transparency   |
| GOV-132 | The system SHALL highlight high-risk elements in intent             | P1       | User awareness |
| GOV-133 | The system SHALL show estimated cost/complexity if available        | P2       | Planning       |
| GOV-134 | The system SHALL provide "modify intent" option                     | P1       | User control   |

---

## 3. Policy Engine Requirements

### 3.1 Policy Structure

| ID      | Requirement                                                                        | Priority | Notes         |
| ------- | ---------------------------------------------------------------------------------- | -------- | ------------- |
| GOV-201 | The system SHALL support policies with ID, name, description, rules, enabled flag  | P0       | Policy schema |
| GOV-202 | The system SHALL support policy rules with condition, severity, enforcement action | P0       | Rule schema   |
| GOV-203 | The system SHALL load policies from `~/.sophiaclaw/policies.json`                  | P0       | Persistence   |
| GOV-204 | The system SHALL support custom rules from `~/.sophiaclaw/custom_rules.json`       | P0       | User-defined  |
| GOV-205 | The system SHALL evaluate custom rules before standard policies                    | P0       | Precedence    |
| GOV-206 | The system SHALL support policy overrides per rule                                 | P1       | Flexibility   |
| GOV-207 | The system SHALL support policy enable/disable without deletion                    | P1       | Management    |

### 3.2 Policy Schema

```typescript
interface Policy {
  id: string;
  name: string;
  description: string;
  enabled: boolean;
  rules: PolicyRule[];
  overrides?: Record<string, boolean>; // ruleId -> enabled
}

interface PolicyRule {
  id: string;
  name: string;
  description: string;
  enabled: boolean;
  condition: string; // JavaScript expression (evaluated safely)
  severity: "info" | "warning" | "error" | "critical";
  enforcement: "allow" | "require_approval" | "deny";
  scope?: string[]; // Actions this rule applies to
  metadata?: Record<string, any>;
}

interface Violation {
  policyId: string;
  ruleId: string;
  severity: "info" | "warning" | "error" | "critical";
  enforcement: "allow" | "require_approval" | "deny";
  message: string;
  context: Record<string, any>;
}
```

### 3.3 Policy Evaluation

| ID      | Requirement                                                                        | Priority | Notes            |
| ------- | ---------------------------------------------------------------------------------- | -------- | ---------------- |
| GOV-211 | The system SHALL evaluate all enabled policies for every action                    | P0       | Enforcement      |
| GOV-212 | The system SHALL return PolicyCheckResult with passed, violations, warnings, infos | P0       | Result schema    |
| GOV-213 | The system SHALL determine highest enforcement: allow < require_approval < deny    | P0       | Decision logic   |
| GOV-214 | The system SHALL short-circuit evaluation on first "deny" from custom rules        | P0       | Performance      |
| GOV-215 | The system SHALL evaluate policies in <100ms (p95)                                 | P0       | Performance      |
| GOV-216 | The system SHALL support rule conditions matching action type                      | P1       | Targeting        |
| GOV-217 | The system SHALL support rule conditions matching content patterns                 | P1       | Content analysis |
| GOV-218 | The system SHALL support rule conditions with metadata context                     | P1       | Contextual       |

### 3.4 Default Policies

| Policy ID         | Name                    | Description                                      | Enforcement          |
| ----------------- | ----------------------- | ------------------------------------------------ | -------------------- |
| `safe-defaults`   | Safe Default Operations | Allow read-only operations, gate destructive ops | require_approval     |
| `budget-control`  | API Budget Control      | Limit daily API spending to $10                  | deny if exceeded     |
| `shell-allowlist` | Shell Command Allowlist | Only allowlisted shell commands permitted        | deny others          |
| `data-protection` | Data Protection         | Block external sharing of PII                    | deny                 |
| `rate-limiting`   | Rate Limiting           | Limit requests per minute per user               | require_approval     |
| `business-hours`  | Business Hours Only     | Restrict certain ops to 9am-6pm (optional)       | allow (configurable) |

### 3.5 Custom Policy Definition

| ID      | Requirement                                                                   | Priority | Notes         |
| ------- | ----------------------------------------------------------------------------- | -------- | ------------- |
| GOV-231 | The system SHALL support user-defined custom rules in JSON format             | P0       | Extensibility |
| GOV-232 | The system SHALL validate custom rules with Zod schema on load                | P0       | Validation    |
| GOV-233 | The system SHALL support custom rule conditions as JavaScript expressions     | P0       | Flexibility   |
| GOV-234 | The system SHALL sandbox custom rule evaluation (no arbitrary code execution) | P0       | Security      |
| GOV-235 | The system SHALL provide CLI for policy management: `sophiaclaw policy add`   | P1       | Usability     |
| GOV-236 | The system SHALL support rule templates for common patterns                   | P2       | Convenience   |

### 3.6 Policy Violation Handling

| ID      | Requirement                                                                     | Priority | Notes        |
| ------- | ------------------------------------------------------------------------------- | -------- | ------------ |
| GOV-241 | The system SHALL record all policy violations to bulletin                       | P0       | Audit        |
| GOV-242 | The system SHALL present violation details to user on block                     | P0       | Transparency |
| GOV-243 | The system SHALL suggest remediation for common violations                      | P1       | UX           |
| GOV-244 | The system SHALL allow one-time override for require_approval violations        | P1       | Flexibility  |
| GOV-245 | The system SHALL NOT allow override for deny violations (without policy change) | P0       | Security     |
| GOV-246 | The system SHALL escalate repeated violations to admin review                   | P2       | Compliance   |

---

## 4. Gate Engine Requirements

### 4.1 Gate Check Types

| ID      | Requirement                                            | Priority | Notes               |
| ------- | ------------------------------------------------------ | -------- | ------------------- |
| GOV-301 | The system SHALL support risk-assessment gate checks   | P0       | High-risk detection |
| GOV-302 | The system SHALL support policy-violation gate checks  | P0       | Policy enforcement  |
| GOV-303 | The system SHALL support resource-conflict gate checks | P1       | Claim conflicts     |
| GOV-304 | The system SHALL support cost-threshold gate checks    | P1       | Budget control      |
| GOV-305 | The system SHALL support custom gate checker plugins   | P2       | Extensibility       |

### 4.2 Gate Check Schema

```typescript
interface GateCheckParams {
  sessionId: string;
  agentId: string;
  action: string; // Action being attempted
  resource: string; // Target resource
  context: Record<string, any>; // Additional context
}

interface GateCheckResult {
  type: GateCheckType;
  passed: boolean;
  message?: string;
  violations?: Violation[];
  conflicts?: Conflict[];
  durationMs: number;
}

interface GateResult {
  decision: "approved" | "blocked" | "escalate";
  sessionId: string;
  action: string;
  resource: string;
  checks: GateCheckResult[];
  violations: Violation[];
  conflicts: Conflict[];
  escalationReason?: EscalationReason;
  timestamp: string;
  durationMs: number;
}

type GateDecision = "approved" | "blocked" | "escalate";
type EscalationReason = "policy_violation" | "resource_conflict" | "high_risk" | "cost_exceeded";
```

### 4.3 Gate Triggers

| ID      | Requirement                                                       | Priority | Trigger Condition     |
| ------- | ----------------------------------------------------------------- | -------- | --------------------- |
| GOV-311 | The system SHALL trigger gate for file deletions >10 files        | P0       | Destructive operation |
| GOV-312 | The system SHALL trigger gate for API spending >$5 single request | P0       | Budget control        |
| GOV-313 | The system SHALL trigger gate for non-allowlisted shell commands  | P0       | Security              |
| GOV-314 | The system SHALL trigger gate for external data sharing           | P0       | Data protection       |
| GOV-315 | The system SHALL trigger gate for file access outside allowlist   | P0       | Access control        |
| GOV-316 | The system SHALL trigger gate for operations on >100 resources    | P1       | Scale protection      |
| GOV-317 | The system SHALL trigger gate for critical-risk intent            | P1       | Risk-based            |

### 4.4 Gate Decisions

| ID      | Requirement                                                      | Priority | Notes        |
| ------- | ---------------------------------------------------------------- | -------- | ------------ |
| GOV-321 | The system SHALL return "approved" when all checks pass          | P0       | Proceed      |
| GOV-322 | The system SHALL return "blocked" when critical check fails      | P0       | Stop         |
| GOV-323 | The system SHALL return "escalate" for non-critical violations   | P0       | Human review |
| GOV-324 | The system SHALL log all gate decisions to bulletin              | P0       | Audit        |
| GOV-325 | The system SHALL present gate result to user with action options | P0       | Transparency |

### 4.5 User Gate Responses

| ID      | Requirement                                                                  | Priority | Notes            |
| ------- | ---------------------------------------------------------------------------- | -------- | ---------------- |
| GOV-331 | The system SHALL present user with: Approve, Modify, Reject options          | P0       | User control     |
| GOV-332 | The system SHALL allow one-time approval for require_approval gates          | P0       | Flexibility      |
| GOV-333 | The system SHALL allow permanent rule creation from gate response            | P1       | Learning         |
| GOV-334 | The system SHALL require re-authentication for critical approvals (optional) | P2       | Security         |
| GOV-335 | The system SHALL timeout gate approvals after 15 minutes (configurable)      | P1       | Stale prevention |

### 4.6 Escalation Handling

| ID      | Requirement                                                             | Priority | Notes          |
| ------- | ----------------------------------------------------------------------- | -------- | -------------- |
| GOV-341 | The system SHALL log all escalations to bulletin with reason            | P0       | Audit          |
| GOV-342 | The system SHALL notify user of escalation and expected resolution time | P1       | UX             |
| GOV-343 | The system SHALL support escalation to admin user or team               | P1       | Team workflows |
| GOV-344 | The system SHALL track escalation resolution time                       | P2       | Metrics        |
| GOV-345 | The system SHALL generate escalation reports on demand                  | P2       | Compliance     |

---

## 5. Bulletin Service (Audit Trail) Requirements

### 5.1 Event Types

| ID      | Requirement                                           | Priority | Event Types                                 |
| ------- | ----------------------------------------------------- | -------- | ------------------------------------------- |
| GOV-401 | The system SHALL log intent creation events           | P0       | `intent.created`                            |
| GOV-402 | The system SHALL log intent approval/rejection events | P0       | `intent.approved`, `intent.rejected`        |
| GOV-403 | The system SHALL log policy evaluation events         | P0       | `policy.evaluated`                          |
| GOV-404 | The system SHALL log policy violation events          | P0       | `policy.violation`                          |
| GOV-405 | The system SHALL log gate check events                | P0       | `gate.check`, `gate.passed`, `gate.blocked` |
| GOV-406 | The system SHALL log tool execution events            | P0       | `tool.executed`                             |
| GOV-407 | The system SHALL log security events                  | P0       | `security.*`                                |
| GOV-408 | The system SHALL log configuration change events      | P1       | `config.changed`                            |
| GOV-409 | The system SHALL log session lifecycle events         | P1       | `session.started`, `session.ended`          |

### 5.2 Event Schema

```typescript
interface BulletinEvent {
  id: string; // UUID v4
  type: string; // Event type (e.g., "intent.created")
  sessionId: string; // Associated session
  agentId: string; // Agent identifier
  timestamp: string; // ISO8601
  severity: "info" | "warning" | "error" | "critical";
  actor: {
    type: "user" | "system" | "channel" | "ai";
    id: string;
  };
  resource?: string; // Affected resource
  action?: string; // Action taken
  result?: "success" | "failure" | "blocked" | "pending";
  payload: Record<string, any>; // Event-specific data
  metadata?: {
    durationMs?: number;
    cost?: number;
    tokens?: number;
  };
}
```

### 5.3 Storage Requirements

| ID      | Requirement                                                               | Priority | Notes              |
| ------- | ------------------------------------------------------------------------- | -------- | ------------------ |
| GOV-411 | The system SHALL store bulletin events in append-only SQLite table        | P0       | Immutability       |
| GOV-412 | The system SHALL index events by: timestamp, session, type, severity      | P0       | Query performance  |
| GOV-413 | The system SHALL NOT allow modification of committed events               | P0       | Integrity          |
| GOV-414 | The system SHALL support optional cryptographic verification (hash chain) | P2       | Tamper evidence    |
| GOV-415 | The system SHALL implement automatic partitioning by date                 | P1       | Performance        |
| GOV-416 | The system SHALL support event retention policies                         | P1       | Storage management |

### 5.4 Retention Policies

| Event Type        | Default Retention | Configurable | Notes           |
| ----------------- | ----------------- | ------------ | --------------- |
| Security events   | 1 year            | Yes          | Compliance      |
| Policy violations | 1 year            | Yes          | Audit           |
| Gate events       | 90 days           | Yes          | Review          |
| Tool executions   | 90 days           | Yes          | Debugging       |
| Session events    | 90 days           | Yes          | History         |
| Config changes    | 1 year            | Yes          | Change tracking |

### 5.5 Query and Export

| ID      | Requirement                                            | Priority | Notes          |
| ------- | ------------------------------------------------------ | -------- | -------------- |
| GOV-421 | The system SHALL support query by session ID           | P0       | Session audit  |
| GOV-422 | The system SHALL support query by date range           | P0       | Time-based     |
| GOV-423 | The system SHALL support query by event type           | P0       | Filtering      |
| GOV-424 | The system SHALL support query by severity             | P1       | Prioritization |
| GOV-425 | The system SHALL support query by resource             | P1       | Resource audit |
| GOV-426 | The system SHALL export events to JSON format          | P0       | Portability    |
| GOV-427 | The system SHALL export events to Markdown format      | P1       | Readability    |
| GOV-428 | The system SHALL generate governance reports on demand | P1       | Compliance     |

### 5.6 Bulletin Commands

| Command                                        | Purpose                 | Example               |
| ---------------------------------------------- | ----------------------- | --------------------- |
| `sophiaclaw bulletin list`                     | List recent events      | `--last 24h`          |
| `sophiaclaw bulletin list --session <id>`      | Session-specific events |                       |
| `sophiaclaw bulletin list --violations`        | Only policy violations  |                       |
| `sophiaclaw bulletin export --format json`     | Export to JSON          | `--output audit.json` |
| `sophiaclaw bulletin export --format markdown` | Export to Markdown      | `--output audit.md`   |
| `sophiaclaw bulletin purge --before <date>`    | Delete old events       | Admin only            |

---

## 6. Claims Service (Conflict Detection) Requirements

### 6.1 Claim Structure

| ID      | Requirement                                                 | Priority | Notes             |
| ------- | ----------------------------------------------------------- | -------- | ----------------- |
| GOV-501 | The system SHALL create claims for resources being modified | P0       | Resource tracking |
| GOV-502 | The system SHALL support file-level claims                  | P0       | Granular          |
| GOV-503 | The system SHALL support directory-level claims             | P1       | Scope             |
| GOV-504 | The system SHALL support custom resource types              | P2       | Extensibility     |
| GOV-505 | The system SHALL store claims in SQLite with expiration     | P0       | Persistence       |

### 6.2 Claim Schema

```typescript
interface Claim {
  id: string; // UUID v4
  sessionId: string; // Session holding claim
  agentId: string; // Agent identifier
  resourceType: "file" | "directory" | "database" | "custom";
  resourceId: string; // Path or identifier
  mode: "read" | "write" | "exclusive";
  createdAt: string; // ISO8601
  expiresAt: string; // ISO8601
  metadata?: Record<string, any>;
}

interface Conflict {
  claim1: Claim;
  claim2: Claim;
  conflictType: "write_write" | "read_exclusive" | "exclusive_exclusive";
  detectedAt: string;
  resolved?: boolean;
  resolution?: "cancelled" | "proceeded" | "merged";
}
```

### 6.3 Conflict Detection

| ID      | Requirement                                                             | Priority | Notes                   |
| ------- | ----------------------------------------------------------------------- | -------- | ----------------------- |
| GOV-511 | The system SHALL detect when two sessions claim same resource for write | P0       | Write-write conflict    |
| GOV-512 | The system SHALL detect when read claim conflicts with exclusive claim  | P0       | Read-exclusive conflict |
| GOV-513 | The system SHALL detect when two exclusive claims overlap               | P0       | Exclusive conflict      |
| GOV-514 | The system SHALL notify both sessions of detected conflict              | P0       | User awareness          |
| GOV-515 | The system SHALL present conflict details and resolution options        | P0       | UX                      |
| GOV-516 | The system SHALL log all conflicts to bulletin                          | P0       | Audit                   |

### 6.4 Conflict Resolution

| ID      | Requirement                                                           | Priority | Notes        |
| ------- | --------------------------------------------------------------------- | -------- | ------------ |
| GOV-521 | The system SHALL offer "view changes" option to compare modifications | P0       | Transparency |
| GOV-522 | The system SHALL offer "proceed anyway" with warning                  | P0       | User choice  |
| GOV-523 | The system SHALL offer "cancel my operation" option                   | P0       | Safety       |
| GOV-524 | The system SHALL offer "merge changes" option (future)                | P2       | Advanced     |
| GOV-525 | The system SHALL default to blocking on unresolvable conflicts        | P1       | Safety       |

### 6.5 Lock Management

| ID      | Requirement                                                            | Priority | Notes               |
| ------- | ---------------------------------------------------------------------- | -------- | ------------------- |
| GOV-531 | The system SHALL implement automatic claim expiration (default 30 min) | P0       | Deadlock prevention |
| GOV-532 | The system SHALL support explicit claim release                        | P0       | Manual control      |
| GOV-533 | The system SHALL renew claim on activity (rolling expiration)          | P1       | Long operations     |
| GOV-534 | The system SHALL support claim prioritization (admin > user)           | P2       | Priority            |
| GOV-535 | The system SHALL implement claim queue for contested resources         | P2       | Fairness            |

---

## 7. User Consent and Control Requirements

### 7.1 Consent Capture

| ID      | Requirement                                                                | Priority | Notes             |
| ------- | -------------------------------------------------------------------------- | -------- | ----------------- |
| GOV-601 | The system SHALL capture explicit user consent before high-risk operations | P0       | Informed consent  |
| GOV-602 | The system SHALL present clear description of what will happen             | P0       | Transparency      |
| GOV-603 | The system SHALL present potential risks or side effects                   | P0       | Risk disclosure   |
| GOV-604 | The system SHALL present estimated cost if applicable                      | P1       | Cost transparency |
| GOV-605 | The system SHALL require affirmative action (not pre-checked)              | P0       | Explicit consent  |
| GOV-606 | The system SHALL log consent to bulletin with timestamp                    | P0       | Audit             |

### 7.2 User Control Options

| ID      | Requirement                                            | Priority | Notes          |
| ------- | ------------------------------------------------------ | -------- | -------------- |
| GOV-611 | The system SHALL provide "approve once" option         | P0       | One-time       |
| GOV-612 | The system SHALL provide "approve and remember" option | P0       | Create rule    |
| GOV-613 | The system SHALL provide "modify request" option       | P0       | User editing   |
| GOV-614 | The system SHALL provide "reject" option               | P0       | User veto      |
| GOV-615 | The system SHALL provide "escalate to admin" option    | P1       | Team workflows |
| GOV-616 | The system SHALL provide "show details" option         | P0       | Transparency   |

### 7.3 Governance Configuration

| ID      | Requirement                                                                      | Priority | Notes            |
| ------- | -------------------------------------------------------------------------------- | -------- | ---------------- |
| GOV-621 | The system SHALL support governance levels: permissive, standard, strict, custom | P0       | Presets          |
| GOV-622 | The system SHALL allow users to customize governance level via CLI               | P0       | Configuration    |
| GOV-623 | The system SHALL allow users to create custom policies                           | P0       | Extensibility    |
| GOV-624 | The system SHALL allow users to enable/disable specific policies                 | P1       | Granular control |
| GOV-625 | The system SHALL provide governance status dashboard                             | P1       | Visibility       |
| GOV-626 | The system SHALL allow audit log review at any time                              | P0       | Transparency     |

### 7.4 Governance Levels

| Level        | Description      | Gates            | Policies              | Best For                  |
| ------------ | ---------------- | ---------------- | --------------------- | ------------------------- |
| `permissive` | Minimal friction | Logging only     | Basic safety          | Solo dev, experimentation |
| `standard`   | Balanced safety  | Default triggers | Default policies      | Small teams, daily use    |
| `strict`     | Maximum safety   | All triggers     | All policies + custom | Business, sensitive data  |
| `custom`     | User-defined     | User-configured  | User-configured       | Specific compliance needs |

---

## 8. Compliance Considerations

### 8.1 GDPR Compliance

| Requirement                   | Implementation                                         | Status         |
| ----------------------------- | ------------------------------------------------------ | -------------- |
| Right to access               | `sophiaclaw bulletin export` provides full audit trail | ✅ Implemented |
| Right to rectification        | Intent correction before approval                      | ✅ Implemented |
| Right to erasure              | `sophiaclaw sessions delete-all` purges data           | ✅ Implemented |
| Data minimization             | Local-first storage, no cloud dependency               | ✅ Implemented |
| Purpose limitation            | Intent capture ensures understood purpose              | ✅ Implemented |
| Accuracy                      | User can correct intent and structured data            | ✅ Implemented |
| Storage limitation            | Configurable retention policies                        | ✅ Implemented |
| Integrity and confidentiality | Encryption, access controls, audit logging             | ✅ Implemented |

### 8.2 CCPA Compliance

| Requirement                 | Implementation                                        | Status         |
| --------------------------- | ----------------------------------------------------- | -------------- |
| Right to know               | Audit export shows all data processing                | ✅ Implemented |
| Right to delete             | Session and data purge commands                       | ✅ Implemented |
| Right to opt-out            | Governance level can be set to block external sharing | ✅ Implemented |
| Right to non-discrimination | All users subject to same policies                    | ✅ Implemented |

### 8.3 Data Processing Records

| ID      | Requirement                                                        | Priority | Notes           |
| ------- | ------------------------------------------------------------------ | -------- | --------------- |
| GOV-701 | The system SHALL maintain record of all data processing activities | P0       | Bulletin events |
| GOV-702 | The system SHALL record purpose of processing (from intent)        | P0       | Intent service  |
| GOV-703 | The system SHALL record categories of data processed               | P1       | Metadata        |
| GOV-704 | The system SHALL record recipients of data (external sharing)      | P1       | Data flow       |
| GOV-705 | The system SHALL record retention periods applied                  | P1       | Compliance      |
| GOV-706 | The system SHALL generate data processing report on demand         | P2       | DPA support     |

### 8.4 Audit Readiness

| ID      | Requirement                                                            | Priority | Notes           |
| ------- | ---------------------------------------------------------------------- | -------- | --------------- |
| GOV-711 | The system SHALL support export of complete audit trail for date range | P0       | External audit  |
| GOV-712 | The system SHALL provide audit trail integrity verification            | P1       | Tamper evidence |
| GOV-713 | The system SHALL maintain chain of custody for critical events         | P2       | Legal           |
| GOV-714 | The system SHALL support subpoena response with targeted export        | P2       | Legal           |

---

## 9. Governance Metrics and Reporting

### 9.1 Operational Metrics

| Metric                    | Description                               | Target |
| ------------------------- | ----------------------------------------- | ------ |
| Intent accuracy rate      | % intents correctly understood first time | >90%   |
| Policy evaluation latency | p95 time to evaluate policies             | <100ms |
| Gate trigger rate         | % actions requiring gate approval         | <20%   |
| Gate approval time        | Average time to approve at gate           | <2 min |
| Conflict rate             | % operations with detected conflicts      | <5%    |
| Violation rate            | % operations with policy violations       | <10%   |

### 9.2 Compliance Metrics

| Metric                    | Description                  | Retention |
| ------------------------- | ---------------------------- | --------- |
| Total governance events   | Count of all bulletin events | 1 year    |
| Policy violations by type | Breakdown of violations      | 1 year    |
| Gate escalations          | Count and resolution time    | 1 year    |
| User overrides            | Count of one-time approvals  | 1 year    |
| Audit log exports         | Count and recipients         | 1 year    |

### 9.3 Reporting Commands

| Command                                             | Purpose             | Output        |
| --------------------------------------------------- | ------------------- | ------------- |
| `sophiaclaw governance report --last 30d`           | Governance summary  | Markdown      |
| `sophiaclaw governance violations --period <range>` | Violation report    | JSON/Markdown |
| `sophiaclaw governance metrics`                     | Operational metrics | JSON          |
| `sophiaclaw governance audit --session <id>`        | Session audit       | Full details  |

---

## 10. Related Documents

- [System Requirements](./SYSTEM_REQUIREMENTS.md)
- [Security Requirements](./SECURITY_REQUIREMENTS.md)
- [Performance Requirements](./PERFORMANCE_REQUIREMENTS.md)
- [Governance Guide](../governance.md)
- [Security Architecture](../security.md)

---

<p align="center">
  <em>SophiaClaw Governance — Trust Through Transparency</em><br>
  <sub>Every action understood. Every decision recorded.</sub>
</p>
