Question: signed receipts for selected Fuseforks multi-agent handoffs?

[cullenmeyers]

Hi — I found Fuseforks while looking at multi-agent orchestration projects where scheduled triggers, pre-checks, agent delegation, tool outputs, MCP tool calls, conversation forks, or exported run summaries may need evidence that survives outside the original runtime.

I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:

https://github.com/cullenmeyers/BoundaryAttest

The idea is not to replace Fuseforks’ agent-core, data_contract.yaml, conversation persistence, OS keyring usage, MCP client/server support, built-in tools, work-folder boundaries, pre-check rules, village UI, public-square log, path completion, or normal local records. The receipt only proves a narrow claim:

a specific signer signed a specific claim, and the signed claim has not been altered.

Fuseforks seemed relevant because it is a desktop multi-agent orchestration app where agents can coordinate, delegate, split work, bundle results, run scheduled requests, perform pre-checks before spending tokens, use MCP, call built-in tools, preserve/fork conversations, and distinguish searched/source-backed facts from unfound facts. The README also notes that tool-use reasons are the model’s own account, not an audit record, which seems like an important boundary.

A receipt could potentially bind selected boundary events like:

• village/session/conversation reference;
• agent ID / role reference;
• scheduled trigger reference;
• pre-check command digest and match result;
• MCP tool call reference;
• built-in tool name and result hash;
• work-folder or allowed-folder reference;
• delegation / handoff / bundled-result reference;
• grounded-source references or answer artifact hash;
• conversation fork/export reference;
• public-square log excerpt hash, if relevant;
• generated summary/report hash;
• status, such as scheduled, prechecked, delegated, tool-called, bundled, answered, forked, exported, failed, or handed off;
• timestamp/event ID;
• signer/public key ID.

The strongest use case would be when a Fuseforks run summary, delegated subtask result, pre-check result, MCP/tool output, grounded answer, conversation fork, exported transcript, or bundled multi-agent artifact is handed to another agent, reviewer, CI/debugging process, project maintainer, downstream workflow, or future session, and they should not have to fully trust the original local app runtime, conversation database, public-square log, or exported summary.

BoundaryAttest would not prove the answer was correct, the agent reasoned well, the tool reason was truthful, the pre-check was sufficient, the MCP tool was safe, the work-folder boundary was complete, or the runtime was uncompromised. It would only prove that a specific claim about a selected Fuseforks artifact/action/handoff was signed and has not been altered after export.

There are a few small external interop patterns/examples here:

https://github.com/cullenmeyers/BoundaryAttest/blob/main/docs/external-interop-patterns.md

Does this kind of portable signed receipt fit any workflow you imagine for Fuseforks, especially around scheduled/pre-check runs, MCP tool calls, delegated subtask results, bundled answers, conversation forks, exported transcripts, or multi-agent handoffs? Or are the current local records, data contract, conversation persistence, tool boundaries, and app state 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 local multi-agent orchestration systems.

[betyourluck]

Hi @cullenmeyers , thanks for the detailed writeup and for reading the spec closely — the README line you quoted is accurate, and the distinction you're drawing (self-reported tool-use reasons vs. an audit record) is one we're aware of as a real boundary in the current design.

That said, right now Fuseforks is scoped as a single-village, local-first tool: conversation persistence and the plaza log both live in local SQLite, and there isn't currently a spec'd path for exporting bundled artifacts (plan results, grounded evidence, etc.) to another organization or runtime for third-party verification. Given that, a cross-boundary signing layer like BoundaryAttest doesn't have an obvious integration point yet — the "hash-only" pattern in Spec 28 (schedule_probe) is solving a different problem (an internal match check for billing/dedup) rather than portable non-repudiation.

If a concrete cross-runtime handoff use case comes up (e.g. exporting a plan bundle for external review), we'd revisit this — the scoping in your README ("not a permission engine," "not a correctness proof") is honest and would make integration easier to reason about than something with broader claims. For now we'll leave this as scope-for-later rather than a near-term item. No pressure, and thanks again for thinking about this from outside the project.

