/lore

Knowledge Synthesis — Pattern Extraction Methodology

Purpose: Read this file when harvesting journals, clustering similar insights, deduplicating candidates, resolving contradictions, or producing the Lore synthesis report.

Contents

• Harvest protocol
• Clustering algorithm
• Relationship tracking
• Deduplication protocol
• Confidence scoring
• Contradiction resolution
• Synthesis report output

How Lore harvests, clusters, deduplicates, and scores patterns from agent journals.

Harvest Protocol

Source Priority

Extraction Rules

1. Read the full journal entry — never extract from partial context
2. Identify the core insight — what was learned that is generalizable?
3. Extract supporting evidence — dates, metrics, outcomes
4. Note the context — project type, technology stack, scale
5. Check for prior art — does this reinforce or contradict existing patterns?

Clustering Algorithm

Step 1: Semantic Grouping

Group extracted insights by similarity:

For each new insight:
  1. Compare against existing METAPATTERNS entries
  2. Calculate semantic similarity (topic + domain + outcome)
  3. If similarity ≥ 80%: cluster with existing pattern
  4. If similarity 50-79%: flag as potential variant
  5. If similarity < 50%: mark as new candidate

Step 2: Cross-Agent Correlation

Look for the same insight appearing across multiple agents:

Step 3: Temporal Analysis

Track pattern evolution over time:

• Emerging: First appeared recently, limited evidence
• Growing: Evidence increasing, appearing in more contexts
• Stable: Consistent evidence over extended period
• Declining: Evidence frequency dropping, may be becoming obsolete

Relationship Tracking

Patterns stored as flat entries miss deeper insights. Explicit inter-pattern links improve contradiction detection, reveal systemic issues, and surface emergent knowledge.

2026 Memory-Architecture Framing

Recent surveys formalise agent memory as a write → manage → read loop and group implementations into five mechanism families. Lore is opinionated about which family does the work at which phase:

The lifecycle separates into Formation → Evolution → Retrieval. Harvest + Clustering populate Formation; Confidence Scoring + Contradiction Resolution + Decay Detection drive Evolution; Propagation owns Retrieval. Skipping any phase produces the same failure mode the surveys document: shallow snapshots that look healthy structurally but cannot inform agent behaviour.

Link Types

Relationship Maintenance Protocol

1. On registration: When adding a new pattern, scan existing patterns in the same domain for potential links. Check cross-domain patterns with similarity ≥ 60%.
2. On reinforcement: When updating evidence, check if the new evidence also reinforces or contradicts linked patterns.
3. On contradiction detection: Automatically create a →contradicts→ link between the conflicting patterns.
4. On archival: When archiving a pattern, review its links — if a →generalizes→ target is archived, check if the specialized pattern should also be flagged.

Recording Links in METAPATTERNS.md

Extend the existing **Related:** field with typed links:

**Related:**
- →reinforces→ INFRA-HEURISTIC-007 (rolling restart effectiveness)
- →contradicts→ APP-SUCCESS-012 (when scale > 10k RPS)
- →specializes→ APP-ANTI-009 (security-specific case)

Relationship-Driven Insights

During synthesis, actively look for:

• Contradiction clusters: 3+ patterns with mutual →contradicts→ links indicate a domain with unclear best practices — escalate to Architect
• Reinforcement chains: A→B→C reinforcement chains indicate foundational knowledge — consider promoting the root pattern
• Orphan patterns: Patterns with zero relationships after 90 days may be too narrow or poorly classified

Deduplication Protocol

Before registering a new pattern, check:

Merge Rules

When merging insights into an existing pattern:

1. Preserve all unique evidence instances
2. Update confidence level based on new evidence count
3. Expand consumer list if new agents are relevant
4. Update last_validated timestamp
5. Note any new context (project type, scale, etc.)

Confidence Scoring

Evidence-Based Scoring

Confidence Modifiers

Promotion Criteria

A pattern is promoted to the next confidence level when:

1. New evidence instance from a different context (not just same project repeated)
2. No active contradictions at time of promotion
3. Last evidence instance is within 90 days (freshness requirement)

Contradiction Resolution

When conflicting insights are discovered:

Resolution Protocol

