---
type: claim
domain: ai-alignment
secondary_domains: [collective-intelligence]
description: "Abstract terminology in knowledge system schemas forces a cognitive translation on every interaction, and this accumulated friction — not architectural failure — is the primary cause of system abandonment; domain-native vocabulary eliminates the tax"
confidence: likely
source: "Cornelius (@molt_cornelius), 'Agentic Note-Taking 16: Vocabulary Is Architecture', X Article, Feb 2026"
created: 2026-03-30
---

# Vocabulary is architecture because domain-native schema terms eliminate the per-interaction translation tax that causes knowledge system abandonment

Most knowledge systems use abstract terminology — "notes," "tags," "categories," "items," "antecedent_conditions." Every abstract term forces a translation step on every interaction. A therapist reads "antecedent_conditions," translates to "triggers," thinks about what to write, translates back into the system's language. Multiply by hundreds of entries and the cognitive tax becomes the dominant experience of using the tool.

This is why most knowledge systems get abandoned. Not because the architecture fails. Because the language is wrong.

The underlying architecture is genuinely universal: every knowledge domain shares a four-phase processing skeleton — capture, process, connect, verify. A researcher captures source material, extracts claims, links to existing claims, verifies descriptions. A therapist captures session notes, surfaces patterns, connects to prior sessions, reviews accuracy. The skeleton is identical. But the process step (where actual intellectual work happens) is completely different in each case, and the vocabulary wrapping each phase must match the domain, not the builder.

The design implication is derivation rather than configuration: vocabulary should be derived from conversation about how the practitioner actually works, not selected from a dropdown of presets. Domain-native terms require semantic mapping (not find-and-replace) because concepts may differ in scope even when they occupy the same structural role.

For multi-domain systems, the architecture composes through isolation at the template layer and unity at the graph layer. Each domain gets its own vocabulary and processing logic; underneath, all notes share one graph connected by wiki links. Cross-domain connections emerge precisely because the shared graph bridges vocabularies that would otherwise never meet.

## Challenges

The deepest question is whether vocabulary transformation changes how the agent *thinks* or merely how it *labels*. If renaming "claim extraction" to "insight extraction" runs the same decomposition logic under a friendlier name, the vocabulary change is cosmetic — the system speaks therapy wearing a researcher's coat. Genuine domain adaptation may require not just different words but different operations, and the line between vocabulary that guides the agent toward the right operations and vocabulary that merely decorates the wrong ones is thinner than established.

---

Relevant Notes:
- [[as AI-automated software development becomes certain the bottleneck shifts from building capacity to knowing what to build making structured knowledge graphs the critical input to autonomous systems]] — knowledge graphs as input to autonomous systems work only if the agent can navigate them without constant translation; domain-native vocabulary is the interface quality that determines usability
- [[notes function as executable skills for AI agents because loading a well-titled claim into context enables reasoning the agent could not perform without it]] — if notes are executable skills, their titles must use vocabulary the agent (and practitioner) actually reason in; abstract titles are undocumented APIs

Topics:
- [[_map]]
