# Consolidation Pass

Consolidation reconciles non-canonical working notes. It cannot mutate registry truth, accept proposals, or clear event history.

## Procedure

1. Freeze scope and obtain write permission for any proposed changes.
2. Load HOT pointers, their WARM/COLD targets, approved decisions, and relevant registry projection offsets.
3. Group comparable notes by unit, field, window, denominator, source meaning, and authority.
4. Deduplicate exact semantic duplicates while retaining the strongest source pointer.
5. Supersede an older note only when newer evidence is comparable and equal/higher authority; annotate `superseded_by` rather than silently deleting.
6. Preserve genuine conflicts in open loops. For registry-owned truth, submit an authorized proposal with current revision.
7. Distill a conclusion to HOT only when the user explicitly pins it; detail remains in WARM.
8. Archive by age/retention policy and report every changed path.

## Structural Checks

- HOT pointer without a source artifact or accepted registry record;
- broken Markdown links or nonexistent memory paths;
- orphan WARM artifacts that still matter but have no index/reference;
- audit summaries missing framework/profile/version/target/window;
- projections or human views whose offset/revision no longer matches replay;
- unresolved claim or consent references used as if approved.

## Guardrails

- Never edit `memory/events/*.ndjson` or `memory/projections/*.json` manually.
- Never let recency override a higher-authority or differently scoped fact.
- Never overwrite a user-approved decision; surface the conflict.
- Never hard-delete for tidiness. Destructive erasure follows the explicit privacy flow.
- Never copy a score into a new aggregate after stripping its profile/version/context.

The output is a diff summary: deduplicated notes, explicit supersessions, archived artifacts, proposals submitted, unresolved conflicts, broken links, and exact paths/event IDs.

# Memory Management Examples

---

## Example 1: Update Rankings for Hero Keywords

**User**: "Update rankings for our hero keywords"

```markdown
I'll update rankings for your hero keywords.
[Reads memory/hot-cache.md -> Hero Keywords section]
[If ~~SEO tool connected: runs automated ranking check]
[If manual: asks user for current rankings]

## Ranking Update - December 15, 2024

| Keyword | Previous | Current | Change | Target | Status |
|---------|----------|---------|--------|--------|--------|
| keyword research tools | #15 | #12 | up 3 | #5 | Improving |
| best seo software | #23 | #24 | down 1 | #10 | Stable |
| free backlink checker | #8 | #6 | up 2 | #3 | Near target |

### Updated Files
1. memory/hot-cache.md -> Hero Keywords table updated
2. memory/monitoring/rank-history/2024-12-15-ranks.csv -> New row added

### Recommendations
1. Push additional content/backlinks to "free backlink checker" to hit #3
2. Investigate "keyword research tools" +3 gain (replicate success)
3. Monitor "best seo software" for negative trends

Hot cache refreshed. Next ranking check: December 22, 2024.
```

---

## Example 2: Glossary Lookup

**User**: "What does 'quick wins' mean in our project?"

```markdown
[Check memory/hot-cache.md -> not found]
[Check memory/glossary.md -> found!]

**Quick Wins**
- **Definition**: Low-difficulty, high-value target keywords
- **Keyword Count**: 25
- **Context**: Keywords achievable for page 1 within 30-60 days due to low competition

Current list stored in: `memory/research/keywords/long-tail-keywords.md` (tagged "quick-win")
```

---

## Example 3: Initialize Memory for New Project

**User**: "Set up memory for a new e-commerce site selling outdoor gear"

```markdown
I'll set up the two-layer memory system.
[Creates: memory/glossary.md, memory/research/, memory/content/, memory/monitoring/, etc.]

To populate hot cache, I need:
1. **Target Keywords**: Top 10 hero keywords
2. **Primary Competitors**: Top 3-5 competitors
3. **Current Metrics**: DA, organic traffic, existing rankings
4. **Active Initiatives**: New categories, content campaigns, product focus
5. **Project Terminology**: Internal names, abbreviations, keyword segmentation

Once provided, I'll generate:
- memory/hot-cache.md, memory/glossary.md
- memory/research/keywords/ and memory/research/competitors/ structures
- memory/content/calendar/active-calendar.md
```

