← The Machine
The record · shiplog.yml

Shiplog

Every thing this repository shipped, sealed so a stranger can re-verify it.

.github/workflows/shiplog.ymlruns @flashyos/shiplog

What it does

The workflow derives `shipped/1` from the repository’s own git history with the vendored emitter, one sealed entry per thing that reached the branch that deploys, and re-verifies every digest against the entry it claims to cover before committing.

Where a checkpoint emitter is present it rebuilds the RFC 6962 tree head in the same run, because a head emitted from its own workflow would leave a window in which the published root and the published record disagree.

The log is a generated artifact like a lockfile — regenerated and committed, never hand-edited — and `paths-ignore` covers the files it writes so the commit it makes does not trigger it again. Everything lands private; publishing is one field in `.shiplog/config.json`.

When it runs
On every push to the default branch, daily at 04:23 UTC so a quiet week still refreshes, and on demand. Pushes on other branches are skipped by a per-run default-branch gate.
What it emits
A re-emitted `shiplog.fragment.json`, a refreshed checkpoint head where one exists, and — for a published repository — the public projection at `/.well-known/shiplog.json`, written by the emitter rather than copied by a step.

What a stranger can verify

That every entry hashes to the digest on record. Re-derive the log from the same git history with `npx @flashyos/shiplog check ./fragments`; an entry whose bytes were edited would have a different digest and fail. The seal, not our word, is the evidence.

Questions

What does the Shiplog workflow produce?
A sealed shipped/1 fragment derived from the repository’s own git history — one dated, attributed, hashed entry per thing that reached the deploying branch — regenerated and committed like a lockfile, never hand-edited.
Why does it re-verify every seal on each run?
Because a seal nobody recomputes is decoration. The workflow recomputes each entry’s digest against the entry it covers, so a fragment that was edited by hand fails the run rather than being published as if it verified.
Why rebuild the checkpoint in the same run?
A tree head committed to the old log would describe a tree that no longer exists. Rebuilding it in the run that rebuilt the fragment closes the window where the published root and the published record would disagree.
The concept

A sealed shipping record is one entry per thing that reached the deploying branch — dated, attributed to the agents and humans who did it, and hashed with the same canonicalisation that seals every settlement, so a stranger can re-verify it and the cross-repository changelog is a projection of the merge.

sealed shipping record →

Keep reading

Read the workflow — it hides nothing ↗The format it keeps current: @flashyos/shiplogHow the estate stays honest — all of it
Also in the record
Estate record