Memory Governor

Memory governance kernel for AI agents that complements OpenClaw Dreaming with explicit correction staging, target-class routing, adapter boundaries, and safer manual hardening rules.

Reusable memory-governance core for different host environments.

The OpenClaw integration in this repository is only a reference host profile, not the only host model.

It is not a second-brain system, sync bus, or knowledge manager. It governs what should be remembered, where it should go, when it should be promoted, and what should be excluded.

It is a governance kernel, not an execution-first productivity skill. Its value is highest when a host already has multiple memory layers, multiple memory-writing skills, or adapter drift.

When to Use

Use this skill when:

• you need to decide whether something should enter memory
• you need to choose the right memory layer or target class
• you need to promote daily, correction, or working state into durable rules
• multiple skills are starting to define memory differently and need governance

First Reading Path

If this is your first time opening memory-governor, start here:

1. SKILL.md
2. references/memory-routing.md
3. references/promotion-rules.md
4. references/exclusions.md
5. references/adapters.md

The remaining reference files are optional on first read.

What Counts as Memory

Only information that improves future judgment, recovery, execution quality, or coordination consistency counts as memory.

Typical examples:

• stable long-term preferences
• stable long-term facts
• key same-day events
• explicit corrections
• unproven but promising candidate lessons
• reusable lessons
• current progress state
• short-term recovery hints

For content that should stay out of memory, see references/exclusions.md.

Core Rule

The thing being standardized is the memory contract, not every skill implementation.

That means:

• all skills should follow the same classification, routing, promotion, and exclusion rules
• each skill may keep its own internal logic, downstream tools, interaction style, and directory habits

In short:

standardize the core, not everything else

Target Classes

The kernel defines abstract target classes before it defines any optional skill path.

Recommended standard target classes:

• long_term_memory
• daily_memory
• learning_candidates
• reusable_lessons
• proactive_state
• working_buffer
• project_facts
• system_rules
• tool_rules

Concrete file paths are adapter details, not the contract itself.

Notes:

• learning_candidates is a low-commitment staging layer for corrections and emerging lessons
• it exists to prevent single observations from hardening too early
• proactive_state and working_buffer are stateful targets
• they should not become infinite append-only logs
• they need freshness, replace or merge, and retention rules by default

Routing Order

When evaluating a candidate memory, reason in this order:

1. Is it worth remembering at all?
2. What memory type is it?
3. Which target class does that type belong to?
4. Which adapter in the current host should store that target class?
5. Is it still short-term, or is it ready for promotion?
6. Does it match any exclusion rule?

See references/memory-routing.md for the routing table.

See references/routing-precedence.md for ambiguity resolution.

Promotion Rules

All promotion should extract and refine before it hardens.

Never:

• write raw logs directly into long-term memory
• treat a working buffer as long-term memory
• use system-governance files as temporary capture inboxes

See references/promotion-rules.md for details.

See references/correction-pipeline.md for the correction-to-candidate-to-rule flow.

See references/candidate-review.md for keep/promote/discard review workflow.

See references/dreaming-integration.md for how this kernel should coexist with OpenClaw Dreaming without duplicate promotion paths.

See references/stateful-targets.md for update semantics on stateful targets.

See references/schema-conventions.md if the host wants stronger structured constraints.

See references/retention-rules.md for lifecycle rules.

See references/read-order.md for recovery-time read order.

Skill Integration

When another skill integrates with this kernel:

• the skill may declare which information types it emits
• the skill may declare where those types usually land
• the skill should not invent a new global memory-layer definition
• the skill should not bypass exclusion rules
• the skill should not confuse downstream storage rules with upstream memory rules

See references/skill-integration.md.

Adapters

memory-governor may provide default adapters, but those adapters are not the only truth.

Examples:

• long_term_memory -> MEMORY.md
• daily_memory -> memory/YYYY-MM-DD.md
• reusable_lessons -> ~/self-improving/... if self-improving is installed
• reusable_lessons -> a local fallback file if self-improving is absent

See references/adapters.md for default adapter behavior.

See references/integration-checklist.md for integration checks.

See references/installation-integration.md for installation and host integration guidance.

See references/host-profiles.md for host differences.

Never Do

• do not turn this skill into a monolithic personal memory system
• do not embed Obsidian, Notion, or OmniFocus implementation details into the governance kernel
• do not force every skill into the same implementation style
• do not invent a new primary memory directory unless the governance layer explicitly approves it
• do not write secrets, raw long logs, or short-lived noise into memory

Phase Boundary

The current phase is governance core only.

That means:

• it may define contracts
• it may define references
• it may constrain how other skills write memory
• it may not quietly grow into a unified execution bus at this stage

If the project later wants an orchestration layer or a full personal memory system, that should be scoped separately after the governance layer is stable.