Ontological Topic Enrichment & Web-Searched Knowledge Engine

---

---

Architecture Specification & Implementation Guide
A Systematic Pipeline for Discovering Graph Topics, Triggering Contextual Web Research, Extracting Authoritative Best Practices, and Grounding Synthesized Knowledge back into the Second Brain Graph.

---

1. Executive Summary & Architectural Thesis

1.1 The Static Knowledge Graph Paradox

Traditional personal and enterprise knowledge graphs suffer from an inherent decay problem: they record internal decisions (such as Architecture Decision Records, User Stories, and sprint logs) but remain epistemically insulated from external industry consensus, evolving standards, and authoritative best practices.

When nodes declare metadata topics (such as topics: [Data Governance, Aspect-Based Sentiment Analysis, Row-Level Security, Token Bucket]), these topics frequently remain:

1. Un-elaborated Stubs: Free-text keywords without formal definitions or operational depth.

2. Disconnected from Standards: Unanchored to established frameworks like DAMA-DMBOK, TOGAF, ISO/IEC 25010, NIST, or OWASP.

3. Prone to Semantic Drift: Isolated from state-of-the-art technological and architectural advancements.

1.2 The Core Thesis: "System of Record" meets "System of Intelligence"

Integrating automated web research into an ontology-governed knowledge graph bridges this gap. In accordance with Andrej Karpathy's Compiled LLM Wiki Pattern and modern Bidirectional GraphRAG architectures:

• The Knowledge Graph & Ontology serve as the System of Record: They provide deterministic boundary rules, taxonomy trees, entity types, and relational constraints (ONTOLOGY.json, PROJECT-MANAGEMENT-ONTOLOGY.json).

• Web Search & Large Language Models serve as the System of Intelligence: They act as active knowledge researchers that discover external empirical consensus, state-of-the-art production architectures, and authoritative best practices.

flowchart TD
    subgraph Graph_Layer ["Graph & Ontology Layer (System of Record)"]
        KG[Knowledge Graph & MOCs] --> |Identify Candidate Topics| TE[Topic Discovery Engine]
        Schema[ONTOLOGY.json / DMBOK] --> |Constraint Filter| Ground[Dual-Validation Engine]
    end

    subgraph Intelligence_Layer ["Research & Web Search Layer (System of Intelligence)"]
        TE --> |Disambiguated Context| QG[Query Formulation Engine]
        QG --> |Structured Queries| Search[Multi-Provider Web Search]
        Search --> |HTML / Text / Snippets| Clean[Content Hygiene & Authority Filter]
        Clean --> |Curated Evidence| Synth[LLM Synthesis & Best-Practice Extractor]
    end

    Synth --> Ground
    Ground --> |Validated Atomic Concept Note| Write[Atomic Note Compiler]
    Ground --> |Typed Relational Edges| Link[Bidirectional Graph Linker]
    Write --> KG
    Link --> KG

---

2. The 6-Stage Ontological Enrichment Pipeline

To enrich graph topics safely without hallucination, pollution, or semantic drift, the enrichment engine operates across six deterministic stages:

sequenceDiagram
    autonumber
    participant KG as Knowledge Graph / Vault
    participant Discov as 1. Topic Discovery
    participant Query as 2. Query Formulation
    participant Web as 3. Web Retrieval & Filter
    participant Synth as 4. Cognitive Synthesis
    participant Valid as 5. Ontological Validation
    participant Ingest as 6. Graph Ingestion & Linking

    KG->>Discov: Scan Frontmatter, MOCs & Link Centrality
    Discov-->>Query: Candidate Topics + Neighborhood Context
    Query->>Web: Targeted Query Facets (Definition, Standards, Best Practices, Gotchas)
    Web-->>Synth: Filtered & Scored Source Evidence (Markdown/Snippets)
    Synth->>Valid: Structured Concept Extraction Draft (JSON/YAML)
    Valid->>Valid: Check Schema Constraints (ONTOLOGY.json / Allowed Keys)
    Valid->>Valid: Check Vault Conflicts & Decision Inversions (ADRs)
    Valid-->>Ingest: Approved Enriched Entity Payload
    Ingest->>KG: Write Atomic Concept Note in wiki/Concepts/
    Ingest->>KG: Update MOC Hubs & Frontmatter Topics
    Ingest->>KG: Inject Typed Backlinks & Semantic Triples

