Type system enforces metadata that navigation depends on
Type: kb/types/note.md · Tags: type-system
The navigation argument assumes documents have descriptions. But descriptions don't appear spontaneously — the type system is what makes them exist.
The note base type requires both a path-valued type and a
description. Every note-family artifact must identify its type contract and
carry a non-empty description. Promotion from text to the
base note type uses type: kb/types/note.md; specialized types use their own
type-spec paths. Validation checks both structural requirements; whether the
description is discriminating remains a judgment-level check. This is the
enforcement mechanism: the type creates the obligation, and /validate checks
compliance.
Without this enforcement, a knowledge base degrades quickly. Agents writing notes under time pressure skip metadata. Human authors forget. The result is a collection of documents that can only be navigated by opening each one — which defeats the point of having a structured KB.
The type system's role here is not routing (that's the navigation claim) but ensuring the routing data exists at all. It's the difference between a library with a catalogue and a library where some books have catalogue cards and some don't. The catalogue is only useful if it's comprehensive; the type system is the mechanism that makes it comprehensive.
Relevant Notes:
- types-give-agents-structural-hints-before-opening-documents — depends on: the navigation argument that assumes descriptions exist; this note explains why they do
- note base type — requires the type pointer and description; the description obligation is the enforcement mechanism this note describes
- text root type — the boundary: crossing from text to note triggers both required frontmatter fields
- why-notes-have-types — context: the overview of all type system roles; this note develops the enforcement role