Hi — I found DevRAG while looking at MCP/RAG projects where source-grounded answers, retrieval evidence, or indexed knowledge artifacts may need evidence that survives outside the original local runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace DevRAG’s index, SQLite metadata, Qdrant collections, source hashes, CLI output, MCP responses, Claude Code skills/hooks, eval results, or normal developer workflow. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
Your repo seemed relevant because DevRAG indexes code, PRs, issues, Jira tickets, Slite pages, Slack conversations, documents, and Claude Code session logs, then exposes search through a CLI and FastMCP server. It also has retrieval eval commands and a rag-first hook that can gate exploration until DevRAG search has run.
A receipt could potentially bind selected events like:
- indexed repository/source set;
- index snapshot or refresh run;
- source collection versions;
- query string or query digest;
- retrieval result bundle hash;
- cited source IDs / file refs / PR refs / issue refs;
- answer evidence packet hash;
- eval input/output artifact hash;
- precision/recall/MRR result artifact hash;
- Claude Code session/search handoff reference;
- MCP tool name, such as
mcp__devrag__search;
- status, such as indexed, searched, evaluated, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a RAG search result bundle, source-grounded answer, retrieval-eval result, index snapshot report, or Claude Code evidence packet is handed to another agent, developer, reviewer, CI job, or downstream workflow, and they should not have to fully trust the original local DevRAG runtime, Qdrant store, or CLI logs.
BoundaryAttest would not prove the retrieved answer is correct, the index is complete, the ranking is optimal, the source interpretation is true, or that Slack/Jira/GitHub data was authorized to export. It would only prove that a specific claim about a selected RAG artifact or handoff was signed and has not been altered after export.
Does that kind of portable signed receipt fit any workflow you imagine for DevRAG, especially around source-grounded answer bundles, retrieval eval artifacts, index snapshots, or Claude Code handoffs? Or are the current index metadata, eval outputs, and MCP/CLI responses enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around RAG systems that produce source-grounded developer evidence.
Hi — I found DevRAG while looking at MCP/RAG projects where source-grounded answers, retrieval evidence, or indexed knowledge artifacts may need evidence that survives outside the original local runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace DevRAG’s index, SQLite metadata, Qdrant collections, source hashes, CLI output, MCP responses, Claude Code skills/hooks, eval results, or normal developer workflow. The receipt only proves a narrow claim:
Your repo seemed relevant because DevRAG indexes code, PRs, issues, Jira tickets, Slite pages, Slack conversations, documents, and Claude Code session logs, then exposes search through a CLI and FastMCP server. It also has retrieval eval commands and a
rag-firsthook that can gate exploration until DevRAG search has run.A receipt could potentially bind selected events like:
mcp__devrag__search;The strongest use case would be when a RAG search result bundle, source-grounded answer, retrieval-eval result, index snapshot report, or Claude Code evidence packet is handed to another agent, developer, reviewer, CI job, or downstream workflow, and they should not have to fully trust the original local DevRAG runtime, Qdrant store, or CLI logs.
BoundaryAttest would not prove the retrieved answer is correct, the index is complete, the ranking is optimal, the source interpretation is true, or that Slack/Jira/GitHub data was authorized to export. It would only prove that a specific claim about a selected RAG artifact or handoff was signed and has not been altered after export.
Does that kind of portable signed receipt fit any workflow you imagine for DevRAG, especially around source-grounded answer bundles, retrieval eval artifacts, index snapshots, or Claude Code handoffs? Or are the current index metadata, eval outputs, and MCP/CLI responses enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around RAG systems that produce source-grounded developer evidence.