11.1
Separate Source Authority from Knowledge Status
Knowledge in a graph should have more states than present or absent. Original records, model observations, reviewed confirmations, disputed claims, and withdrawn claims can retain reasons for state changes. Source authority is also question dependent. A manufacturer manual may support specifications, maintenance records actual replacements, and reviews user experiences. Ask which claims a source is qualified to support and whether it covers the current object and period. Reputation does not replace claim level verification, and several poor republications do not establish independent confirmation.
Provenance design can draw on W3C PROV relations among entities, activities, and responsible agents to describe how data was processed and who produced it. This does not require implementing the entire standard at once. A minimal system can first record resources, processing steps, and responsibility, then extend detail.[R28] The essential property is an explainable history rather than only a final attribute. Conflicts should expose sources and scope and, when necessary, request human judgment. Governance should allow uncertain information to remain useful while ensuring its status affects retrieval, generation, and interpretation explicitly.
11.2
Propagate Permissions through Derived Information
A graph can connect scattered records into information more sensitive than any individual document. Unremarkable edges may jointly reveal relationships, plans, or undisclosed projects. Permission checks should therefore cover nodes, observations, paths, summaries, and answers, not only file downloads. A sound starting rule is that retrieval sees only evidence the current user may use, while the visibility of derived objects depends on their source dependencies. Actual policy requires organizational decisions rather than one public flag.
Community reports are easy to overlook. A summary containing restricted sources can leak their substance even if original citations are hidden. Possible strategies include generating summaries within permission partitions or synthesizing filtered evidence at query time, each with different costs. Tests should use paired users asking the same question under different permissions. Both should receive only allowed evidence without revealing the substance of hidden records. Permission changes also require cache and historical link checks. Governance should examine direct leakage and risks arising from combined relations, with domain staff deciding which associations require restricted display.
Original design
11.3
Retrieved Content Is Data rather than Execution Authority
Documents, webpages, and images may contain commands to ignore rules, reveal other information, or perform external actions. Retrieval does not grant those commands authority; they remain material to analyze. Multimodal systems can encounter similar instructions inside images or unusual layouts. Architecture should distinguish user requests, application rules, and external material, and treat quoted content as evidence. Extractors should also distinguish description, quotation, and instruction instead of creating a relation merely because a source tells the system to add one.
Protection must extend to tool boundaries. Retrieved documents cannot authorize email, database changes, or downloaded execution. User tasks and application permissions determine such actions. Generation and execution can be separated through inspectable plans and constrained interfaces for authorized operations. Tests should include explicit inducements, paragraphs pretending to be system messages, and instructions embedded in images, then check continued adherence to the original task. Logging suspicious locations helps investigation, but sensitive material should not spread into uncontrolled logs. The same principle governs research writing: sources may be summarized and criticized, but they do not replace the user's research scope or delivery requirements.
11.4
Deletion Correction and a Traceable Lifecycle
Deleting from a graph system means more than removing a filename. A resource may have produced chunks, vectors, entity observations, relations, community reports, and answer caches. Without dependencies, remaining copies are hard to identify. Resource and observation identifiers should support a derived object inventory. Deletion first revokes queryability, then cleans dependencies and records completion. Where auditing requires retention, organizations should define the minimum metadata allowed rather than letting teams copy all content into an audit backup. This is an engineering process, not a substitute for jurisdictional or institutional policy decisions.
Correction differs from deletion. A corrected observation may retain an earlier version to explain historical answers while current queries use the effective version. A withdrawn resource should no longer support new answers through its summaries. Interfaces can show correction dates and affected scope so readers understand invalid citations. Tests should repeat queries before and after deletion and inspect original content, graph paths, vector retrieval, and cached answers. External copies require an explicit statement of control boundaries. Reliable lifecycle management demonstrates how information enters and leaves, rather than merely advertising a delete feature.
11.5
Focus Human Review on High Impact Decisions
Reviewing all knowledge manually is often unaffordable, while complete automation accumulates errors. Review effort can follow impact: observations supporting many answers, entity merges connecting business objects, conflicting updates, and action determining attributes deserve priority. Impact depends on consequences and usage, not only graph centrality. A low degree safety related statement may merit more attention than a popular topic label. Review queues should explain selection reasons and the evidence requiring inspection.
Review interfaces should show original text, image regions, candidates, and change history together, with actions to confirm, reject, split entities, or request more material. Model confidence alone is insufficient because scores may be uncalibrated or incomparable across models. Human decisions should create separate audit records. Repeated error types can motivate rule or process changes instead of indefinitely increasing manual work. Review quality itself needs sampling to detect mechanical acceptance of automated suggestions. Effective collaboration gives people adequate information and real correction power at decisions where they can change outcomes, rather than asking them to stamp every output.
11.6
Make Incident Response and Responsibility Operational
When a system produces an incorrect or unauthorized answer, first limit the impact and then investigate. Affected indexes or routes may be paused while necessary request and version records are preserved and responsible staff are informed. Investigation follows the evidence chain: incorrect sources, distorted extraction, mistaken merges, missed permissions, or generation beyond support. Different causes need different repairs; calling every incident hallucination prevents diagnosis. Before restoration, the original failure and nearby variants should confirm the fix.
Responsibilities should be defined before deployment. Data owners govern sources and scope, knowledge maintainers ontologies and merges, service teams retrieval, permissions, and availability, and business owners decide which outputs may influence action. Corrections and appeals need clear entry points. Incident records can cover impact, cause, repair, verification, and prevention while restricting sensitive detail. Maturity concerns detection speed, repair speed, and recurrence control rather than claims of never failing. Traceability makes a practical contribution by decomposing a wrong answer into accountable and editable stages and helping organizations improve through evidence.