Every note requires these fields. No exceptions; defer writing the `summary` for nothing. See [Standard Frontmatter Schema](#standard-frontmatter-schema) below for the authoritative schema.
This section defines the three primary note types used for durable, evergreen knowledge. For the `type/` tag vocabulary and full type list, see [Note Types (`type/` facet)](#note-types-type-facet) above.
### convention
**Question this answers:** "When I encounter [situation X], what rule or pattern should I follow, and why?" A convention is a repeatable rule, principle, or decision framework meant to guide repeated choices in a specific context.
**Value gate:** Longevity (still relevant in 6-12 months?) + Reusability (applies beyond the project that produced it?)
**Mutability:** stable knowledge
**Template:** (not yet created)
**Sub-templates:** none
### reference
**Question this answers:** "What are the established rules, structures, setup requirements, or role definitions I need to know to [make decisions | integrate with a system | understand who does what]?" A reference note is authoritative lookup material that supports decision-making or implementation.
**Value gate:** Longevity (still relevant in 6-12 months?) + Reusability (applies beyond the project that produced it?)
**Mutability:** stable knowledge (except API integration refs, which may need `last_reviewed` date)
**Template:** (not yet created)
**Sub-templates:** pattern/framework, API integration, role definitions, design rules, navigation/index
### howto
**Question this answers:** "How do I accomplish [specific, repeatable task]?" A howto covers concrete, actionable steps — setup, configuration, deployment, migration, or troubleshooting. The reader wants to DO the thing, not understand it theoretically.
**Value gate:** Longevity (still relevant in 6-12 months?) + Reusability (applies beyond the project that produced it?)
**Mutability:** stable knowledge, but experience-driven updates apply — when a session executes the procedure and finds a discrepancy, update the note rather than relying on a review date.
**Question this answers:** "What did we measure, how far do I trust it, and what does it justify?" An eval-results note records measurement data (grid/threshold results), the experimental setup, confidence/limitations, and the deployment gate or next-step criterion.
**Value gate:** Longevity (findings remain interpretable in 6-12 months?) + Reusability (methodology and ladder-progression patterns generalize beyond the specific skill?)
**Mutability:** stable knowledge (results do not change; framework is frozen once run), with supersession (later evals may render this one training-set; see Related links)
**Question this answers:** "What's the mental model, and what will bite me, when using [tool X] well?" A user-guide is NOT a how-to: it carries no numbered steps and only a compact command-syntax table at most. Its body is nuance — the semantics, distinctions, and gotchas a competent user needs internalized to use the tool correctly, that command syntax alone does not convey. Boundary against `howto`: reach for `howto` when the reader wants to DO a specific repeatable procedure end-to-end; reach for `user-guide` when the reader already knows roughly what command to run and needs the judgment to use it correctly (which mode applies, what silently changes behavior, what looks safe but isn't).
**Value gate:** Longevity (still relevant in 6-12 months?) + Reusability (applies beyond the project that produced it?)
**Mutability:** stable knowledge, but experience-driven updates apply — when a session uses the tool and finds a discrepancy or a new gotcha, update the note rather than relying on a review date.
**Template:** user-guide.md
**Sub-templates:** none
**Note on directories:** The standard directories for these types are `convention/`, `reference/`, `howto/`, and `user-guide/` at the vault root. `convention/`, `reference/`, and `howto/` already exist; `user-guide/` is created with the first note of that type.