1. Document both sides — preserve both perspectives with full evidence
2. Identify the variable — what differs between contexts? (scale, domain, tech stack)
3. Classify the contradiction:
   • Context-dependent: Both are correct in their respective contexts → Create conditional pattern
   • Temporal: Older insight superseded by newer knowledge → Archive old, promote new
   • Genuine conflict: Fundamentally incompatible → Escalate to relevant domain agents
4. Register resolution with reasoning in pattern entry

Conditional Pattern Format

**Pattern:** [Description]
**When [context A]:** [Approach A] — Evidence: [sources]
**When [context B]:** [Approach B] — Evidence: [sources]
**Deciding factor:** [What determines which context applies]

Output: Synthesis Report

After each synthesis cycle, produce:

## Lore Synthesis Report — [YYYY-MM-DD]

### Journals Scanned
| Agent | Entries Processed | New Insights | Updated Patterns |
|-------|-------------------|-------------|------------------|

### New Patterns Registered
| Pattern ID | Title | Confidence | Consumers |
|------------|-------|------------|-----------|

### Patterns Reinforced
| Pattern ID | Previous Confidence | New Confidence | New Evidence |
|------------|--------------------|----|------|

### Contradictions Detected
| Pattern ID | Conflicting Source | Resolution Status |
|------------|-------------------|-------------------|

### Decay Alerts
| Pattern ID | State | Days Since Last Evidence | Recommended Action |
|------------|-------|------------------------|-------------------|

Architecture Sub-Graph, Concept Audit, and Write Authority (SKILL.md excerpt)

• Architecture node/edge type catalog (v5 fold-in, extended v6): knowledge_graph_enrichment supports an Architecture sub-graph with the following node types — service, module, api, event, database, table, queue, cloud_resource, user_journey, persona, policy, adr, runbook, dashboard, alert, owner, slo, plus ops-extension nodes (v6): secret, config, feature_flag, environment, cluster, iam_role, vulnerability, metric, terraform_resource, kubernetes_object, container_image — and edge types — calls, publishes, subscribes, owns, stores, reads, writes, depends_on, governed_by, documented_by, monitored_by, decided_by, plus ops-extension edges (v6): reads_secret, exposes_data, has_vulnerability, scaled_by, rolled_back_by, deployed_to. This is the local equivalent of both the "Architecture Knowledge Graph" and the "Ops Knowledge Graph" concepts; both live as a single unified sub-graph within METAPATTERNS.md and the existing knowledge graph, NOT as separate centralized "Living Architecture Twin" or "Ops Twin" Single Source of Truth (the Twin Tyranny anti-pattern — omen v5 FM-V-7 RPN 1080, omen v6 FM-5 RPN 640). The ops-extension nodes/edges are intentionally absorbed into the same Architecture sub-graph to prevent dual-source-of-truth drift between architecture KG and a separate ops KG.

• Concept consistency audit (v7 fold-in, advisory only): Architecture sub-graph supports a concept node sub-type representing key product/domain concepts (e.g. active_user, retention, engagement) with definition, boundary (included/excluded), metric_ref, aliases, category fields. concept_consistency_audit capability detects category errors (concept used inconsistently across journals / docs / METAPATTERNS), naming collisions, and orphan concepts (defined but unreferenced). Advisory only — never blocks merge; flags drift for human review per G11 KB Write Authority Separation (AI proposes, Architect/Research Lead merges). Polysemy is preserved: when one concept legitimately has multiple definitions per audience (e.g. Marketing-active_user vs Product-active_user), the audit records the legitimate variants rather than forcing canonicity (anti-pattern: Concept Graph false canonicity, omen v7 FM-V7-12 RPN 280). Absorbs "Concept Proof / Concept Graph" intent (Reflective Decision OS proposal v7) into existing knowledge graph without creating a parallel SoT.

• G11 KB Write Authority Separation applies to Architecture sub-graph: AI agents are read-only; Architecture node/edge mutations require human Architecture Lead merge (Architect skill). Confidence and freshness fields are deterministic-computed, never hand-set. AI proposed edits go to a queue. The Architecture sub-graph is advisory — when divergence with reality codebase is detected, reality wins; the sub-graph is updated to match reality, never the reverse. See _common/PROOF_CARRYING.md v3 G11 and the Twin Tyranny anti-pattern.