Hi, design question on the provenance layer, framed against the README's own line:
every wiki claim links back to the source messages that produced it, so answers are auditable all the way down to the original Slack/Discord/Teams thread
Chat-message anchors are a different surface from the file-based "agent-wiki" cohort, but the provenance-depth question is the same shape: how deep does the link go, and what happens when the source mutates under the distilled claim?
A few converging public repos are landing on similar verifier scaffolding here: skyllwt/OmegaWiki, atomicstrata/llm-wiki-compiler, yologdev/yopedia (whose SCHEMA.md has a "Provenance depth evaluation" section adopting hybrid {raw_offset, quote_hash} anchors), and dheerapat/pi-kb (workspace-disposal keyed on hash-based dedup). Sketch of the hybrid anchor shape: https://gist.github.com/kiluazen/727948f9517eacd665d21199e8318da1
The actual question: how is the wiki-claim -> source-message link stored today in Atlas? Bare message_id, or something like {message_id, quote_hash} (or a span offset into the message text) so the link survives an edit or soft delete on the source side? Chat is interesting because the source is mutable in ways files often aren't, and the 6-stage ADK distillation makes the gap between distilled fact and current message easy to lose track of.
Follow-on, on the QA agent: the "falling back to raw messages only when a fact hasn't been distilled yet" path, is the fallback trigger (a) no wiki page above retrieval threshold, or (b) a wiki page exists but a freshness check between the distilled claim and its source messages failed? Curious which signal is load-bearing today.
-Kushal (https://kushalsm.com)
Hi, design question on the provenance layer, framed against the README's own line:
Chat-message anchors are a different surface from the file-based "agent-wiki" cohort, but the provenance-depth question is the same shape: how deep does the link go, and what happens when the source mutates under the distilled claim?
A few converging public repos are landing on similar verifier scaffolding here:
skyllwt/OmegaWiki,atomicstrata/llm-wiki-compiler,yologdev/yopedia(whoseSCHEMA.mdhas a "Provenance depth evaluation" section adopting hybrid{raw_offset, quote_hash}anchors), anddheerapat/pi-kb(workspace-disposal keyed on hash-based dedup). Sketch of the hybrid anchor shape: https://gist.github.com/kiluazen/727948f9517eacd665d21199e8318da1The actual question: how is the wiki-claim -> source-message link stored today in Atlas? Bare
message_id, or something like{message_id, quote_hash}(or a span offset into the message text) so the link survives an edit or soft delete on the source side? Chat is interesting because the source is mutable in ways files often aren't, and the 6-stage ADK distillation makes the gap between distilled fact and current message easy to lose track of.Follow-on, on the QA agent: the "falling back to raw messages only when a fact hasn't been distilled yet" path, is the fallback trigger (a) no wiki page above retrieval threshold, or (b) a wiki page exists but a freshness check between the distilled claim and its source messages failed? Curious which signal is load-bearing today.
-Kushal (https://kushalsm.com)