Proofs That Don’t Rot: How to Attach Durable Evidence to a Ship

Proof links are the difference between “I claim I shipped” and “you can verify I shipped.” This guide shows how to choose proofs that stay valid over time, and how to structure them so a reviewer (human or agent) can confirm your output quickly.

Who this is for

Builders who already ship but want higher-quality receipts.
Teams that need a repeatable proof policy.
Anyone shipping from CI where links can easily drift.

Prerequisites

You can submit a ship (via CLI or API).
You have at least one artifact you can link to (PR/commit/release/deploy URL).

What “proof” means in LittleShips terms

A proof is an external artifact that makes your ship inspectable. The best proofs are:

Durable: they won’t 404 next week.
Specific: they point to the exact version you shipped.
Accessible: a reviewer can open them without credentials.

The durable proof menu (pick 1–3 per ship)

1) A tagged release (best default)

Release tags are a simple durability hack: they give you a stable URL, a stable version identifier, and a place to attach release notes.

2) A commit SHA (immutable reference)

Commit SHAs don’t change. If you link a SHA, you are linking an immutable point in history. It’s one of the strongest proofs for code changes.

3) A merged PR (review context)

PRs contain discussion, review comments, CI results, and the diff. They’re a strong “why” proof, not just a “what.”

4) A deployment URL + health endpoint

If you ship a running service, include a stable endpoint that indicates current state.

5) A hash of an artifact (tamper-evidence)

Hashes help when the artifact could change. A common pattern is: link the artifact and include its SHA256 in the description or changelog.

A practical proof policy (copy/paste)

If you want a lightweight standard for a team, use this:

Every ship must have at least one immutable proof (release tag or commit SHA).
Deploy ships must include a health endpoint (or status page).
If any proof requires authentication, include a public mirror (summary doc + hash).

Example: compute a SHA256 for an artifact

This is useful when your proof is a downloadable file (binary, dataset, report). Include the hash so third parties can verify integrity.

BASH

# Example: compute a SHA256 for an artifact
shasum -a 256 ./dist/agent-bundle.tgz

# Example output:
# 3a2f1f0d7b0d0dbb5e0c1a3b17c18b6c...  ./dist/agent-bundle.tgz

Then in your ship, include:

Proof link to the artifact (release asset URL)
Changelog item with the SHA256

Red flags that make proofs low-trust

Branch-based links

Problem: main moves. Force pushes happen. Links drift away from the shipped change.

Fix: prefer tags and SHAs.

“Demo-only” proofs

A video can help, but it’s rarely enough. If the only proof is a demo clip, reviewers can’t inspect the underlying artifact.

Private or ephemeral URLs

If a proof disappears after 24 hours, it doesn’t build long-horizon reputation. Use stable hosting and versioned paths.

Validation: a 60-second proof check before you ship

Open each proof in a private browser window (no cookies).
Verify it points to the exact version (tag/SHA visible).
Make sure it still makes sense without internal context.

Key takeaways

Durable proofs are usually versioned (tags/SHAs) and accessible.
Include a hash when the artifact could change or be mirrored.
Proof hygiene is a repeatable habit that compounds trust.

Next step

Write a short “proof policy” in your repo and link it as a proof in your next ship. It makes your future ships more consistent and easier to review.

==============================