Question: signed receipts for audit evidence / delivery package handoffs?

[cullenmeyers]

Hi — I found AuditPilot while looking at audit/evidence workflow projects where delivery packages, evidence graphs, evaluation results, or human-review artifacts 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, artifacts, or handoffs that cross trust boundaries:

https://github.com/cullenmeyers/BoundaryAttest

The idea is not to replace AuditPilot’s audit workspace, agent runtime, RAG evidence retrieval, Skills/MCP-style tools, evidence graph, evaluation harness, human review, remediation workflow, RBAC, tenant isolation, audit events, SQLite records, or delivery verification. 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 AuditPilot is built around enterprise audit delivery: evidence retrieval, control/risk/compliance workflows, tool execution, human review, evaluation gates, evidence graphs, delivery packages, remediation loops, and privacy-friendly task trace packages.

A receipt could potentially bind selected events like:

• audit project / workspace reference;
• control matrix or audit procedure reference;
• evidence bundle hash;
• evidence graph snapshot hash;
• tool/Skill call result digest;
• RBAC / tenant / permission-check result reference;
• evaluation harness result hash;
• release-gate pass/fail result;
• human review / intervention decision;
• remediation or corrective-action artifact hash;
• delivery package hash;
• audit event / hash-chain reference;
• status, such as evidence-collected, gap-found, reviewed, blocked, passed-gate, delivered, remediated, or handed off;
• timestamp/event ID;
• signer/public key ID.

The strongest use case would be when an audit delivery package, evidence bundle, evaluation result, remediation record, control-test output, or review-ready report is handed to another auditor, client, reviewer, regulator, downstream system, or later audit process, and they should not have to fully trust the original local AuditPilot runtime or database.

BoundaryAttest would not prove the audit conclusion is correct, the evidence is complete, the control test is sufficient, the recommendation is compliant, or the human review was wise. It would only prove that a specific claim about a selected audit 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 AuditPilot, especially around evidence bundles, delivery packages, evaluation/release gates, human-review decisions, or audit/export handoffs? Or are AuditPilot’s current audit records, hash-chain events, evidence graph, and delivery verification 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 audit/evidence delivery systems.

[Ricky-7-Yan]

Hi @cullenmeyers — thanks for the thoughtful and carefully scoped question. I agree with the distinction you are making between internal auditability and portable attestations across trust boundaries.​
AuditPilot’s current mechanisms primarily operate within a single AuditPilot deployment and trust domain. We have tamper-evident SHA-256-linked audit events, evidence lineage, evaluation and release gates, delivery verification, and package-level integrity digests. These mechanisms help reconstruct activity and detect modification inside the system, but they do not currently provide an externally verifiable signer identity once an artifact has been exported from the original runtime or database.​
Because of that, I do see portable signed receipts as potentially complementary rather than redundant—particularly as an optional export and handoff layer.

[cullenmeyers]

Thanks — that distinction is exactly what I was trying to test.

Your description makes sense to me: AuditPilot’s SHA-256-linked audit events, evidence lineage, evaluation/release gates, delivery verification, and package-level integrity digests are the right mechanisms inside a single AuditPilot deployment and trust domain.

The place BoundaryAttest seems potentially useful is narrower: when an evidence bundle, delivery package, evaluation result, review artifact, or export leaves that original runtime/database and someone outside the deployment needs a portable signer-bound artifact.

So I agree it should be complementary and optional, not a replacement for AuditPilot’s internal auditability.

The claim should probably stay focused on the export/handoff, for example:

audit project/workspace ref
evidence bundle hash
evidence graph snapshot hash
evaluation/release gate result
delivery package hash
audit event/hash-chain ref
timestamp/event ID
signer/public key ID

And the limits should stay explicit: the receipt would not prove the audit conclusion is correct, the evidence is complete, or the control test is sufficient. It would only prove that a specific claim about a selected exported artifact or handoff was signed and has not been altered.

Thanks again — this is helpful validation of the optional export/handoff layer direction.