---

Stage 1: Topic Discovery & Graph Candidate Selection

The ontology cannot blindly query the web for every noun in the vault. Doing so leads to API quota exhaustion, context bloat, and noise. Instead, candidate topics are prioritized via graph-theoretic metrics and structural gap analysis:

1. Frontmatter Metadata Analysis

Nodes throughout the vault declare topics in their YAML frontmatter (e.g., topics: [data_governance, schema, rate_limits]). The discovery engine scans:

• Untracked topics that do not yet have a corresponding canonical page in wiki/Projects/SocialEngage/06 Synthesis & Lessons Learned/ or wiki/System/.

• Stub pages where word_count < 250 or authority_level < 2.

2. Graph Centrality & Gap Metrics

• Degree & Betweenness Centrality: Topics that bridge multiple independent domains (e.g., Rate Limiting connecting Ingestion Connectors and Security & Multi-Tenancy) receive the highest enrichment priority.

• MOC Inclusion without Node Representation: Topics referenced in Map of Content hubs (e.g., MOC - DMBOK - Data Governance.md) that lack dedicated conceptual synthesis are flagged as Priority 1 Structural Voids.

• Semantic Drift Warnings: Nodes flagged by semantic drift evaluators (e.g., ADR-0116: Semantic Drift Detection) trigger re-enrichment to verify whether external definitions have evolved.

Discovery Selection Matrix

Selection Criteria	Trigger Condition	Enrichment Priority	Action
MOC Stub	Referenced in MOC hub; no file in vault	P1 (Immediate)	Full web research + Atomic note creation
High Centrality Topic	Referenced across \(\ge 5\) ADRs/FDDs; shallow body	P1 (Immediate)	Best practices + Architecture patterns
Domain Framework Void	DMBOK / BABOK / PMBOK category without deep note	P2 (Scheduled)	Standards alignment + Metrics extraction
Explicit User Request	User or agent triggers research on draft	P0 (Real-Time)	Focused context comparison & summary

---

Stage 2: Intent-Driven & Ontologically-Grounded Query Formulation

Naive web searches (such as "Data Governance") return generic, marketing-heavy, or non-actionable results. The query formulation engine uses the graph neighborhood to build disambiguated, multi-perspective query facets.

1. Graph Neighborhood Disambiguation

Every query is contextualized with its immediate graph ancestors:

• Target Topic: Token Bucket

• Parent Domain Cluster: Ingestion, Connectors & Rate Limits

• Connected Architecture Decisions: ADR-0044: Rate Limiting & Distributed Redis State

• Framework Mapping: DMBOK: Data Operations / PMBOK: Quality Management

Disambiguated Query Target: Prevents confusing a "Token Bucket" in network traffic shaping with token usage in LLM prompt billing.

2. The 5 Ontological Query Facets

For each prioritized topic, the engine compiles a structured search battery across five distinct inquiry dimensions:

graph LR
    Topic["Candidate Topic<br/>(e.g., Data Governance)"] --> Q1["1. Definitional & Taxonomical<br/>(Core Tenets & Conceptual Boundaries)"]
    Topic --> Q2["2. Industry Best Practices<br/>(Production Architecture & Modern Patterns)"]
    Topic --> Q3["3. Standards & Benchmarks<br/>(DMBOK, TOGAF, ISO, NIST Alignment)"]
    Topic --> Q4["4. Failure Modes & Gotchas<br/>(Anti-Patterns & Operational Pitfalls)"]
    Topic --> Q5["5. Quantitative Metrics & KPIs<br/>(SLOs, SLAs, Measurement Models)"]

1. Definitional & Taxonomical:

   • "[Topic]" definition architecture ontology core-principles

2. Industry Best Practices & Modern Production Patterns:

   • "[Topic]" "best practices" production architecture 2025 OR 2026 enterprise

