cc-os/docs/adr/0011-faceted-tag-taxonomy-six-independent-namespaces-refines-adr-003.md

id	date	status	supersedes	superseded-by	affected-paths	affected-components	migration_confidence	migration_source
0011	2026-06-04	Accepted					medium	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.