# Topical Archive
The topical archive is organized by topic, not by source repository, project dump, date of ingestion, or agent session. A path name is a claim about what the material is about, and misleading names damage later classification work.
## Organizing Rule
The topical archive MUST be organized according to Library of Congress topical headings at the broad levels when those headings are available. When Library of Congress is insufficient or a topic needs finer organization, use the domain-specific standard taxonomy appropriate to that topic inside the narrower domain.
Do not flatten a source corpus into a single bucket because the source had a name. Split source dumps into the topical branches their contents actually belong to.
## Recursive Shape
The canonical shape is recursive:
```text
topical-archive/
topic/
library/
topic/
library/
topic/
library/
```
In shorthand, this is `topic/lib/topic/lib/topic/lib`; the directory name in this archive is `library/`.
Use each `topic/` directory for the topical claim. Use its `library/` directory for the organized body of intentionally promoted material under that topic. Continue the pattern whenever a narrower topic has enough internal structure to deserve its own branch.
Do not promote source-dump material into `library/` just because its topical home is known. Source-dump notes, old notes, conflicting notes, and unmerged material go under the relevant topic's `archive/` until a human or explicit task promotes them.
## Archive Shape
The current knowledge root is `archive/topical-archive/`. The intended future archive package shape is:
```text
archive/
code/
knowledge/
```
`knowledge/` is the home for topical knowledge artifacts: Markdown, JSON, JSONL, PDF, BibTeX, and similar flat information files. `code/` is the home for archive-serving, archive-indexing, and archive-management source code. Do not place new source code inside the topical knowledge tree while moving toward this split.
## Allowed Topic Children
A topic in the knowledge tree MAY contain:
- `library/` for organized topical subtopics and stable library material.
- `archive/` for older notes, displaced material, superseded drafts, and local historical residue that still belongs under that topic.
- `docs/explanations/` for explanatory prose.
- `docs/references/` for reference material.
- `docs/tutorials/` for tutorial material.
- `docs/guides/` for procedural guidance.
Do not create new top-level `texts/`, `terms/`, `theories/`, or source-repository dump directories while organizing the topical archive. Existing directories with those names are legacy evidence to inspect, not a target shape to copy.
## Classification Discipline
Classify by what the file is about, not where it came from. Existing paths are evidence, not authority.
Organize directories before standardizing note metadata. A note that cannot be found by topic cannot be made useful by adding tags.
Agent organization work should happen in substantial heartbeats: inspect the existing topical tree, choose a relevant file set, subtree, or source-dump slice, move or repair as much mis-organized content as that slice reveals, audit any touched `_index.md` files, verify the immediate result, and update the organizing skill/docs/scripts when the pass reveals a missing rule or bad affordance. Do not treat a heartbeat as an artificial one-file or one-object quota.
At the end of each user turn spent on the archive-organization goal, commit and push the `archive` repository.
Before moving a subtree, inspect the nearby topical branches that already exist. Choose the best specific branch available; do not guess from a flat top-level label when the archive already has a deeper topic for the material.
Some existing topic trees still use legacy `domains/` branches. During cleanup, treat an existing specific `domains/<topic>/` branch as the current topical home for that material and put source-dump notes under that branch's `archive/`. Do not flatten the material or create a parallel branch just to normalize the tree shape during an unrelated move.
When no good home exists, create the smallest topic branch that truthfully names the material and follows the recursive shape.
When moving from a source dump, put each note under the destination topic's `archive/`. If the archive already contains the same filename, suffix the incoming file, for example `name-2.md` or `name-2026-06-08.md`; do not skip the move and do not overwrite.
Do not delete `_index.md` files by filename alone. Inspect each `_index.md` before removal. If it is empty or only a navigation shell, remove it during cleanup. If it contains substantive prose or meaningful metadata, preserve that content by renaming it to a normal slug file such as `topic/topic.md` under the relevant topical `archive/` branch. When a source `_index.md` appears deleted because it was renamed, verify the destination slug file exists and carries the content.
## Frontmatter Discipline
After a topic branch is findable, standardize note frontmatter toward:
- `title`: the human-readable title when the note should have one.
- `description`: a short retrieval-oriented description of what the note contains.
- `date-created` and `date-modified`: preserve these when they are present and meaningful.
- `tags`: inline YAML arrays of kebab-case slugs for key topics actually mentioned in the file, not redundant restatements of the path, for example `tags: [abolition, digital-gardens]`.
Remove frontmatter that only records prior AI taxonomization attempts, generated relation cruft, or obsolete source-system bookkeeping, unless it is needed to understand provenance.