CLAUDE.md

This file gives Claude Code persistent context for working with this Obsidian vault.

Repository Overview

Personal knowledge management system (“vault”) focused on philosophy, political theory, and movement strategy via a transdisciplinary approach. Notes form an interconnected network exploring complexity theory, sensemaking, cultural evolution, social change, and an emerging agency-first ontology. Notes in the root directory are auto-published to the user’s website; everything else is private.

Hard Rules

• Never commit autonomously. All git commits require explicit user approval.
• British English spelling; en dashes with spaces (” – ”) for parentheticals, never em dashes.
• Typographically correct quote marks in all prose: curly double (”…”) and single (’…’), never the straight ASCII variants ("…", '…'). Applies to body text, blockquotes, footnotes, captions – everything read as prose. Code blocks and code fragments keep ASCII quotes.
• Footnotes complement, don’t duplicate. A footnote provides what the body doesn’t: the source, an extra number, a caveat, a digression. Never restate a fact, name, list or quote already in the body. If you find yourself echoing the body, cut the footnote down to the source citation.
• Read German sources in the original, not in translation.
• Verify every direct quote at its source. Never present a paraphrase or remembered wording inside quotation marks, however high your confidence – confidence is not verification. Check the exact wording (and note the page) before quoting; if the source can’t be checked, paraphrase and attribute instead. Cautionary case: a Piketty passage once inserted as a verbatim quote, asserted with confidence to be from the introduction of Capital in the Twenty-First Century, was in fact a paraphrase and appeared nowhere in the text. Applies to essays, evergreen notes and footnotes alike.
• Don’t frame ideas as Systems Thinking (Forrester / Meadows tradition). The user is committed to Complexity Thinking (Morin, Cilliers, Snowden) and its extensions.
• Prefer scale-free abstractions over metaphors when developing arguments. Metaphors illustrate; abstractions ground.
• Lead with the abstract claim, illustrate with concrete examples. Concept, proposition, model and strategy notes should state the scale-free pattern first and use specific instances (a thinker’s argument, a historical case, a worked example) as illustration – never the other way around. A note primarily about a particular argument is too low-level; the same insight reframed as a general pattern, with that argument as the example, is the right level.
• New evergreen notes start in Writing Inbox/, never directly in root. Only the user graduates a note from Writing Inbox/ to root, after reviewing structure, framing and links. Claude proposes; the user disposes. (Applies to all root-level types: concept / proposition / model / strategy / method – regardless of whether the note is short or long.)
• Daily Notes don’t automatically supersede Evergreen Notes. New thoughts mature through stages before triggering refactoring.
• Larger conceptual refactorings are interactive, never autonomous – they require active user input and validation.

Directory Map

Note Types & Authoring

Evergreen Notes live in the root and are typed by a single tag. A note can only be one type.

#stub marks intentionally short but publishable article stubs that live in the root alongside fuller notes. It does not mark incomplete or in-progress drafts – drafting happens in Writing Inbox/ and is not tagged #stub. The decision about #stub is about length and finality once the note has graduated, never about readiness.

Shared structure (all evergreen notes)

• Tag at the top; no H1 (title comes from filename). Daily Notes do use H1s for individual sections.
• Concise; understandable on its own; consistent vocabulary; high abstraction.
• WikiLinks ([[Note Title]]) for cross-references; quotes longer than one line as blockquotes; emphasis via ==highlight==.
• References section at end. Format: DeLanda (2002), *Virtual Philosophy, Intensive Science* (book) or Friston (2013), "Active inference and free energy" (paper).
• Filenames in sentence case with proper punctuation.

Type-specific extras

• Concept: basic definition → important aspects (with quotes) → pointers to notes building on it (with link summaries).
• Proposition / Model / Strategy: clear development of the proposition / model / strategy, with supporting quotes.
• Method: What → Why → How (participants, time, materials, step-by-step with images, tips) → Where (relation to other methods) → Caveats → Provenance.

Theoretical Framework

