GrantOS

cg-pack/1.4

What’s inside an audit pack

The audit pack is a self-contained, independently verifiable record of a grant. Everything an auditor, accountant or funder needs is in the ZIP — including the means to prove none of it has been altered. The format is versioned (see the formatVersion field in manifest.json) so a pack accepted today stays verifiable tomorrow.

Contents

  • manifest.jsonMachine-readable index: format version, who generated the pack and when, the grant summary and baseline version, every evidence file with its SHA-256 fingerprint, and the audit-chain verification result.
  • verification.txtThe integrity report. Every evidence file is re-hashed at the moment of export and marked OK, TAMPERED or MISSING against the fingerprint recorded when it was first uploaded.
  • ledger.csvEvery expense with its budget line, amount, compliance status and any rule flags (over budget, outside the grant window, possible duplicate, no receipt).
  • delivery-record.csvEvery logged activity: date, venue (and whether it was on the approved list), attendee count, and whether the entry was backdated.
  • variations.csvEvery change request with the funder's recorded decision — the written approval trail that informal email chains can't provide.
  • milestones.csvThe delivery plan with KPI targets: what was promised by when, and what was actually achieved against each target.
  • payment-schedule.csvExpected instalments and recorded receipts (present when the grant has a payment schedule): what money was due, why it releases, and what actually arrived.
  • reporting-calendar.csvThe reporting obligations and their fulfilment (present when reporting is scheduled): what was due, when, and which frozen report answered it.
  • incidents.csvThe incident register (present when incidents were recorded): what happened, when the organisation became aware, and when — and to whom — it was notified, with full timestamps.
  • repayments.csvMoney returned (present when recorded): underspend returns, clawbacks and error payments — the demand and the repayment, both as recorded facts.
  • partners.csvSub-contracted delivery partners (present when recorded), with the funder's eligibility confirmation on the record.
  • audit-trail.csvThe append-only event chain. Each event carries the hash of the one before it, so any attempt to rewrite history breaks every hash that follows.
  • evidence/Every evidence file, byte-for-byte as uploaded, filenames prefixed with the first 8 characters of their SHA-256 hash.
  • reports/Each frozen report snapshot as issued, with the hash it was sealed with.
  • README.txtOrientation for a reader who has only the ZIP — including how to verify it without this platform.

How to verify a pack independently

  1. Evidence files — compute the SHA-256 of any file in evidence/ and compare it with its entry in manifest.json. Files are write-once in the platform; a mismatch means the file was altered after upload.
  2. The audit trail — each row’s hash is SHA-256 of the previous row’s hash plus the event’s canonical JSON. Recompute the chain from the first event (which chains from the literal string genesis): if any historic record had been edited or removed, every later hash would fail.
  3. Reports — each snapshot in reports/ carries the hash it was sealed with when generated, so a report can’t be quietly rewritten after submission.
  4. Access is visible — generating a pack is itself recorded in the audit trail, so pack exports appear in the next pack’s history.

Format guarantees within version 1.x: unrecognised fields may be added (ignore safely), CSV column order is stable, and the hash construction will not change. Questions from your auditor? Privacy notice covers what the pack contains and why.