[cullenmeyers]

Thanks — this is a very helpful answer.

I agree with your framing. If Fuseforks is currently single-village/local-first, with conversation persistence and plaza logs staying in local SQLite, then there is not an obvious BoundaryAttest integration point yet.

The clarification on Spec 28 is also useful. I will not treat that hash-only schedule_probe pattern as an attestation seam, since it is solving internal matching/billing/dedup rather than portable verification across a boundary.

The possible future case you named — exporting a plan bundle or grounded evidence bundle for external review — is exactly the kind of place I would revisit later. In that case the receipt would stay narrow: bind the exported artifact/hash and selected claim, not prove correctness, permission, safety, or reasoning quality.

For now I’ll treat this as scope-for-later rather than a near-term fit. Thanks again for the careful response and for distinguishing the local design from a real cross-runtime handoff.

[betyourluck]

I just handed over the English translation generated by AI without checking it.
Sorry.

@cullenmeyers — I need to correct three factual errors in my previous reply. It was drafted with AI assistance against the wrong context, and you've already quoted two of them back, so I'd rather fix the record before it propagates.

1. Storage is redb, not SQLite. Conversation persistence lives in a single sessions.redb (a pure-Rust embedded store). We actually evaluated SQLite during design and rejected it — bundled rusqlite brings ~10 dependencies including a C library, and its default FTS tokenizer returns zero hits for Japanese. The plaza log itself isn't a database at all: it's an in-memory ring (last 5,000 messages), whose underlying conversation records are what get persisted to redb.

2. An export path does exist. export_session writes any conversation to JSONL under {workspace}/exports/ (in the spec since our session-persistence work). Bundled plan results appear in that export as ordinary messages. What I should have said: there is no dedicated export for a standalone evidence bundle (grounded sources + answer as one artifact) — that narrower statement is the true one.

3. The Spec 28 hash is a security binding, not billing/dedup. Pre-check approvals are stored as SHA-256(canonical_json({args, command, cwd, villageId})) — hashes only, so the file never becomes an inventory of runnable commands, and salted with the village's identity so a swapped-in workspace can't carry pre-approved commands with it. Nothing to do with billing. Honestly, this correction moves it slightly closer to your territory than my reply suggested: it is a locally-scoped integrity binding. It's still not an attestation seam though — it never leaves the machine and proves nothing to a third party.

The conclusion stands unchanged: single-village, local-first, and no cross-runtime handoff surface yet, so BoundaryAttest remains scope-for-later for us. But it stands on corrected facts now. Sorry for the noise, and thanks for engaging carefully enough that the errors mattered.

[cullenmeyers]

Thanks for correcting the record — that is helpful, and no worries.

The corrected facts make the boundary clearer:

• redb / sessions.redb is the local persistence layer, not SQLite;
• export_session already creates a JSONL export under {workspace}/exports/;
• Spec 28 is a local security/integrity binding around pre-check approvals, not billing/dedup.

That last point is especially useful. I agree it moves closer to BoundaryAttest conceptually, but still stays on the local side of the line: it binds approved command context inside the same machine/village, while BoundaryAttest would only become relevant if a selected claim or artifact needed to leave that local trust boundary and be verified elsewhere.

So I think the conclusion still makes sense:

local integrity binding / local export = current Fuseforks scope
portable third-party attestation = scope-for-later unless a real cross-runtime handoff appears

The future case I’d watch for is the narrower one you named: a dedicated evidence or plan bundle, such as grounded sources + answer + plan result, exported for external review. That would be a much cleaner seam than trying to sign normal conversation persistence or internal pre-check state.

Thanks again for taking the time to correct the details. This is actually a useful distinction for BoundaryAttest too: not every hash or local integrity check is an attestation boundary.