| name | knowledge-architecture |
| description | Design knowledge systems using ontological principles—organizing by what things ARE rather than arbitrary hierarchies. Use when structuring personal knowledge bases, designing documentation systems, creating cross-domain linking patterns, building the {OS.me} ecosystem, or architecting information that reveals rather than obscures essential nature. Triggers on knowledge management, documentation architecture, information ontology, or systematic organization of complex domains. |
| license | MIT |
| governance_phases | ["shape"] |
| organ_affinity | ["organ-i","meta"] |
| triggers | ["user-asks-about-knowledge-management","user-asks-about-ontology","context:information-architecture"] |
| complements | ["research-synthesis-workflow","knowledge-graph-builder"] |
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.
| Category | Examples | Identifying Question |
|---|
| Persons | You, collaborators, mentors | Who acts? |
| Projects | in-midst-my-life, AI Council | What is being built? |
| Tools | Codex, Figma, modular synth | What enables action? |
| Works | Essays, code, art pieces | What has been created? |
| Concepts | Ideas, theories, frameworks | What is understood? |
Properties (Dependent Entities)
Exist only as aspects of substances.
| Category | Examples | Identifying Question |
|---|
| States | In-progress, complete, abandoned | What phase? |
| Qualities | Elegant, experimental, stable | What character? |
| Relations | Depends-on, extends, contradicts | How connected? |
| Measures | Size, duration, complexity | What quantity? |
Events (Temporal Entities)
Things that happen, with beginning and end.
| Category | Examples | Identifying Question |
|---|
| Actions | Decisions, commits, publications | What was done? |
| Processes | Learning, building, evolving | What unfolds? |
| Occasions | Meetings, deadlines, milestones | What marks time? |
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.
| Relation Type | Meaning | Inverse |
|---|
| depends-on | Cannot exist without | enables |
| extends | Builds upon foundation | is-extended-by |
| contradicts | In tension with | is-contradicted-by |
| implements | Realizes abstraction | is-implemented-by |
| exemplifies | Is instance of pattern | is-exemplified-by |
| supersedes | Replaces previous | is-superseded-by |
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-Codex-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 vocabularyreferences/implementation-patterns.md - Concrete file/linking patterns
