Guides

Knowledge Delta

Answer change-shaped questions directly: what moved since Tuesday, what structurally changed in this note, and which conclusions depended on it.

A knowledge base rots quietly. Someone edits the decision note, and the three documents that cite it keep looking authoritative. A runbook picks up a step, and the Capsule you built for last month’s review still says what it said. Search cannot help with any of this, because search answers “what is true now” and the question is “what changed, and what did it break”.

Knowledge Delta is three commands for those questions, plus the freshness machinery that connects them to saved Context Capsules. Everything it retains is bounded metadata and structural summary. It never stores source bodies, and notifications never carry content.

The three questions

QuestionCommand
What moved since the last release / meeting / Tuesday?gno changes
What structurally changed inside this document?gno diff
What else depends on this document?gno impact

gno changes

gno changes --since 2026-07-20T00:00:00Z --json
gno changes --since <opaque-cursor> --json

A metadata-only lifecycle journal: documents created, updated, removed, reactivated. --since takes either an ISO-8601 timestamp or an opaque cursor returned by an earlier response, which is how you build a “what is new since I last looked” loop without re-scanning.

Retention is bounded, and this is where it gets careful: if retention has expired your cursor, GNO does not invent the gap. The response returns no fabricated history and tells you the earliest cursor still available, so a script can restart honestly instead of silently skipping a week.

gno diff

gno diff gno://notes/plan.md --json
gno diff gno://notes/plan.md --change <opaque-change-id> --json

This is a structural diff, not a text diff. It reports what changed about the document’s shape: headings added, removed, or renamed; links appearing or disappearing; typed relationships from frontmatter changing. That is deliberate. Source bodies are never retained, so GNO cannot show you a line-level patch, and pretending otherwise would mean keeping a copy of every version of every private note.

Structural is usually the level you want anyway. “The Decision heading disappeared from the RFC” is more actionable than forty lines of prose churn. Where prior structure is missing, history and structureDelta.truncated disclose it rather than presenting a partial view as complete.

gno impact

gno impact gno://notes/plan.md --max-depth 3 --max-edges 250 --json

Impact walks inbound dependencies: what points at this document, then what points at those, following typed relations, wiki links, and Markdown links. Every result carries an evidence path back to the changed document, so the answer is not a vague “these 40 notes look related” but “this note reaches that one through exactly these links”.

Depth, node, edge, frontier, and visited-row caps are always enforced. A knowledge graph with one hub note would otherwise return most of your vault and tell you nothing; bounded traversal keeps the answer usable and the runtime predictable.

Capsule freshness

The three commands above tell you what changed. Freshness closes the loop back to conclusions you already drew.

gno context watch capsule.json --question "Who owns launch?"
gno context watches --json
gno context reverify capsule-abc123 --json

A registered Capsule is watched by evidence identity, not by content: GNO stores hash references, never the passages. When gno serve or gno daemon is running, it coalesces settled journal changes and reverifies only the registrations whose evidence actually moved. Restart resumes from a durable high-water mark; if that cursor has expired, it makes one conservative bounded pass rather than skipping work.

The stored result is the same canonical, non-generative receipt gno context verify produces. Reverification never invokes answer generation, so a background freshness check cannot quietly rewrite a conclusion. --notify emits a local capsule-reverified event carrying identity, status, affected-question state, and a timestamp, and nothing else.

A useful pattern

Run this after a week of edits to find decisions that may have moved under you:

# What changed this week
gno changes --since "$(date -v-7d +%Y-%m-%dT00:00:00Z)" --json > week.json

# For a document that changed, what depended on it
gno impact gno://notes/pricing-decision.md --max-depth 2 --md

# And which saved evidence bundles are now stale
gno context watches --json

Everywhere else

changes, diff, and impact have equivalent REST, MCP (gno_changes, gno_diff, gno_impact), and SDK reads with the same bounds and the same opaque cursors. The machine-readable contracts are changes.schema.json, document-diff.schema.json, and impact.schema.json. Saved-Capsule watch lifecycle is CLI-only by design; it is a durable local registration, not a request-scoped read.

Explicitly empty filters and selectors are rejected across every surface rather than being treated as “everything”, because an accidental empty filter that returns the whole journal is a worse failure than an error.