Part 3 · Topic 3 of 11
Ownership
Ownership: federate the content, standardize the pattern
2 min read
The organizational question is harder than the technical one. Who owns a knowledge base?
The centralized answer — a single team owns all enterprise knowledge — fails on domain expertise. That team does not know what the content means, when it changes, or what correct looks like. They become a ticket queue between the people who know and the systems that need to know.
The decentralized answer — every team builds and owns its own — fails on coherence. Each team makes different choices about structure, metadata, versioning, and retrieval, and the organization ends up unable to ask a question across domains, unable to find what already exists, and processing the same documents several times over.
The model I hold is federated ownership on a shared platform. Domain teams own their content, their vocabulary, their ingestion decisions, their review workflows, their freshness commitments, and their domain-specific interpretation. The platform owns the pattern: the canonical document model, the metadata contract, the chunk and annotation schemas, the provenance model, the retrieval API, the evaluation harness, the catalog, and the shared services — parsing, extraction, embedding, indexing — that any domain can invoke.
What must be the same everywhere, and what may vary:
| Standardized enterprise-wide | Extensible by domain |
|---|---|
| Canonical document model and chunk object format | Domain taxonomy, ontology, and business vocabulary |
| Required metadata fields, formats, and validation | Additional domain-specific metadata fields |
| Provenance and version model; supersession semantics | Approval and review workflows; who signs off |
| Sensitivity classification scheme and access-label vocabulary | Freshness windows per content class within the domain |
| Retrieval API request and response contracts | Enrichment configuration: which extractors, which summaries |
| Baseline evaluation metrics and how they are measured | Domain-specific evaluation sets and quality thresholds |
| Catalog registration and discovery schema | Domain-specific annotations and entity types beyond the core |
| Audit logging requirements | Retrieval policies for the domain's own use cases |
The test of whether the split is right: a consumer in one domain should be able to retrieve from another domain's knowledge without learning anything about how that domain built it, and a domain team should be able to onboard content without asking the platform team for anything but capacity.