3. Standard Reference Frameworks & Benchmarks:

   • "[Topic]" ("DMBOK" OR "TOGAF" OR "NIST" OR "ISO") implementation standard

4. Anti-Patterns & Known Failure Modes:

   • "[Topic]" "anti-patterns" "common pitfalls" "failures" postmortem

5. Quantitative KPIs, SLOs & Metrics:

   • "[Topic]" key metrics KPIs measurement SLO operational benchmarks

---

Stage 3: Multi-Provider Web Retrieval & Source Authority Scoring

1. Search Provider Orchestration

The engine abstracts web search through pluggable providers, mirroring the vault's architectural standards (ADR-0076: Composer Deep Research Agent):

• Brave Search API: Fast, privacy-preserving web and news search.

• Bing Search API: Enterprise-grade indexing with broad technical coverage.

• Specialized Repositories: ArXiv, OpenAlex, Semantic Scholar (for algorithmic/theoretical depth), and GitHub/W3C/IETF RFCs (for protocol standards).

2. Authority Scoring Algorithm

Not all web pages are equal. The engine passes raw URLs through a domain reputation filter:

$$\text{Authority Score} (S) = w_{\text{tier}} + w_{\text{freshness}} + w_{\text{structure}}$$

pie title Authority Tier Weighting
    "Tier 1: Standards Bodies & Official Docs (DAMA, NIST, W3C, AWS Architecture)" : 50
    "Tier 2: Peer-Reviewed Papers & Established Engineers (Fowler, IEEE, ACM)" : 30
    "Tier 3: Verified Technical Media (InfoQ, Towards Data Science, The New Stack)" : 15
    "Tier 4: General Web / Unverified Blogs (Filtered out if < Threshold)" : 5

• Tier 1 (Score 0.9–1.0): Formal standards bodies (dama.org, nist.gov, iso.org, w3.org, ietf.org), official vendor architecture centers (AWS Architecture Center, Microsoft Learn, Google Cloud Architecture).

• Tier 2 (Score 0.75–0.89): Recognized industry authorities (Martin Fowler, High Scalability, ACM, IEEE), official open-source documentation.

• Tier 3 (Score 0.60–0.74): Verified engineering blogs (Uber Engineering, Netflix TechBlog, Stripe Engineering, InfoQ).

• Disqualified (< 0.50): SEO content farms, AI-generated spam, unverified forums.

3. Scraping Hygiene & Token Budgeting

• Strip JavaScript, headers, footers, and advertisement DOM trees using readability heuristics.

• Convert sanitized HTML to clean GitHub-Flavored Markdown.

• Apply sliding-window snippet extraction focused on semantic density (discarding generic marketing introductions).

---

Stage 4: Cognitive Synthesis & Dual-Validation Grounding

The synthesized output must never be arbitrary free-form text. It must conform directly to the vault's formal schema (ONTOLOGY.json).

1. Structured Schema Extraction Prompting

The LLM receives the source evidence and is bound by a strict JSON/YAML extraction contract:

topic_name: "Data Governance"
canonical_definition: "A system of decision rights and accountabilities for information-related processes..."
taxonomy:
  upper_class: "GovernanceArtifact"
  domain_cluster: "Project Governance & Management"
  framework_mappings:
    dmbok_category: "Data Governance"
    pmbok_category: "Integration Management"
    babok_category: "Business Analysis Planning & Monitoring"
best_practices:
  - id: "BP-01"
    principle: "Federated Stewardship with Centralized Policy"
    description: "Decouple policy definition from operational domain execution..."
    evidence_source: "https://www.dama.org/dmbok"
  - id: "BP-02"
    principle: "Automated Metadata Ingestion over Manual Logging"
    description: "Embed data catalog registration into CI/CD pipelines..."
    evidence_source: "https://martinfowler.com/articles/data-mesh-principles.html"
anti_patterns:
  - id: "AP-01"
    name: "Bureaucracy Bottleneck"
    description: "Requiring committee approval for minor schema changes stalls engineering velocity."
metrics_and_kpis:
  - name: "Data Asset Coverage"
    target: ">= 95% of production tables cataloged"
  - name: "Metadata Freshness"
    target: "< 24h lag from schema migration"
