query-knowledge

Query the the knowledge base (time-aware)

Answer from the current state of the knowledge graph, always dated and cited, and frame the insight — not just the raw fact. Superseded facts are history: never present them as current. This skill is read-only; it changes nothing.

Paths are relative to the workspace root. Tools (dependency-free, run from src/semantic/):

• query.py — temporality-aware entity & relationship lookup. Current-only by default. python query.py "<term>" · --rel <relation> · --history · --as-of YYYY-MM-DD · --stale
• search.py — TF-IDF passage recall + entity resolution across the whole corpus. python search.py "<question>" · --entity "<term>" · -n <k>
• The graph itself (semantic/knowledge-graph.json), entity pages (knowledge-base/entities/*.md), thematic notes (knowledge-base/0X-*.md), and the ontology (ontology/ontology.md) for what the relationship/types mean.

Method

1. Resolve. Turn the question into entities and/or topics. Use query.py "<term>" to pin the entity (it returns the best match + alternates) and search.py for passage recall when the question is thematic ("how does funding allocation work").
2. Retrieve — current only. Read facts from query.py (which already filters to status:current and traverses relationships). For multi-hop questions, follow the edges it prints (the ontology names what each relation means). Cross-check narrative in the relevant knowledge-base/ note.
3. Check temporality before answering:
   • If the resolving fact is superseded, query.py auto-steers to the current successor — answer from that, and only mention the old value if the user asked for history.
   • If a fact carries an as_of / valid_from, state it ("target headcount is 728, current as of 2026-03-01").
   • If a fact has no date (legacy), treat it as current but say it's undated if precision matters.
   • Run query.py --stale if you need to know what's been superseded recently.
4. Answer concisely and cite: entity id(s) + the sources / source_doc. Honour the KB's convention — ⚠️ marks inference, not a stated fact; §=SOW section, s=slide, p=PDF page.
5. Frame the insight (this is the point, not an extra): after the direct answer, add
   • So what — what the answer implies (a breach, a risk, a gap, a dependency).
   • Action — what the user could decide or do, if anything.
   • Open — what the KB does not answer here (missing data, undated fact, an ⚠️ inference that needs confirming). Never bluff: if the graph doesn't know, say so.

History & point-in-time (only when asked)

• "what did we believe before / what changed" → query.py "<term>" --history (shows the superseded predecessors with their date ranges).
• "as of " → query.py "<term>" --as-of <date> (valid-time slice).

Performance & model

This is a retrieve-summarize-cite flow — the graph does the heavy lifting, so it runs well on a faster model. Prefer Sonnet for everyday Q&A and Haiku for pure fact lookups (/model sonnet or /model haiku); reserve Opus for the reasoning-heavy ingest-document side. Keep latency down by using the warm <project>-kg MCP tools (loaded once) or query_sql.py (indexed SQLite) instead of spawning query.py per call — see src/semantic/README.md → Fast query paths. Batch related lookups into one call to cut round-trips.

Guardrails

• Current-by-default. Do not surface superseded or proposed facts as if current.
• Always date & cite. An undated, uncited number is not an answer here.
• Distinguish stated vs inferred (⚠️). Don't upgrade an inference to a fact.
• Read-only. If the user wants to change the knowledge (add a doc, correct a fact), hand off to the ingest-document skill — do not edit the graph from here.
• Don't invent edges. If two entities aren't connected in the graph, say the link is unstated rather than asserting it.