[NGI TALER] Milestone 3 — Evidence bundle and offline verifier

[safal207]

Goal

Make ProofPath payment-guard decisions portable, tamper-evident, and verifiable without trusting a live service.

Deliverables

• Hash-chained audit log improvements.
• Portable evidence bundle format.
• Offline evidence verifier.
• Deterministic fixtures for reviewer testing.
• Documentation for privacy-aware evidence export.

Acceptance checks

• Evidence can be exported from local decisions.
• Exported evidence can be verified offline.
• Tampered evidence fails verification.
• Evidence avoids unnecessary personal/payment data.

Grant context

Application: 2026-08-00b
Fund: NGI TALER
Reviewer docs: docs/AGENT_PAYMENT_GUARD_DEMO.md

[marywang-aiops]

For the offline verifier, I would keep the first bundle format intentionally small and fixture-driven.

A minimum useful evidence bundle could be:

proofpath-evidence/
  manifest.json
  decisions.jsonl
  hash-chain.json
  verifier-result.json
  privacy-report.json
  README.md

Where:

• manifest.json records bundle id, schema version, app version, generated_at, file hashes, and verifier version expected;
• decisions.jsonl contains one payment-guard decision per line with stable ids and redacted/minimized fields;
• hash-chain.json records chain head, genesis/null marker, and per-record hash links;
• privacy-report.json states which personal/payment fields were omitted, redacted, hashed, or retained;
• verifier-result.json separates signature_or_hash_valid, chain_complete, tamper_detected, and privacy_boundary_valid.

I would add four deterministic fixtures before building more surface area:

1. valid bundle verifies offline;
2. changed decision field breaks the hash chain;
3. deleted middle record breaks continuity;
4. unnecessary personal/payment field causes privacy-boundary failure even if the hash chain is otherwise valid.

That gives grant reviewers a simple story: the evidence is portable, tampering is detectable, and the export does not require trusting the live service or exposing more payment data than necessary.

[safal207]

Thanks — I like this direction. Keeping the first offline-verifier bundle small and fixture-driven makes the milestone much easier to review and harder to over-engineer.

I propose we treat this as the v0.1 bundle contract:

proofpath-evidence/

• manifest.json
• decisions.jsonl
• hash-chain.json
• verifier-result.json
• privacy-report.json
• README.md

For v0.1, the core verifier should answer only a few concrete questions:

1. Is every file declared in manifest.json present and hash-matching?
2. Is the decision chain complete from genesis/null marker to chain head?
3. Does changing a decision field break verification?
4. Does deleting a middle record break continuity?
5. Does the privacy report confirm that unnecessary personal/payment data was omitted, redacted, hashed, or explicitly justified?

I also agree with the four deterministic fixtures:

• valid bundle verifies offline;
• modified decision field fails hash-chain verification;
• deleted middle record fails continuity;
• unnecessary personal/payment field fails the privacy-boundary check even if the hash chain remains valid.

That gives reviewers a simple story: the evidence bundle is portable, tamper-evident, offline-verifiable, and privacy-minimized. I will keep the implementation intentionally boring: schema + fixtures + CLI verification output, before adding any extra surface area.

A useful next step could be to add a /fixtures directory and a README section that explains the reviewer flow: export bundle → run verifier → inspect verifier-result.json → confirm privacy boundary.

[marywang-aiops]

I opened a small first-pass PR for the fixture contract here: #164

I kept it intentionally narrow: a fixtures/evidence-bundle-v0.1/README.md that captures the v0.1 bundle shape, reviewer flow, verifier questions, fixture matrix, and stable result-code candidates. No fake sample data or implementation claims yet.