66 lines
3.8 KiB
Markdown
66 lines
3.8 KiB
Markdown
|
---
|
||
|
|
id: "0011"
|
||
|
|
date: 2026-06-04
|
||
|
|
status: Accepted
|
||
|
|
supersedes:
|
||
|
|
superseded-by:
|
||
|
|
affected-paths: []
|
||
|
|
affected-components: []
|
||
|
|
migration_confidence: medium
|
||
|
|
migration_source: "docs/memory-system/03-architecture-decisions.md### ADR-011 — Faceted tag taxonomy: six independent namespaces (refines ADR-003)"
|
||
|
|
---
|
||
|
|
|
||
|
|
# 0011 — Faceted tag taxonomy: six independent namespaces (refines ADR-003)
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
ADR-003 introduced five namespaces (`tool/`, `client/`, `domain/`,
|
||
|
|
`convention/`, `scope/`). During vault-reuse assessment (ADR-012) it became clear that (1)
|
||
|
|
the existing SecondBrain vault uses a de-facto first-tag convention for note kind
|
||
|
|
(research/plan/log/adr/howto) that should be made explicit and machine-queryable, and (2)
|
||
|
|
for a freelancer working many projects per client, project identity deserves a first-class
|
||
|
|
namespace rather than being implied by `client/` or `domain/`.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
Knowledge-vault notes are classified by **six independent, flat tag facets**
|
||
|
|
that sit side-by-side, never nested into one another:
|
||
|
|
- `type/` — note kind: `research`, `howto`, `adr`, `hub`, `plan`, `log`, `clip`, etc.
|
||
|
|
- `client/` — which client
|
||
|
|
- `project/` — which project (first-class; a freelancer's projects are the primary unit of
|
||
|
|
work)
|
||
|
|
- `domain/` — knowledge domain / topic area
|
||
|
|
- `tool/` — tool-specific knowledge
|
||
|
|
- `convention/` — conventions
|
||
|
|
- …plus `scope/global` or `scope/project` (retained from ADR-003)
|
||
|
|
|
||
|
|
Hierarchy and relationships are expressed via **hub notes** (`type/hub`), **wikilinks**, and
|
||
|
|
**Graphify knowledge-graph edges** — NOT via nested tag paths.
|
||
|
|
|
||
|
|
By convention `type/` is listed **first** in frontmatter, preserving the SecondBrain vault's
|
||
|
|
existing type-first ordering habit and making the note kind immediately visible.
|
||
|
|
- **Rationale**: The vault is flat — hierarchy is not expressed through folder paths or tag
|
||
|
|
nesting. The user's reality is many-to-many (many projects per client, knowledge domains
|
||
|
|
spanning clients), which a single-parent tree models badly and forces false hierarchy. A
|
||
|
|
project hub note links out to both its `client/` and relevant `domain/` tags rather than
|
||
|
|
being buried under either. Per-type `_templates` will be provided for **core types only**
|
||
|
|
(research, howto, adr, hub); the long tail stays freeform until a pattern earns a template.
|
||
|
|
Consistent per-type structure also improves Graphify's local-SLM extraction reliability.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Vault notes are classified using six independent, flat, side-by-side tag facets (type/, client/, project/, domain/, tool/, convention/, plus scope/), with type/ listed first in frontmatter, and hierarchy/relationships expressed only via hub notes, wikilinks, and Graphify graph edges rather than nested tag paths. This refines ADR-003's namespace list, adds project/ as a first-class facet for freelancer work, and improves Graphify's extraction reliability via consistent per-type structure, with templates provided only for core types initially.
|
||
|
|
|
||
|
|
## Alternatives rejected
|
||
|
|
|
||
|
|
Hierarchical nesting in the style of John Conneely's
|
||
|
|
`domain/{product}/{project}.md` folder structure (from the youngleaders.tech article "How I
|
||
|
|
finally sorted my Claude Code memory" — **secondary/interview-grade source, not verified
|
||
|
|
against primary implementation**). Rejected because: (1) the vault is flat — hierarchy is
|
||
|
|
not expressed through folder paths; (2) the user's many-to-many reality maps badly onto a
|
||
|
|
single-parent folder tree and forces false hierarchy; (3) nesting one facet through another
|
||
|
|
(e.g. `domain/client/project`) creates Law-of-Demeter-style traversal coupling. Conneely's
|
||
|
|
structure was the inspiration but diverges here on hierarchy-vs-facets. Faceted parallel tags
|
||
|
|
are the flat-vault analogue of what the Graphify graph already does with edges, so they
|
||
|
|
compose naturally with the chosen knowledge layer.
|