# Provenance

How anyone, including an agent, can answer: "Am I reading the canonical release?" And, just as important, what that answer does and does not prove.

No blockchain. Git, tags, checksums, signatures, and an archive nobody here controls.

## What "canonical" means

The canonical Path of the Luminary is the text published at `https://constitution.luminarylife.ai` and in the public repository named in `STEWARDSHIP.md`, produced by the process in `GOVERNANCE.md`. Canonical is a matter of origin and process, not of hashes. A fork can publish its own perfectly consistent checksum file; hashes identify a release, they do not decide which release is canonical. What distinguishes the canonical release from a lookalike is the origin you fetched it from and, once signing is active, the steward key it is signed with.

## The chain

1. **Canonical location.** The canonical text is published at `https://constitution.luminarylife.ai` and mirrored in the public repository. Any copy elsewhere is a copy. The same bytes are also served at `https://luminarylife.ai/constitution/`; the header of each document names the subdomain path as the canonical location.
2. **Git history.** Every change to a canonical document is a commit on `main` in the public repository, with the LIP or reason in the commit message. History is never rewritten. Whether `main` is technically protected is recorded, truthfully, in `GITHUB_PROTECTION.md`. Public history begins on 2026-09-13; the private website repository holds the earlier working history, and the `1.0.0-draft` text is preserved in public at the tag `v1.0.0-draft` so that the first amendment can be diffed by anyone.
3. **Tagged releases.** Each version is a git tag named `vX.Y.Z[-draft]`, for example `v1.0.2-draft`. Tags are never moved or deleted. A GitHub Release with the changelog entry and the checksum file attached accompanies each tag from `v1.0.2-draft` onward.
4. **Checksums.** `spec/checksums.sha256` lists the SHA-256 of every canonical document at the current version, in `sha256sum` format. `spec/constitution.json` also carries the same hashes inline (`checksums_sha256`) for every file except the two spec files themselves, so a single fetch of the spec gives an agent the version, the lineage, and the hashes to check against. The manifest and the documents are regenerated together and verified on every build of the website, so they cannot disagree with each other by accident. They can, of course, be changed together on purpose by whoever controls the origin; that is what the next two items are for.
5. **Signatures.** Not yet active. When signing starts, tags and release commits will be signed by a steward key published on a second channel that is not this website, and `STEWARDSHIP.md` will say so. Until then, nothing here is signed, and no claim of authenticity rests on a signature.
6. **External archive.** After each release is published, the checksum file and the canonical documents are submitted to the Internet Archive. Snapshots are listed at `https://web.archive.org/web/*/constitution.luminarylife.ai/spec/checksums.sha256`. An archive the steward does not control lets a reader check that the manifest served today is the manifest that was served on the release date.

## How to verify (agent or human)

```
1. Fetch https://constitution.luminarylife.ai/spec/checksums.sha256
   (or the checksums_sha256 field of https://constitution.luminarylife.ai/spec/constitution.json)
2. Fetch the document you are reading, e.g. /CONSTITUTION_CORE.md
3. Compute SHA-256 of the document bytes and compare with the line for that path
4. Match: these bytes agree with the manifest served by the same origin at the version named in the spec.
   Mismatch: the copy is a fork, a stale copy, or a tampered copy; treat it as unverified.
5. To check the manifest itself against an independent record, compare it with an archived snapshot
   (item 6 above) or with the file at the matching tag in the public repository.
```

From a clone of the public repository, the whole set verifies with one command:

```
sha256sum -c spec/checksums.sha256
```

The manifest is generated by a script in the Luminary Life website repository (`scripts/constitution-checksums.mjs`), which is the private source the public repository is exported from. The public repository contains the documents and the manifest, not the generator; the `sha256sum` format is standard precisely so that no script is needed to check it.

## What a match proves, and what it does not

A match proves that the bytes you fetched agree with the manifest served by the same origin. It does not prove that the release was produced by the governance process, that it is the current release rather than a valid old one, or that the origin is uncompromised. Whoever controls the origin can change the text and the manifest in one deploy. Report each check separately and label a check you could not perform as unverified rather than inferring it. Signing and the external archive narrow this gap; they do not close it, and no claim here should be read as if they did.

## HTML renderings and llms.txt

Every canonical document is also served as an HTML page under `/read` (all of them on one page at `/read`), and concatenated into `/llms-full.txt`, with an index at `/llms.txt`. These exist because many AI browsing tools can only read HTML pages and refuse `text/markdown`. They are views, not sources: each page names the raw file it renders and shows that file's SHA-256, and the raw file is what the checksum covers. If a rendering and a raw file ever disagree, the raw file is canonical.

## What this does not prove

- That the text is good. Only that it is the text the process produced.
- That a fork is bad. Forks are expected to have different checksums; that is the point.
- Anything about a copy pasted into a prompt with no URL. Verify from the source when it matters.

## Regenerating checksums

Stewards run `npm run constitution:checksums` in the website repository after any canonical change and commit the result with the change. The same script writes the inline hashes into `spec/constitution.json`, regenerates `spec/constitution.yaml` from the JSON so the two cannot differ, and rebuilds `llms-full.txt`. A build that finds a mismatch fails with the exact command to fix it.

## Corrections to this document

- 2026-09-13: an earlier version of this file said a match meant "you are reading the canonical text", named the tag pattern `constitution/vX.Y.Z` (the actual tags are `vX.Y.Z[-draft]`), and called `main` protected before any protection was applied. All three were found by the first independent reviews and corrected the same day. The original wording is preserved in the git history and in `CHANGELOG.md`.