# Search, sources and corrections A useful answer is more than a confident sentence. You need the memories behind it, enough context to judge them and a clear distinction between what is current and what used to be true. ## Ask about the work, not the whole company {#search} Give Korium a focused question. Name the project, decision or problem and add a scope when you know it. Two small searches often work better than one sentence containing every topic you can think of. ``` Search Korium under billing.refunds. Why did we keep the existing provider? Show the decision, the rejected alternative and the supporting test. ``` If the result is weak, try the actual names your team used. A missing result is not proof that nobody ever made the decision. Check the scope, the terminology and whether the connection is reading the right workspace. ## Read the memories behind the answer {#evidence} Ask the assistant to identify the source memories and distinguish a recorded decision from its own interpretation. Follow the source link when the decision carries risk. A summary is useful for orientation, but it does not replace the evidence. `korium_browse` helps when you want a filtered list instead of a search. `korium_trace` follows links from a particular memory so you can inspect what supported it or what came after it. ## Correct something without erasing what happened {#correct} First find the old memory and keep its ID. Then write the correction, explain why it changed and link the new memory to the one it supersedes. The new statement and the old record have different jobs. ``` Find the release-check decision in Korium. We changed it in today's review: the data owner and the release owner must both approve the totals. Save that correction with the review as evidence, and link it as superseding the old decision. Show both memory IDs and confirm the link succeeded. ``` Where the capture interface supports attached relations, Korium can write the memory and its relation in the same transaction. If your client only offers separate capture and relation calls, verify both results. A successful capture by itself does not prove the replacement link exists. Keep a disagreement as a disagreement until somebody resolves it. Use a contradiction link when two statements conflict; don’t mark one superseded just because it is older. ## Ask whether you want today’s answer or the history {#current} “What should we do now?” and “Why did we change?” are different questions. For current guidance, ask for the latest applicable decision and check its replacement chain. For a review, ask to see the earlier decisions too. A superseded memory is not necessarily wrong. It may describe exactly what was right at the time. That is why the old end of the chain can be the answer when you are investigating how the work changed. ``` Trace the decisions that led to the current release rule. Separate the current rule from the earlier rules, and explain the evidence for each change. ``` ## Fix labels without rewriting the record {#names} Agent names and work phases are recorded at capture time. Use `korium_list_provenance` to find misspellings or names that changed. An administrator can use `korium_set_provenance_alias` to change how a name is displayed without rewriting the original memory. This is different from correcting a fact. An alias fixes the label. A correction records new knowledge and its relationship to what came before. ## Check whether memory is helping {#quality} Pick a real task someone else has to continue. Can they find the reason for the decision, see the evidence and identify what is still open? If they need the original chat to understand the memory, add the missing context. Keep the useful result, the failures and the rejected alternatives. Don’t inflate confidence because a save succeeded. Storage proves a record exists, not that its contents are true. ## Check the scope before concluding there is nothing {#scope-check} A capture uses exact filing paths. A search can use a pattern. Searching `billing` does not mean “billing and every project below it.”
Search scopeWhat it asks for
billingThat exact path.
billing.*Billing and paths beneath it.
*The whole tree visible to your authorized connection.
If a known decision is missing, compare the saved scope with your filter. Widen the search only within material you are allowed to read. A scope is not a private compartment or a permission grant. ## Follow one correction all the way through {#worked-correction} This continues the [onboarding demonstration](getting-started.html#correction). The UUIDs below are invented; replace them with the IDs your own calls returned. The first record says the data owner checks totals, and the new record adds the release owner. 1. Search for the original and inspect its content and source. Keep its ID. 2. Capture the new example as a correction. Keep the exercise label, the changed rule and its reason. Do not put a fictional approver in the provenance. 3. Check the new capture receipt. If the save failed, stop here. 4. When using separate calls, link the new ID to the old ID with `supersedes`. 5. Trace the new ID and confirm the edge reaches the original. Open a fresh chat and ask for the current rule. The separate relation request is: ``` { "source_id": "22222222-2222-4222-8222-222222222222", "target_id": "11111111-1111-4111-8111-111111111111", "relation_type": "supersedes" } ``` Then call `korium_trace`: ``` { "thought_id": "22222222-2222-4222-8222-222222222222", "direction": "both", "max_depth": 2 } ``` Check the returned IDs, direction and relation type rather than expecting a particular count or display order. If the new memory saved but the link failed, report “correction saved; replacement link not confirmed.” Do not save another copy as a substitute for repairing the link. The later answer should require both reviewers and cite the new memory. The trace should preserve why the original rule existed. If ordinary search misses an older record, use history inspection rather than assuming it was deleted; [expiry and supersession affect current results](how-memory-works.html#stale). ## When the result is incomplete {#incomplete} A partial result can still help, but it cannot support “we have no record of that” on its own. Show which source memories were found and the limit reported by the service. The [response examples](tool-reference.html#search-response) distinguish incomplete search from missing related-entity context. Retry the affected read once if appropriate, check the exact scope and compare with browsing. Keep the original capture ID when reporting a processing problem. Repeated captures create duplicates; they do not repair a search path.