How to turn messy text into useful structure for analytics and decision-making — while keeping context, time, and provenance intact.

Introduction

Teams are sitting on mountains of unstructured text: filings, emails, meeting notes, tickets, research docs, and chat logs. We want to turn that into something we can query and analyze: entities, relationships, timelines, and “facts.” The risk is that the structure starts to feel like truth — especially when the world changes, sources disagree, and meaning depends on context.

In this article, I’m proposing a different stance: a Knowledge Map. Store evidence first (observations with provenance), use entities and relationships as navigational handles back to that evidence, and compute a “best understanding” at query time based on what matters for the current question. It’s not anti-structure — it’s structure that stays accountable to narrative.

At Kineviz, we’ve implemented this concept in SightXR: an integrated unstructured data processing pipeline, with GraphXR as the user interface for exploration.

Why text doesn’t want to be “facts”

Human knowledge is often recorded as narrative: what someone said, what a document claims, what a meeting concluded, what a report summarizes. This is powerful because it preserves scope, intent, uncertainty, and time. But that same richness makes it hard to flatten into “facts” without losing something important.

The hard parts aren’t just technical (parsing). They’re real-world: things change, sources disagree, and words are overloaded and context-dependent.

If structure is produced by aggressively collapsing narrative into fixed “facts,” the resulting system becomes brittle: it will be wrong in precisely the situations where you need it most (edge cases, exceptions, evolving realities).

Names, context, and the point of structure

Over the last decade, compute has been shifting from brittle, rule-heavy systems toward systems that learn representations from data. A simple way to remember the arc is Deep Blue → AlphaGo: one leaned on explicit rules and search, the other leaned on learned intuition plus search. In knowledge work, that same shift shows up as a move from “hand-built facts” toward systems that can read messy language and still extract useful signals.

It’s tempting to say we’re moving from “symbolic” systems to “semantic” systems. In practice, you almost always end up with a hybrid. We still need structure for indexing and querying. We also need context for meaning. The question isn’t which to pick — it’s what you allow each layer to claim.

The Tao Te Ching captures a tension that shows up in every knowledge system:

“道可道，非常道；名可名，非常名。无名天地之始，有名万物之母。”

(The Tao that can be told is not the eternal Tao; The name that can be named is not the eternal name. The nameless is the beginning of heaven and earth; The named is the mother of all things.)

In plain terms, the unnamed is the full messiness of reality and language, and the named is what we do to make it usable — categories, labels, abstractions. The danger isn’t naming; it’s **reification**: treating the label as the thing. When that happens, edge cases and time get flattened, and “facts” drift away from where they came from.

Knowledge Graph vs Knowledge Map (what changes in practice)

Knowledge Graphs are powerful and widely used. They tend to make structure the primary artifact: entities and predicates become the center, triples become the canonical unit, and “truth” is implied by membership in the graph.

In practice, many KGs do model provenance, uncertainty, and temporal validity. The issue is that these often become optional, uneven, or dropped — especially when the graph is produced automatically from text.

A Knowledge Map reverses the priority:

evidence is primary, structure is an index into evidence, and the system does not pretend the structure is a final ontology of reality.

One immediate implication is entity resolution. If evidence is the anchor, resolution can’t be an aggressive “merge everything into one canonical identity” step. It has to be conservative and scoped: resolve within a document when it’s clear (pronouns, implicit subjects), let users specify local disambiguation when needed, and use lightweight global aliases for consistency — while always keeping the original quotes and sources intact. I’ll discuss in detail in a follow-up post on practical resolution strategies and tradeoffs.

How a Knowledge Map works: observations + query-time views

An Observation is a minimal unit of knowledge you can audit: an excerpt (quote), its provenance (source, location, time), and optional structure (entities and relationships) that points back to the excerpt.

The key principle:

The quote is the anchor

This doesn’t mean quotes are always true. It means the quote is the auditable anchor for what was recorded, and any structure derived from it is a helpful handle, not an eternal truth.

“Query-time meaning” is just a practical rule: don’t store one final answer. Store evidence. Compute the view when you ask.

Most teams want the system to answer questions like “What’s the current status of Project X?”, “Who is the customer’s champion right now?”, or “Is Jerry still at Acme?”

If you force the system to store a single “current truth,” you immediately run into the real world: status changes, different docs disagree, and “current” depends on what you mean (time window, scope, trust).

In a Knowledge Map, you do this instead:

Pull the evidence relevant to the question (the quotes + where they came from).
Apply a view (a small set of rules) to turn evidence into an answer.
Show your work (citations back to the quotes).

A concrete example

Question: “Is Jerry still at Acme?”

You might have quotes like “Jerry joined Acme in 2018.” (source A) and “Jerry left Acme in late 2024 due to restructuring.” (source B).

A reasonable view could prefer the newest evidence within the time window you care about; if there’s a later “left” quote, show “not currently.”

Result:

Best-effort answer: likely not at Acme (based on the “left” quote), with citations linking to the two quotes.

The key point: the answer is a derived view, not a permanent fact stored in the database.

Different views (or different scope) can yield different answers — and that’s okay — because the system stays grounded in evidence.

Modern language models make it feasible to propose structure from text at scale. The Knowledge Map claim is not “models will finally extract truth.” It’s narrower: models can propose structure, and provenance keeps it honest. When structure is always tethered to evidence, the system becomes auditable (show the source), correctable (improve prompts and re-run extraction), and robust to change (add new observations instead of rewriting history).

Why this matters (analytics + decision support)

Evidence-linked structure unlocks a more trustworthy pipeline. In practice, this shows up in a few ways. First, analytics: you can count relationship occurrences over time, detect narrative shifts, and build dashboards that remain traceable to sources. Second, decision support: you can generate summaries with citations (“based on these sources…”), surface contradictions (multiple narratives about the same subject), and maintain decision trails (why the system recommended something).

The defining property isn’t “having a graph.” It’s having an evidentiary chain from structure back to language.

Practical notes if you’re building one

Here are a few rules of thumb. Treat prompts as part of the system: version them, review them, and assume they will evolve. Make provenance non-optional so every extracted item carries source, location, and time (or the best available proxy). Keep structure lightweight with a small set of stable labels, and capture nuance in text and metadata. Store evidence and derive views (“current status,” “best answer”) instead of writing them back as permanent facts. Finally, design for re-processing and show citations in the product — trust comes from letting users see “why” in one click.

No system escapes error. Extraction errors happen, but citations and re-processing keep them from becoming invisible truth. Naming is never perfectly consistent, but normalization policies help — and names remain handles, not essences. Ambiguity is unavoidable, so preserving context and allowing multiple narratives to coexist is a feature, not a bug. And to avoid false certainty, always show evidence and treat derived views as scoped.

Conclusion

The point of a Knowledge Map is not to replace your documents with a database. It’s to make unstructured text easier to work with: you can start from an entity or a relationship, immediately see the supporting observations, and understand the story in the original context.

This is also why we treat “naming” as a tool instead of truth. Labels make search and analytics possible, but the thing you ultimately trust is the evidence: the quote, its source, and when it was written.

In a future post, I’ll go deeper on entity resolution in this setting: when merging is helpful, when it’s risky, and how to stay conservative without losing usefulness.

Knowledge Maps — Evidence-First, Context-Preserving Structure for Real-World Knowledge