> Public study copy. Original Xavier note path: `30-39 Projects/33 Xavier/33.05 Hermes Memory Mirror Policy.md`. Secrets/credential-like values, if any, are redacted.

# 33.05 Hermes Memory Mirror Policy

> Operating policy for how Xavier mirrors Hermes runtime identity and memory into Obsidian.
> Last updated: 2026-06-02

## Direction

Default direction:

```text
Hermes runtime → Obsidian mirror
```

This means the Obsidian notes are visual/audit copies, not the live executable source.

## Runtime source files

- Soul / identity: `/opt/data/SOUL.md`
- User profile: `/opt/data/memories/USER.md`
- Operational memory: `/opt/data/memories/MEMORY.md`

## Mirror notes

- [[33.02 Xavier Soul]] mirrors `/opt/data/SOUL.md`
- [[33.03 Paulo User Profile]] mirrors `/opt/data/memories/USER.md`
- [[33.04 Xavier Runtime Memory]] mirrors `/opt/data/memories/MEMORY.md`

## Change workflow

1. Paulo reviews the Obsidian mirror.
2. Paulo asks Xavier explicitly to change Soul, User, or Memory.
3. Xavier updates the runtime source deliberately.
4. Xavier mirrors the new state back into Obsidian.

## Classification rules

Before saving information, classify it by destination:

- **SOUL.md** — Xavier identity, tone, operating posture, and stable behavioral priorities.
- **USER.md** — Paulo's durable preferences, communication style, workflow preferences, and stable cross-session habits.
- **MEMORY.md** — durable operational facts: paths, environment quirks, tool constraints, stable project facts needed across sessions.
- **Obsidian** — long-form project state, decisions, plans, reports, relationship context, dashboards, architecture, and human-readable notes.
- **Skills** — procedures with steps, commands, pitfalls, and verification.
- **AGENTS.md** — workspace/project rules that should load automatically when working in that folder.
- **session_search** — recall of previous conversations; do not copy raw history into runtime memory.
- **Nowhere** — temporary, obvious, stale, sensitive, or low-value information.

## Runtime write test

Only write to runtime memory when the answer is yes to all or most of these:

1. Will this still matter in 7 days?
2. Will it reduce future steering from Paulo?
3. Is it stable enough to avoid misleading future sessions?
4. Is it compact enough to fit in one declarative sentence?
5. Is it not already stored elsewhere?
6. Is it free of secrets and unnecessary sensitive data?

## Never store

Do not store these in runtime memory, Obsidian notes, skills, logs, or final summaries:

- API keys, tokens, passwords, private keys, seed phrases, credential values, or webhook URLs.
- Raw private conversation dumps.
- Completed-work logs, PR numbers, issue numbers, commit SHAs, or ephemeral task progress.
- Sensitive personal data unless Paulo explicitly asks and there is a clear durable reason.
- Long procedures in runtime memory; create skills instead.

## Why not automatic bidirectional sync?

Automatic Obsidian → Hermes sync is intentionally avoided because:

- accidental edits could alter runtime behavior;
- long notes may exceed Hermes memory limits;
- human reflection could be confused with executable instruction;
- memory updates are safest when curated deliberately;
- runtime memory is injected at session start, so some changes may only apply cleanly in later sessions.

## Supporting skills

- `xavier-memory-curation` — audit and route information between runtime memory, Obsidian, skills, AGENTS.md, session history, or nowhere.
- `xavier-decision-capture` — preserve durable decisions, tradeoffs, implications, and project-state changes in the Xavier vault.

## Rule of thumb

- Obsidian is the readable dashboard.
- Hermes runtime files are the executable state.
- Paulo can request changes; Xavier applies and re-mirrors them deliberately.