local_vault_relevance:
  impacts_adrs: ["ADR-0010", "ADR-0027", "ADR-0122"]
  impacts_fdds: ["FDD-0017", "FDD-0080"]

2. The Dual-Validation Guardrails

Before writing to the vault, two automated validation checks execute:

1. Structural Validation (Shape Conformance): Verifies that all frontmatter keys, arrays, and types match ONTOLOGY.json's allowedKeys and required fields.

2. Logical Validation (Decision Inversion Check): Compares extracted best practices against the vault's accepted Architecture Decision Records.

   • Example Conflict: An external best practice states "Store all session state in a centralized multi-tenant Redis cluster." The vault has accepted ADR-0027: Zero-Intermediation Tenant Credential Storage.

   • Engine Resolution: The conflict is detected, flagged with an Obsidian > [!WARNING] callout, and documented under ## Deviations & Internal Project Rationales rather than overwriting internal project constraints.

---

Stage 5: Graph Ingestion, Atomic Note Generation & Linking

Once validated, the research is permanently crystallized into the Second Brain graph:

1. Atomic Concept Note Generation

A new Markdown note is created in wiki/Projects/SocialEngage/06 Synthesis & Lessons Learned/ (or wiki/System/) following the exact vault standard:

• Canonical frontmatter with generated entity_id (MD5 hash of slug), artifact_id, type: "concept", and multi-taxonomy placement.

• Synthesized sections: Definition, Core Principles, Enterprise Framework Alignment, Production Best Practices, Anti-Patterns, Concrete Metrics, and Internal Traceability.

2. MOC Hub Expansion & Index Synchronization

The relevant Map of Content hubs (e.g., wiki/_MOCs/MOC - DMBOK - Data Governance.md and wiki/_MOCs/MOC - AI, NLP & Semantic Enrichment.md) are updated:

• The new concept node is linked under ## Enriched Concepts & Deep Research Topics.

• Outgoing and backlink counters are recalculated.

3. Bidirectional Relational Linking

The engine creates typed wikilinks to relevant project artifacts using the authorized verbs from ONTOLOGY.json:

• [[ADR-0076]] groundedIn [[Ontological-Topic-Enrichment-and-Web-Research-Engine]]

• [[Data-Governance]] influences [[Business-Case-v6.0]]

• [[Data-Governance]] compliesWith [[MOC - DAMA-DMBOK Master Hub]]

---

Stage 6: Lifecycle Maintenance, Self-Healing & Drift Protection

Knowledge enrichment is not a one-time script; it is a continuous maintenance loop.

1. Integration with the Brain Heal Orchestrator

The vault's maintenance orchestrator (node socialengage/scripts/heal-obsidian-brain.mjs) is extended with an enrichment audit pass:

• Scan: Discovers newly added user stories or ADRs containing un-enriched topics.

• Queue: Writes pending topic candidates to raw/enrichment-queue.json.

• Audit: Detects broken wikilinks or stale enrichment timestamps (> 90 days old).

2. Authority Gating & Human-in-the-Loop Overrides

In accordance with ADPA/ECS governance:

• Authority Level 1 (Machine Generated / Proposed): Newly enriched topics are marked with confidence_score: 0.85 and authority_level: 1. They are visible in Dataview queries with an #unverified-research tag.

• Authority Level 2 (Human Reviewed & Approved): Once the lead architect reviews and confirms the note, frontmatter is updated to authority_level: 2, elevating it to an authoritative project benchmark.

---

3. Comprehensive End-to-End Walkthrough: "Data Governance"

To demonstrate the full execution of the pipeline, consider the topic Data Governance (as identified in wiki/_MOCs/MOC - DMBOK - Data Governance.md):

