---
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.