---

## Advanced Features

- **Smart Context Loading**: `Load full context for [campaign name]`
- **Memory Health Check**: `Run memory health check` — orphaned files, missing timestamps, stale items
- **Bulk Promotion/Demotion**: `Promote all keywords ranking in top 10 to hot cache`
- **Memory Snapshot**: `Create memory snapshot for [date/milestone]`
- **Cross-Project Memory**: `Compare memory with [other project]`

---

## Practical Limitations

- **Concurrent access**: Use timestamped filenames to avoid overwrites from parallel sessions.
- **Cold storage retrieval**: WARM/COLD files only load on demand. Hot cache is primary cross-session mechanism.
- **Data freshness**: Stale data (>90 days) should be flagged for refresh.

---

## Auditor Pointer Index Format

Append to `memory/indexes/audits/YYYY-MM.md`, newest at bottom:

```markdown
## 2026-07-10 · paid-search-q3 · ROAS/direct-response
- artifact: memory/audits/ad/2026-07-10-paid-search-q3.md
- artifact_sha256: <sha256 of the validated file>
- schema_version: 3.0
- runbook_version: 3.0.0
- observed_at: 2026-07-10
```

**Rules**:
- One pointer block per immutable audit artifact; do not copy scores, findings, vetoes, status, or verdict into the index.
- Verify the artifact with `validate-audit-artifact.py` before indexing it and retain framework/profile/version in the heading.
- Never place the index itself under `memory/audits/`; that namespace accepts only typed auditor artifacts.
- Attribution workbooks and other non-auditor reports remain in their discipline paths and may use separate pointer indexes without being represented as gate results.
- Subject erasure updates the working artifact and then refreshes its hash pointer. Record the operation separately in `memory/privacy/erasure-log.md`; never turn a privacy log into an audit artifact.
- If the monthly index does not exist, create it with `# Audit Artifact Index — YYYY-MM`.

---
name: gdpr-purge-log-template
description: Honest, minimal schema for memory/privacy/erasure-log.md entries — a human-readable record of erasure requests, not an auditor artifact or erasure proof.
type: reference
---

# Erasure Operation Log — `memory/privacy/erasure-log.md`

An append-only, human-readable record of every Art 17 / CCPA §1798.105 erasure request
handled by `memory-management`. It documents **what was requested and what the working tree
edit did** — it is NOT a cryptographic or audit-grade proof of complete erasure.

`memory/audits/` is reserved for the eight typed marketing gate artifacts. Privacy operations are
operational records with a different construct and therefore never share that namespace.

> **Read this first — scope honesty.** A purge edits the **working tree** only. If `memory/` is
> under version control, the subject still exists in git history; verify with
> `git log -S"<name>" -- memory/` and use `git filter-repo` for true history erasure (the user's
> responsibility, out of scope here). This log does not, and cannot, prove that the subject is gone
> everywhere. Do not present it as such to a data subject or auditor. There is no salted-fingerprint
> or reingest-blocking mechanism in the hooks; do not record fields that imply one exists.

## Entry schema

Append-only YAML list, newest at the bottom. One entry per purge. **Never store the raw subject** —
use a stable redacted label.

```yaml
- date: 2026-06-10                 # date the purge was run
  redacted_label: "Subject-A1B2"   # stable non-identifying label; NEVER the raw name
  legal_basis: art_17_request      # art_17_request | ccpa_1798.105 | proactive_minimization
  action: anonymize                # delete | anonymize
  scope:                           # working-tree files edited
    - memory/hot-cache.md
    - memory/entities/acme-corp.md
  files_modified: 9                # how many files were changed
  working_tree_only: true          # always true — git history is NOT touched by this flow
  note: "Replaced subject string with [REDACTED] across 14 lines. Advised user to run git filter-repo for history."
```

## Required fields

`date`, `redacted_label` (never raw), `legal_basis`, `action`, `scope`, `working_tree_only: true`.
Everything else is optional context. Keep `note` free of the raw subject name.

## Cross-references

- [memory-management SKILL.md §GDPR / Privacy Compliance](../SKILL.md) — purge procedure and its honest limitation
- [references/skill-contract.md](../../../references/skill-contract.md) — Write Paths table