graph TD
    subgraph Step1 ["1. Graph Discovery"]
        MOC["MOC - DMBOK - Data Governance.md<br/>(283 backlinks, topics: [pages, referenced])"]
        Gap["Observation: High backlink density, but lacks an atomic Concept note synthesizing operational best practices."]
        MOC --> Gap
    end

    subgraph Step2 ["2. Query Formulation"]
        Q["Battery of 5 Targeted Queries:<br/>1. 'Data Governance definition DMBOK2 framework core tenets'<br/>2. 'Enterprise Data Governance best practices 2025 2026 production'<br/>3. 'Data Governance anti-patterns bureaucratic bottleneck'<br/>4. 'Data Governance KPIs metrics data catalog coverage'<br/>5. 'Federated data governance data mesh steward model'"]
    end

    subgraph Step3 ["3. Web Search & Scraping"]
        SearchRes["Brave/Bing Search Dispatched<br/>Filtered Domains: dama.org, martinfowler.com, nist.gov, datamesh-architecture.com<br/>Extracted 8 high-density text snippets + citations"]
    end

    subgraph Step4 ["4. Cognitive Synthesis & Validation"]
        SynthNode["Structured Extraction:<br/>- DMBOK 11 Knowledge Area Anchor<br/>- 4 Core Best Practices<br/>- 3 Critical Anti-Patterns<br/>- 4 Quantitative Operational KPIs<br/>- Cross-reference with ADR-0010, ADR-0027, ADR-0122"]
    end

    subgraph Step5 ["5. Graph Ingestion & Recompilation"]
        Note["wiki/.../06 Synthesis/Concept-Data-Governance.md"]
        UpdateMOC["wiki/_MOCs/MOC - DMBOK - Data Governance.md updated with wikilink"]
        Triples["Bidirectional edges wired into Dataview graph"]
    end

    Gap --> Q
    Q --> SearchRes
    SearchRes --> SynthNode
    SynthNode --> Note
    Note --> UpdateMOC
    Note --> Triples

The Resulting Enriched Note Layout

When compiled, the resulting atomic note in the vault provides complete, actionable reference knowledge:

---
title: "Concept: Data Governance (DMBOK-Aligned Framework)"
artifact_id: "Concept-Data-Governance"
entity_id: "7b4c91e0a8d3e2f1c5a6b7c8d9e0f1a2"
version: "1.0.0"
type: "concept"
pm_class: "DomainKnowledge"
pm_subclass: "Concept"
pm_relationships:
  - influences
  - groundedIn
  - compliesWith
domain_cluster: "Project Governance & Management"
dmbok_category: "Data Governance"
pmbok_category: "Integration Management"
babok_category: "Business Analysis Planning & Monitoring"
status: "Active"
authority_level: 2
confidence_score: 0.98
source_urls:
  - "https://www.dama.org/cpages/body-of-knowledge"
  - "https://martinfowler.com/articles/data-mesh-principles.html"
  - "https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final"
tags:
  - concept
  - data-governance
  - dmbok
  - best-practices
---

# Concept: Data Governance

## 1. Ontological Definition & Purpose
Data Governance is the exercise of authority and control (planning, monitoring, and enforcement) over the management of data assets. Under DAMA-DMBOK2, it serves as the foundational wheel center connecting all other 10 data management disciplines.

## 2. Industry Best Practices (Synthesized 2025/2026 Consensus)
1. **Federated Governance with Centralized Guardrails**: Avoid centralized bureaucracy by assigning data product owners in domain clusters while enforcing security and privacy globally.
2. **Automated Continuous Stewardship**: Replace annual spreadsheet audits with automated CI/CD schema verification, contract testing, and pipeline telemetry.
3. **Data Quality as Code**: Treat data quality rules as version-controlled test suites executed on pull requests.

## 3. Anti-Patterns & Failure Modes
- **The Ivory Tower Committee**: Governance teams that mandate policies without providing self-serve developer tooling create bypass incentives.
- **Big-Bang Data Cataloging**: Attempting to catalog legacy, unused schemas before establishing clear domain ownership leads to catalog abandonment.

## 4. Operational KPIs & Metrics
- **Cataloged Asset Ratio**: Target $\ge 95\%$ of all active tenant-facing models documented.
- **Contract Test Coverage**: Target $100\%$ compliance across inter-service APIs.
- **Incident Time-to-Remediation (TTR)**: Mean time to detect and quarantine corrupted ingested posts $< 15$ minutes.

