Reviewing What the System Learned

SMB operator5 min read

A familiar analogy

Nobody trusts a new hire's first draft blindly. You read it, you catch the thing they got wrong, you tell them why, and the good ones don't make that mistake again. Trust isn't granted on day one — it's built through a few rounds of correction. The new hire who's never corrected isn't trustworthy; they're just unchecked.

A knowledge system is the same. Out of extraction, every fact it pulled from your documents is a first draft — mostly right, occasionally wrong, and worth a glance before you rely on it. The Facts tab is where that glance happens. Confirming what's right, fixing what's wrong, and removing what shouldn't be there is not busywork; it's the process that turns "the system extracted some stuff" into "I trust what the system tells me."

The mechanic: facts are the unit of review

A fact is a short, structured statement — a subject, a relationship, and an object. "Northwind Co. — has contract — MSA Contract A." "Crestline Logistics — supplies — Product NW-100." Stating knowledge this way is what makes it reviewable: each fact is small enough to judge true or false at a glance, unlike a whole document.

The Facts tab gives you a row per fact and a small set of operator moves on each one:

• Filter to find what you're looking for in a long list — by entity, by type, by status.
• Inline edit to correct a fact the extractor got almost right — a misspelled name, a wrong date.
• Priority to mark which facts matter most, so the system weights them more heavily when it grounds answers.
• Retract to remove a fact that's wrong or that's noise you don't want in the graph.
• Needs Review — a filter that surfaces the facts the system is least sure about, so you can spend your review time where it's most needed instead of reading everything.
• Add Fact to enter knowledge by hand that the documents didn't state outright but you know to be true.

Enlarge

Pruning the noise you chose not to keep

Here's where this unit connects straight back to Unit 01. Back there, you decided what kinds of things were worth tracking and what was noise. Extraction, being thorough, will sometimes pull in the noise anyway — a one-off name mentioned in passing, a low-value entity that technically appears in a document. The Facts tab is where you finish the job: you retract the facts that represent the noise you already decided not to keep.

This is the maintenance half of the design loop. Design says "these types matter, these don't." Maintenance says "this specific low-value fact slipped in — out it goes." Done regularly, in small passes, it keeps the graph a sharp map instead of letting clutter creep back in. One honest note on scope: you prune at the fact and relationship level — there's no separate "delete this node from the graph" button, and relationship properties are fixed once extracted. So curation lives here, in the facts, which is exactly where it should: the fact is the reviewable unit.

Watching for staleness

The other thing that quietly erodes trust is age. A fact that was true when its document was written can drift out of date — a price changes, a contract is amended, a contact leaves. A stale fact is worse than a missing one, because it's confidently wrong.

The system helps you catch this with fact health. An admin can run Analyze Fact Health, and the Health view colors the graph by signals like confidence and staleness, so the aging corners light up. In the demo workspace, there's a pricing fact that's gone almost a hundred days without re-confirmation — exactly the kind of thing that should catch your eye before someone quotes it to a customer.

Enlarge

The widget below walks the gate every fact passes through on its way to being trusted — extracted, pre-filtered, verified, and licensed — and shows what gets rejected and why. It's the same logic the Health view is surfacing, made concrete.

The mental model

Treat facts like drafts from a capable but new employee: worth reading, easy to correct, and trustworthy because you review them, not in spite of it. Three habits cover the job — confirm and correct what's right, retract the noise you flagged in your design, and re-check what the staleness signals light up. None of these takes long. All of them, skipped, end the same way: a graph nobody trusts.

The quiet payoff

The difference between a knowledge base people rely on and one they quietly route around is almost never the extraction quality — it's whether anybody maintains it. A maintained graph is a graph where the answers are current and the clutter is gone, which means people believe the answers, which means they keep asking. That last part — what people actually asked — turns out to be its own source of signal, and it's recorded in the next tab.

✕

✕