Asserted vs Inferred

A knowledge graph holds two kinds of edges that look the same. One is asserted: an order belongs to a customer, a contract has an end date, this person is my sister. Someone with the authority to decide wrote it down, and it is true until they change it. The other is inferred: customers who buy X also buy Y, strength 0.7; these two documents are similar; this supplier is probably the same company as that one. A model or a rule computed it, and it is true only as far as the method and the data behind it.

The market's context-layer pictures put both in one graph and give every edge "a type and a strength score". That makes the difference disappear. A business rule with a score of 1.0 and a correlation with a score of 0.95 now look almost alike, and an agent that acts on the edge cannot tell whether it follows policy or a pattern. When the correlation is wrong, the error arrives in the same shape as the rule (a confident error has no tell).

The fix is structural, not clever: give every edge a provenance. Asserted edges carry who decided, where it is written and from when to when it holds: a rule that was true at nine can be revoked at five past. Inferred edges carry the method, the input data, the date computed and the score, and they are rebuilt when their inputs change, because inferred facts expire faster than asserted ones. Then the agent's rule is simple: act on asserted edges, propose on inferred ones, and escalate when the two disagree.

In a structured personal system this already runs. The curated .md and .yaml files are the asserted layer; the DuckDB tables generated from them, and the derived insights rules add on top, are the inferred layer. When they disagree, the file wins and the database is rebuilt. Nobody has to remember which is which, because the location says it.

Boundary: inferred is not inferior. Most of the value of a graph is in what it can infer. The point is that the edge says which kind it is, so trust follows the label, not the score.