Memory Governor

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

Security Scan

The package is an instruction-first governance kernel that matches its description: it provides docs and small helper scripts to validate/bootstraps host files and does not request credentials or perform surprising installs or network access.

Purpose & Capability

Name/description (a memory-governor governance kernel) align with the shipped files: policy docs, adapter/manifest guidance, fallback templates, and helper scripts for host checking, frontmatter validation, candidate review, and a lightweight bootstrap. There are no unrelated environment variables, binaries, or credentials requested.

Instruction Scope

SKILL.md and the references concentrate on classification, routing, promotion and exclusion rules. The included scripts read host manifests and structured memory files and the bootstrap script creates example files. This is coherent with the stated purpose, but note that running the scripts will read and (in the case of bootstrap) write files in a host directory — exactly as documented.

Install Mechanism

No install spec; the skill is instruction-only and ships helper scripts. No downloads, package managers, or external installers are referenced in the metadata. Risk from installation is low since nothing will be pulled from arbitrary URLs.

Credentials

The skill requires no environment variables, credentials, or config paths. The job it performs (governing memory artifacts) legitimately needs access to host files and manifests, which is consistent with the provided scripts and guidance.

Persistence & Privilege

Flags are default (always: false). The package does include a bootstrap script that can create host files when run, but installation metadata does not request permanent platform privileges or automatic modification of unrelated skills; the docs explicitly state integration should be explicit and not silent.

Assessment

This skill is internally consistent with its documentation: it provides rules, templates, and small helper scripts to check and bootstrap host-level memory adapter files. Before running anything, review the included scripts (bootstrap-generic-host.sh, check-memory-host.py, validate-memory-frontmatter.py, review-learning-candidates.py) so you understand what files they will read or create. The bootstrap script will create example files in a target directory (it documents that it won't overwrite existing files). Avoid copying secrets into the memory files it manages (references/exclusions.md explicitly forbids storing tokens/passwords). If you do not want the agent or scripts to access certain workspace files, run them in a controlled directory or inspect/limit file permissions. If you need stricter runtime guarantees, run the scripts manually rather than allowing autonomous agent invocation. Overall, the package appears to do what it claims; proceed if that governance model fits your host and you are comfortable with the scripts' filesystem access.

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.