Context

A passage of text stored with an embedding is content. It becomes knowledge when it carries enough context for a consumer — human or model — to judge whether it applies, whether it is authoritative, whether it is current, and what it relates to.

I think of context in five dimensions, and I would require every knowledge object to carry all five.

Business context: which domain owns this, which products, regions, customer segments, or processes it applies to, what business purpose it serves. This is what makes "does this apply to me" answerable without reading the whole thing.

Source context: where it came from, who authored or approved it, what system of record it lives in, what its version is, what its rank is in the source-of-truth hierarchy when it overlaps with other sources.

Structural context: where it sits in its document — the heading breadcrumb, the section type, whether it is a definition, a rule, an exception, an example, a table. A rule and an exception to that rule are different kinds of knowledge and should be marked as such.

Semantic context: what it is about — the entities it mentions, the topics it covers, its relationships to other knowledge objects (defines, references, supersedes, contradicts, elaborates).

Operational context: effective dates, review cycle, freshness window, sensitivity classification, access constraints, quality signals from parsing and review, usage and feedback history.

Most of this can be captured at ingestion — some from source metadata, some from the document structure, some from extraction models — and enriched over time by human review and by usage. The expensive part is not capturing it; it is deciding to require it. A knowledge base where context is optional becomes a knowledge base where context is absent.