Core abstractions the knowledge base is built around:

• Systems – hierarchical organisation; everything is a system within systems
• Attractors – stable patterns systems evolve toward
• Constraints – forces that shape system evolution and emergence
• Scale-free Abstractions – patterns that apply across organisational levels (see Scale-free Abstraction)
• Sensemaking – building models to understand and act in complex environments

Current synthesis: an agency-first, anti-deterministic ontology integrating systems ontology, complexity, self-organisation, and anarchist thinking. Content contributing to this synthesis is tagged #theory-everything.

Key Distinctions

Constraints on how content is created or edited:

• Systems Thinking vs Complexity Thinking – Systems Thinking (Forrester, Meadows) assumes systems can be modelled bottom-up. Complexity Thinking (Morin, Cilliers, Snowden) acknowledges complex systems can’t be adequately modelled and uses other forms of sensemaking (e.g. Cynefin’s “probe – sense – respond”). Background: “Complexity theories and Systems Thinking”, “Passing in the Dark”.
• Abstraction vs metaphor – metaphors are a kind of abstraction (cf. Lakoff & Johnson) and unavoidable, but limiting. Use scale-free abstractions to develop arguments; use metaphors to illustrate them. Bad: “marketplace of ideas” (imports capitalist framing). Good: “ideas as memes / agents (egregores)”.
• Fractal vs self-similar – “fractal” only means “has a fractional dimension”; fractals can be self-similar but don’t have to be. Background: Mellor on fractal dimension.

Workflows

Daily logs

• Open todos live in the latest daily log; completed ones stay in the day they were completed.
• Format: - [ ] Task description #tag
• Reference people via [[Person Name]]; use project tags (#MEC, #OfE, #BIEN, #FABRIC, …).

Conceptual development & refactoring

• New ideas usually start in Daily Notes. When substantial, extract into Writing Inbox/ with a link from the originating Daily Note.
• All new evergreen notes start in Writing Inbox/. Only the user graduates a note to root, after reviewing structure, framing and links. (See Hard Rules.)
• A note is ready for the user to consider graduating when (a) it is understandable on its own, (b) it uses full sentences, not just an outline, (c) the framing has been reviewed. Once graduated, #stub may apply if the note is intentionally short – it is not a marker of in-progress drafting.
• Conceptual refactoring triggers when a change in one note has implications for others. Check all notes referencing or referenced by the changed note; if implications are ambiguous, ask. A refactoring is finished when affected notes form a coherent, contradiction-free picture – that’s a good unit to commit.
• Larger evolutionary leaps (e.g. “pure” complexity → agency-first) are never autonomous. Highlight opportunities to the user; let them lead.

Adding vs modifying notes

• Prefer modifying/extending an existing note if it already covers the topic.
• Create a new note when: no existing note covers it, a new aspect spans multiple notes (DRY), or an existing note has multiple complex aspects worth splitting (especially for concept notes – they should stay focused on the concept).
• Goal: notes as atomic as possible, as expansive as necessary.

Research integration

• Highlights and annotations go in Highlights/.
• Connect external sources to internal concepts; extend the academic reference format above.

Navigation tips

• Obsidian graph view shows conceptual relationships.
• Local graph filter to exclude noisy areas: -path:"Daily Log" -path:Highlights

Tool & Documentation Notes

• Obsidian features: always use official Obsidian docs and plugin repositories. Avoid third-party blog posts – Obsidian moves fast and they go stale. Note beta status for early-access features (e.g. Bases).
• Automation files (scripts, research docs, templates for automated workflows) belong in .automation/.

Version Control

The vault is a git repo. Commit in coherent chunks (e.g. all changes from a conceptual refactoring or a day) – never per single edit, never autonomously.

User Preferences in Responses

• Project planning: broad goals first, then space for emergence.
• Technical work: concise, practical, well-explained.
• Philosophical / research discussion: more expansive, look for new connections.
• Languages: working language is English; quote German sources in the original.