# Glossary Template

Use this template to create the project glossary at memory/glossary.md.

```markdown
# [Project Name] - SEO Glossary
**Last Updated**: [Date]

## Brand Terms
| Term | Full Name | Context |
|------|-----------|---------|
| [abbreviation] | [full name] | [when/how used] |

## Product Names
| Internal Name | Public Name | Category |
|---------------|-------------|----------|
| [code name] | [market name] | [product type] |

## Custom Segments
| Segment Name | Definition | Keyword Count |
|--------------|------------|---------------|
| Hero KWs | Top 10 revenue-driving keywords | 10 |
| Quick Wins | Low-difficulty, high-value targets | 25 |
| Brand Defense | Brand + modifier combinations | 15 |

## Competitor Shorthand
| Shorthand | Full Domain | Notes |
|-----------|-------------|-------|
| Comp A | competitor-a.com | Main competitor, [industry] |

## Project Acronyms
| Acronym | Full Term | Definition |
|---------|-----------|------------|
| [ABC] | [Full term] | [project meaning] |

## Internal Jargon
| Phrase | Meaning | Example Usage |
|--------|---------|---------------|
| [phrase] | [definition] | "Check rankings for [phrase]" |

## Historical Context
- **Project started**: [Date]
- **Major algorithm updates**: [List with dates]
- **Site migrations/redesigns**: [List with dates]
- **Key milestones**: [List with dates]
```

# Hot cache template (`memory/hot-cache.md`)

Use this template when initializing memory for a new SEO project. The HOT tier is the single file `memory/hot-cache.md` (auto-loaded every session via the SessionStart hook, hard limit 80 lines / 25KB). Do NOT place this content in the project root's CLAUDE.md.

```markdown
# [Project Name] - SEO Memory (hot cache)
**Last Updated**: [Date] | **Project Status**: [Active/Maintenance/Growth]

## Active Target Keywords (Top 10-20)

### Hero Keywords (Priority 1)
| Keyword | Current Rank | Target Rank | Volume | Status |
|---------|--------------|-------------|--------|--------|
| [keyword 1] | #[X] | #[Y] | [vol] | [tracking/optimizing/achieved] |

### Secondary Keywords (Priority 2)
| Keyword | Current Rank | Target Rank | Volume | Status |
|---------|--------------|-------------|--------|--------|
| [keyword 1] | #[X] | #[Y] | [vol] | [tracking/optimizing/achieved] |

_Full keyword research: memory/research/keywords/_

## Primary Competitors (Top 3-5)
1. **[Competitor 1]** (DA: [X]) — Strengths: [brief] | Position: [ahead/behind/competitive]
2. **[Competitor 2]** (DA: [X]) — Strengths: [brief] | Position: [ahead/behind/competitive]

_Detailed analyses: memory/research/competitors/_

## Current Optimization Priorities
1. **[Priority 1]** — Status: [not started/in progress/completed] | Impact: [H/M/L] | Deadline: [date]
2. **[Priority 2]** — Status: [not started/in progress/completed] | Impact: [H/M/L] | Deadline: [date]

## Key Metrics Snapshot
**Last Metrics Update**: [Date]
| Metric | Current | Previous | Change | Target |
|--------|---------|----------|--------|--------|
| Organic Traffic | [X] | [X] | [+/-X%] | [target] |
| Avg. Position | [X] | [X] | [+/-X] | [target] |
| Page 1 Rankings | [X] | [X] | [+/-X] | [target] |
| Domain Authority | [X] | [X] | [+/-X] | [target] |
| CITE Score | [X] | [X] | [+/-X] | [target] |
| Last Audit Score | [score]/100 ([rating]) — [date] | [page] |
| Total Backlinks | [X] | [X] | [+/-X%] | [target] |

_Historical data: memory/monitoring/reports/ and memory/monitoring/rank-history/_

## Active Campaigns
### [Campaign Name 1]
- **Duration**: [Start] - [End] | **Goal**: [goal] | **Status**: [planning/active/completed] | **Progress**: [X]%
- **Key activities**: [brief list]

_Campaign plans and archives: memory/content/calendar/_

## Quick Reference Notes
- [Important note 1]
- [Important note 2]

_For project terminology, see: memory/glossary.md_
```

