feat: scalable entities & patterns architecture
- Entity format: 3-line compact registry (### Name / key facts / status+links) Heavy entries promoted to thread files. Cross-domain pointers for shared entities. - Pattern satellites: core patterns.md cap reduced from 110→70 lines (5.5KB). Domain-specific patterns go in satellite files loaded only by owning skill. - Reflect: pattern routing rules, entity format enforcement (step 3b) - Housekeeping: entity registry enforcement (step 5b), glacier inactive entities - Evolve: scorecard metrics for pattern distribution + entity compression ratio - README: updated entity example to 3-line format Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -20,6 +20,7 @@ Architecture reference:
|
||||
Measure (don't edit content):
|
||||
- `memory/hot-memory.md`
|
||||
- `memory/cog-meta/patterns.md`
|
||||
- Any domain satellite pattern files (e.g. `work/*/patterns.md`)
|
||||
|
||||
## Process
|
||||
|
||||
@@ -40,11 +41,19 @@ Review the output of recent housekeeping and reflect runs:
|
||||
- Did pruning priority order work? Or did it trim wrong things?
|
||||
- Are glacier thresholds (50 obs, 10 action items) right?
|
||||
- Is the 50-line hot-memory cap appropriate?
|
||||
- Is entity format enforcement catching violations?
|
||||
|
||||
**Reflect rules check:**
|
||||
- Did condensation produce useful patterns, or noise?
|
||||
- Did thread candidate detection work?
|
||||
- Is reflect staying in its lane?
|
||||
- Are patterns routing to the right file (core vs satellite)?
|
||||
|
||||
**Scorecard metrics** — measure and record in evolve-log:
|
||||
- Core `patterns.md`: line count / 70, byte size / 5.5KB (target: ≤1.0)
|
||||
- Satellite pattern files: list each with line count (soft cap: 30)
|
||||
- Entity compression ratio: `(total entity lines across all files) / (total ### entries)` (target: ≤3.0)
|
||||
- Hot-memory line counts vs caps
|
||||
|
||||
### 3. Rule Change Proposals
|
||||
|
||||
|
||||
@@ -64,7 +64,15 @@ For each non-glacier memory file:
|
||||
|
||||
Only add links where the reference is substantive.
|
||||
|
||||
## 5b. Temporal Fact Maintenance
|
||||
## 5b. Entity Registry Format Enforcement
|
||||
|
||||
Scan all `entities.md` files for registry format compliance:
|
||||
|
||||
1. **3-line max**: Any `### entry` with >3 content lines should be compressed. If the entry has an associated detail file (`→ [[link]]`), compress to: name/relationship, pipe-separated key facts, status+link. If no detail file exists and entry is >5 lines, flag as a promotion candidate (suggest creating a thread file).
|
||||
2. **Glacier candidates**: Entries with `status: inactive` or `last:` date >6 months ago → move to `glacier/{domain}/entities-inactive.md` (leave a stub with archived comment).
|
||||
3. **Missing metadata**: Flag entries missing `status:` or `last:` fields.
|
||||
|
||||
## 5c. Temporal Fact Maintenance
|
||||
|
||||
Scan all `entities.md` files for `(until YYYY-MM)` markers with past dates:
|
||||
1. If the line has no ~~strikethrough~~, add it
|
||||
|
||||
@@ -74,18 +74,31 @@ Check if findings are already captured:
|
||||
- Distill into a pattern and add/update in `memory/cog-meta/patterns.md` (or domain `patterns.md` if domain-specific)
|
||||
- Don't delete the observations — they stay as the raw record
|
||||
|
||||
**patterns.md size cap — HARD LIMIT: 110 lines / 7KB.** After any updates, check the file size. If it exceeds the cap:
|
||||
**Core patterns.md size cap — HARD LIMIT: 70 lines / 5.5KB.** After any updates, check the file size. If it exceeds the cap:
|
||||
1. Compress multi-line entries to single lines
|
||||
2. Merge entries with overlapping lessons
|
||||
3. Remove point-in-time data: counts with date ranges, incident tallies with specific dates
|
||||
4. Entries must be **timeless rules** — "what to do" not "what happened"
|
||||
5. Move domain-specific patterns to satellite files (e.g. `work/acme/patterns.md`) — only universal rules stay in core
|
||||
|
||||
**Pattern routing** — when adding a new pattern, decide where it belongs:
|
||||
- **Core** (`cog-meta/patterns.md`) — universal rules that apply every conversation
|
||||
- **Domain satellite** (`{domain}/patterns.md`) — rules specific to one domain, loaded only by that skill
|
||||
- Satellite files have a soft cap of 30 lines each
|
||||
|
||||
**Hot-memory relevance** — Review all `hot-memory.md` files:
|
||||
- **Promote**: If a pattern is heating up → add to appropriate `hot-memory.md`
|
||||
- **Demote**: If a hot-memory item has gone quiet (no references in 2+ weeks) → remove from hot-memory
|
||||
- **Goal**: hot-memory = what matters *right now*
|
||||
|
||||
### 3b. Detect Thread Candidates
|
||||
### 3b. Entity Registry Format Enforcement
|
||||
|
||||
Scan all `entities.md` files for format compliance:
|
||||
1. **3-line check**: Any `### entry` with >3 content lines → compress. If the entry has a detail file (`→ [[link]]`), trim to: name line, key facts, status/link. If no detail file exists but entry is >5 lines, flag as a promotion candidate for a thread file.
|
||||
2. **Status/last fields**: Every entry should have `status: active|inactive` and `last: YYYY-MM-DD`. Scan recent session transcripts to update `last:` dates for mentioned entities.
|
||||
3. **Cross-domain pointers**: If the same person appears in multiple entity files, ensure one is canonical (full entry) and others are pointers (`see [[link]]`).
|
||||
|
||||
### 3c. Detect Thread Candidates
|
||||
|
||||
Scan observations for topics that appear across 3+ dates or span 2+ weeks. These are thread candidates.
|
||||
|
||||
@@ -94,7 +107,7 @@ For each candidate:
|
||||
- If not, note it as a suggestion: "Thread candidate: [topic] — [N] fragments across [date range]"
|
||||
- Don't auto-create threads — suggest them
|
||||
|
||||
### 3c. Scenario Feedback Loop
|
||||
### 3d. Scenario Feedback Loop
|
||||
|
||||
Scan `memory/cog-meta/scenarios/` for active scenario files.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user