# GoClaw Level 5 Vision

This document describes a possible path from GoClaw's current Level 4 model, an autonomous digital workforce gateway, toward a Level 5 enterprise operating layer. It is a roadmap document, not a statement of current implementation.

## Level 4 To Level 5

| Dimension | Level 4 | Level 5 target |
|---|---|---|
| Goal source | Humans assign tasks | Agents infer candidate goals from organizational signals |
| Learning | Learns facts from conversations; corrects a failed tool call in the same turn | Learns from controlled experiments and outcomes |
| Collaboration | Manager-to-worker delegation | Peer negotiation, reputation, and collective decisions |
| Organization model | Channels, sessions, tools, SOPs | Live world model of systems, dependencies, risk, and priorities |
| Safety | Role, tool, auth, and channel controls | Constitutional policy layer with decision provenance |
| Self-improvement | Admin-approved notes, saved queries and SOPs | Proposed SOPs, skill gaps, and tool composition under review |

## Pillar 1: Autonomous Goal Formation

Level 5 should propose goals from observed operational signals instead of waiting only for direct commands.

Candidate inputs:

- Repeated cron failures.
- Repeated Zabbix or Grafana alerts.
- GitLab pipeline patterns.
- Unresolved SOP failures.
- Frequent user requests in the same area.
- Missing documentation discovered during repeated tool use.

Conceptual model:

```go
type StrategicGoal struct {
    ID          string
    Description string
    Priority    int
    Evidence    []string
    GeneratedBy string
    CreatedAt   time.Time
}
```

Goal lifecycle:

```mermaid
stateDiagram-v2
    direction LR
    [*] --> proposed
    proposed --> approved
    approved --> in_progress
    in_progress --> completed
    in_progress --> abandoned
```

Human approval should remain the default. Auto-approval can be considered only for low-risk goals with clear policy boundaries.

## Pillar 2: Hypothesis-Driven Learning

Level 5 should learn by proposing and testing hypotheses in controlled environments.

Experiment lifecycle:

1. Form a hypothesis.
2. Define a safe test environment.
3. Execute the smallest useful test.
4. Measure the outcome.
5. Write verified learning to memory or agent notes.
6. Mark unverified assumptions as such.

Example:

```text
Hypothesis: Increasing GitLab runner cache reuse will reduce deploy duration.
Environment: staging project only.
Metric: median pipeline duration over 10 runs.
Approval: required before changing runner configuration.
```

## Pillar 3: Agent Society

The current system supports subagents and session tools. A Level 5 system would add richer peer coordination.

Future concepts:

- Peer task bidding based on expertise and availability.
- Agent reputation scores based on completed work and reviewed outcomes.
- Collective decision sessions for high-risk actions.
- Cross-agent knowledge transfer with confidence and verification metadata.

Conceptual model:

```go
type AgentReputation struct {
    AgentID        string
    TrustScore     float64
    SuccessRate    float64
    SpecialtyAreas []string
}
```

## Pillar 4: World Model And Causal Reasoning

GoClaw already has observability tools, memory, graph storage, and metrics storage. Level 5 would connect those into a live world model.

World model inputs:

- Service topology from Uptrace.
- Host and trigger state from Zabbix.
- Alerts from Grafana.
- Logs from Graylog.
- Security events from Wazuh.
- Inventory from NetBox.
- Deploy and issue data from GitLab.
- Stored metrics from `metrics_store`.

Conceptual model:

```go
type WorldModel struct {
    Systems            map[string]*SystemNode
    Dependencies       []Dependency
    CurrentState       map[string]StateValue
    HistoricalPatterns []Pattern
    LastUpdated        time.Time
}
```

The goal is not just to answer "what is broken?" but to evaluate "what is likely to happen if we take this action?"

## Pillar 5: Adaptive Communication

Level 5 should adjust communication style to user state, channel, and urgency while staying transparent.

Examples:

| Situation | Preferred behavior |
|---|---|
| Incident response | Short status, concrete action, no long background unless asked |
| New user | Plain language, fewer internal abbreviations |
| Risky action | Explicit risk, approval requirement, rollback plan |
| Repeated failure | State what changed since the previous attempt |

This should be implemented as style guidance and response policy, not as hidden emotional profiling.

## Pillar 6: Self-Architecture And Meta-Learning

GoClaw already has SOPs, tools, auto-learning, and skill registries. Level 5 would add governed self-improvement proposals.

Future capabilities:

- Detect repeated tool sequences and propose SOPs.
- Detect skill gaps and recommend new skills or docs to index.
- Suggest tool compositions, then require review before promotion.
- Track whether generated SOPs actually improve outcomes.

Conceptual model:

```go
type SynthesizedToolProposal struct {
    Name        string
    Components  []string
    Reason      string
    Evidence    []string
    RequiresReview bool
}
```

## Pillar 7: Constitutional Policy And Auditability

As autonomy increases, the policy layer must become more explicit.

Required controls:

- Immutable prohibitions for destructive production actions.
- Approval thresholds by blast radius, data volume, financial risk, and security scope.
- Decision chains for every automated action.
- Prompt-injection boundaries for webhook, email, web, and document inputs.
- Separation between suggestions, approved plans, and executed actions.

Example policy sketch:

```yaml
constitution:
  absolute_prohibitions:
    - "Delete production data without explicit approval"
    - "Expose credentials or secrets"
    - "Escalate beyond configured role permissions"
  approval_required:
    - "Actions affecting more than 500 users"
    - "External API bursts above configured thresholds"
    - "Bulk data movement above configured size limits"
```

## Implementation Roadmap

### Phase A: Foundation

- World model store.
- Goal proposal API and review UI.
- Cross-agent knowledge bus.
- Experiment sandbox with read-only defaults.
- SOP suggestion from repeated patterns.

### Phase B: Intelligence

- Causal inference over observability and deploy signals.
- Counterfactual simulation for operational actions.
- Peer negotiation protocol.
- Adaptive communication policy.
- Skill gap tracking.

### Phase C: Governed Autonomy

- Strategic intent engine.
- Constitutional enforcement middleware.
- Collective decision system.
- Full decision-chain UI.
- Outcome measurement for goals and SOPs.

## Near-Term Practical Steps

1. Store observed operational facts in a world-model schema.
2. Add a goal proposal table and Web UI review flow.
3. Add SOP suggestion from repeated trace patterns.
4. Add policy checks before any high-risk SOP or tool action.
5. Record outcome metrics for completed goals.

## Summary

Level 5 is not just a smarter single agent. It is a governed coordination layer where agents can propose goals, test hypotheses, collaborate, reason over operational state, and improve workflows while remaining auditable and policy-bound.