beckmann-knowledge-graph

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.

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:

text

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

text

+-------------------------------------+
| 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

text

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:

text

## 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