# Promotion and Demotion Rules

HOT promotion is an explicit user-authorized indexing decision, not an automatic consequence of score, veto, recency, frequency, or a hook.

## Promote to HOT

Promote only a current conclusion needed across sessions, such as an approved priority, active safety block, or high-value pointer. The entry:

- is three lines or fewer;
- records `last_updated` and the permission/decision reference;
- links to an accepted registry record or dated WARM artifact;
- contains no raw personal data, credential, or large dataset.

Auditors and registry owners do not receive an automatic HOT exception.

## Demote

- Review HOT entries older than 30 days; move the detail back to its WARM source and remove stale pointers after permission.
- Review WARM artifacts older than 90 days for COLD archival, subject to retention/legal hold.
- Preserve original path, content hash, and source links in archive metadata.
- Registry events/projections and live consent suppression never participate in HOT/WARM/COLD demotion.

## Supersede

For comparable non-canonical notes, mark the older note `superseded_by: <artifact/date>` and keep both until normal retention. If unit, window, denominator, source meaning, or authority differs, preserve both and open a conflict.

Registry facts change only through the owner event protocol with current revision. Working-memory consolidation may submit a proposal but may not edit the stream, projection, or generated human view.

# Update Triggers and Cross-Skill Integration

These are permission-aware working-memory routines. They never grant standing write authority and never bypass a registry owner.

## Common Sequence

1. Finish the user-facing result and label evidence/source dates.
2. If persistence is authorized, save the smallest useful WARM artifact in the producing skill's path.
3. For durable truth, submit one idempotent `operation: propose` event per aggregate to the owning registry with current `expected_revision`.
4. Do not write HOT unless the user explicitly pins a conclusion.
5. Do not publish, send, upload, spend, or delete as part of a memory update.

## Trigger Table

| Trigger | WARM action | Registry action | Safety note |
|---|---|---|---|
| Ranking/competitor read | Save dated research/monitoring artifact | Entity proposal only for durable identity facts | A movement threshold is a review cue, not automatic promotion |
| Content/ad/email/social build | Save versioned asset/handoff | Claims/Narrative/channel proposals as needed | Preserve `[needs source]`; no external execution |
| Influencer campaign close | Save closed-cycle analysis | Creator proposals for rate/rights/outcomes | Minimize personal data; no reputation label |
| Paid readback | Save normalized window and truth-set reconciliation | Claim/offer proposal when state changed | No automatic budget action |
| Email suppression event | Save no duplicate contact data | Direct consent `suppress`, then replay check | Never queue withdrawal as a proposal |
| Launch T-0 observation | Save incident/runbook evidence | Launch proposal per timestamped fact | Registry resolves in offset order; no stream clearing |
| Narrative change | Save authored draft/test evidence | Complete-canon proposal, not partial patch | Claims remain separate pointers |
| Auditor gate | Present result; save only when authorized | No registry mutation | v3 artifact validator required; no automatic HOT write |

## Archive Management

### Monthly

- Review HOT pointers older than 30 days and demote when no longer current.
- Review WARM artifacts older than 90 days and archive with original path/content hash metadata.
- Run the consolidation pass for duplicates, explicit supersession, broken links, and unsupported summaries.
- Do not archive or compress registry streams/projections through the temperature lifecycle.

### Quarterly

- Review COLD retention and legal-hold requirements.
- Link milestone summaries to source artifacts rather than copying scores/facts without context.
- Verify all seven registry streams and rebuild projections when needed.
- Review consent suppression by replay before any reactivation workflow.

## Integration Boundaries

| Role | Allowed persistent action |
|---|---|
| Ordinary execution skill | Own WARM artifact plus authorized proposal events |
| Auditor gate | Own validator-clean audit artifact after permission |
| Registry owner | Accept/reject/upsert/transition its registry through runtime |
| `memory-management` | HOT/WARM/COLD lifecycle and authorized tombstone/erase |

Monthly indexes may reference audit artifact IDs but must not synthesize a cross-framework score. Registry projections and human views always expose the source offset/revision.