For auditors

This page is written for the person checking the evidence, not the team producing it. It sets out what a Slipmark record proves, what it does not, and how to check it without taking our word for it.

What a record proves

Each record in the ledger is one CI run. For each verdict in that run, it shows that:

• an agent with the stated name gave the stated verdict (for example pass or cleared);
• the verdict was about files with these exact SHA-256 hashes;
• at the stated commit, those files still had exactly those hashes, or did not, in which case the verdict was refused;
• the record was sent by that repository's own GitHub Actions workflow. Slipmark Cloud only accepts a record with a GitHub-signed OIDC token, and the token, not the request, decides which repository, commit, workflow run and pull request the record belongs to.

Re-verified against GitHub

Slipmark Cloud does not rely on CI's report alone. Where the Slipmark GitHub App is installed, it reads the attestation files and every attested file from GitHub's own copy of the commit, re-hashes them and works out each verdict's status itself, with the same rules as the open-source gate. Checks, rules and evidence use that result. If CI reported verdicts that GitHub's copy does not support, the Slipmark check fails with “CI reported verdicts GitHub's copy doesn't support”. A workflow edited to fake a pass is caught this way.

Proof pages show “Re-verified against GitHub” when this happened. For very large commits (a file tree too big for GitHub to list in full, more than 200 attestation files, or more than 600 attested files) Slipmark falls back to CI's report and the record says so.

What a record does not prove

• That the verdict was right. Slipmark proves which files a verdict was about. It does not judge the quality of the review.
• That the named agent wrote an unsigned attestation. Unsigned, the agent name is whatever the file says, and anyone who can write to the attestation folder can write one. If the team uses signed verdicts, each verdict carries a Sigstore signature naming the workflow that gave it, logged in the public Rekor log, and Slipmark Cloud checks every signature itself. The proof record and the pack show the signer next to the agent. Ask which workflow they trust, and check it runs from a protected branch. Without signatures, look at who committed attestation files, and expect .slipmark/attestations/ and .github/workflows/ to be protected with CODEOWNERS and branch protection.
• That every change was reviewed. Only files covered by a rule, or listed as required in the workflow, must carry a verdict. The pack shows which rules were in force and when they changed.

Why the record cannot be quietly changed

Append-only. The database rejects any update or delete of a ledger entry, whoever asks. Someone with full control of the database could remove that safeguard, which is why the chain and the public anchors below exist.

Hash-chained. Each entry's hash is the SHA-256 of the previous entry's hash and the entry's own contents. Changing, removing or reordering any entry changes every hash after it. The account log, which holds rule changes and overrides, is chained the same way. Every evidence pack recomputes both chains when it is generated and states whether they are intact.

Publicly anchored. Once a day we take the latest hash of every ledger and account log, sign a document listing them, and publish its digest to Rekor, Sigstore's public transparency log. Rekor is run independently of us and is itself append-only. Records older than the latest daily anchor can't be rewritten without it showing, not even by us. If a day's publish to Rekor fails, that anchor is listed as “not logged” rather than hidden.

Stored alongside the chain. Rule results and re-verification results are also append-only: they cannot be edited or deleted. They are stored next to the hash chain, not inside it, so the chain check and the anchors cover the runs, not these results.

• Our public key (ECDSA P-256): /anchors/public-key.pem
• Every anchor, with its Rekor log index and a Verify in your browser button: /anchors

What is in an evidence pack

Evidence packs are part of the Business plan. Each covers one repository and one period, and includes:

• a summary of runs, verdicts and agents;
• every run in the period (up to 2,000; pick a shorter period for more), each with its verdicts, file hashes, Slipmark Cloud's own gate result, ledger entry number, prev_hash, entry_hash and the exact ledger_payload;
• the result of each organisation rule on each run;
• the rules in force on the first day of the period, replayed from the account log, and every rule change during the period, by whom and when;
• the exceptions report: every override, by whom, when and why;
• the chain check for the ledger and the account log;
• the anchor match: the first anchor published after the end of the period that includes the repository (or the latest, if none has been published yet), the repository's anchor id, and a check that today's ledger has the anchored hash at the anchored entry number.

The pack downloads as a PDF with the JSON attached inside it, and the SHA-256 of that JSON printed on the first page, so one file carries both the readable record and the data to check it. The JSON also downloads on its own.

Auditor links

Instead of emailing files back and forth, an admin can give you a private link from the Evidence tab. It opens one repository's pack for one period, read-only, with the PDF and JSON downloads, and needs no GitHub account. The team chooses how long it lasts (7, 30 or 90 days) and can end it at any time. Creating it, ending it and every visit are recorded, so there's a record of exactly what was shared with you and when you opened it.

How to check it yourself

1. Get the pack. Ask the team for the evidence pack PDF for the period. Open its attachments (in most PDF readers, the paperclip panel) to get the JSON, and check its SHA-256 matches the one on page 1.

2. Recompute the chain. For each run in the JSON, recompute each entry from prev_hash and the payload:

   entry_hash = SHA-256( prev_hash + "\n" + ledger_payload )

   ledger_payload is serialised as PostgreSQL jsonb text: keys in PostgreSQL's canonical order, with ", " between items and ": " between a key and its value. The result should equal entry_hash, and each entry's prev_hash should equal the entry_hash of the entry before it.

3. Hash a file yourself. Pick any verdict and hash the file at the recorded commit. For a pull request run, the recorded commit is GitHub's merge commit, so fetch it first:

   git fetch origin refs/pull/<N>/merge
   git show <sha>:<path> | sha256sum

   For a verified verdict the result matches the hash in the pack.

4. Check the anchor. The pack names an anchor number. On /anchors, choose Verify in your browser for that anchor. It checks the document's digest, our signature and the Rekor entry. To do it by hand:

   • Download /anchors/<N>.json. Keep the exact bytes. The signature is in the x-slipmark-signature response header, base64-encoded DER ECDSA P-256 over those bytes.
   • Check the SHA-256 of the file equals the digest in the Rekor entry. Look the entry up by its log index at search.sigstore.dev, which also shows when it was logged.
   • Decode the header from base64 into sig.der and check it with our public key, for example openssl dgst -sha256 -verify public-key.pem -signature sig.der N.json.
   • Find the repository's anchor id in the document (the pack gives it). The head hash and entry number listed there should match the pack's anchor check. If they do, every record up to that entry existed in that form on that day.

Which controls it supports

An evidence pack is evidence. It does not make anyone compliant, and the auditor decides what it demonstrates. Teams commonly use it to support change-management controls such as:

Questions from an auditor are welcome at hello@replyintelligencegroup.co.uk.