## 5. Local Vault Traceability & Internal Project Cross-Links
- **Direct Decisions**: [[ADR-0010|ADR-0010: Multi-Tenant Schema Partitioning]], [[ADR-0027|ADR-0027: Zero-Intermediation Credential Storage]].
- **Implementation Design**: [[FDD-0017|FDD-0017: Real-Time Audit Log Emission]].
- **Master Map**: [[MOC - DMBOK - Data Governance]].

---

4. Technical Architecture: Automated Enrichment Engine CLI / Script

The enrichment workflow can be executed via a dedicated Node.js compiler script integrated into the vault's existing compilation toolchain (socialengage/scripts/enrich-brain-topics.mjs):

/**
 * enrich-brain-topics.mjs
 * Automated Ontological Topic Discovery, Web Research, and Vault Ingestion Engine.
 */

import fs from 'fs';
import path from 'path';
import { fileURLToPath } from 'url';

// 1. Load Vault Ontology & Schema Rules
const ONTOLOGY_PATH = './ONTOLOGY.json';
const ontology = JSON.parse(fs.readFileSync(ONTOLOGY_PATH, 'utf-8'));

/**
 * Stage 1: Discover topics with missing atomic concept pages
 */
export async function discoverEnrichmentGaps(vaultRoot) {
  const mocsDir = path.join(vaultRoot, ontology.folders.mocs);
  const synthesisDir = path.join(vaultRoot, 'wiki/Projects/SocialEngage/06 Synthesis & Lessons Learned');
  
  const existingNotes = new Set(fs.readdirSync(synthesisDir).map(f => f.replace(/\.md$/, '').toLowerCase()));
  const missingCandidates = [];

  const mocFiles = fs.readdirSync(mocsDir).filter(f => f.endsWith('.md'));
  for (const file of mocFiles) {
    const content = fs.readFileSync(path.join(mocsDir, file), 'utf-8');
    // Extract frontmatter topics and body links
    const topicMatches = content.match(/topics:\s*\n((?:\s*-\s*.*\n)+)/);
    if (topicMatches) {
      const topics = topicMatches[1].split('\n')
        .map(l => l.replace(/^\s*-\s*/, '').trim())
        .filter(t => t.length > 2 && t !== 'pages' && t !== 'referenced');
      
      for (const topic of topics) {
        const slug = topic.toLowerCase().replace(/[^a-z0-9]+/g, '-');
        if (!existingNotes.has(slug) && !existingNotes.has(`concept-${slug}`)) {
          missingCandidates.push({ topic, sourceMoc: file, slug });
        }
      }
    }
  }
  return missingCandidates;
}

/**
 * Stage 2: Formulate 5-Facet Web Queries
 */
export function formulateQueryBattery(candidate, domainContext = 'Software Architecture & Data Governance') {
  const t = candidate.topic;
  return [
    `"${t}" definition "${domainContext}" core principles architecture`,
    `"${t}" "best practices" production architecture 2025 OR 2026`,
    `"${t}" ("DMBOK" OR "TOGAF" OR "NIST" OR "ISO") standard`,
    `"${t}" "anti-patterns" OR "common mistakes" enterprise`,
    `"${t}" key metrics KPIs benchmarks operational`
  ];
}

/**
 * Stage 3: Dispatch Search via Brave / Bing API (Reusing Tenant Connectors)
 */
export async function fetchAuthoritativeEvidence(queries, searchConnector) {
  const results = [];
  for (const q of queries) {
    const res = await searchConnector.searchForResearch(q, 3);
    results.push(...res);
  }
  // Filter for Tier-1 & Tier-2 authority domains
  return results.filter(r => !r.url.includes('pinterest') && !r.url.includes('medium.com/@spam'));
}

/**
 * Stage 4 & 5: Synthesize and Validate Note Output
 */
