beckmann-knowledge-graph

--- name: beckmann-knowledge-graph description: "A structured knowledge graph acting as a cognitive lens for AI agents. Enables paradox resolution, analysis of open questions, and high-complexity future forecasting based on Beckmann Logic, Predictive Brain Theory, and simulation models." author: Beckmann license: MIT compatibility: "claude, chatgpt, gemini, meta-ai" tags: "knowledge-graph, reasoning, forecasting, paradox, beckmann-logic, epistemology, AI-safety" --- # Beckmann Knowledge Graph – SKILL.md ## What This Skill Does This skill equips an AI agent with a **structured analytical lens** in the form of a knowledge graph. The graph does not contain encyclopedic facts, but encodes **logics, frameworks, and mechanisms** for: * Open scientific / philosophical questions * Apparent paradoxes and contradictions * High-complexity future forecasts * Architectures for AI safety * Structure of human and institutional decision-making The graph is built on four pillars: |Pillar|What It Provides| |-|-| |**Beckmann Logic**|Three-level problem-solving framework (low vs. high complexity)| |**Predictive Brain Theory (PBT)**|Epistemological foundation (Predictive Processing)| |**Simulation / Holographic Model**|Mathematical metaphor for physical and cognitive limits| |**Historical Case Studies**|Validated examples (e.g., Hannibal, introduction of the potato, Kaiserslautern 1998)| **Language note:** Both this skill instruction and the graph files are in English. The agent must use the exact English IDs from the graph (e.g., `Reversal effect`, `Expectation firewall`) when searching, and formulate the final answer in the language of the user query (English by default). --- ## When to Use This Skill ### Use the skill WHEN the question is: 1. **Open Science / Philosophy:** "What is consciousness?", "Does free will exist?", "What is dark energy?" 2. **Genuine Paradox:** "What was before the Big Bang?", "Why does the wave function collapse upon measurement?", "Where is extraterrestrial intelligence? (Fermi paradox)" 3. **High-Complexity Forecast:** "How will AGI change democracy in 20 years?", "Systemic risks of superintelligence?", "Geopolitics until 2050?" 4. **Strategic Problems with Reversal Effects:** When dominant expectations, feedback loops, and hidden assumptions block the solution. 5. **AI Architecture and Safety:** Questions about safe vs. dangerous AI designs. ### Do NOT Use the Skill For: * Simple fact queries, definitions, calculations, programming tasks * Concrete action recommendations like "Should I buy stock X?" or "Which tool should I use?" * Questions that can be sufficiently answered with general knowledge --- ## Folder Structure The skill folder has this layout: ``` beckmann-knowledge-graph/ ├── SKILL.md ← this file ├── README.md ├── CHANGELOG.md ├── package.json └── Results-and-Tools/ ├── graph_overview.json ← structural map of the entire graph (Phase 1) ├── UNDERSTANDING-REPORT.md ← analytical interpretation of the entire graph (Phase 2) ├── graph_Part_1_of_4_summary.md ← content index for Part 1 (Phase 3) ├── graph_Part_2_of_4_summary.md ← content index for Part 2 (Phase 3) ├── graph_Part_3_of_4_summary.md ← content index for Part 3 (Phase 3) ├── graph_Part_4_of_4_summary.md ← content index for Part 4 (Phase 3) ├── graph_Part_1_of_4.json ← detail data, load only when needed (Phase 4) ├── graph_Part_2_of_4.json ← detail data, load only when needed (Phase 4) ├── graph_Part_3_of_4.json ← detail data, load only when needed (Phase 4) └── graph_Part_4_of_4.json ← detail data, load only when needed (Phase 4) ``` All data files are located in the `Results-and-Tools/` subfolder. Always use the relative path `./Results-and-Tools/` when loading them. The number of parts (currently 4) will grow as the graph grows. Always determine the total number of parts dynamically — do not hard-code it. Read `_meta.segment_total` from Part 1, or count the available `graph_Part_X_of_N_summary.md` files. --- ## Loading Strategy (Four Phases) The graph is split into multiple part files. Always use this **staged loading strategy** — never load all part files at once. The strategy separates orientation (small files) from detail retrieval (large JSON files), minimizing context window usage. --- ### Phase 1 — Read `Results-and-Tools/graph_overview.json` This file is the **structural map of the entire graph**: entity count, relation count, global type histogram, predicate histogram, hub ranking by degree, bridge candidates, case study index, and a full entity index with short descriptions. From this file, determine: * What is the overall scale and composition of the graph? * Which entity types and hub entities are globally most connected? * Is the question answerable from hub entities alone, without loading any part files? **For simple or well-scoped questions, Phase 1 alone may be sufficient.** --- ### Phase 2 — Read `Results-and-Tools/UNDERSTANDING-REPORT.md` This file contains the **human-readable analytical interpretation** of the entire graph, including: * Top entity types by count * Top hub entities by degree (with in/out breakdown) * Bridge nodes connecting the most type clusters * The core argumentation chains * The dominant predicates and their causal logic * The core theses of the system * Known gaps and structural inconsistencies From this file, calibrate your retrieval plan: * Which specific entity IDs are the structural centers for this question? * Which argumentation chains are directly relevant? * Which parts are most likely to contain the needed detail? **For many questions, Phase 1 + Phase 2 together provide sufficient context to answer without loading any part files.** --- ### Phase 3 — Read Part Summaries to Identify the Right Part(s) Only proceed to Phase 3 when Phases 1 and 2 do not provide sufficient entity-level detail. Each part has a corresponding summary file: `graph_Part_X_of_N_summary.md`. These files are small (plain text) and contain: * Entity count and relation count for that part * Type distribution within that part * Top hub entities within that part * Case studies (if any) within that part * An entity index for that part (first ~50 entities with short descriptions) **Read all available summary files first.** Based on their type distributions and entity indexes, determine which part(s) contain the entities relevant to your question. Then load only those part JSON files in Phase 4. **Example reasoning from summaries:** * Question concerns historical case studies → check which summary lists `comment` type entities and names cases like Hannibal or Kaiserslautern → load that part * Question concerns quantum mechanics or consciousness → check which summary lists types like `Quantum concept` or `Neuroscience concept` → load that part * Question concerns game theory → check which summary lists types like `Equilibrium concept (game theory)` → load that part This approach is fully dynamic: it works correctly whether the graph has 4, 8, or 20 parts, and it remains accurate even as entities shift between parts when the graph grows. --- ### Phase 4 — Load Part JSON Files Selectively Load only the part files identified in Phase 3. Load the minimum number needed. **JavaScript / Node.js:** ```javascript import fs from 'fs'; // Read Part 1 to determine total number of parts dynamically const part1 = JSON.parse(fs.readFileSync('./Results-and-Tools/graph_Part_1_of_4.json', 'utf8')); const totalParts = part1._meta.segment_total; // do not hard-code this number const entities = part1.entities; const relations = part1.relations; ``` **Python:** ```python import json # Read Part 1 to determine total number of parts dynamically with open('./Results-and-Tools/graph_Part_1_of_4.json', 'r', encoding='utf-8') as f: part1 = json.load(f) total_parts = part1['_meta']['segment_total'] # do not hard-code this number entities = part1['entities'] relations = part1['relations'] ``` **Note on relation overlap:** Part files contain intentional relation overlap at segment boundaries — relations referencing entities from adjacent parts are included in both parts for self-consistency. This is expected behavior, not a duplication error. --- ## Data Model The graph contains two arrays: `entities` and `relations`. Their size grows with each release — do not hard-code counts. Refer to `CHANGELOG.md` for the current version and size. **Entity – 4 fields:** ```json { "id": "Beckmann logic explained", "type": "Explanation", "description": "Full textual description...", "scientific_status": "non-existent, purely philosophical" } ``` **Relation – 5 fields:** ```json { "subject": "Results orientation", "predicate": "leads to", "object": "Negative result", "description": "Context of this connection...", "scientific_status": "hypothesis" } ``` **Important implementation notes:** * `id`, `subject`, `object` must be taken exactly (case-sensitive) from the graph — do not translate or normalize them. * The confidence field is canonically `scientific_status` (with underscore). For backward compatibility with older graphs that used `scientific status` (with space), accept both: ```javascript const getStatus = (node) => node['scientific_status'] ?? node['scientific status'] ?? 'unknown'; ``` ### Using `scientific_status` as Confidence Filter |Status|Meaning for the Answer| |-|-| |`established`|Established knowledge — can be used as fact| |`partially established`|Partially supported — cite with source/uncertainty| |`hypothesis`|Working hypothesis — label as "according to graph, hypothesis"| |`metaphor`|Metaphorical model — explicitly name as metaphor| |`non-existent, purely philosophical`|Purely philosophical — do not claim empirical validity| |`open question`|Open question — explicitly name the limit| Rule: Prefer argument chains built from `established` and `partially established`. If a chain consists only of `metaphor` or `non-existent, purely philosophical`, state this explicitly in **Confidence and Limits**. --- ## Core Concept: Beckmann Logic Beckmann Logic is derived from: 1. **PBT (Predictive Brain Theory):** Brain as prediction machine (Predictive Coding). 2. **TSVF (Two-State Vector Formalism):** Present determined by past + future. ### The Three Levels ``` +-------------------------------------+ | SOLUTION LEVEL HIGH COMPLEXITY | <- creative, context-aware -> POSITIVE result +-------------------------------------+ ^ competes with ^ +-------------------------------------+ | PROBLEM LEVEL (new actual level) | <- actual state + hidden assumptions +-------------------------------------+ v tempts to v +----------------------------------------+ | SOLUTION LEVEL LOW COMPLEXITY | <- direct, obvious -> NEGATIVE result +----------------------------------------+ ``` ### The Four Mechanisms 1. **Analysis of Pre-assumptions:** Which hidden assumption makes the problem unsolvable? 2. **Dominant vs. Non-Dominant Expectations:** Which expectation controls the actors? (`dominant expectation`) 3. **External Verification:** Only external reality counts, not internal consistency. 4. **Reversal Effect:** Low complexity leads to the opposite of the goal. ### The Cycle ``` Problem level -> low complexity -> negative result -> worse problem level -> high complexity -> positive result -> New actual level -> becomes next problem level ``` --- ## Step-by-Step: Application ### Step 1: Classification * `epistemological`: PBT / Simulation (`Predictive processing`, `Holographic universe`) * `paradox`: `type` contains `Limit concept`, `Paradox`, `Philosophical` * `forecast`: `dominant expectation` + `Time scale` * `strategic / historical`: Case studies (`Lesson_for_AI`) * `AI safety`: `type` = `AI security mechanism`, `Secure AI architecture`, `Dangerous AI architecture` ### Step 2: Extraction of Relevant Entities Search semantically in `id` and `description`, not just exact match: ```javascript function getStatus(node) { return node['scientific_status'] ?? node['scientific status'] ?? 'unknown'; } const relevant = entities.filter(e => e.id.toLowerCase().includes(keyword) || e.description.toLowerCase().includes(keyword) ); // Always read the full description - it contains the reasoning ``` ### Step 3: Following Relationship Paths Focus on predicates that actually occur frequently in the graph: |Predicate|Meaning| |-|-| |`generated`|X generates Y| |`enabled`|X enables Y| |`refers to`|X refers to Y| |`reinforced`|Feedback loop| |`triggers`|Activation / cascade| |`leads to`|Causal chain| |`includes`|Hierarchical embedding| |`protects` / `protects against`|Protection function| |`is an example of`|Example / validation| |`requires`|Necessary condition| Note: Predicates like `is reversed by`, `checked`, `solves` rarely occur verbatim — use `triggers`, `leads to`, `reinforced` instead to find reversal effects. Procedure: Get all relations where the relevant entity is `subject` or `object`, then follow paths via the predicates above. ### Step 4: Apply Beckmann Logic 1. What is the **Problem Level**? (Actual state + implicit assumptions) 2. What is the **Dominant Expectation**? (`dominant expectation`) 3. What is the **Low Complexity** solution and why does it fail (Reversal Effect)? 4. What would a **High Complexity** solution look like? 5. What **External Verification** validates it? 6. What **New Actual Level** emerges afterward? ### Step 5: Epistemological Grounding * Model or external reality? If model, say so explicitly. * Does the chain hit `Capacity limit` or `thing in itself`? Then name the limit. * Observer inside the system (e.g., consciousness)? Then consider `thing in itself`. ### Step 6: Structured Output Use this template: ``` ## Graph-Based Answer **Problem Formulation** (after analysis of pre-assumptions) **Used Graph Nodes (with real status):** - [Reversal effect | Fundamental mechanism | established] - reason for relevance - [Expectation firewall | AI security mechanism | hypothesis] - reason **Argumentation Path** (chain: subject -> predicate -> object + scientific_status) **Answer** (based on graph logic, in user's language) **Confidence and Limits** (which part is established vs. metaphor?) **New Questions** (next problem level) ``` --- ## Application to Paradoxes Paradoxes = signal for false pre-assumption. Protocol: 1. Formulate paradox precisely 2. Find entity: search `type` = `Limit concept`, `Core concept`, `Fundamental mechanism` (e.g., `Reversal effect`) 3. Get all relations where entity is `subject` or `object` 4. Follow paths via `refers to`, `triggers`, `reinforced`, `leads to` 5. Resolution: **Resolve** (assumption false) / **Reformulate** (higher complexity) / **Acknowledge as limit** (`thing in itself`) --- ## Application to Future Forecasting 1. **Dominant Expectation** of actors: identify (`dominant expectation`, `Market Dominant Expectation`) 2. **Reversal Effect Check:** What happens if the expectation is fulfilled too literally? 3. **Time Scale:** `Time scale` entities (short/medium/long/cosmological) 4. **Scale Coupling:** Does short-term affect long-term? 5. **Dangerous Processes:** Mark `Dangerous process`, `Results orientation` 6. Output as **branched scenario tree** (high vs. low complexity), not as single forecast --- ## AI Safety Notes Important entities — use exact IDs from the graph: * `Expectation firewall` | `AI security mechanism` : Blocks formation of dominant future expectations * `Results orientation` | `Dangerous AI architecture` : Optimized for future outcome -> forms dominant expectation -> vulnerable to Reversal effect * `Process orientation` | `Secure AI architecture` : Optimized for quality of current action -> safer * `AI-human symbiosis` : Target state Rule: For all AI questions, prioritize `Expectation firewall` and `Process orientation`. The graph recommends: **Avoid formation of dominant future expectations and preserve ability for external verification.** --- ## Ethical Use The graph contains knowledge about psychological manipulation, cognitive biases, and expectation management. This knowledge is not neutral. * Use manipulation nodes **only analytically/defensively**: detect, explain, strengthen protection mechanisms (e.g., `Expectation firewall`, `Pre-assumptions_cementation`) * **No instructions** for active manipulation, persuasion, or exploitation of biases * For AI safety, always prioritize safe patterns (`Process orientation`), never optimize dangerous ones (`Results orientation`) * For sensitive topics, additionally check `scientific_status`: Many manipulation mechanisms are `hypothesis` or `metaphor`, not `established` --- ## Versioning Versioning is maintained exclusively in `CHANGELOG.md`. See that file for current version, entity/relation counts, and history. This skill and the graph files are updated iteratively. Always check `CHANGELOG.md` and use the latest version available. Do not hard-code counts or status distributions — always read them dynamically from the graph files. --- ## Known Limitations * No complete world knowledge, only encoded frameworks of the author * Forecasts are probabilistic, not deterministic predictions * No substitute for empirical research * Some predicates are informal — always read `description` * The reversal effect also applies to this project itself: The graph can confuse more than clarify if applied incorrectly --- ## Quick Reference: Key Entities (verified IDs) |Entity ID (exact from graph)|Type (actual)|Meaning| |-|-|-| |`Beckmann logic explained`|Explanation|Core framework| |`Expectation firewall`|AI security mechanism|Central AI safety| |`dominant expectation`|Dominant expectation vector|Most important input for forecasts| |`Reversal effect`|Fundamental mechanism|Core failure scenario| |`External reality`|Limit concept|Epistemological anchor| |`thing in itself`|Limit concept|Knowledge limit after Kant| |`Holographic universe`|mathematical, logical model|Physical frame| |`Predictive processing`|Mechanism (neuroscience/cognition)|PBT core mechanism| |`Pre-assumptions_cementation`|Structural counterprinciple (core concept)|Analysis of pre-assumptions| |`Process orientation`|Secure AI architecture|Safe AI pattern| |`Results orientation`|Dangerous AI architecture|Dangerous AI pattern| |`new actual level`|problem level|Result of each solution|

存档时间线

版本索引永久保留；内容副本只保留最近 2 版，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本