The knowledge graph is small and curated by design. Agents and humans both contribute proposals; an operator approves them before the graph takes the edge. This keeps speculation out of the live graph.
When you've observed a missing edge that has clear page-level support and you want it landed.
propose_knowledge writes a proposal row to the kg_proposals table with
status = pending. Its required arguments are proposal_type (new-node,
new-edge, new-property or modify-property), proposed_data, source_page,
confidence and reasoning; for a new-edge, proposed_data is
{source, target, relationship}. list_proposals returns the queue (optional filters
status, source_page, limit, offset).
Operators triage in the Proposals tab of the admin Knowledge Graph page
(/admin/knowledge-graph), or an admin agent does it with inspect_proposals
(conflict flags and prior reviews for 1 to 50 ids) and review_proposals
(approve, reject or judge; reject needs a reason). Approving a proposal
promotes it into the graph as a human-curated entry; rejecting one keeps it in
history with its reason, and for an edge the rejection is remembered so the same
edge cannot be proposed again. Approving a proposal whose source page sits on
the Knowledge Graph exclusion list still succeeds but returns a warning; see
KG Inclusion Policy.
The frontmatter steps capture the canonical workflow: read,
propose, confirm, hand off, track. The "read first" step is
load-bearing — proposals without page-level support get rejected.
The frontmatter pitfalls are the recurring failure modes. The
"agent inference instead of page text" pitfall is the worst —
proposals from speculation rather than citation pollute the queue.
Cluster Hub: Agent Cookbook (agent-cookbook)