export function constructEnrichedMarkdown(synthesis, candidate) {
  return `---
title: "Concept: ${candidate.topic}"
artifact_id: "Concept-${candidate.slug}"
entity_id: "${Buffer.from(candidate.slug).toString('hex').padEnd(32, '0').slice(0, 32)}"
version: "1.0.0"
type: "concept"
pm_class: "DomainKnowledge"
pm_subclass: "Concept"
pm_relationships:
  - influences
  - groundedIn
domain_cluster: "AI, NLP & Semantic Enrichment"
dmbok_category: "Metadata Management"
status: "Active"
authority_level: 1
confidence_score: 0.90
source_urls:
${synthesis.sources.map(s => `  - "${s.url}"`).join('\n')}
tags:
  - concept
  - semantic-enrichment
  - best-practices
---

# Concept: ${candidate.topic}

## 1. Architectural Definition
${synthesis.definition}

## 2. Industry Best Practices (2025/2026)
${synthesis.bestPractices.map(bp => `- **${bp.title}**: ${bp.details}`).join('\n')}

## 3. Anti-Patterns & Pitfalls
${synthesis.antiPatterns.map(ap => `- **${ap.title}**: ${ap.details}`).join('\n')}

## 4. Key Operational Metrics & KPIs
${synthesis.kpis.map(k => `- **${k.name}**: ${k.target}`).join('\n')}

## 5. Related Graph Nodes
- MOC Anchor: [[${candidate.sourceMoc.replace(/\.md$/, '')}]]
`;
}

---

5. Risk Governance & Anti-Hallucination Guardrails

Automating graph updates via external search and generative models presents tangible architectural risks. The table below codifies the operational safeguards enforced by this specification:

Failure Mode	Root Cause	Architectural Mitigation
Ontology Pollution	LLM creates arbitrary tags or non-existent frontmatter keys	Strict Key Validation: Any synthesized note containing keys outside ONTOLOGY.json's allowedKeys is rejected at compile time.
SEO Echo Chamber	Search engines return low-quality marketing content	Domain Whitelisting & Tier-Weighted Scoring: Tier-1 standards bodies and established engineering blogs receive \(5\times\) rank weighting.
Internal Architecture Inversion	External best practice contradicts accepted vault ADR	Conflict Callout Protocol: Extracted patterns that clash with accepted ADRs are rendered as > [!WARNING] internal trade-offs, preserving local design intent.
Graph Explosion / Bloat	Engine creates thousands of trivial, low-value concept notes	Centrality Thresholding: Only topics with \(\ge 3\) incoming references or direct MOC inclusion are eligible for autonomous creation.
Stale External Citations	Dead links or evolving external standards	Hash-Based Provenance & TTL: Each note records source_urls and last_enriched_at. Stale notes (\(> 180\text{ days}\)) are queued for re-verification.

---

6. Summary of Architectural Benefits

Adopting this systematic ontological topic enrichment engine transforms the Obsidian Second Brain:

1. From Static Archive to Compounding Intelligence: Internal ADRs and User Stories are continuously contextualized with modern global engineering consensus.

2. Deterministic Quality Control: The rigid ontology guarantees that external web research cannot destabilize graph schemas, broken links, or naming conventions.

3. Enhanced GraphRAG Reasoning: Downstream agents answering questions about the architecture can traverse from an implementation story, through an ADR, into a fully enriched Concept note with authoritative metrics and external citations.

---

7. Related System Documentation & Protocols

• [[wiki/System/The-Compiled-Second-Brain-Architecture|The Compiled Second Brain Architecture]]

• [[wiki/System/Compilation-and-Ingestion-Protocols|Compilation and Ingestion Protocols]]

• [[CLAUDE.md|Second Brain Operating Manual]]

• [[ONTOLOGY.json|Canonical Machine-Readable Ontology Schema]]

• [[PROJECT-MANAGEMENT-ONTOLOGY.json|Project Management Ontology Extension]]

• [[Projects/SocialEngage/01 Architecture Decisions (ADR)/0076-composer-deep-research-agent|ADR-0076: Composer Deep Research Agent]]

• [[wiki/_MOCs/MOC - AI, NLP & Semantic Enrichment|MOC - AI, NLP & Semantic Enrichment]]

• [[wiki/_MOCs/MOC - DMBOK - Data Governance|MOC - DMBOK - Data Governance]]