Knowledge Architecture

Knowledge Architecture

Organize knowledge by being, not bureaucracy.

Ontological Foundations

The Problem with Arbitrary Categories

Most knowledge systems fail because they organize by:

• Convention: "This is how it's always been done"
• Convenience: "This was easiest at the time"
• Accident: "It just ended up here"

Result: Knowledge fragments. Connections hide. Understanding atrophies.

Ontological Alternative

Organize by asking: What is this thing, essentially?

Not "where should this file go?" but "what is the nature of this entity, and what does it relate to by that nature?"

Categories of Being

Substances (Primary Entities)

Things that exist in themselves, not as properties of other things.

Properties (Dependent Entities)

Exist only as aspects of substances.

Events (Temporal Entities)

Things that happen, with beginning and end.

Structural Principles

Essential vs. Accidental Properties

Essential: What makes the thing that thing. Remove it, and it's something else. Accidental: Could be otherwise without changing identity.

Example: A "portfolio website"

• Essential: Displays work, represents identity
• Accidental: Uses React, hosted on Vercel, blue color scheme

Organizing principle: Group by essential properties. Tag/filter by accidental.

Genus and Differentia

Classical definition structure: "A is a B that C"

Project
├── Software Project (produces code)
│   ├── Library (produces reusable code)
│   ├── Application (produces usable program)
│   └── Infrastructure (produces enabling system)
├── Creative Project (produces art/writing)
│   ├── Visual Work (produces images)
│   ├── Written Work (produces text)
│   └── Interactive Work (produces experience)
└── Research Project (produces knowledge)
    ├── Academic (produces citable work)
    └── Applied (produces practical insight)

Relations as First-Class Citizens

Don't bury relations in properties. Make them navigable.

Architecture Patterns

The Atomic Note

Each note captures ONE thing:

• One concept
• One decision
• One reference
• One connection

Connections emerge from linking atoms, not from cramming compounds into single containers.

The Index Pattern

Create navigational hubs, not hierarchical folders.

# Project Index

## By Nature
- [[Software Projects]]
- [[Creative Projects]]
- [[Research Projects]]

## By State
- [[Active Work]]
- [[Completed Work]]
- [[Archived Work]]

## By Relation
- [[Dependencies Map]]
- [[Influence Graph]]

The Context Layer

Same entity, different contexts:

/entities/project-alpha.md          # The thing itself
/contexts/technical/project-alpha.md  # Technical view
/contexts/business/project-alpha.md   # Business view
/contexts/personal/project-alpha.md   # Personal meaning

The Temporal Layer

Knowledge changes. Track it:

/current/concept-x.md      # Current understanding
/history/concept-x/        # Evolution
  ├── 2024-01-understanding.md
  ├── 2024-06-revision.md
  └── changelog.md

Naming Conventions

Entity Naming

[type]-[identifier]

project-in-midst-my-life
concept-modular-synthesis
person-mentor-name
tool-claude-desktop

Relation Naming

[source]--[relation]--[target]

project-alpha--depends-on--library-beta
concept-x--contradicts--concept-y

State Naming

[entity].[state-type]

project-alpha.status = active
project-alpha.phase = development
project-alpha.health = stable

Cross-Domain Integration

The Translation Pattern

Same concept, different domain vocabularies:

concept: feedback-loop
domains:
  synthesis: "output patches to input, creating evolving timbre"
  systems: "output affects input, creating dynamic behavior"
  learning: "results inform practice, creating improvement"
  biology: "effect influences cause, creating homeostasis"

The Isomorphism Pattern

Find structural similarities across domains:

Modular Synthesis     ←→     Software Architecture
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Oscillator            ←→     Data Source
Filter                ←→     Transformer
Patch Cable           ←→     API Connection
Mixer                 ←→     Aggregator
CV                    ←→     Configuration
Audio Signal          ←→     Data Payload

The Emergence Pattern

Document what emerges from combination:

Component A + Component B = Emergent Property C

# Example
Note-taking + Linking + Time = Evolving understanding
(None of the parts alone produces this)

Implementation

File System Mapping

knowledge/
├── entities/           # Primary substances
│   ├── projects/
│   ├── concepts/
│   ├── works/
│   └── tools/
├── relations/          # Connection maps
│   ├── dependencies.md
│   ├── influences.md
│   └── contradictions.md
├── contexts/           # Perspective layers
│   ├── technical/
│   ├── personal/
│   └── temporal/
├── indices/            # Navigation hubs
│   ├── by-nature.md
│   ├── by-state.md
│   └── by-domain.md
└── meta/               # About the system itself
    ├── ontology.md
    ├── conventions.md
    └── changelog.md

Metadata Schema

---
type: [entity-type]
nature: [essential description]
state: [current state]
created: [date]
modified: [date]
relations:
  depends-on: [list]
  extends: [list]
  relates-to: [list]
contexts: [list of applicable contexts]
tags: [accidental properties for filtering]
---

References

• references/ontological-terms.md - Philosophical vocabulary
• references/implementation-patterns.md - Concrete file/linking patterns