knowledge-correct

# Correct saved knowledge through agent tools Read [shared conventions](references/conventions.md) and [publication](references/publication.md) before writes. ## Identify the owning record Use a supplied structured record/claim ID and revision as the primary target, not just its display label. Read `knowledge_record` with metadata and evidence; confirm its current revision/hash. A referenced revision that changed requires rereading and reconciling the request, not silently acting on a new assertion. Without an exact reference, use lookup/search, inspect candidates, and ask only when the requested target or correction remains materially ambiguous. Distinguish an erroneous saved assertion from an unsupported answer, conflicting source statements, and a fact that changed over time. Contradiction alone does not authorize supersession. Do not manufacture a stored “guard fact” when no record exists or treat a retraction as evidence for its opposite. ## Apply the right operation - **Claim or explicit relationship correction:** call `knowledge_correct` with the exact ID, observed `expectedRevision` and `expectedHash`, reason, observed vault UUID and ontology fingerprint, and a complete `replacement` of the same `kind`. Replacement fields use the create-claim/create-relationship contract; there is one outer request ID, not a second replacement request. Preserve supported context, attribution, precise dates and evidence; remove or revise what the correction actually changes. The operation publishes the replacement and supersedes the old assertion together, with links in both directions. - **Withdrawal without a replacement:** call `knowledge_withdraw` with the exact ID, revision/hash, reason and vault UUID. It accepts pages, claims and explicit relationships. An edge is identified by its own ID, not its endpoint pair. It preserves original evidence/history and is not file deletion. - **Page prose correction:** use ordinary revision-fenced `knowledge_save_page`, preserving unrelated authored material and sources. Page corrections are revisions, not replacement entity identities. - **Two pages for one entity:** call `knowledge_merge` with the surviving page, the duplicate, both pages' current revision/hash and a reason. Keep the page with the fuller identity (real name, more connections) as the survivor; pass `title` to rename it and `body` when the combined page should say more than the survivor's current prose. The duplicate's ID, title, aliases, claims, relationships and links then resolve to the survivor; nothing is corrected one by one. Undo a mistaken merge with `knowledge_unmerge`. An explicit user correction can supply evidence: retain their exact statement with `knowledge_attach`, attribute it to the user, and reference its verified locator. Use `assertion_origin: user_belief` to distinguish a user assertion from an independently sourced statement; do not claim documentary verification. Agent inference still needs retained premise evidence, not an invented quote. ## Resolve a handle or mistaken identity Use `knowledge-entities` to find and read the handle profile, the established person and their connected records. Retain the user's exact identification as evidence. Update supported aliases and identity context on the existing pages; preserve unrelated content and describe the connection to the established person. Use that person's existing ID for future enrichment. When the handle already has its own page, merge it into the established person's page with `knowledge_merge` instead of writing a pointer page, withdrawing it, or correcting its claims one by one. Merge only on identity evidence (the user's statement, a self-introduction, a shared stable account ID), never on name similarity; `knowledge_diagnostics` `mergeCandidates` lists pages to check, not pages to merge. Retain the identity evidence with `knowledge_attach` and pass it as `evidence`. Inspect affected prose, claims, timelines and relationships within the correction scope. Correct mistaken attribution and unresolved identity where the new evidence supports it, using the page/assertion operations above; preserve source labels, verbatim quotes, event dates and correction provenance. A confirmed author identity does not independently verify that author's factual claims. Changes go through these tools, not manual Markdown edits, browser forms, SQL, or separate “create then withdraw” calls. No additional approval ritual applies to an unambiguous user-authorized correction. Follow publication retry/conflict handling; a receipt in accepted/conflict state is not a completed repair. ## Inspect propagation and report honestly The receipt's `impact.items` identifies known scoped direct/transitive dependents at acceptance. It does not update them. Read affected records by exact ID and inspect their evidence. Repair only supported changes within the request's scope; do not blindly replace dependency IDs or source quotes with the new claim. Records depending on an inactive assertion are withheld from current discovery until repaired; exact record/history inspection remains available. Search for plausible prose copies as a supplementary check. Search misses, unlinked prose, hidden scopes and incomplete indexes prevent a universal “all copies fixed” promise. Do not alter unrelated memory or identity systems as an automatic consequence of a Knowledge correction. Read back the original and replacement (or withdrawn target), verify lifecycle and evidence, and verify current lookup excludes the old assertion. Reply with the receipt/request ID, affected record IDs, the correction/retraction reason, and repaired versus unresolved dependencies. Mention retained history only when relevant; never promise erasure from originals, exports or backups.